[infinispan-dev] Why no use async listener executor?

[Dan Berindei]

On Thu, Oct 6, 2011 at 5:51 PM, Galder Zamarreño <galder at redhat.com> wrote:
>
> On Oct 6, 2011, at 12:26 PM, Dan Berindei wrote:
>
>
>> I've been been
>> trying to reuse the async transport executor in my cache views
>> manager, but I didn't know it's also configured to use 1 thread max
>> and I spent a good part of yesterday trying to understand what's going
>> on :)
>> I eventually moved on to create my own executor because I also wanted
>> to name my threads better and I couldn't find a simple way to include
>> the node name in the async transport executor's thread names, but I'm
>> pretty sure 1 is not a reasonable default for the async transport
>> either.
>
> I think we should have a chat online to see what exactly you're trying to do and see if we can accomodate it. I'm looking into this area right now.
>

Definitely, let's talk tomorrow.

Maybe you'll be able to convince me of the usefulness of exposing all
these configuration settings, up until now I haven't seen it used to
fix things but I've seen at least one wrong configuration break things
(by enabling queueing in the JGroups executors).

> Btw, if you end up creating your executor, you need to follow the global configuration rules. I'd probably suggest that I commit first https://issues.jboss.org/browse/ISPN-1396 so that you can get an idea of how I extended other parts to use shared executors.
>
> Btw, async transport does not use 1 as default, but instead 25 threads, see KnownComponentNames.
>

Hmm, maybe the test suite overrides it then? If I run a test and put a
breakpoint in RpcManagerImpl.java:106 I see the injected executor has
core size 1 and max size also 1.

>>
>> Cheers
>> Dan
>>
>>
>> On Wed, Oct 5, 2011 at 6:53 PM, Galder Zamarreño <galder at redhat.com> 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)
>>>
>>> Unless you have very strict requirements, the async listener executor should just work, and would lead to reuse of executors which results in lower consumption.
>>>
>>> The same applies to the singleton store executor btw.
>>>
>>> Surely, if we were to expand on to other use cases, async notification executor should have more than 1 max thread by default, otherwise we could easily hold up tasks.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>