Joern Huxhorn (JIRA | 24 Apr 01:34 2014
Picon

[JIRA] (LOGBACK-624) MDC Adapter with configurable InheritableThreadLocal

Joern Huxhorn commented on LOGBACK-624

+1 for replacing InheritableThreadLocal with ThreadLocal. InheritableThreadLocal is essentially introducing an uncontrollable side effect to the MDC.

The issue can be circumvented by calling MDC.clear() before doing any work in a Runnable/Callable if those are in your own codebase but otherwise you are out of luck.

This could even leak sensitive data in a worst-case scenario. Such data probably shouldn't end up in the MDC in the first place but I wouldn't expect it to - sometimes - "leak into unrelated Threads" by calling Executor.execute().

I really don't see a use case for the inheritance functionality. Those use cases may exist (and the functionality could be manually emulated in that circumstance) but they are certainly not the behavior expected by default. I'd suspect that if we changed this right away (breaking compatibility in the process, strictly speaking) that no one would ever complain about it since no one would miss the current functionality.

And, yes, this has bitten me in the past. It was quite astonishing.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Juan Meyer | 23 Apr 15:47 2014
Picon

LOGBACK-588: RFC5424 Support in SLF4J / Logback

Hi, 
A JIRA <http://jira.qos.ch/browse/LOGBACK-588> was created requesting support for Syslog RFC5424
(Structured Data). I was wondering whether the commit provided by Carl Harris (currently branched at
<https://github.com/qos-ch/logback/tree/zooml-syslog-rfc5424>) is being considered for
release? I am more than willing to assist with any work necessary to expedite the release of code necessary
to resolve this ticket.
Regards, 
Juan 
Markus Kull (JIRA | 23 Apr 11:48 2014
Picon

[JIRA] (LOGBACK-624) MDC Adapter with configurable InheritableThreadLocal

Markus Kull commented on LOGBACK-624

Also was hit by this. I vote for completely replacing the InheritableThreadLocal by a ordinary ThreadLocal. The days of Java 1.4 are over, when a thread was started for a single task and then finished. Since Java 1.5 ExecutorServices with ThreadPools are recommended, and these start threads on demand and also reuse threads for multiple tasks. Thus MDC-Values are easily propagated to unrelated tasks, which is unwanted.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Ross Goldberg (JIRA | 22 Apr 07:50 2014
Picon

[JIRA] (LOGBACK-978) Configuration variable & literal parsing errors

Issue Type: Bug
Affects Versions: 1.1.2
Assignee: Logback dev list
Components: logback-core
Created: 22/Apr/14 7:49 AM
Description:

When logback attempts to substitute values in for variables (of of the style $

{...}

) in the body of an element in logback.xml, if the body String ends with a dollar sign, '$', line 63 of ch.qos.logback.core.subst.Tokenizer performs:

throw new ScanException("Unexpected end of pattern string");

Which incorrectly throws a ScanException, because it is incorrectly expecting more characters, either a '{' to tell it to expect a variable name, or not a '{', to indicate that the '$' was a literal. If a '$' is the last character, obviously it is a literal instead of the beginning of a variable reference token.

Also, if the body String ends with "${", an NPE is thrown by some other method. Instead, my solution below throws a ScanException in this case (plus for the case where a "$

{" is not closed by a "}

").

Lastly, if the String includes unbalanced '

{' without corresponding closing '}

', your code throws exceptions elsewhere. Why must '

{' be balanced by closing '}

', if the '{' is not preceded by a '$'? My solution doesn't fix this issue, only the previous issues. Assuming my solution works for the earlier issues, however, it should be put into place, and the latter '{' issue can be handled later.

Solution (not tested or even compiled, so it might contain typos):
The body of the switch statement that include line 63 should probably be replaced with something like the following:

case LITERAL_STATE:
final int tokenCount = tokenList.size();
if (tokenCount >= 2 && tokenList.get(tokenCount - 2) == Token.START_TOKEN) {
throw new ScanException("variable reference open, \"$

{\", without a variable reference close, \"}

\" for variable name " + buf);
}
addLiteralToken(tokenList, buf);
break;
case START_STATE:
buf.append(CoreConstants.DOLLAR);
addLiteralToken(tokenList, buf);
break;

Environment:

All

Project: logback
Priority: Major
Reporter: Ross Goldberg
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Sebastian Gröbler (JIRA | 21 Apr 15:34 2014
Picon

[JIRA] (LOGBACK-977) AbstractSocketAppender loses event for every socket connection break

The application would not freeze, it would slow down with 100 (default value) ms waits on calling queue.offer and would show warnings for dropping events. So the use-case of connection drops would overlap with the one where there are more events than the queue can take.

By the way if I am not mistaken, the behaviour you describe is documented as such, see "In particular, in the extreme case where the network link to the server is down, the client will be eventually blocked.". Which seems outdated considering the current code base.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Kanapathipillai Senthuran | 21 Apr 14:27 2014
Picon

How can we get the AuditEvent id while persisting it

Hello Team,

We are using logback audit for our project purpose.

We want to persist AuditEvent in initial stage and the final stage we need to add the predicates.

Currently we could not do it because there is no way to get the persisted object or id from the logback API. AuditFacade.audit() does not return any thing.

Please suggest me how can we get the AuditEvent or ID once I persist the AuditEvent?

--
Thanks & Regards,
K.Senthuran
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Joern Huxhorn (JIRA | 21 Apr 14:04 2014
Picon

[JIRA] (LOGBACK-977) AbstractSocketAppender loses event for every socket connection break

Joern Huxhorn commented on LOGBACK-977

So if a network connection can't be established, the application is supposed to freeze until one becomes available?
Because that's what would happen... The queue would eventually be full and the app would grind to a halt.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Sebastian Gröbler (JIRA | 21 Apr 13:29 2014
Picon

[JIRA] (LOGBACK-977) AbstractSocketAppender loses event for every socket connection break

Issue Type: Bug
Affects Versions: 1.1.2
Assignee: Logback dev list
Components: logback-core
Created: 21/Apr/14 1:28 PM
Description:

Problem
The AbstractSocketAppender takes events from its queue without knowing if it can actually deliver them. In case the socket connection breaks the next write operation on the OutputStream will fail with an IOException and the event will never be delivered.

Solution
Change queue consumer strategy from "take" to "peek/remove". This allows to keep the event in the queue until it's transmission was successful. This will require to move away from the SynchronousQueue (queueSize == 0) logic and use the ArrayBlockingQueue with a size of 1 to implement a "synchronous queue".

Project: logback
Priority: Major
Reporter: Sebastian Gröbler
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Benjamin Weber (JIRA | 20 Apr 21:32 2014
Picon

[JIRA] (LOGBACK-895) Logback not correctly parsing IntegerToken with given fileNameFormat

I had this problem configuring with Java. In my case it was caused by not calling setContext on the rollingPolicy (as well as the fileAppender).

This context ultimately ends up being null in OptionHelper#instantiateByClassName which results in the converter for Integers/Dates not being instantiated correctly.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Joern Huxhorn (JIRA | 20 Apr 21:00 2014
Picon

[JIRA] (LOGBACK-973) PermGen with orphan async appenders

Joern Huxhorn commented on LOGBACK-973

I'd leave it open.
I just mentioned it so they can all be closed together once the cause gets addressed.

LOGBACK-925 is just stating the fact while this one describes a nasty effect of it.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Régis Ramillien (JIRA | 20 Apr 20:45 2014
Picon

[JIRA] (LOGBACK-925) Unattached appenders are started but not stopped

As found by Joern, other informations can be found here:
http://jira.qos.ch/browse/LOGBACK-973

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev

Gmane