[logback-user] Multiple web-applications logging to same file
Alex Vb
i8c.alex at gmail.com
Fri Apr 8 15:32:01 CEST 2011
I created a bug report about it a while back:
http://jira.qos.ch/browse/LBCORE-168
I am not a windows expert by any stretch of the imagination, but in a
windows cluster you can define a single owner for a shared SAN, this means
if one server goes down, the other automatically takes up ownership of the
drive which should be relatively transparant to other systems. However there
is a 10-ish second delay in the switch and during those 10 seconds,
something can go awefully wrong with the file locks in prudent mode it
seems. Basically the JVM reports the log file as locked and because the
lock() is blocking the thread trying to lock it will hang indefinately. The
current custom appender we have written uses tryLock() multiple times with a
delay and after x (configurable) amount of failures it dies gracefully.
It is hard to write a testcase for this for obvious reasons, but I was able
(at least back when the issue was filed) to recreate the situation
repeatedly.
On 8 April 2011 08:58, Ceki Gulcu <ceki at qos.ch> wrote:
>
> Hi Alex,
>
>
> Thank you for the heads up. I was not aware of deadlocks occuring in
> prudent mode. Can you tell us more about your environment, OS version, file
> system sharing technology, etc? For example, what do you man by "ownership
> of the drive"?
>
> Cheers,
> --
> Ceki
>
> QOS.ch, main sponsor of cal10n, logback, mistletoe and slf4j open source
>
> projects, is looking to hire talented software engineers. For
> further details, see http://logback.qos.ch/job.html
>
> On 08.04.2011 07:19, Alex Vb wrote:
>
>> Just a heads up: we had a similar usecase at a client, but unfortunatly
>> they were using a windows cluster where one node owned the shared drive
>> where the logs had to be written to. The problem was that when you
>> switched ownership of the drive while the application was logging in
>> prudent mode, the file lock could not always be released. This means the
>> next time you tried to log, the blocking lock() call would hang
>> infinitely. After this happened a few times (caught it before production
>> luckily), we wrote custom appenders with non-blocking locking and now we
>> usually log asynchronously which avoids the problem alltogether (no
>> prudent mode needed).
>>
>> On 7 April 2011 18:44, Ceki Gulcu <ceki at qos.ch <mailto:ceki at qos.ch>>
>> wrote:
>>
>>
>> As David mentioned prudent mode caters for this use case. It should
>> should work nicely.
>>
>> BTW, I did not see get the original message from "LogbackUser"
>> apparently posted from nabble.
>>
>> --
>> Ceki
>>
>> QOS.ch, main sponsor of cal10n, logback and slf4j open source
>> projects, is looking to hire talented software engineers. For
>> further details, see http://logback.qos.ch/job.html
>>
>>
>>
>> On 07.04.2011 17:56, David Roussel wrote:
>>
>>
>> Use prudent mode -
>> http://logback.qos.ch/manual/appenders.html#FileAppender
>>
>>
>>
>> LogbackUser wrote:
>>
>>
>> Are there any configuration properties through which multiple
>> web-applications using logback could be configured to log to
>> the same log
>> file? This is taking into consideration that the messages
>> would be logged
>> concurrently without losing any messages.
>>
>> The reason I ask this question is that - we have a clustered
>> environment
>> of glassfish server instances where the same web application
>> is installed
>> on all the server instances in the cluster.
>>
>>
>>
>> _______________________________________________
>> Logback-user mailing list
>> Logback-user at qos.ch <mailto:Logback-user at qos.ch>
>>
>> http://qos.ch/mailman/listinfo/logback-user
>>
>>
>>
>>
>> _______________________________________________
>> Logback-user mailing list
>> Logback-user at qos.ch
>> http://qos.ch/mailman/listinfo/logback-user
>>
>
>
> --
> QOS.ch, main sponsor of cal10n, logback and slf4j open source projects, is
> looking to hire talented software engineers. For further details, see
> http://logback.qos.ch/job.html
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-user/attachments/20110408/86fe9d91/attachment.html>
More information about the Logback-user
mailing list