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