Hi Mike
We are probably not in the same time zone as you are so our replies may
not be immediate. It also depends on other priorities we are required to
attend to so do expect a slight variance in how soon we respond. :)
Our responses in the community aliases on a best effort basis.
Thanks for asking these very good questions, I will try to get some
answers for you below:
Mike Wannamaker wrote:
>
> Any thoughts?
>
>
>
> Also has anyone run the tests lately? GroupLeaderTest fails,
>
> looks as though ClusterManager line 161
>
> è this.bindInterfaceAddress =
> (String)props.get(JxtaConfigConstants.BIND_INTERFACE_ADDRESS.toString());
>
> requires the BIND_INTERFACE_ADDRESS property to be given or throws
> null pointer?
>
Good catch. Sheetal will look into this today. We are in the process of
getting some automated test setup so that these tests are run regularly
and issues can be caught early on. Hope to get to that soon. More below:
>
>
> --ekiM
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Mike Wannamaker [mailto:mwannama_at_opentext.com]
> *Sent:* June 24, 2008 10:30 PM
> *To:* users_at_shoal.dev.java.net
> *Subject:* [Shoal-Users] Questions and Documentation?
>
>
>
> Hi I have a few questions
>
>
>
> Was wondering if there is any documentation on bootstrapping the JXTA
> in order to facilitate cross sub-net/firewall communications?
>
Will have a wiki page ready for you later today on that. :)
>
> Also any documents on writing your own SPI like JXTA SPI? For example
> app servers have their own communication layer, ie: JBoss/JGroups, I
> would like to see how to hook in an already running JGroups in JBoss
> into Shoal's SPI layer.
>
Not yet. But if you take a look into the com.sun.enterprise.ee.cms.spi
<
https://shoal.dev.java.net/nonav/docs/api/com/sun/enterprise/ee/cms/spi/package-frame.html>
package, the SPI layer is fairly thin. You should be able to contribute
a JGroups based SPI implementation - something we have been looking for
from the community for a while given our limited resources.
In the process, we may find extensions and enhancements that are need in
the SPI to enable multiple providers to be supports.
>
>
>
> Does Shoal take into account the fact that a component could saturate
> the network with messages and in affect possibly take down the Shoal
> cluster? IE: If I pump shoal full of large messages, this could in
> effect stop shoal's heartbeat responses?
>
The heartbeat messages/health monitoring protocol messages are sent
using UDP while app level messaging peer to peer and peer to group are
done using TCP. Jxta's TCP Transport layer has a good non blocking IO
based implementation which allows for pretty good scaling and
throughput. With this combo (TCP and NIO), flow control with very good
scaling is fairly highly possible - we have just not proved that to
ourselves with focused testing.
It would certainly help to know if you find any hotspots while sending
massive amounts of messages and report any issues that arise therein.
You could consider contributing those tests to Shoal. This is an area
where we are now beginning to look into. Obviously, there is scope for
improvement but there are surely boundaries upto which Shoal or any
other framework could work predictably.
> Does shoal try to do any kind of smart marshalling of messages to
> ensure that network saturation does not happen?
>
Shoal does not do more than compressing messages. We are considering
using send side channel pools for further scaling but those may come
with ordering challenges. Do share any thoughts on scaling that you may
have.
I am not sure if Jxta provides any facilities, Mo should be able to
answer that.
>
>
>
> I believe also I read somewhere that there are plans to support
> cluster splits or partitioning. IE: If a network glitch or a network
> splits, we would in effect have two sub-clusters. Eventually the
> network would come back and these clusters would come back together
> and join.
>
Yes, the master node protocol already supports the partition healing
portion of the deal. With JDK 6 we can use some new APIs therein to
determine if a member's network interface link is down and hence
isolated from the group. Using that to build some knowledge of network
isolation is a work in progress. So far, Shoal customers/users have not
indicated that this is a highly critical requirement that needs to be
addressed on a high priority. Our focus has been on stabilizing the
foundation i.e. cluster lifecycle event reporting, with large size
cluster. These are primarily driven by GlassFish and Sailfin project
requirements.
It would certainly help us if you can contact us offline to discuss your
specific use cases, requirements, release roadmap, and future support
requirements. There are other companies employing Shoal in their
products who have contacted us offline with indications of these which
can help us inform our stakeholders for resource and planning needs.
hth
Shreedhar
>
>
>
> TIA
>
> Mike
>
>
>