Logback thread pool
I use Logback for logging and I have a question.
I use AsyncAppender with ConsoleAppender.
When application starts it creates thread pool with "logback-" thread names.
All logging work is completed by "AsyncAppender-Worker-" thread.
For what purpose thread pool with "logback-" thread names was created and what work does it do?
java logging logback
add a comment |
I use Logback for logging and I have a question.
I use AsyncAppender with ConsoleAppender.
When application starts it creates thread pool with "logback-" thread names.
All logging work is completed by "AsyncAppender-Worker-" thread.
For what purpose thread pool with "logback-" thread names was created and what work does it do?
java logging logback
add a comment |
I use Logback for logging and I have a question.
I use AsyncAppender with ConsoleAppender.
When application starts it creates thread pool with "logback-" thread names.
All logging work is completed by "AsyncAppender-Worker-" thread.
For what purpose thread pool with "logback-" thread names was created and what work does it do?
java logging logback
I use Logback for logging and I have a question.
I use AsyncAppender with ConsoleAppender.
When application starts it creates thread pool with "logback-" thread names.
All logging work is completed by "AsyncAppender-Worker-" thread.
For what purpose thread pool with "logback-" thread names was created and what work does it do?
java logging logback
java logging logback
asked yesterday
Artiom Saidanov
436
436
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The short answer
These threads are used for all other work logback needs to do in the background - time-based rollovers, socket appenders, async SMTP appenders etc.
A slightly longer answer
By running a search on "logback-" over the logback codebase, I found only a single place where it's used: ExecutorServiceUtil
.
This helper class is used for creating executor services (accessed only by Contextbase.getScheduledExecutorService()
), and by tracking its usages I found these usages:
- Time-based rollover will asynchronously compress (if compression is enabled) and cleanup old archives. I assume this is because compressing old files on the application thread would be a bad thing.
- Socket appenders have a connector thread that reconnects if the connection fails, and have an async message buffer that is being processed by the background thread.
- A SMTP appender can be asynchronous if configured that way - then it will use the background executor, too.
This is an exhaustive list. Note that all these are read from the source code. The time-based rollover, while it makes absolute sense to be asynchronous, is not documented to be, and could therefore change. The socket appender and the SMTP appender are documented to use a background thread.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53944821%2flogback-thread-pool%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The short answer
These threads are used for all other work logback needs to do in the background - time-based rollovers, socket appenders, async SMTP appenders etc.
A slightly longer answer
By running a search on "logback-" over the logback codebase, I found only a single place where it's used: ExecutorServiceUtil
.
This helper class is used for creating executor services (accessed only by Contextbase.getScheduledExecutorService()
), and by tracking its usages I found these usages:
- Time-based rollover will asynchronously compress (if compression is enabled) and cleanup old archives. I assume this is because compressing old files on the application thread would be a bad thing.
- Socket appenders have a connector thread that reconnects if the connection fails, and have an async message buffer that is being processed by the background thread.
- A SMTP appender can be asynchronous if configured that way - then it will use the background executor, too.
This is an exhaustive list. Note that all these are read from the source code. The time-based rollover, while it makes absolute sense to be asynchronous, is not documented to be, and could therefore change. The socket appender and the SMTP appender are documented to use a background thread.
add a comment |
The short answer
These threads are used for all other work logback needs to do in the background - time-based rollovers, socket appenders, async SMTP appenders etc.
A slightly longer answer
By running a search on "logback-" over the logback codebase, I found only a single place where it's used: ExecutorServiceUtil
.
This helper class is used for creating executor services (accessed only by Contextbase.getScheduledExecutorService()
), and by tracking its usages I found these usages:
- Time-based rollover will asynchronously compress (if compression is enabled) and cleanup old archives. I assume this is because compressing old files on the application thread would be a bad thing.
- Socket appenders have a connector thread that reconnects if the connection fails, and have an async message buffer that is being processed by the background thread.
- A SMTP appender can be asynchronous if configured that way - then it will use the background executor, too.
This is an exhaustive list. Note that all these are read from the source code. The time-based rollover, while it makes absolute sense to be asynchronous, is not documented to be, and could therefore change. The socket appender and the SMTP appender are documented to use a background thread.
add a comment |
The short answer
These threads are used for all other work logback needs to do in the background - time-based rollovers, socket appenders, async SMTP appenders etc.
A slightly longer answer
By running a search on "logback-" over the logback codebase, I found only a single place where it's used: ExecutorServiceUtil
.
This helper class is used for creating executor services (accessed only by Contextbase.getScheduledExecutorService()
), and by tracking its usages I found these usages:
- Time-based rollover will asynchronously compress (if compression is enabled) and cleanup old archives. I assume this is because compressing old files on the application thread would be a bad thing.
- Socket appenders have a connector thread that reconnects if the connection fails, and have an async message buffer that is being processed by the background thread.
- A SMTP appender can be asynchronous if configured that way - then it will use the background executor, too.
This is an exhaustive list. Note that all these are read from the source code. The time-based rollover, while it makes absolute sense to be asynchronous, is not documented to be, and could therefore change. The socket appender and the SMTP appender are documented to use a background thread.
The short answer
These threads are used for all other work logback needs to do in the background - time-based rollovers, socket appenders, async SMTP appenders etc.
A slightly longer answer
By running a search on "logback-" over the logback codebase, I found only a single place where it's used: ExecutorServiceUtil
.
This helper class is used for creating executor services (accessed only by Contextbase.getScheduledExecutorService()
), and by tracking its usages I found these usages:
- Time-based rollover will asynchronously compress (if compression is enabled) and cleanup old archives. I assume this is because compressing old files on the application thread would be a bad thing.
- Socket appenders have a connector thread that reconnects if the connection fails, and have an async message buffer that is being processed by the background thread.
- A SMTP appender can be asynchronous if configured that way - then it will use the background executor, too.
This is an exhaustive list. Note that all these are read from the source code. The time-based rollover, while it makes absolute sense to be asynchronous, is not documented to be, and could therefore change. The socket appender and the SMTP appender are documented to use a background thread.
answered yesterday
Petr Janeček
29.8k890124
29.8k890124
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53944821%2flogback-thread-pool%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown