Hi,
Well, I got the 04-22 nightly build on Monday morning,
and it doesn't solve the TCPMonitor Socket problems,
although I've been able to reclassify the business about
requests and responses being concatenated to previous
ones as "user error" on my part -- failure to notice that these
were in the context of Active connections due to the HTTP
header "Connection: Keep-Alive" being sent when running the
"Building Web Services with Java" examples from the browser.
Regarding the Socket exceptions, however, it's a different story,
and I'm very surprised that other people aren't experiencing
similar problems with tcpmon, though perhaps it has something
to do with threads on Win2K (my OS) as opposed to Unix.
But surely, there are others running the TCPMonitor on Win2K ??
Anyway, here are my observations, from perusing the source code for
classes tcpmon and its nested classes, particularly tcpmon$Connection,
tcpmon$SocketRR, and tcpmon$Listener. The issues basically boil down
to two:
(1) There is a synchronization problem between tcpmon$Connection.run()
and tcpmon$SocketRR.run(). Specifically, after the SocketRR threads
have finished executing near the end of Connection.run(), it seems that
the following critical section requires synchronization:
synchronized (tcpmon.this) {
rr1.halt();
rr2.halt();
rr1 = null;
rr2 = null;
active = false;
}
and likewise the following critical section in SocketRR.run(), with the
"if (!done)" guard inserted as well:
synchronized (tcpmon.this) {
if (!done) {
len1 = in.read(buffer, saved, len);
}
}
Without these changes, the Connection and SocketRR threads interleave
in ways that lead to "java.net.SocketException: Socket closed" errors.
Again, I'm running on Win2K and am uncertain how the mileage may differ
on systems with a different underlying thread model.
(2) The "Resend" function simply does not work, because NullPointerExceptions
are thrown at the lines
inSocket.setSoTimeout(10);
outSocket.setSoTimeout(10);
in tcpmon$SocketRR.run() due to the fact that, in the Resend context, the two
instances of SocketRR created by tcpmon$Connection.run() are passed a
null inSocket, and this in turn is because the particular tcpmon$Connection
constructor invoked by tcpmon$Listener.resend() -- namely, the one that
accepts an InputStream argument -- does nothing to ensure that inSocket
is instantiated in the Connection thread that resend() constructs and fires up.
After having fiddled with this for a while, I've concluded that a proper solution
to the problem (that is, one that wouldn't break more essential tcpmon functionality)
would require more effort from me right now than the benefit of Resend is worth,
so I think I'll just avoid that function and hope that some AXIS developer(s) will
fix it for the first official AXIS release (as Resend is kind of a nice feature, in principle).
Thanks for your assistance and attention.
-- Ivan
| "Doug Davis" <[EMAIL PROTECTED]>
04/22/2002 03:59 AM
|
To: [EMAIL PROTECTED] cc: Subject: Re: TCPMonitor (Beta1) anomalies |
Just wondering - can you grab the latest tcpmon and try that. There were
some changes made prior to beta1 but I believe they were backed out right
after beta1 so they're probably not be there anymore. I use tcpmon quite a
bit and haven't noticed anything like what you're seeing.
-Dug
"Ivan Filippenko" <[EMAIL PROTECTED]>@notes.aero.org> on
04/22/2002 12:34:45 AM
Please respond to [EMAIL PROTECTED]
Sent by: "Ivan V Filippenko" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: TCPMonitor (Beta1) anomalies
Anyone have an idea why I'm having the following problems?
1) Most of the time, except for the first couple of requests passing
through the monitor (even just regular HTTP, not necessarily to AXIS),
the requests and responses get concatenated to the previous ones
displayed in the monitor instead of each one being listed separately
in the top table.
2) This appears to be related to the following exceptions appearing
at about the same time or shortly thereafter:
java.net.SocketException: Descriptor not a socket: JVM_recv in socket input
stream read
� � � � at java.net.SocketInputStream.socketRead(Native Method)
� � � � at java.net.SocketInputStream.read(Unknown Source)
� � � � at org.apache.axis.utils.tcpmon$SocketRR.run(Unknown Source)
As I say, this occurs without me doing anything special with Web services,
-- just passing HTTP requests to Tomcat 4.0.4-b1 via TCPMonitor.
Is there something I've set up wrong, or is this a Beta1 problem I haven't
heard about? �Any clues or suggestions would be appreciated! �I can't
use TCPMonitor this way.
Thanks,
� -- Ivan
