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
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