Critical Description
A blocking recieve() with the java 0-10 client connected to the Java broker was observed to fail because the client connection timed out:
org.apache.qpid.transport.ConnectionException: Read timed out
at org.apache.qpid.transport.Connection.exception(Connection.java:474)
at org.apache.qpid.transport.network.Assembler.exception(Assembler.java:108)
at org.apache.qpid.transport.network.InputHandler.exception(InputHandler.java:197)
at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:145)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:123)
... 1 more
Examining the client logs reveals this to be because the client had heartbeating enabled despite the fact the Java broker is currently unable to generate 0-10 heartbeats (as its implementation is largely based on the client, and the client can only seems able to reflect heartbeats it recieves, not generate them at will, meaning neither client or server can initiate the heartbeating currently. See QPID-2796). As a result, the client timed the socket out after the defaulted 120sec heartbeat delay. The client default was allowed to be used because the broker innaccurately indicated it could support >0sec heartbeats by sending the wrong heartbeatMax value:
IoReceiver - localhost/127.0.0.1:5672 2010-09-19 16:21:52,980 DEBUG [apache.qpid.transport.Connection] RECV: [conn:e32802] ch=0 ConnectionTune(channelMax=65535, maxFrameSize=65535, hear
tbeatMin=0, heartbeatMax=65535)
IoReceiver - localhost/127.0.0.1:5672 2010-09-19 16:21:52,980 DEBUG [apache.qpid.transport.Connection] SEND: [conn:e32802] ch=0 ConnectionTuneOk(channelMax=65535, maxFrameSize=65535, he
artbeat=120)
Until QPID-2796 is fixed, the broker should not indicate it supports heartbeating.