Improving error handling
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- java
- Domain
- observability-sre
Research direction
Start by reviewing the FluentLogger API and the current error paths described for log return values, unmanaged exceptions, and buffer-full exceptions. Compare the proposed handler and blocking-exception plans, including access to unsent message-packed Event objects. Done requires an agreed design and a defined error-reporting behavior for the 0.2.x versions.
Written by the indexing model from the issue text.
Description
I and @komamitsu san discussed how to improve error reporting of the current 0.2.x versions.
The major changes we considered are:
- Add
setHandler(handler)method to FluentLogger to accept an application-specific error handler. - In the error handler, provide a method for retrieving the remaining logs (the last one or all logs) that are not yet sent to fluentd.
- The last logs are message packed Event objects. We need to provide a decoder so that the last log is meaningful to the user.
In this change, we should consider the following problem:
- (Plan 1) A timing to report error. Currently errors can be reported in three ways: return value of
logmethod (true or false), unmanaged exceptions or exceptions thrown when the buffer is full. If an error handler is added,logmethod should be non-blocking method, and the error must be handled in the user-defined error handler (in the subsequent code or in another thread). Does it the right choice?
Another option would be:
- (Plan 2) Making
loga blocking method and reporting errors by Exception rather than returning true or false. The last log event should be included in the thrown exception.
After writing this ticket, Plan 2 now looks simpler to me.
Any idea?
- Dominant language
- Java
- Stars
- 210
- Forks
- 86
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from fluent/fluent-logger-java
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
fluent/fluent-logger-java#100 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 15/100
fluent/fluent-logger-java#99 · 1 comment · 2 reactions ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
fluent/fluent-logger-java#98 · 1 comment ·
-
Null Pointer Exception with slf4j-log4j12-1.7.30 (Fluent-logger incompatible with the new version) Open
Difficulty 3/5 1-2 days Newbie friendliness 42/100
fluent/fluent-logger-java#89 · 3 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 25/100
fluent/fluent-logger-java#88 · 1 comment ·
All issues in fluent/fluent-logger-java
Similar issues
-
certification
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
[BUG] ECR GetAuthorizationToken returns a proxyEndpoint for the default region, not the request's Openbug ecr
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Needs: Triage Type: Feature request
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AntennaPod/AntennaPod#8794 ·
-
agentic-workflows
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
github/copilot-sdk#2760 ·