[rabbitmq-discuss] .NET BasicPublish randomly blocks forever

Tue Jan 26 21:24:47 GMT 2010

Hi,

this is my first RabbitMQ project, and I'm trying to signal a Java
application from a Mono/.NET app. So the Mono application only sends
messages (multithreaded, locking the IModel / channel before publishing),
while the Java application only retrieves them. One virtual host, one
exchange bound to one queue, direct type, one routing key, RabbitMQ 1.7.0
client libraries. Both apps use guest logins (i.e. no authentification).

On my dev environment (Ubuntu 09.10) running RabbitMQ server 1.6.0-1ubuntu,
everything runs fine. In the production environment (Debian testing on a
Virtuozzo virtual server) running RabbitMQ server 1.7.0-3, the Mono
application (the message publishing thread, to be precise) randomly blocks
forever when calling BasicPublish.

I found some side effects that frame "randomly" a bit. Given RabbitMQ server
is running, the Java app is running and created the exchange, queue and
binding, I start the Mono app, which blocks after successfully publishing
some (or no) messages. Then:

1)  I kill the Java app, the Mono app unblocks (!) and continues.

1a) If I design the Mono app to create a fresh IModel (channel) before
sending each message, it successfully publishes some more messages before
blocking again.

1b) Restarting the Java app does not influence 1a) behavior, meaning the
"kill Java app to unblock the Mono app" trick only works exactly once.

2) I kill the RabbitMQ server, the Mono app unblocks (throwing an AMQP
close/shutdown exception) and continues.

I tried downgrading the production environment to RabbitMQ 1.6.0-1 - same
effect. The rabbitmqctl outputs all look correct (regarding connections,
exchanges, bindings); list_queues does not change after the Mono app blocks.

The log has a lot of entries like these:

=INFO REPORT==== 24-Jan-2010::15:12:34 ===
    alarm_handler: {set,{system_memory_high_watermark,[]}}

=INFO REPORT==== 24-Jan-2010::15:12:35 ===
    alarm_handler: {clear,system_memory_high_watermark}

After reading the docs, I figured these errors would cause RabbitMQ telling
the application to stop sending messages. So I added these parameters to the
startup command line:
-os_mon memory_alarms false -os_mon memsup_system_only false -os_mon
memsup_system_only false'
to get rid of them. (In Virtuozzo VMs, it seems there's no way to get a
valid figure of free memory, so this always triggers.) No effect though, the
Mono app still blocks.

Any ideas on where else to look?
Dominik

PS: The Mono app should continue committing changes to a MySQL DB in
concurrent threads. Interestingly enough, these commits (via Castle
ActiveRecord / NHibernate) seem to stop as soon as the first BasicPublish
call blocks.
-- 
View this message in context: http://old.nabble.com/.NET-BasicPublish-randomly-blocks-forever-tp27295461p27295461.html
Sent from the RabbitMQ mailing list archive at Nabble.com.