On Wed, Sep 17, 2014 at 11:41 AM, Rodrigo Boavida rodrigo.boav...@gmail.com
wrote:
Tnks again Patrik. I'm happy not to be the only one having this kind of
requirement.
You're welcome
I will definitely have a look at this and will give you some feedback.
Thanks, looking forward to that
Tnks for the reply Patrik.
Yes we have that option on the table as well, but would each node in the
cluster still participate in the gossip control of all the other nodes, or
would it be confined to nodes within the same role?
Let me expand a bit on what we have. Both backend and front end
Hi Konrad,
We have the same requirement. The reason why we need this approach is
because we need two types of cluster: Web and Processing cluster. Both have
different lifecycles and concerns, but the Web cluster needs to subscribe
to data sources processed by the backend cluster. The
Hello Brian,
yeah this sounds OK to me.
You may want to tweak when the cluster determines to be up:
http://doc.akka.io/docs/akka/snapshot/scala/cluster-usage.html#how-to-startup-when-cluster-size-reached
Happy hakking!
On Thu, Aug 7, 2014 at 5:35 PM, Brian Dunlap bdunla...@gmail.com wrote:
Hi Brian,
No, PubSub works within a cluster – it needs to know which nodes to send
messages to, right?
However you could have a subscriber that will mediate the messages to the
other cluster via Cluster Client –
http://doc.akka.io/docs/akka/2.3.4/contrib/cluster-client.html
Would that help in your
Is it possible to connect DistributedPubSub mediators between
**different** ActorSystems?
In ClusterSystemA we'd like to subscribe to events from the ClusterSystemB
mediator.
We need **separate** clusters - that's why can't use the same cluster name.
Thanks!
Brian -
--
Read the
