The sync block is large - more or less. But IMHO it has no impact in speed.
1.I you have times of what you called heavy load and times of low load use the
SocketAppender together with AsyncAppender and your
app will perform well.
2. If your app will log so much that the wire can not deal with it you are lost anyway.
Kind regards
Frank-Olaf Lohmann
>>> Mats Henricson <[EMAIL PROTECTED]> 14.09.2001 16.38 Uhr >>>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
