Re: [infinispan-dev] Why no use async listener executor?
Btw, state transfer and lock break service's executors are based around the concept of
having a single thread running for each of the executors and either discarding any other
requests (i.e. view changes) while there's an executor in use.
So, how do these carry on functioning the same way when all caches share the same cache
manager? You can't just have an executor of 1 because it could easily cause different
caches to block each other. If you have a thread pool of N, you could easily find yourself
in the situation where multiple threads execute rehashing for a single cache for example,
which I don't think is desirable.
A custom thread factory could make sure only as many different cache threads are created,
but the problem is still there. If you have 5 caches and you create 5 threads, two
consecutive view changes for a cache could still result in two paralell threads executing
it.
I can't think of an easy way to resolve this with the standard executors available and
maintaining a central executor for all caches.
This might be a situation where it does make sense having cache specific executor
configuration. Besides, these executors are single thread ones, so even if you create
thousands of caches, the cost should be relatively small.
Thoughts?
On Oct 7, 2011, at 9:05 AM, Galder Zamarreño wrote:
On Oct 6, 2011, at 5:48 PM, Mircea Markus wrote:
>
> On 6 Oct 2011, at 15:52, Galder Zamarreño wrote:
>
>>
>> On Oct 6, 2011, at 4:04 PM, Mircea Markus wrote:
>>
>>>
>>> On 5 Oct 2011, at 16:53, Galder Zamarreño wrote:
>>>
>>>> Hey guys,
>>>>
>>>> Re: https://issues.jboss.org/browse/ISPN-1396
>>>>
>>>> While looking into this, I've discovered that we have been creating
executors in cache level components, where we're calling submit from @Listener
implementations.
>>>>
>>>> For example, BaseStateTransferManagerImpl.ViewChangeListener submits a
rehash task and TransactionTable.StaleTransactionCleanup submits a tasks to break locks.
>>>>
>>>> Did the people that wrote these listeners (Dan & Mircea respectively)
consider defining listeners to be called asynchronously? i.e. @Listener(sync = false)
>>> this can work indeed for BaseStateTransferManagerImpl.ViewChangeListener?
This seems like a small change - can you modify that in the scope of ISPN-1396 or do you
want me to look into it?
>>
>> BaseStateTransferManagerImpl.ViewChangeListener? Dan seems to disagree. You meant
TransactionTable.StaleTransactionCleanup instead?
> yes indeed :-)
Ok. I'll get this changed as part of ISPN-1396.
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache