[rabbitmq-discuss] Program crashes in amqp_abort() on HP-UX 11.31

Tony Garnock-Jones tonygarnockjones+rabbitmq at gmail.com
Tue Jul 9 13:35:38 BST 2013


On 9 July 2013 07:30, Haster <haster2004 at yandex.ru> wrote:

> first thread creates all things (connection, channels to queue and
> exchanges), call basic.consume and start new thread that reads messages
> from
> queue and processes them...
>

In principle, this is fine. I would still not do it, myself: instead, I
would never let a connection "cross over" between threads. But that's
probably just superstitious of me :-)


> But first thread can call one method, that add some binds and maybe declare
> new exchanges
>

Aha! OK. Yes, that is probably the cause of the problem.

Try making sure that each thread has its own private connection to the
broker. Perhaps the thread that only occasionally needs to use a connection
could create it when needed, and destroy it when it is finished.

Connections *must* not be shared between threads[1].


> But can it be the root of problem?
> I use separate channel for each used exchange and queue.
>

There is *no* locking in librabbitmq, so *any* use of a connection across
threads requires you to do the locking manually.


> And one thing for thinking. My program crashes only on HP-UX 11.31, on
> windows, Solaris and Linux Red Hat it works well
>

My guess is that this is just chance. If two threads are sharing a single
librabbitmq connection without any mutexing, then the bug exists on all
platforms, even if it doesn't manifest deterministically.

Regards,
  Tony

[1] Unless you do some locking yourself, which is difficult and
error-prone, and not something I'd recommend.
-- 
Tony Garnock-Jones
tonygarnockjones at gmail.com
http://homepages.kcbbs.gen.nz/tonyg/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130709/21393eb7/attachment.htm>


More information about the rabbitmq-discuss mailing list