Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception in Service Kills Consumer #1

Open
devinfoley opened this issue Jun 24, 2010 · 3 comments
Open

Exception in Service Kills Consumer #1

devinfoley opened this issue Jun 24, 2010 · 3 comments

Comments

@devinfoley
Copy link

I perform some database operations in my rabbitQueue listener service via GORM. Occasionally, under high volume, I get a org.springframework.dao.CannotAcquireLockException. This causes the associated consumer to hang, and eventually, all consumers get hung and stop processing messages. At this point, I have to restart RabbitMQ to get things going again.

I'm just running save() on a domain model with semi high volume (1-2 million per day).

I plan to find and fix the cause of my CannotAcquireLockException but it would be nice if the RabbitMQ was more fault tolerant as well. Is this something that can be handled by the plugin?

Thanks!

@devinfoley
Copy link
Author

I think I finally figured out the cause of this...

doWithSpring is declaring queues via RabbitTemplate before doWithApplicationContext assigns the MessageListener delegates. So, the queue is declared before an appropriate listener has been assigned, resulting in un-ack'd messages from the server. The effect of this is that this plugin cannot receive messages from queues which have messages waiting for delivery at boot time.

I'm working to commit a fix.

@markpollack
Copy link

Hi, this is Mark who wrote some of the underlying java stuff for message listening. There is a bug that we need to work out in message handling when exceptions are thrown. We are actually talking with the RabbitMQ team to make sure we do 'the right thing here' and want to get a fix out for that quickly.

As for the second issue, declaring queues before listeners are consuming is OK, it is quite a typical case from the administrative point of view as far as I can tell. If the messages are persistent you will still receive them when the listener starts - I've done this several times but at the Java level, maybe something is going on in the plug-in, we need to reproduce the situation within the grails environment.

@jaGarcia
Copy link

Did this ever get resolved? It looks like i'm running into this.

selamialtin pushed a commit to selamialtin/grails-rabbitmq that referenced this issue Mar 18, 2021
selamialtin pushed a commit to selamialtin/grails-rabbitmq that referenced this issue Mar 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants