search

twingly / twingly-amqp

:bus: Ruby gem for RabbitMQ subscribing and publishing
0 stars 0 forks source link

Handle exceptions #3

Open jage opened 9 years ago

jage commented 9 years ago

I think it's important that we try to figure out how to handle different Bunny (and OpenSSL) exceptions in this gem. In most of our applications it's mostly annoying (Sentry notifications), but in others like Mako and Ganges it could take the application down if exceptions are not handled carefully.

Basically we need to handle:

dentarg commented 8 years ago

Note: closed issues above can be closed because the issues are covered by other issues (duplicates), not because they are solved

twingly-mob commented 7 years ago

RabbitMQ server shutdown

We have HA in our datacenter, but twingly-amqp can't switch server without causing problems.

jage commented 7 years ago

Found an interesting example which might be useful for testing, i.e. compare this with a twingly-amqp-implementation.

walro commented 7 years ago

Upgraded RabbitMQ, which caused restart. Two projects did not like it still.

roback commented 6 years ago

Bunny >=2.9 tries to reconnect on timeout errors: https://github.com/ruby-amqp/bunny/blob/master/ChangeLog.md#connection-recovery-now-retries-on-timeouts

Related PR: https://github.com/ruby-amqp/bunny/pull/537

dentarg commented 6 years ago

Could be some help in the article at https://www.cloudamqp.com/blog/2018-01-19-part4-rabbitmq-13-common-errors.html

One thing I wondered if we are following was:

Use separate connections for publish and consume.

walro commented 4 years ago

Use separate connections for publish and consume.

Without looking, I'd say no. I think we share the same connection.