You mean an unbounded queue ? This would be bad if the insertion rate of
messages is higher than the processing rate.
The problem with the Infinispan pool is that we cannot simply discard
messages; they won't get retransmitted, as they're been delivered by
JGroups.
If we end up with our own ordering of messages in the ISPN pool, then a
rejection policy of "run" would also cause harm, as it would destroy the
ordering (except for OOB messages)...
On 3/13/13 2:52 PM, Erik Salter wrote:
Any reason the messages can't be queued? In my mind, the
benefits would
outweigh the unbounded nature of it.
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Pedro Ruivo
Sent: Wednesday, March 13, 2013 9:29 AM
To: ispn-dev
Subject: [infinispan-dev] DefaultExecutorFactory and rejection policy
Hi
I'm working on ISPN-2808 (
https://issues.jboss.org/browse/ISPN-2808) and I
noticed that the DefaultExecutorFactory is creating the executor service
with an Abortpolicy.
Is there any particular reason for that?
In the new thread pool needed by ISPN-2808, I cannot have the messages (i.e.
the runnables) discarded, because it can cause some inconsistent state and
even block all the cluster.
I have set in my branch a CallerRunPolicy. If you see any issue with this
let me know.
Cheers,
Pedro
--
Bela Ban, JGroups lead (
http://www.jgroups.org)