Hi Shreedhar,
Mike is right. I have reported it to you when we talked about sendMessage's bug. May be you ignored it. We just need add a simple condition statement before that.
if( props != null) this.bindInterfaceAddress = (String)props.get(JxtaConfigConstants.BIND_INTERFACE_ADDRESS.toString());
leehui
2008-06-26
发件人： Shreedhar Ganapathy
发送时间： 2008-06-26 00:17:32
收件人： users_at_shoal.dev.java.net
抄送：
主题： Re: [Shoal-Users] Questions and Documentation?
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
<!--[if !supportLists]-->è <!--[endif]-->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 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