[rabbitmq-discuss] librabbitmq-c and amqp_channel_close

Fri Jun 22 17:19:27 BST 2012

On 06/22/2012 11:55 AM, Matthias Radestock wrote:
> Closing a channel is a synchronous operation, the completion of which
> provides various guarantees on resource reclamation (e.g. exclusive
> queues get deleted, etc). Depending on what operations were performed on
> that channel prior to closure a fair amount of tidying up / cleaning up
> might take place, some of which involves taking (the equivalent) of
> exclusive write logs on server-wide shared data structures, doing
> fsyncs, etc.
>
> So what you are seeing may not be unusual.

Ah, that makes sense -- and if it's I/O bound, it may explain why I 
haven't been able to reproduce it on my test machine.  I don't suppose 
there's an equivalent async method?  I'm not seeing anything obvious in 
the source....  I'm leery about threading it off, given librabbitmq-c's 
lack of thread safety.

This is happening as a client is unsubscribing from a queue (and closing 
the associated channel), so we won't be trying to touch the channel 
again (obviously).  Architecturally, it seems like there's no reason to 
wait on the client side for it to complete.

It's only an issue because the unsubscribe is occurring at the end of a 
query-response cycle, and is delaying the return of data to the 
requester (yeah, I know, pub/sub is generally better, but rewriting 
legacy procedural/synchronous code to be event-driven is a slow 
process).  We won't be doing anything else with the channel, so if we 
could tell the server we don't need a response, I'd be happy.

Failing that, any thoughts on what can be done server-side to speed up 
the process?  Do durable queues/exchanges exacerbate the problem?

Thanks much,

-Brennan