Josh Tilles, how did you manage connection failure with Langhor and
component, I thought there were an automatic connection recovery by default.
Le lundi 7 septembre 2015 01:57:30 UTC+2, Josh Tilles a écrit :
>
> Thanks a ton for writing all of this up. I'm actually using Langohr &
> RabbitMQ as well, so I have the sense that you've solved problems that I
> might encounter down the road.
>
> On Friday, September 4, 2015 at 7:57:21 AM UTC-4, Dave Tenny wrote:
>>
>> I'm using components to encapsulate Langohr/RabbitMQ interactions in
>> cases where Langohr auto-recovery wasn't happy with what was going on.
>>
>> I make sure the Lifecycle methods are idempotent, built the component
>> stack in the correct order.
>>
>> To make sure that I can deal with the exceptions that require restarting
>> the component stack, I have some macros that wrap up exception handling,
>> retries, and component stack restarts.
>>
>> So
>>
>> (with-rmq-publisher! [channel component-system]
>> ... do my stuff ...)
>>
>> The body of the macro ("... do my stuff ...") is turned into a function
>> and and will be re-executed if the system is restarted, so you have to
>> beware
>> of side effects or other things you may not want executed multiple times.
>> Not a problem for me, all I'm doing is entering the macro long enough
>> to get a channel and publish to it, or similar types of things.
>>
>> The component-system is a wrap of the system-map call with some other
>> data, in an atom, that will be mutated
>> if we do things like dynamically add subscribers to the system or call
>> (restart! component-system).
>> There are some thread safety/locking concerns, since a connection failure
>> is likely to be seen by callers
>> on multiple threads using the components, and I try to avoid race
>> conditions on restarts (only one thread will do the restart until it
>> succeeds,
>> the unblock the others).
>>
>> Hope this helps with strategy, even if the code is omitted.
>>
>> The trick to me was not in restarting the component stack, but in
>> managing the shared state across threads safely and making sure
>> (with-stack-activity [system] <code>)
>> code was prepared to re-execute on failures with new connections or other
>> stack components.
>>
>> In my case I also needed to add components to the stack dynamically. Not
>> often, but dynamcially, not at (system-map) call time. That required some
>> lock consideration,
>> and I'd have to call Lifecycle/start on the stack every time I added a
>> component. They methods have to be idempotent.
>>
>>
>>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
