Alex P <oleksandr.petrov at> writes:
As far as I understood, that even though Librabbitmq is event-driven, it
doesn't mean it's non-blocking, right?
Correct. librabbitmq does not really support non-blocking use.
For instance, wait_frame_inner is blocking until we recv() is responding
with something useful.

Are there ways to work it around? We actually need some non-blocking
approach, since we want to be able to send heartbeats and do many other
things in same thread, while we have no data available.

Actually, just changing that function would change many things. As far as I
can tell, Send() calls are currently blocking as well, even though they're
unlikely to block cycle for long time.

Should we just use several threads and create a connection per thread, or
there are better approaches that were built into the lib?
It's better to use threads that to try to persuade librabbitmq to do
non-blocking operation.
Thanks for the help, again.
It seems that something is causing basic_get to eat out memory when ran in
cycle. If i manage to reproduce it without app itself and have more info,
i'll file a bug-report. For now it may very well be my mistake(
Make sure you call amqp_maybe_release_buffers when you are finished with
each message, as shown at

David Wragg
Staff Engineer, RabbitMQ
VMware, Inc.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 6 | next ›
Discussion Overview
grouprabbitmq-discuss @
postedSep 2, '11 at 10:35a
activeSep 2, '11 at 9:37p

2 users in discussion

Alex P: 4 posts David Wragg: 2 posts



site design / logo © 2022 Grokbase