PHP engine errors cause infinite retries

[jeffkotula]

If the PHP code being called by the consumer exits due to a PHP engine failure -- e.g. memory exhaustion or a compile error) the consumer will simply keep calling the code over and over. The only wait to stop it seems to be killing of supervisord -- removing the entry from the rabbit queue at this point doesn't seem to work.

[andrefigueira]

Are you using --strict-exit-code ? Or is the exit code thrown not one that would be caught by this flag?

[jeffkotula]

Yes. I don't know if an exit code is even provided in this case, actually. I've got my stuff wrapped in a try-catch but this type of error completely bypasses it.

On Wed, Nov 30, 2016 at 8:12 AM, André Figueira notifications@github.com wrote:

Are you using --strict-exit-code ? Or is the exit code thrown not one that would be caught by this flag?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ricbra/rabbitmq-cli-consumer/issues/49#issuecomment-263882694, or mute the thread https://github.com/notifications/unsubscribe-auth/AXJgktCpli-YuOpktvXDGOJx_cYKmI9gks5rDYRFgaJpZM4LAOxi .

--

Jeff

[ricbra]

I prefer to configure a DLX where failed messages get parked for x minutes/hours and then retry them.

[jeffkotula]

Well, that would be fine. But the behavior right now is that the handler is just invoked right away, again, ad infinitum. That's definitely not preferred... :)

On Wed, Nov 30, 2016 at 9:18 AM, Richard van den Brand < notifications@github.com> wrote:

I prefer to configure a DLX where failed messages get parked for x minutes/hours and then retry them.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ricbra/rabbitmq-cli-consumer/issues/49#issuecomment-263899488, or mute the thread https://github.com/notifications/unsubscribe-auth/AXJgkhjOfe8N1yHk-Hg8Y7v13PHKtygyks5rDZPdgaJpZM4LAOxi .

--

Jeff

[ricbra]

Yes, that's the current behaviour. It would be nice if you could configure a max retry count (like supervisor does) and when then this limit is reached the consumer will kill itself. If someone wants to contribute this, I'm happy to merge it. Most people running this consumer (including me) don't like it when the consumer die (hence, thats one of the reasons I once started writing this consumer) and that's the reason why it's currently implemented like this.

btw. @vicdelfant you should configure your out-of-office properly so it doesn't reply to automated mails, I'm getting spammed atm

[jeffkotula]

Well, I don't think we necessarily need the consumer to die -- just discard the entry from the queue and move on...

On Wed, Nov 30, 2016 at 10:49 AM, Richard van den Brand < notifications@github.com> wrote:

Yes, that's the current behaviour. It would be nice if you could configure a max retry count (like supervisor does) and when then this limit is reached the consumer will kill itself. If someone wants to contribute this, I'm happy to merge it. Most people running this consumer (including me) don't like it when the consumer die (hence, thats one of the reasons I once started writing this consumer) and that's the reason why it's currently implemented like this.

btw. @vicdelfant https://github.com/vicdelfant you should configure your out-of-office properly so it doesn't reply to automated mails, I'm getting spammed atm

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ricbra/rabbitmq-cli-consumer/issues/49#issuecomment-263926943, or mute the thread https://github.com/notifications/unsubscribe-auth/AXJgksE2pfenybmic_Y9S488WgaZ5_x9ks5rDakugaJpZM4LAOxi .

--

Jeff

[vicdelfant]

@ricbra sorry about that, FrontApp doesn't seem to handle those properly indeed. Apologies!