Bongjae's subsequent response suggests that even smaller packets (with
just a Hello World string) have this problem on a tcp channel and with
both instances on the same machines.
Mohamed Abdelaziz wrote:
> 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
>
>