[rabbitmq-discuss] TCP timeout is also happening for C# clients

Tue May 13 22:54:52 BST 2008

FYI: I have found that a Hearbeat adjustment solves a BasicPublish() timeout problem
in dotnet clients.

OK guys thanks for guidance with diagnosing the connection problems.  It is solved
after I created an environment variable.

Now I progressed to the next problem (progress of sorts).  But I bring a solution
too.

It all started when I called this line of code in my C# application:

mqModel.BasicPublish(mqTicket, mqExchange, mqRoutingKey, null,
builder.GetContentBody());

The following exception is always thrown by it:

"AMQP close-reason, initiated by Library, code=541, text=\"Unexpected Exception\",
classId=0, methodId=0, cause=System.IO.IOException: Unable to read data from the
transport connection: A connection attempt failed because the connected party did
not properly respond after a period of time, or established connection failed
because connected host has failed to respond. --->
System.Net.Sockets.SocketException: A connection attempt failed because the
connected party did not properly respond after a period of time, or established
connection failed because connected host has failed to respond\r\n   at
System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size,
SocketFlags socketFlags)\r\n   at System.Net.Sockets.NetworkStream.Read(Byte[]
buffer, Int32 offset, Int32 size)\r\n   --- End of inner exception stack trace
---\r\n   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
Int32 size)\r\n   at System.IO.Stream.ReadByte()\r\n   at
System.IO.BinaryReader.ReadByte()\r\n   at
RabbitMQ.Client.Impl.Frame.ReadFrom(NetworkBinaryReader reader)\r\n   at
RabbitMQ.Client.Impl.SocketFrameHandler_0_9.ReadFrame()\r\n   at
RabbitMQ.Client.Impl.ConnectionBase.MainLoopIteration()\r\n   at
RabbitMQ.Client.Impl.ConnectionBase.MainLoop()"

So I looked around for solutions on the web, and discovered a "Java"-related
discussion recently in the mailing list:

http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-May/001183.html

The topic is TCP timeouts.

One possible solution to the "java" problem was proposed by manipulating the
heartbeat value of the connection factory:

http://www.rabbitmq.com/javadoc/com/rabbitmq/client/ConnectionParameters.html#setRequestedHeartbeat(int

But now I'm using C# rather than Java but the symptoms looked similar enough.

So I added a line of C# code to manipulate the heartbeat, just before it runs the
CreateConnection():

mqFactory.Parameters.RequestedHeartbeat = 50;

50 is a totally wild first guess but it actually works.

As a result of heartbeat modification my BasicPublish() call runs OK now.  I dont
get the exception, and the code continues flowing in the preferred way.

I just want you all to know that by appearances this is not strictly a java specific
problem but the discussion seemed to assume it was limited to java clients, or
limited to the Sun company's products.

http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-May/001211.html

Excerpt:  "A very interesting anomaly indeed, especially considering that it only 
seems to affect 1.5, not 1.4 or 1.6. However, as far as I can tell this 
behaviour can only occur with one CPU."

http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-May/001207.html

Actually I do have just one CPU core, it's true, but I do not code in java, just C#.

Here is what my log shows FWIW.

=INFO REPORT==== 13-May-2008::17:22:42 ===
Rolling persister log to "c:/Documents and
Settings/ga/rabbitmq/db/rabbit-mnesia/rabbit_persister.LOG.previous"

=INFO REPORT==== 13-May-2008::17:22:43 ===
started TCP listener on 0.0.0.0:5672

=INFO REPORT==== 13-May-2008::17:23:01 ===
accepted TCP connection on 0.0.0.0:5672 from 192.168.1.100:1551

=ERROR REPORT==== 13-May-2008::17:23:03 ===
error on TCP connection from 192.168.1.100:1551
connection_closed_abruptly

=INFO REPORT==== 13-May-2008::17:23:03 ===
closing TCP connection from 192.168.1.100:1551

I now suspect there is a threading bug in the RabbitMQ stack and it is common to
both C# and java clients either by repetition of a mistaken code pattern, or by some
code layer in the RabbitMQ system which is shared in common by clients of both
languages.  Solutions applied in the application layer are probably not the best
way.

Hope this helps the knowledge base.

Geoffrey