I'm using DPS as a routing engine, basically. We will have multiple nodes
of a particular type connecting into the system which are basically
different applications that have different needs. These different
applications should only consume a message one time, but it doesn't matter
which of their nodes gets it (load balancing or competing consumers).
As far as requiring the cluster to stay in-tact, I'm not really concerned
about that so much and that's to be expected that things will happen ("let
it fail" right), but what I do want to be able to do is, in a controlled
fashion, upgrade a running system to a new version by doing some sort of
rolling restart approach, or the like. That's what I'm trying to
understand is how do folks do that? Sure, things will happen when things
don't go as planned, but I want to at least come up with the "as planned"
situation first before we worry about the failure scenarios.
On Monday, July 6, 2015 at 1:04:49 PM UTC-4, Michael Frank wrote:
>
> what problem are you trying to solve with DistributedPubSub? if you are
> not tolerant to losing some messages, then DistributedPubSub might not be
> appropriate in your scenario.
>
> i wouldn't depend on always being able to gracefully leave the cluster in
> production! node failures and network partitions are a fact of life.
>
> -Michael
>
> On 07/06/15 06:08, James Carman wrote:
>
> We are considering using the DistributedPubSub support in a production
> system. We would like to be able to upgrade this system on the fly. I am
> trying to get some advice on that sort of setup. What we've seen is that
> when a node dies, we definitely have missed messages. However, when I
> issue the "leave" command (via JMX), things appear to clean up gracefully.
> Obviously, we would use the "leave" command in a production upgrade
> scenario, but is there anything we can do (other than setting up the
> at-least-once-delivery stuff) to get the cluster to more gracefully recover
> from a node failure? I've been playing around with this stuff using this
> very simple project on github:
>
> https://github.com/jwcarman/akka-cluster-sandbox
>
> Basically, I've set it up so that there are three "seed" nodes, which I
> start up together. Then, I fire up the "client" node, which basically just
> sends strings to one of the seed nodes using a
> DistributedPubSubMediator.Send message.
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected]
> <javascript:>.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
