users@shoal.java.net

Re: Shoal-Users Rules concerning servers and groups inside JVM

From: Shreedhar Ganapathy <Shreedhar.Ganapathy_at_Sun.COM>
Date: Wed, 08 Nov 2006 13:45:51 -0800

Hello Johan
Thanks for the answers.
Your use case is interesting in that they are almost the same
requirements in the case of our GlassFish Appserver! GF v2 will have
Shoal in it for this purpose.
Also, some of our plans ahead are to support state sync and caching as
part of this generic framework. So perhaps you could consider joining
our fledgling community as a developer contributor. You only need to
sign Sun's Contributor Agreement to contribute code, patches or test cases.

Some more below:

Johan Stuyts wrote:
>> 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.
Okay Got it. It does not hurt to support this case. So will add it to
our todos.
>
>> 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.
Done. Once you log the issue, could you point to specific code area you
were referring to for clarity. Alternatively you could also submit a
patch if you have time.
>
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>