Scala Logging: is LazyLogging blocking or non-blocking?
I recently read this article that makes me wonder whether using LazyLogging would create a performance bottleneck.
My question: is Scala Logging's LazyLogging trait blocking or non-blocking?
We log and process a lot of messages and use Akka. So does having just lazy loggers help or hurt when it comes to performance?
scala
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
add a comment |
I recently read this article that makes me wonder whether using LazyLogging would create a performance bottleneck.
My question: is Scala Logging's LazyLogging trait blocking or non-blocking?
We log and process a lot of messages and use Akka. So does having just lazy loggers help or hurt when it comes to performance?
scala
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
scala-logging is not related to Akka, btw, they are different libraries.
– Vladimir Matveev
Nov 14 '18 at 21:12
add a comment |
I recently read this article that makes me wonder whether using LazyLogging would create a performance bottleneck.
My question: is Scala Logging's LazyLogging trait blocking or non-blocking?
We log and process a lot of messages and use Akka. So does having just lazy loggers help or hurt when it comes to performance?
scala
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
I recently read this article that makes me wonder whether using LazyLogging would create a performance bottleneck.
My question: is Scala Logging's LazyLogging trait blocking or non-blocking?
We log and process a lot of messages and use Akka. So does having just lazy loggers help or hurt when it comes to performance?
scala
scala
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
edited Nov 14 '18 at 23:11
Jeffrey Chung
14.2k62140
14.2k62140
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
asked Nov 14 '18 at 21:08
AchilleusAchilleus
680418
680418
scala-logging is not related to Akka, btw, they are different libraries.
– Vladimir Matveev
Nov 14 '18 at 21:12
add a comment |
scala-logging is not related to Akka, btw, they are different libraries.
– Vladimir Matveev
Nov 14 '18 at 21:12
scala-logging is not related to Akka, btw, they are different libraries.
– Vladimir Matveev
Nov 14 '18 at 21:12
scala-logging is not related to Akka, btw, they are different libraries.
– Vladimir Matveev
Nov 14 '18 at 21:12
add a comment |
1 Answer
1
active
oldest
votes
The scala-logging library relies on the SLF4J library, which is an API frontend for various logging libraries. Therefore, whether logging is synchronous or not is completely defined by the actual logging framework that you use. The most prominent and modern ones are Logback and Log4J 2, but there are other, usually older alternatives, like commons-logging, log4j1 or even java.util.Logging (JUL).
So, depending on your backend configuration, your log invocations might be either synchronous or not. For example, Logback has AsyncAppender which acts as an asynchronous frontend for other, potentially blocking appenders; it is also possible for specific appenders to be async as well, e.g. if it is an appender which writes to an external logging aggregation system.
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
Thanks for your response. Does this affect the latency significantly? Using AsyncAppender over synchronous ones? Also are there any drawbacks using AsyncAppender?
– Achilleus
Nov 14 '18 at 22:13
That's pretty much explained in that documentation page - asynchronicity implies potential issues with flushing and also with overloading the processing queue. There is no universal answer - if it is critical for your application not to block even on logs, and your output sinks for logs can be blocking in synchronous mode (e.g. network socket, slow disk, etc), then you most likely have to use some kind of async appender. Otherwise, you'll have to benchmark and find whether it is okay for your application to block on logging statements or not.
– Vladimir Matveev
Nov 14 '18 at 22:31
Thanks for your help. Will read up more on that.
– Achilleus
Nov 14 '18 at 22:34
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%2f53308741%2fscala-logging-is-lazylogging-blocking-or-non-blocking%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 scala-logging library relies on the SLF4J library, which is an API frontend for various logging libraries. Therefore, whether logging is synchronous or not is completely defined by the actual logging framework that you use. The most prominent and modern ones are Logback and Log4J 2, but there are other, usually older alternatives, like commons-logging, log4j1 or even java.util.Logging (JUL).
So, depending on your backend configuration, your log invocations might be either synchronous or not. For example, Logback has AsyncAppender which acts as an asynchronous frontend for other, potentially blocking appenders; it is also possible for specific appenders to be async as well, e.g. if it is an appender which writes to an external logging aggregation system.
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
Thanks for your response. Does this affect the latency significantly? Using AsyncAppender over synchronous ones? Also are there any drawbacks using AsyncAppender?
– Achilleus
Nov 14 '18 at 22:13
That's pretty much explained in that documentation page - asynchronicity implies potential issues with flushing and also with overloading the processing queue. There is no universal answer - if it is critical for your application not to block even on logs, and your output sinks for logs can be blocking in synchronous mode (e.g. network socket, slow disk, etc), then you most likely have to use some kind of async appender. Otherwise, you'll have to benchmark and find whether it is okay for your application to block on logging statements or not.
– Vladimir Matveev
Nov 14 '18 at 22:31
Thanks for your help. Will read up more on that.
– Achilleus
Nov 14 '18 at 22:34
add a comment |
The scala-logging library relies on the SLF4J library, which is an API frontend for various logging libraries. Therefore, whether logging is synchronous or not is completely defined by the actual logging framework that you use. The most prominent and modern ones are Logback and Log4J 2, but there are other, usually older alternatives, like commons-logging, log4j1 or even java.util.Logging (JUL).
So, depending on your backend configuration, your log invocations might be either synchronous or not. For example, Logback has AsyncAppender which acts as an asynchronous frontend for other, potentially blocking appenders; it is also possible for specific appenders to be async as well, e.g. if it is an appender which writes to an external logging aggregation system.
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
Thanks for your response. Does this affect the latency significantly? Using AsyncAppender over synchronous ones? Also are there any drawbacks using AsyncAppender?
– Achilleus
Nov 14 '18 at 22:13
That's pretty much explained in that documentation page - asynchronicity implies potential issues with flushing and also with overloading the processing queue. There is no universal answer - if it is critical for your application not to block even on logs, and your output sinks for logs can be blocking in synchronous mode (e.g. network socket, slow disk, etc), then you most likely have to use some kind of async appender. Otherwise, you'll have to benchmark and find whether it is okay for your application to block on logging statements or not.
– Vladimir Matveev
Nov 14 '18 at 22:31
Thanks for your help. Will read up more on that.
– Achilleus
Nov 14 '18 at 22:34
add a comment |
The scala-logging library relies on the SLF4J library, which is an API frontend for various logging libraries. Therefore, whether logging is synchronous or not is completely defined by the actual logging framework that you use. The most prominent and modern ones are Logback and Log4J 2, but there are other, usually older alternatives, like commons-logging, log4j1 or even java.util.Logging (JUL).
So, depending on your backend configuration, your log invocations might be either synchronous or not. For example, Logback has AsyncAppender which acts as an asynchronous frontend for other, potentially blocking appenders; it is also possible for specific appenders to be async as well, e.g. if it is an appender which writes to an external logging aggregation system.
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
The scala-logging library relies on the SLF4J library, which is an API frontend for various logging libraries. Therefore, whether logging is synchronous or not is completely defined by the actual logging framework that you use. The most prominent and modern ones are Logback and Log4J 2, but there are other, usually older alternatives, like commons-logging, log4j1 or even java.util.Logging (JUL).
So, depending on your backend configuration, your log invocations might be either synchronous or not. For example, Logback has AsyncAppender which acts as an asynchronous frontend for other, potentially blocking appenders; it is also possible for specific appenders to be async as well, e.g. if it is an appender which writes to an external logging aggregation system.
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
answered Nov 14 '18 at 21:29
Vladimir MatveevVladimir Matveev
70.5k15171214
70.5k15171214
Thanks for your response. Does this affect the latency significantly? Using AsyncAppender over synchronous ones? Also are there any drawbacks using AsyncAppender?
– Achilleus
Nov 14 '18 at 22:13
That's pretty much explained in that documentation page - asynchronicity implies potential issues with flushing and also with overloading the processing queue. There is no universal answer - if it is critical for your application not to block even on logs, and your output sinks for logs can be blocking in synchronous mode (e.g. network socket, slow disk, etc), then you most likely have to use some kind of async appender. Otherwise, you'll have to benchmark and find whether it is okay for your application to block on logging statements or not.
– Vladimir Matveev
Nov 14 '18 at 22:31
Thanks for your help. Will read up more on that.
– Achilleus
Nov 14 '18 at 22:34
add a comment |
Thanks for your response. Does this affect the latency significantly? Using AsyncAppender over synchronous ones? Also are there any drawbacks using AsyncAppender?
– Achilleus
Nov 14 '18 at 22:13
That's pretty much explained in that documentation page - asynchronicity implies potential issues with flushing and also with overloading the processing queue. There is no universal answer - if it is critical for your application not to block even on logs, and your output sinks for logs can be blocking in synchronous mode (e.g. network socket, slow disk, etc), then you most likely have to use some kind of async appender. Otherwise, you'll have to benchmark and find whether it is okay for your application to block on logging statements or not.
– Vladimir Matveev
Nov 14 '18 at 22:31
Thanks for your help. Will read up more on that.
– Achilleus
Nov 14 '18 at 22:34
Thanks for your response. Does this affect the latency significantly? Using AsyncAppender over synchronous ones? Also are there any drawbacks using AsyncAppender?
– Achilleus
Nov 14 '18 at 22:13
Thanks for your response. Does this affect the latency significantly? Using AsyncAppender over synchronous ones? Also are there any drawbacks using AsyncAppender?
– Achilleus
Nov 14 '18 at 22:13
That's pretty much explained in that documentation page - asynchronicity implies potential issues with flushing and also with overloading the processing queue. There is no universal answer - if it is critical for your application not to block even on logs, and your output sinks for logs can be blocking in synchronous mode (e.g. network socket, slow disk, etc), then you most likely have to use some kind of async appender. Otherwise, you'll have to benchmark and find whether it is okay for your application to block on logging statements or not.
– Vladimir Matveev
Nov 14 '18 at 22:31
That's pretty much explained in that documentation page - asynchronicity implies potential issues with flushing and also with overloading the processing queue. There is no universal answer - if it is critical for your application not to block even on logs, and your output sinks for logs can be blocking in synchronous mode (e.g. network socket, slow disk, etc), then you most likely have to use some kind of async appender. Otherwise, you'll have to benchmark and find whether it is okay for your application to block on logging statements or not.
– Vladimir Matveev
Nov 14 '18 at 22:31
Thanks for your help. Will read up more on that.
– Achilleus
Nov 14 '18 at 22:34
Thanks for your help. Will read up more on that.
– Achilleus
Nov 14 '18 at 22:34
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.
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%2f53308741%2fscala-logging-is-lazylogging-blocking-or-non-blocking%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
scala-logging is not related to Akka, btw, they are different libraries.
– Vladimir Matveev
Nov 14 '18 at 21:12