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 defaulttransport layer(JXTA), most ofpacketswas lost
> with receivingthe 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 thatJXTA'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 valueis 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 packetscould be sent to the remote server successfully, but there
> was a marked decline in the sendingperformance. So, I think that it is
> not good idea that MAX_SEND_RETRIEShas 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