Hello Johan
Thanks very much for your feedback. This sort of feedback helps with the
fine tuning and improving the quality of the library. More below:
Johan Stuyts wrote:
> Hi,
>
> First of all, thanks for this great library. I am doing some tests at
> this moment and it is looking very good.
Glad. At some point, we are interested in the kinds of use cases, this
library is useful for. So do let us know.
> I have a couple of questions about the rules concerning the valid
> server and group combinations running inside the same JVM. I use
> GMSFactory to create GMS modules, but it is unclear to me which
> combinations of server IDs and groups are allowed inside the same JVM.
> Looking at the code of GMSFactory did not help. My questions are:
> - is it allowed to have two modules for the same group inside the same
> JVM? For example, server ID A as a core member and server ID B as a
> spectator, or both server ID A and B as core members.
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.
> - Is it allowed to use different server IDs for different groups? For
> example, server ID A as a member of group foo and server ID B as a
> member of group bar.
Yes. This should not be an issue. These will be two different GMS
modules (or instances).
>
> IMHO, GMSFactory should actively check for violations of the answers
> to my questions and throw a runtime exception if the user attempts to
> create an invalid combination.
I agree.
>
> Also, I think that GMSFactory is broken. To check for the existence of
> a group the server ID passed to startGMSModule is not used. Instead a
> static variable is used that is set on the creation of a module.
> Depending on the order in which startGMSModule is called this leads to
> different behavior. Here is an invocation sequence:
> - server ID A, group foo
> - server ID B, group foo
This combo was not intended. So current code does not address this
elegantly. As you point out, a check for such violation is needed.
> - server ID B, group bar
> The second invocation will return the module created in the first
> invocation. If the second and third invocation are swapped, a new
> module will be created for server ID B and group foo.
That should be a bug. I will look into this. Could you file an issue?
> Another sequence is:
> - server ID A, group foo
> - server ID B, group bar
> - server ID A, group foo
>
> The third invocation will not return the module created in the first
> invocation but will return a new module. If the second invocation is
> left out, the group created in the first is returned.
Yes. These possibilities have not been tested in our unit tests as our
use cases were driven by a single server id within a single JVM and did
not cut to these possibilities.
May I request you to file issues for each one of these ?
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.)
best regards
Shreedhar Ganapathy
>
> Kind regards,
>
> Johan Stuyts
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>