[rabbitmq-discuss] RabbitMQ C library function amqp_simple_wait_frame takes 400 ms

Sat Jun 26 02:57:17 BST 2010

Jim,

I believe that you are looking at a TCP/IP issue here (which you may or may
not be able to address by modifying the libRabbitMQ code). My guess is that
if you set the TCP/IP kernel parameter tcpnodelack (or whatever it is called
on your operating system) to 1 (i.e. don't delay acknowledging TCP data),
you will see things improve rather significantly. Depending on what platform
you're using, you may be able to stick a setsockopt() call (using the option
TCP_NODELACK) in amqp_socket.c between the socket() call and the connect()
call instead of having to make the chnage globally by messing with the
kernel parameter.
For what it's worth, I encountered this problem with libRabbitMQ-C on
OpenVMS just last week.. Luky for me I've seen the problem before. Seem to
recall that you guys at umich.edu used to have some OpenVMS systems...

Regards,
Brett

On Sat, Jun 26, 2010 at 11:54 AM, David Wragg <david at rabbitmq.com> wrote:

> Hi Jim,
>
> Jim Irrer <irrer at umich.edu> writes:
> > I'm working on two functions that act as a client-server pair.  They
> > use two amq.direct queues to communicate.  When ever either of
> > them calls the amqp_simple_wait_frame function, it does not return
> > for 436618 microseconds.
> >
> > Some other background info that might be relevant:
> >
> > If I only send messages in one direction it's really fast.
> >
> > Both processes are using separate connectors and different sockets.
> >
> > I used the amqp_consumer.c amqp_producer.c code in
> > the examples directory as a reference.
> >
> > Is there a way to avoid this delay?
>
> I'm not sure what you are really asking here.  As its name suggests,
> amqp_simple_wait_frame waits for a frame to arrive.  It will typically
> attempt to read from the socket connected to the AMQP server.  If no
> data is available, it will block until data is available.  The resulting
> delays are thus an intrinsic feature of amqp_simple_wait_frame.
>
> Are you sure that the 400ms delay does not simply reflect the wait for a
> message to arrive?
>
> I'm guessing, but perhaps the problem is that you want a single
> application to publish and consume messages concurrently, and you are
> finding that the synchronous nature of amqp_simple_wait_frame is an
> obstacle?  If so, the simplest work around would be to have two threads,
> one to publish and one to consume, and open a separate AMQP connection
> in each thread.
>
> > Also ...
> >
> > Could I use the same socket in each program as long as it was only
> > used by one thread at a time?
> >
> > Could I use the same connection in each program if it was only
> > used by one thread at a time?
>
> What's the distinction between socket and connection here?
>
> librabbitmq does not do anything to explicitly support multithreading,
> but neither does it do anything to conflict with it.  If you, the
> application programmer, ensure that for a given connection, only one
> thread uses librabbitmq at a time, you should be safe.
>
> --
> David Wragg
> Staff Engineer, RabbitMQ
> SpringSource, a division of VMware
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100626/a2ad68c0/attachment.htm>