Hi Kevin,
> Color me sheepish....this is what I get for dashing code off when I don't
> take the time to test it properly. Attached is a patch against current svn
> which should actually work (imagine that! :) this time. I've tested it with
> the Java client with SSL and non-SSL sockets.
I tried it again and it works better. SSL works great. However, with ssl=true
and sslOnly=false, the regular port seems to expect SSL as well!
Trying to open a non-ssl connection with these options set I get:
2007-02-20 10:06:03,823 ERROR [pool-2-thread-1]
protocol.AMQPFastProtocolHandler (AMQPFastProtocolHandler.java:175) -
IOException caught inAMQProtocolSession(/127.0.0.1:1125), session closed
implictly: javax.net.ssl.SSLHandshakeException: Initial SSL handshake failed.
javax.net.ssl.SSLHandshakeException: Initial SSL handshake failed.
at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:424)
It also seems to be a bug in the broker here: In such a case like this, the
broker closes the protocol session internally after the exception, but it does
not actively close the socket connection, which causes the client to hang
(since the server never sends a response back).
Eventually the client might close the connection and stop waiting for the
server to respond, but meanwhile valuable resources are being leaked at the
broker which might be a vector for a DOS attack.
> I can pretty reliably reproduce this stack trace when the client closes its
> side of the connection:
>
> 56303 [SocketAcceptorIoProcessor-0.0] ERROR
> org.apache.qpid.server.protocol.AMQPFastProtocolHandler - IOException
> caught inAMQProtocolSession(/127.0.0.1:47318), session closed implictly:
> java.io.IOException: Connection reset by peer
Humm, I don't get that with the .NET client; the connection closes cleanly.
Tomas Restrepo
[EMAIL PROTECTED]
http://www.winterdom.com/weblog/
