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.
