> Glad. At some point, we are interested in the kinds of use cases, this
> library is useful for. So do let us know.
My use case is that I want to synchronize the state of components running
in different JVMs. The state should be made consistent during failures
and/or additions of a single node. This is for the purpose of load
balancing and fault tolerance. The load balancing mechanism will be
external to the server and client applications, i.e. neither the clients
nor the servers determine which server to use but a dedicated load
balancer does.
> The original intention based on straightforward use cases was to allow
> one GMS module per group. I have not tested a situation where in two
> client components become members of the same group within the same JVM.
> The member type should not be of consequence in this case. It is
> conceivable that this can be allowed but in my earlier experience with a
> unit test containing two members within the same JVM and using JGroups
> underneath, this was not allowed by that provider. Jxta should not have
> such an issue.
> This is an RFE for us.
I do not need this functionality so you do not have to consider this to be
an enhancement request. Other people might need it though. I only want to
know what is allowed and what is not so my programs will continue to work
while Shoal evolves.
> That should be a bug. I will look into this. Could you file an issue?
The issue tracker only has subcomponent 'www' at this moment. Can you add
a subcomponent for the code? Thanks.
> This will help us track these issues actively.
> Also how critical are these issues for your use case ? (if you could
> state your use case as well, it will help us incorporate this into our
> evolving design discussions. You are welcome to participate on those as
> well.)
As I said before they are not critical at all. I just want to use Shoal in
the correct way.
Kind regards,
Johan