[infinispan-dev] RejectedExecutionException

[Sanne Grinovero]

2010/6/14 David M. Lloyd <david.lloyd at redhat.com>:
> On 06/12/2010 10:36 PM, Sanne Grinovero wrote:
>> Hello,
>> I've noticed the forum post about the RejectedExecutionException
>> experienced under load [1]. In Hibernate Search we had a similar issue
>> where the producers where quicker than the consumption of tasks; while
>> I agree about defining a larger queue it's still possible to
>> experience the error.
>> What we did there is to customize the ThreadPool factory to have the
>> caller block waiting for space in the queue when it's full [2].
>>
>> This seems to me a sane approach, not sure why there's no such policy
>> by default in j.u.concurrent. am I missing something obvious?
>
> I have implemented this same policy in the same way, however I abandoned
> this solution when I discovered subtle problems which occur in certain
> cases where there's work in the queue and suddenly no threads to run the
> work, or work is enqueued and the thread pool is below the max size, but
> the work sits in queue because no new thread is started to process it, or
> tasks are accepted after the thread pool is shut down (this is a problem if
> you take acceptance of a task to be any sort of guarantee that it will be
> executed; granted I see that in your example the ultimate fallback policy
> is to discard the task in case of interruption, a policy I happen to
> disagree with because of the indeterminate results that it may cause).
>
> In the end, I decided that TPE was just not designed to solve this problem
> in this way, so for JBossAS 6+ I ended up writing an alternative thread
> pool implementation for the specific case where you want the caller to block.

Hi David, thanks for the insight, I didn't think about the number of threads as
we where using newFixedThreadPool in the case of Hibernate Search.
I assume there's no risk in this case to have no threads available, or
should we still consider including
the custom threadpool you made for JBossAS 6?

Getting back on topic, what would you recommend for Infinispan?
Shouldn't something be done, or do you think throwing an exception
would be best?
We should at least wrap this in a clear error message.

Regards,
Sanne

> --
> - DML ☍
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev