On Feb 24, 2009, at 2:51 PM, Shreedhar Ganapathy wrote:
> 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
Sure, I'll start work on this. I have some other commitments as well
so it may take a few days for me to report back.
>
>>
>> 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.
Does this fix involve significant changes or is it something that
someone not familiar with the Shoal codebase could look into?
>
>>
>> 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?
>>
OK I'm going to start to familiarize myself with the codebase by
talking the rendezvous issue. Once I have a better understanding, I'll
look at what XMPP support will involve and report back.
Jim
>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>