SocketHubAppender issues with socket cleanup

["Bradley, Todd" <to...@Polycom.com>]

Hi, I've been using log4j the past month or so, and am fighting an
unusually wily problem related to socket shutdown from
SocketHubAppender.

I've written a class that acts as a socket client and connects to an
application using a SocketHubAppender to gather up log events.  To unit
test my class, I've written a test fixture that I call FileSpewer.  It
just reads lines from a file and sends them out as log4j log messages.
So, when FileSpewer is running, it's a log source and my other class
(which is called LogProxy, FWIW) is the log sink.  I'm running both in
their own thread.

When FileSpewer's thread exits, I would expect some sort of exception to
be thrown from LogProxy's socket read.  Specifically, I'd expect either
an EOF exception or a connection reset exception.  However, I don't get
either.  The socket read just waits and waits for a log event that's
never going to arrive (because the log source has exited).

I've read the note in the docs about "If the JVM hosting the
SocketHubAppender exits before the SocketHubAppender is closed either
explicitly or subsequent to garbage collection, then there might be
untransmitted data in the pipe which might be lost. This is a common
problem on Windows based systems."  And I thought I might be seeing a
similar issue, since I'm on Windows XP.

So, I tried explicitly calling my SocketHubAppender's close().  However,
it doesn't fix the problem, and causes null pointer exceptions instead
(I noticed through the log4j debug messages that SocketHubAppender is
trying to call serverMonitor.stopMonitor() on a serverMonitor that is
null).

A few other bits of info that may be useful:  When I run my FileSpewer
as a separate app (rather than running as a thread of my JUnit test), my
socket client does get a "Connection reset" exception when that separate
app closes down.  However, when I run FileSpewer in a thread spawned by
my JUnit test case, I never do get that exception.

Any ideas?  I've been debugging this problem all day and am at wit's
end.


Thanks in advance,
Todd.
----
Todd Bradley - Polycom - QA Lead, Super Secret Project

Visit me at my WebOffice for IM and app sharing:
http://www.polycomweboffice.com/todd.bradley@polycom.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

RE: SocketHubAppender issues with socket cleanup

[Tim Mullé <ti...@lighthammer.com>]

Hi,

I also had an earlier post about the SocketHubAppender creating unnecessary
Socket object every second while waiting for a client to connect. It appears
the reason for this is so the SocketHubAppender could be restarted
dynamically.

To fix this, I copied and pasted the code for the SocketHubAppender, removed
the setting of the timeouts on the ServerSocket and added a call to
serverSocket.close() in the shutdown method on the ServerMonitor inner
class. Without calling close on the server socket, the log4j system hangs
because the server socket is stuck in the accept() method. This is why they
were using the timeout on the socket..to periodically break out of the loop
to check if they should shutdown and restart.

My fix is working locally and I could send a diff to the group if they
wanted to see the changes...

- Tim
 

-----Original Message-----
From: Bradley, Todd [mailto:todd.bradley@Polycom.com] 
Sent: Wednesday, February 09, 2005 5:43 PM
To: log4j-user@logging.apache.org
Subject: SocketHubAppender issues with socket cleanup

Hi, I've been using log4j the past month or so, and am fighting an unusually
wily problem related to socket shutdown from SocketHubAppender.

I've written a class that acts as a socket client and connects to an
application using a SocketHubAppender to gather up log events.  To unit test
my class, I've written a test fixture that I call FileSpewer.  It just reads
lines from a file and sends them out as log4j log messages.
So, when FileSpewer is running, it's a log source and my other class (which
is called LogProxy, FWIW) is the log sink.  I'm running both in their own
thread.

When FileSpewer's thread exits, I would expect some sort of exception to be
thrown from LogProxy's socket read.  Specifically, I'd expect either an EOF
exception or a connection reset exception.  However, I don't get either.
The socket read just waits and waits for a log event that's never going to
arrive (because the log source has exited).

I've read the note in the docs about "If the JVM hosting the
SocketHubAppender exits before the SocketHubAppender is closed either
explicitly or subsequent to garbage collection, then there might be
untransmitted data in the pipe which might be lost. This is a common problem
on Windows based systems."  And I thought I might be seeing a similar issue,
since I'm on Windows XP.

So, I tried explicitly calling my SocketHubAppender's close().  However, it
doesn't fix the problem, and causes null pointer exceptions instead (I
noticed through the log4j debug messages that SocketHubAppender is trying to
call serverMonitor.stopMonitor() on a serverMonitor that is null).

A few other bits of info that may be useful:  When I run my FileSpewer as a
separate app (rather than running as a thread of my JUnit test), my socket
client does get a "Connection reset" exception when that separate app closes
down.  However, when I run FileSpewer in a thread spawned by my JUnit test
case, I never do get that exception.

Any ideas?  I've been debugging this problem all day and am at wit's end.


Thanks in advance,
Todd.
----
Todd Bradley - Polycom - QA Lead, Super Secret Project

Visit me at my WebOffice for IM and app sharing:
http://www.polycomweboffice.com/todd.bradley@polycom.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org