When I run this test program, the reader does not hang. It receives a
SocketException. I see the following output:
$ javac TestSocket.java
$ java -cp . TestSocket localhost 23
sleeping
before read
after read
before read
after read
before read
after read
before read
after read
before read
after read
before read
after read
before read
closing socket
closing socket done
java.net.SocketException: socket closed: A file descriptor does not refer
to an open file.
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:98)
at java.net.SocketInputStream.read(SocketInputStream.java:115)
at TestSocket$1.run(TestSocket.java:21)
Also, I do not see the same behavior in 2.1.1 and 2.1.2. My programs do not
hang under 2.1.1.
Is there any way to verify the socket.close() is being called by
connection.close() as expected?
Geoffrey A. Lowney
Senior Software Development Engineer
Recreational Equipment, Inc.
Phone 253-395-8164 Fax 253-437-7291
Pager 206-625-8477 [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.rei.com/
In order to draw a limit to thinking, we should have to think both sides
of this limit.
-- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
> -----Original Message-----
> From: Andreas Mueller [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 30, 2001 6:10 AM
> To: [EMAIL PROTECTED]
> Subject: [developers] progarm hangs under 2.1.2
>
>
>
> > The 2.1.1 has exactly the same behavior here. The reader
> thread stucks
> > at
> > read even after socket.close(). After about 1 minute the
> read returns
> > without any exception and the program then terminates properly. I'll
> > try
> > to solve it today and will eventually deploy 2.1.2 again.
>
> Well, I've tested it here with all possible combinations, incl.
> interrupting the reader thread. It has no effect. The reader hangs on
> read.
>
> This is NOT a SwiftMQ issue but probably a JDK platform problem. I've
> attached a very simple testdriver to test it. It produces
> exactly the same
> behavior. It creates a socket, starts a thread to read from the input
> stream, sleeps 1s, and closes the socket. The reader hangs.
> Just try it
> with java -cp . TestSocket localhost 23. This is the telnet port.
> Strange wise: if I ctrl/z the hanging program and put it in
> the foreground
> again with "fg", it terminates properly with a socket exception.
>
> There must be something wrong with the signaling of the JVM.
> A SwiftMQ
> clients exits after about 60s, because the keepalive interval
> is 60'000.
> The timer is definitively destroyed at the client (I've
> checked it!). But
> the router sends a message in this interval. This might cause
> a signal at
> the client socket which results in termination. If you set
> the keepalive
> interval to 10s, the client terminates after 10s.
>
> So, for you, a workaround could be:
>
> - use 1.3.0 or better with -classic at your client
> - try 1.2.2 with -native
> - simply use System.exit at your client
> - use a keepalive interval of 1000 (1s) for the JMS listener
>
> I don't found a bug in the bug database of JavaSoft. So I can
> do simply
> nothing on this issue. If someone has an idea, please tell me.
>
> --
> Andreas Mueller, IIT GmbH, Bremen/Germany, http://www.iit.de
> SwiftMQ - JMS Enterprise Messaging System, http://www.swiftmq.com
>
> ------------------------------------------------------
> SwiftMQ developers mailing list * http://www.swiftmq.com
> To unsubscribe from this list, send an eMail to
> [EMAIL PROTECTED] and write in the body of your message:
> UNSUBSCRIBE developers <your-email-address>
> Archive: http://www.mail-archive.com/developers@mail.iit.de/
>
>
>
------------------------------------------------------
SwiftMQ developers mailing list * http://www.swiftmq.com
To unsubscribe from this list, send an eMail to
[EMAIL PROTECTED] and write in the body of your message:
UNSUBSCRIBE developers <your-email-address>
Archive: http://www.mail-archive.com/developers@mail.iit.de/
