Comments (6)
Hi, thanks for your comments (and sorry for not replying sooner). I assume you mean that there are multiple calls to "isLoggable()" for the same log statement when you talk about "reading the configuration".
This was a deliberate choice in the design and related to forcing of log statements. In those cases the backend will say that a log statement is not loggable, but we ignore that in the frontend and push the log record through anyway. The decision not to store the result was likely related to a desire to keep the LogContext objects as small as possible (since they get allocated a lot).
See the rather complex in AbstractBackend.java for more.
I think that the worst that happens is a harmless race condition between the time that a log statement begins and when it's output. Is this behaviour causing you a problem?
from flogger.
Hi David,
yes, multiple calls is the issue because the backend can changed in-between those calls, it's not a race because it's not an access on the same data, it's more an API violation.
The behavior of a backend can be compromised because you can have this scenario:
isLoggable is called on backend1, at that point the backend is changed to backend2, then the logging is done on backend2 without calling isLoggable of backend2.
And you're right that storing the backend in LogContext will fix this issue.
from flogger.
The log context logs to the backend of the logger it was created with. And that field is final, so cannot change. If a composite logger backend wishes to allow switching between implementations dynamically it is required to implement any additional checks required to behave "properly".
In short, the backend is already effectively "stored" in the log context (but I actually go via the logger to avoid extra fields). See code in AbstractLogger.
from flogger.
By additional checks, you mean that the logger first checks if it should log by asking the backend, if the answer is true the when .log() is called, the backend has to check again if it should log so performing the logging check twice.
If it's implemented like this, i agree that there is no issue but it means that you have two volatile reads when logging and usually Hotspot tend to not merge those volatile reads (i'm happy if i'm wrong about that).
from flogger.
Yes, but when logging, the cost of doing the second check is utterly insignificant to the rest of the work done. Optimizing for "no work" only matters in the case when you aren't logging. When you are logging, there are allocations, some string formatting, I/O etc...
from flogger.
I agree that doing a second volatile read on the same address is cheap compared to the first volatile read,
but it's still slower that not doing it.
The elephant in the room is a volatile read, by itself is already awful, it's slow from the CPU POV and worst it disables hamper JIT optimizations like loop hoisting (the VM is forced to re-read all fields from the RAM).
Optimizing for "no work" only matters in the case when you aren't logging
yes, but it enable a powerful way of writing/deploying a software. It means that you can have a fine grain logging in production because the cost at runtime is really zero until you enable a particular logger to diagnose an issue.
When you are logging, there are allocations, some string formatting, I/O etc..
yes, i agree, string formatting can be done in one allocation BTW using the StringConcatFactory.
from flogger.
Related Issues (20)
- Architecture diagram for flogger
- Extensibility How to HOT 9
- Better document Flogger's status (active, maintained, in use at Google) HOT 5
- Support for java.util.ResourceBundle HOT 9
- Add tags from thread context to log HOT 17
- Use java.time.Duration for atMostEvery in LoggingApi. HOT 2
- Flag --incompatible_disable_starlark_host_transitions will break Flogger in Bazel 7.0 HOT 6
- Release schedule?
- Default JavaDocs generated for Flogger confusingly suggest it's deprecated (it isn't). HOT 2
- How to handle ScopedLoggingContext for new Threads / ThreadPools? HOT 1
- Provide a log writer to produce JSON log items according to Elastic Common Schema HOT 8
- I don't believe ScopedLoggingContexts should obviously accept null "no-op" arguments. HOT 5
- Incorrect caller details logged with Flogger in spring boot HOT 2
- Error: 'JavaInfo' value has no field or method 'transitive_deps' HOT 5
- Error: 'JavaInfo' value has no field or method 'transitive_deps' HOT 5
- Next release HOT 2
- ThreadlocalRandom instead of ThreadLocal HOT 8
- java failed error executing Javac command from target //api:checks HOT 5
- test
- `LogData.getTemplateContext()` should be `@NullableDecl`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flogger.