Hi Jim
I'm have say I dont have positive news on this long standing issue. We
could not get to fixing it as we were focused on addressing correctness
issues under severe load conditions.
Some responses below:
Jim Marino wrote:
> Hi,
>
> I'm looking at running our service platform which makes use of Shoal
> for discovery and clustering in hosted environments where multicast is
> not available (e.g. Amazon EC2). I have a very limited understanding
> of JXTA but my impression is that it can be configured to use a
> non-multicast protocol by configuring a rendezvous peer.
Yes, it can be done and Shoal needs to better understand and take
advantage of these facilities that were long ago solved by Jxta for
their design center use cases. We coincidentally spoke about these with
Mohamed recently and we hope to get to this soon.
> I also came across this write-up:
>
> http://wikis.sun.com/display/shoal/Shoal+How-To+-+Configuring+for+cross+subnet+support
>
>
> I have a few questions:
>
> 1. Is it possible to configure Shoal with the latest (December)
> promoted build to work with a rendezvous peer and does the above
> document contain accurate information. Also, there is a comment that
> rendezvous peer configuration was temporarily broken. Has it been
> fixed in the latest promoted build?
Unfortunately not, AFAICT. May I ask you to take a shot at it and report
back issues you see with it
>
> 2. Will Shoal work with multiple rendezvous peers so there is no
> single point of failure in the cluster?
It should once we get this comprehensively fixed.
>
> On a slightly different but related topic, I noticed certain
> clustering functionality such as HealthMonitor and MasterNode are
> tightly coupled to JXTA. Is there a technical reason for this?
The way we approached this problem space was based on how we would plug
in other group comm implementations such as JGroups or Appia. Those
typically come with group discovery, health monitoring, etc all bundled
into their own library and are not amenable to being implementations of
a standardized interface. In this case, we implemented the group comm
functionality in the service provider implementation layer on top of Jxta.
> If the algorithms for determining things such as leadership and
> failure could be decoupled from JXTA, it would be easier to plug in
> alternative communications mechanisms such as XMPP or JMS.
That's a good thought. Could be something we could consider for 2.0.
Could you consider contributing in this space?
>
> Thanks,
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>