Hi Mike
Interesting... Hope you saw the responses to your earlier questions in
my previous reply.
For the offline discussion, could you send me an email at my Sun email
address ? i.e shreedhar[dot]ganapathy[at]sun[dot]com
BTW, We have engaged in another thread from your colleague Karl-Heinz
earlier on a slightly related but different set of requirements. Not
sure if you are from different or same groups at OT.
Thanks
Shreedhar
Mike Wannamaker wrote:
>
> Hi Shreedhar
>
>
>
> I fully understand, I didn't mean to sound pushy. ;)
>
>
>
> I wouldn't mind talking offline about some of this. How would one do
> that?
>
>
>
> Background we had our own, similar to shoal clustering framework built
> on top of JGroups. However because of partnerships we have been
> forced to remove JGroups. I'm investigating and prototyping hooking
> shoal into our backend to be the cluster provider. We will need to
> run inside other app servers, like netweaver, weblogic, jboss etc...
> as well as on top of tomcat. This is why I ask about the SPI.
>
>
>
>
>
>
>
> Thanks
>
> Mike
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Shreedhar.Ganapathy_at_Sun.COM [mailto:Shreedhar.Ganapathy_at_Sun.COM]
> *Sent:* June 25, 2008 12:17 PM
> *To:* users_at_shoal.dev.java.net
> *Subject:* 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
>
> 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 <mailto: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
>
>
>