<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<blockquote
cite="mid:CA+nfvwTXBpvRrpjLE03M-3BmjG4mMerOJMZ2ua-hsTOCkAesPQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Investigation:<br>
------------<br>
When I looked at UNICAST3, I saw a lot of missing messages
on the<br>
receive side and unacked messages on the send side. This
caused me to<br>
look into the (mainly OOB) thread pools and - voila -
maxed out !<br>
<br>
I learned from Pedro that the Infinispan internal thread
pool (with a<br>
default of 32 threads) can be configured, so I increased
it to 300 and<br>
increased the OOB pools as well.<br>
<br>
This mitigated the problem somewhat, but when I increased
the requester<br>
threads to 100, I had the same problem again. Apparently,
the Infinispan<br>
internal thread pool uses a rejection policy of "run" and
thus uses the<br>
JGroups (OOB) thread when exhausted.<br>
</blockquote>
<div><br>
</div>
<div>We can't use another rejection policy in the remote
executor because the message won't be re-delivered by
JGroups, and we can't use a queue either.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Can't we just send response "Node is busy" and cancel the operation?
(at least in cases where this is possible - we can't do that safely
for CommitCommand, but usually it could be doable, right?) And
what's the problem with queues, besides that these can grow out of
memory?<br>
<br>
Radim<br>
<br>
<pre class="moz-signature" cols="72">--
Radim Vansa <a class="moz-txt-link-rfc2396E" href="mailto:rvansa@redhat.com"><rvansa@redhat.com></a>
JBoss DataGrid QA
</pre>
</body>
</html>