[rabbitmq-discuss] difficulty closing connections in Windows Forms apps

[Geoffrey Anderson]

I am writing a Windows application (Windows form / executable) on Windows XP OS. I
am using rabbitmq-dotnet-client-1.4.0-net-2.0 to interface to RabbitMQ.

It's cool so far but my connection object seems to be stuck between 'a rock and hard
place' when I try to shut down my app.

These are really just the ABC's of making any app with a RabbitMQ server.  I seem to
be stuck on 'A'.  hahah

I have a crazy question.  Is it possible that I the first person to have written a
Windows Form application, you know, on Windows (not Mono), using the dotnet client
library for Rabbit MQ?  Careful, I'm not talking about console applications on
Mono....

I feel like I might be the first one here....   I've seen the example code, of
course, it's console code not a Windows GUI (for Windows, not Linux/Mono).

To Cut to the chase, here is what seems to be the problem:

1. My app is a long running app by its nature, & needs a long running connection. 
Why? Because the connection must be held open for a long time to allow a camera to
feed bitmaps continuously at a high rate of speed to my RabbitMQ.  The connection
needs to close, or be closed, when the app shuts down but no earlier.  OK fine I
know its possible b/c your nice "CAMCAPTURE" demo app works great on my computer. 
Excellent.  Now, in C# terms, this means the 'using' clause is not useful here.  In
other words the design of the app necessarily disallows imitation of the example
code which uses the 'using' style of connection creation and near-term destruction.
In other words I won't be disposing this connection right away.

I tried to solve it two different ways.

2. Scenario A (the Rock):  It hangs the app on shutdown, as if a thread inside the
library "didnt get the memo" that I am shutting down, when the code uses the
technique of setting the connection.AutoClose = True, and therefore the code does
not even try to call connection.Close() since the connection closure is taking care
of itself now.  But it hangs the app, like I said.  ( Please notice I am well aware
that you have to set up at least one channel before setting .AutoClose = true.  Dont
be distracted with that concept, as it's not the problem here.  I am writing my
camera bitmaps into the queue just fine during the applicaton's lifetime. )

3. Scenario B (the Hard place):  When I use connection.AutoClose = False style of
connection management, I added a line of code which executes at FormClose event
which simply does connection.Close().   In this case your .net library throws a
socket error saying that the connection was already destructed and is not a viable
object to be calling Close() on.  (I am paraphrasing, it's not exactly the text.) 
Hmmm...  OK I try one more thing:   I do this to make sure it's open before I close
it, that should prevent some problems, right?  No.  

 If (conn.IsOpen)
    conn.Close()

Well here's the funny thing.  The conn.IsOpen returns true, code execution moves to
the next line, and the conn.Close() doesn't even run.... it throws the error
indicating the connection object was already destructed.   Which is quite odd
because just a moment ago, one line of code earlier, the object was not destructed.

If anyone would like to show me a real Windows app in C# that has a working
connection management pattern, I would love to see it and copy your technique and
move on with my application.  The only requirement, should you choose to accept this
mission, is that you keep the connection open for the entire duration of the Windows
Form application's execution (but no longer than that!).

Am I supposed to avoid calling connection.Close() and just call Dispose()???  I
would think Close is there for a reason....  and that I should be able to call
Close() in some scenarios.  I know that the 'using' statement calls Dispose
implicitly in C#....

I am a beginner and I may be overlookign something, and I sure hope that's the case
actually.  If you can tell me something simple that I can fix in my application code
then I've accmomplished something useful today.

I've written multithreaded code before.  It sure feels like the connection.AutoClose
= True is not actually stopping a library thread like we want it to, when I shut
down my app.  Just a guess.  Could be wrong.


Thanks for reading.

Geoffrey