dev@shoal.java.net

Re: [Shoal-Dev] About JXTA's sending overflow

From: Mohamed Abdelaziz <Mohamed.Abdelaziz_at_Sun.COM>
Date: Wed, 13 May 2009 10:08:32 -0700

udp allows for definition of datagram size, which shoal sets at 64K,
however setting a packet size lager than the MTU, leads to splitting
the datagram into multiple packets, if for any reason (collision,etc.)
one of these packets are lost, it leads to the datagram being lost.

The problem you're seeing is likely due to the datagram's size exceeding
the recipient's udp transport buffer size (64K).


Mohamed


On 5/13/09 6:47 AM, Shreedhar Ganapathy wrote:
> Hi Bongjae
> What is the size of these large packets? Are these sent to all members
> or to a specific member ? Have you checked for UDP drops through netstat?
> I don't believe Jxta queue size is exposed, Joe may have better idea
> about it.
>
> Shreedhar
>
> Bongjae Chang wrote:
>> Hi,
>> When I sent many large packets to the remote server for the
>> performance comparison classified by kinds of Shoal's transport
>> layers, I used default transport layer(JXTA), most of packets was
>> lost with receiving the following exception.
>> ----
>> com.sun.enterprise.ee.cms.core.GMSException: message
>> com.sun.enterprise.ee.cms.spi.GMSMessage_at_1b6c03
>> <mailto:com.sun.enterprise.ee.cms.spi.GMSMessage_at_1b6c03>
>> 6 not sent to
>> urn:jxta:uuid-59616261646162614A78746150325033A113B2FFB4B64F038C858B9EB8FC413803,
>> send
>> returned false
>> at
>> com.sun.enterprise.ee.cms.impl.jxta.GroupCommunicationProviderImpl.sendMessage(GroupCommu
>> nicationProviderImpl.java:291)
>> at
>> com.sun.enterprise.ee.cms.impl.jxta.GroupHandleImpl.sendMessage(GroupHandleImpl.java:133)
>> at
>> com.sun.enterprise.shoal.jointest.MultiThreadSenderTest$1.run(MultiThreadSenderTest.java:
>> 103)
>> at java.lang.Thread.run(Thread.java:717)
>> ----
>> It seems that JXTA's OutputPipe.send() returns false continuously
>> because of overflow. Shoal already tried to send it again with
>> MAX_SEND_RETRIES which is 4 in JxtaUtil#send().
>> But, it seems that the MAX_SEND_RETRIES value is not enough in my
>> test which has over 100 sender thread simultaneously.
>> When I set MAX_SEND_RETRIES to over 1000 experimentally, I found that
>> all packets could be sent to the remote server successfully, but
>> there was a marked decline in the sending performance. So, I think
>> that it is not good idea that MAX_SEND_RETRIES has too large value in
>> my test.
>> Does anybody know JXTA' options or other solutions for preventing the
>> sender from being overflowed? e.g. Options for increasing internal
>> JXTA's message queue size.
>> Thanks.
>> --
>> Bongjae Chang