[rabbitmq-discuss] Possible bug when disposing connections in .NET client 2.7.0/1

Fri Dec 30 15:30:03 GMT 2011

This really does look like a bug.  Thanks for spotting this.
I'm raising a bugzilla (bug24650) to track it, and will report back.

Steve Powell  (a yule bunny)
----------some more definitions from the SPD----------
avoirdupois (phr.) 'Would you like peas with that?'
distribute (v.) To denigrate an award ceremony.
definite (phr.) 'It's hard of hearing, I think.'
modest (n.) The most mod.

On 29 Dec 2011, at 22:16, Dave Stevens wrote:

> Yes, heartbeat is what is causing this. Version 2.7.1 of the .NET
> client is itself calling System.Net.Sockets.TcpClient.Close() 3 times
> per connection shutdown (4 if shutdown times out).
> ConnectionBase.FinishClose() is called 3 different times when shutting
> down.See MainLoop(), HeartbeatReadLoop(), and HeartbeatWriteLoop() of
> ConnectionBase.cs lines 629, 566 and 538 respectively.
> I am required to set the Heartbeat due to another issue where
> exclusive queues are not being removed at the broker when connections
> died. This prevents components from being able to restart with the
> same queue name.
> See http://stackoverflow.com/questions/8296201/when-does-an-amqp-rabbitmq-channel-with-no-connections-die/8299475
> 
> I believe that even with this, ConnectionBase.FinishClose() will be
> called once successfully which would allow the models to shutdown
> properly. I believe this is a bug though as FinishClose() should not
> be called more than once or it is possible that certain event handlers
> will be called more than once, Session.OnSessionShutdown specifically.
> This may impact certain reconnect implementations.
> 
> On Dec 29, 4:38 pm, Simone Busoli <simone.bus... at gmail.com> wrote:
>> What happens if you remove the heartbeat setting?
>> On Dec 29, 2011 5:43 PM, "Dave Stevens" <daverstev... at gmail.com> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> I get the same exception with this:
>> 
>>>         [Test(Description = "ObjectDispositionException")]
>>>         public void TestFail()
>>>         {
>>>             var cf = new ConnectionFactory
>>>                          {
>>>                              HostName = "10.10.8.96",
>>>                              Port = 5672,
>>>                              RequestedHeartbeat = 2
>>>                          };
>>>             using (var connection = cf.CreateConnection())
>>>             using (var model = connection.CreateModel())
>>>             {
>>>                 Thread.Sleep(TimeSpan.FromSeconds(1));
>>>             }
>>>         }
>> 
>>> On Thu, Dec 29, 2011 at 2:59 AM, Simone Busoli <simone.bus... at gmail.com>
>>> wrote:
>> 
>>>> Hi Dave, although counterintuitive the documentation of the .NET client
>>> states that explicitly. The connection closure/disposal is not idempotent,
>>> i.e. you shall not call it twice.
>> 
>>>> On Dec 29, 2011 1:41 AM, "Dave Stevens" <daverstev... at gmail.com> wrote:
>> 
>>>>> I am getting the following exception when disposing a connection. I
>>>>> had previously noticed this when going from RabbitMQ Client 2.5.1 to
>>>>> 2.7.0 which caused me to back out the update. I ended up going to
>>>>> 2.7.1 because I thought I found a shutdown issue in my own code. The
>>>>> exception did not present itself again until I started testing some
>>>>> reconnect logic. I first noticed it again after simply pulling the
>>>>> plug on my network.
>> 
>>>>> System.ObjectDisposedException: Cannot access a disposed object.
>>>>> Object name: 'System.Net.Sockets.Socket'.
>>>>> at System.Net.Sockets.Socket.SetSocketOption(SocketOptionLevel
>>>>> optionLevel, SocketOptionName optionName, Object optionValue)
>>>>> at RabbitMQ.Client.Impl.SocketFrameHandler_0_9.Close()
>>>>> at RabbitMQ.Client.Impl.ConnectionBase.FinishClose()
>>>>> at RabbitMQ.Client.Impl.ConnectionBase.HeartbeatWriteLoop()
>>>>> at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
>>>>> at System.Threading.ExecutionContext.runTryCode(Object userData)
>>>>> at
>> 
>>> System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCle anup(TryCode
>>>>> code, CleanupCode backoutCode, Object userData)
>>>>> at System.Threading.ExecutionContext.RunInternal(ExecutionContext
>>>>> executionContext, ContextCallback callback, Object state)
>>>>> at System.Threading.ExecutionContext.Run(ExecutionContext
>>>>> executionContext, ContextCallback callback, Object state, Boolean
>>>>> ignoreSyncCtx)
>>>>> at System.Threading.ExecutionContext.Run(ExecutionContext
>>>>> executionContext, ContextCallback callback, Object state)
>>>>> at System.Threading.ThreadHelper.ThreadStart()
>> 
>>>>> This code is reproducible consistently with the following:
>> 
>>>>> using System;
>>>>> using System.Threading;
>>>>> using NUnit.Framework;
>>>>> using RabbitMQ.Client;
>>>>> using RabbitMQ.Client.Framing.v0_9;
>> 
>>>>> namespace BT.ThirdPartyProxy.Functional.Test.FunctionalTests
>>>>> {
>>>>>    [TestFixture]
>>>>>    public class TestingObjectDispositionException
>>>>>    {
>>>>>        [Test(Description = "ObjectDispositionException")]
>>>>>        public void TestFail()
>>>>>        {
>>>>>            var cf = new ConnectionFactory
>>>>>                         {
>>>>>                             HostName = INSERT_IP_HERE,
>>>>>                             Port = 5672,
>>>>>                             RequestedHeartbeat = 2
>>>>>                         };
>>>>>            using (var connection = cf.CreateConnection())
>>>>>            using (var model = connection.CreateModel())
>>>>>            {
>>>>>                Thread.Sleep(TimeSpan.FromSeconds(1));
>>>>>                model.Close(Constants.ReplySuccess, "Goodbye");
>>>>>                connection.Close(Constants.ReplySuccess, "Goodbye");
>>>>>                Thread.Sleep(TimeSpan.FromSeconds(1));
>>>>>            }
>>>>>        }
>>>>>    }
>>>>> }
>> 
>>>>> I am using RabbitMQ.Client.dll 2.7.1.0 in .NET 4.0 app on Windows
>>>>> server 2003 going against RabbitMQ 2.7.0 running on Ubuntu.
>> 
>>>>> Status of node rabbit at xxx ...
>>>>> [{pid,1344},
>>>>>  {running_applications,
>>>>>     [{rabbitmq_management,"RabbitMQ Management Console","2.7.0"},
>>>>>      {rabbitmq_management_agent,"RabbitMQ Management Agent","2.7.0"},
>>>>>      {amqp_client,"RabbitMQ AMQP Client","2.7.0"},
>>>>>      {rabbit,"RabbitMQ","2.7.0"},
>>>>>      {os_mon,"CPO  CXC 138 46","2.2.5"},
>>>>>      {sasl,"SASL  CXC 138 11","2.1.9.3"},
>>>>>      {rabbitmq_mochiweb,"RabbitMQ Mochiweb Embedding","2.7.0"},
>>>>>      {webmachine,"webmachine","1.7.0-rmq2.7.0-hg"},
>>>>>      {mochiweb,"MochiMedia Web Server","1.3-rmq2.7.0-git"},
>>>>>      {inets,"INETS  CXC 138 49","5.5.2"},
>>>>>      {mnesia,"MNESIA  CXC 138 12","4.4.17"},
>>>>>      {stdlib,"ERTS  CXC 138 10","1.17.3"},
>>>>>      {kernel,"ERTS  CXC 138 10","2.14.3"}]},
>>>>>  {os,{unix,linux}},
>>>>>  {erlang_version,
>>>>>     "Erlang R14B02 (erts-5.8.3) [source] [64-bit] [smp:8:8] [rq:8]
>>>>> [async-threads:30] [kernel-poll:true]\n"},
>>>>>  {memory,
>>>>>     [{total,31177024},
>>>>>      {processes,11828776},
>>>>>      {processes_used,11772888},
>>>>>      {system,19348248},
>>>>>      {atom,1355273},
>>>>>      {atom_used,1339382},
>>>>>      {binary,84928},
>>>>>      {code,14547474},
>>>>>      {ets,1099944}]},
>>>>>  {vm_memory_high_watermark,0.39999999995232727},
>>>>>  {vm_memory_limit,5034326425}]
>>>>> ...done.
>>>>> _______________________________________________
>>>>> rabbitmq-discuss mailing list
>>>>> rabbitmq-disc... at lists.rabbitmq.com
>>>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>> 
>> 
>> 
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss