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.
