Hi Leehui
No one's ignoring it. Your test and bug is still open. It needs to be
addressed. You are welcome to check that in.
hth
Shreedhar
leehui wrote:
> Hi Shreedhar,
> Mikeis right. I have reported it toyou when we talked about
> sendMessage's bug. May be you ignored it. Wejustneed adda 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-2600: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
> <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
>>