[rabbitmq-discuss] .NET Client (2.8.1) Unhandled exception

Jonathan Oliver jonathan.s.oliver42 at gmail.com
Thu Apr 19 18:18:55 BST 2012


We are using RabbitMQ Server (v2.8.1) on Windows Server 2008 R2 x64. And we 
have a few NET 4.0 applications using the .NET RabbitMQ client library 
(v2.8.1).  Recently, we encountered an issue that caused the client to hang 
and run the CPU at 100%.  Interestingly enough, this issue occurred on two 
servers that are remote to the RabbitMQ broker server.  We had another 
instance of the application running on the same box as RabbitMQ broker and 
it was unaffected.

For the two machines that were affected, we took a crash dump of 
the process and then fired up Windbg to look at the misbehaving threads and 
associated stack traces.  The stack traces revealed an unhandled exception 
within the RabbitMQ client library that was being raised:

Exception type:   System.IO.EndOfStreamException
Message:          SharedQueue closed
InnerException:   <none>
StackTrace (generated):
    SP       IP       Function
    053FF04C 00D05C77 UNKNOWN!RabbitMQ.Util.SharedQueue.EnsureIsOpen()+0x37
    053FF054 00D05B18 UNKNOWN!RabbitMQ.Util.SharedQueue.Dequeue(Int32, 
System.Object ByRef)+0x78
    053FF0D0 00D05914 
UNKNOWN!RabbitMQ.Client.MessagePatterns.Subscription.Next(Int32, 
RabbitMQ.Client.Events.BasicDeliverEventArgs ByRef)+0x44

Perhaps there was some kind of network hiccup (I'm not sure), but in any 
case, when the subscription was attempting to read from the SharedQueue, it 
tried to read past the end of the stream and this caused the above 
exception which was not handled by the RabbitMQ client library.  We're 
modifying our code slightly to address this issue for now, but you may want 
to have either Emile Joubert or Alexandru Scvortov take a look at the code 
see what can be done.

I wasn't exactly sure how to file an official bug report, so I thought I'd 
post the issue here.

One other "nice to have" that's on a slightly different topic but still 
related to the .NET client library would be to mark the various methods and 
properties within RabbitMQ.Client.MessagePatterns.Subscription as virtual 
such that they can be override (mocked) during testing or perhaps an 
interface created which Subscription implements. This would ease some of 
our testing because we had to create a wrapper class to make Subscription 
testable during our development.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120419/880ad64d/attachment.htm>


More information about the rabbitmq-discuss mailing list