Hi Joe,
Thank you for your proposed solution.
When I put a synchronized block around the pipe.send(), it works well and it has a good performance dramatically than MAX_SEND_RETRIES's adjustment.
But we maybe should improve more performance as your words. And I expect that Shoal will be able to have a good performance with default JXTA layer if we will concentrate on the performance issue later.
I am trying to replace JXTA by Grizzly experimentally as you know because I have seen the possibility of being able to abstract Shoal's transport layer more.
Of course, it never means that Grizzly is better than JXTA, but I just hope that Shoal is perhaps able to become to be more flexible regardless of any transport layers.
Fortunately, Shoal which used Grizzly as a transport layer had a very good performance when I tested it over TCP(at least more 100% performance improvement, but this measure is not accurate). Of cource, I tried to change the base message structure into new structure which was based on ByteBuffer additionally. Needless to say, it doesn't means that all messages are based on ByteBuffer, but the last message type is only based on ByteBuffer just before sending the packet through the transport.
Expect the Shoal's transformation! Coming soon.. :-)
Thanks!!
--
Bongjae Chang
----- Original Message -----
From: "Joseph Fialli" <Joseph.Fialli_at_Sun.COM>
To: <dev_at_shoal.dev.java.net>
Sent: Thursday, May 14, 2009 6:50 AM
Subject: Re: [Shoal-Dev] About JXTA's sending overflow
> Joseph Fialli wrote:
>> Bongjae Chang wrote:
>>
>>> Hi,
>>>
>> <deleted>
>>
>>> 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.
>>>
>> There is no message queue size for this. It is a direct send case, so it
>> is effectively a queue of one.
>> If many threads are trying to send over same pipe at same time(for this
>> case, 100 threads),
>> jxta sendMessage returns false for all subsequent ones till the
>> outstanding one completes (I learned this based on Bongjae's previous
>> analysis in).
>> We retried some arbitrary number of times for time being when
>> sendMessage returns false, thus the constant is definitely subject to
>> change.
>>
>> I agree that this needs to be addressed to be made more reliable than it
>> currently is.
>>
>> I am going to look at this some and propose possible solution from gms
>> layer.
>>
>
> I propose for short term to just put a synchronized block around the
> pipe that is getting used by too many threads at one time.
> I ran the multithreadedsender test with this change and all messages
> were sent properly. Key is whether you still find the
> performance too slow as when you set the max retries higher. I think
> this approach does not thrash as much. Everyone just sends once,
> they just are serialized (for 100 threads, the serialization of sending
> messages is going to slow things down)
>
> ndex: src/java/com/sun/enterprise/jxtamgmt/JxtaUtil.java
> ===================================================================
> RCS file:
> /cvs/shoal/gms/src/java/com/sun/enterprise/jxtamgmt/JxtaUtil.java,v
> retrieving revision 1.11
> diff -u -a -r1.11 JxtaUtil.java
> --- src/java/com/sun/enterprise/jxtamgmt/JxtaUtil.java 6 May 2009
> 19:30:15 -000
> 0 1.11
> +++ src/java/com/sun/enterprise/jxtamgmt/JxtaUtil.java 13 May 2009
> 21:45:31 -00
> 00
> @@ -230,7 +230,9 @@
>
> boolean sent = false;
> for (int i = 0; i < MAX_SEND_RETRIES && !sent; i++) {
> - sent = pipe.send(msg);
> + synchronized(pipe) {
> + sent = pipe.send(msg);
> + }
> }
> return sent;
> }
>
> We could have a pool of pipes that grow with number of threads using the
> pipe.
> It is more sophisticated solution and more error prone so would prefer
> to agree on
> a simple short term solution and put an RFE in for the more scalable
> solution for future.
>
> -Joe
>
>> -Joe
>>
>>
>>> Thanks.
>>> --
>>> Bongjae Chang
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_shoal.dev.java.net
>> For additional commands, e-mail: dev-help_at_shoal.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: dev-help_at_shoal.dev.java.net
>
>
>
>