Hi Leehui, Bongjae
Thanks very much for your contributions. This is VERY helpful.
With bright folks like you, we can be sure, Shoal can only get better. :)
Thanks
Shreedhar
leehui wrote:
> Hi Bongjae,
> Yes, you can. You commit it.
> Thank you very much.
> ------------------------------------------------------------------------
> leehui
> 2008-06-26
> ------------------------------------------------------------------------
> *发件人：* Bongjae Chang
> *发送时间：* 2008-06-2620:29:37
> *收件人：* users_at_shoal.dev.java.net
> *抄送：*
> *主题：* Re: [Shoal-Users] Questions and Documentation?
> Hi LeeHui.
> Thank you for reporting it.
> I opened an issue about NPEs of invoking GMSFactory.startGMSModule().
> https://shoal.dev.java.net/issues/show_bug.cgi?id=63
> /"if( props != null) this.bindInterfaceAddress =
> (String)props.get(JxtaConfigConstants.BIND_INTERFACE_ADDRESS.toString());"/
> Could I check that in instead of you? Or if you will check that in
> later, first of all I will check other NPEsin except property's NPE.
> Thanks.
> --
> Bongjae Chang
>
> ----- Original Message -----
> *From:* Shreedhar Ganapathy <mailto:Shreedhar.Ganapathy_at_Sun.COM>
> *To:* users_at_shoal.dev.java.net <mailto:users_at_shoal.dev.java.net>
> *Sent:* Thursday, June 26, 2008 2:17 PM
> *Subject:* Re: [Shoal-Users] Questions and Documentation?
>
> 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
>>>