> It sounds like your app don't block forever?
Right, so it appears.
> Have you taken into account that your load is not
> that high that the network or your log4j socket
> server might be stopping your logging? If the
> transfer buffer is full the socket stop returning
> from send till the watermark decrease!
You may very well be correct. But my claim below may
still be true: The synch block is far too large.
Mats
> Kind regards
> Frank-Olaf Lohmann
>
> >>> Mats Henricson <[EMAIL PROTECTED]> 13.09.2001 18.48 Uhr >>>
> > > If two threads in my program logs at the same time,
> > > then this function might be called in parallel.
> >
> > Are you sure about this? SocketAppender extends
> > AppenderSkeleton, which only calls append within a
> > synchronized method. This is how I believe the
> > synchronization is meant to work. If you can test it
> > and prove that it *is* being called in parallel,
> > that would be a cause for concern.
> >
> > Of course, I could be entirely wrong...
>
> I think you are right, the thread safety is guaranteed by
> the synchronized doAppend() function in the AppenderSkeleton
> class.
>
> This is how our performance consultant described the problem:
>
> It hanged for quite a while. Then it came up and later
> on freezed again for sometime.
>
> The thread dump showed that many of the threads were waiting
> on org.apache.log4j.Category.callAppenders(Category.java:249).
>
> We then removed the SocketAppender, keeping a FileAppender
> attached to System.out, and a DailyRollingFileAppender. The
> problems then went away.
>
> This could be a coincidence, but we don't know that yet.
> We'll try more later.
>
> Anyway, it seems to me that the synchronization of doAppend()
> is overly large. Much, if not all, of what that function
> does is already thread safe:
>
> public synchronized void doAppend(LoggingEvent event) {
> if(closed) {
> LogLog.error("Attempted to append to closed appender named ["+name+"].");
> }
>
> if(!isAsSevereAsThreshold(event.priority)) {
> return;
> }
>
> Filter f = this.headFilter;
>
> FILTER_LOOP:
> while(f != null) {
> switch(f.decide(event)) {
> case Filter.DENY: return;
> case Filter.ACCEPT: break FILTER_LOOP;
> case Filter.NEUTRAL: f = f.next;
> }
> }
>
> this.append(event);
> }
>
> This leaves the subclass append() function. For the SocketAppender
> much of the code is also thread safe, I think, except for the part
> described in the beginning of this email thread.
>
> So, my current guess is that the sychronization is covering
> so much code that much of our system is just waiting.
>
> What do you all think?
>
> Mats
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Mats Henricson
Talaris Corporation
260 Santa Ana Ct.
Sunnyvale, CA 94086
(408) 730-3337 phone
(650) 704-7081 cell
mailto:[EMAIL PROTECTED]
http://www.talaris.com/
Red Herring “Top 10 Companies to Watch” 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
