[cdi-dev] API for dispatching of async events

[arjan tijms]

Hi,

On Monday, March 16, 2015, Martin Fryč <martin at fryc.eu
<javascript:_e(%7B%7D,'cvml','martin at fryc.eu');>> wrote:

> Hi,
> more than deadlock I meant that quickly processed events (calculations,
> verifications, ...) will be mixed in a queue with slowly processed events
> (writing to FS, WS call, ...) and the application could be interested only
> in the result of "quick" events
>

Sure, you are right. There are many use cases for seperate thread pools.
The one you described above is essentially a QoS one.

The bottom line is that APIs should as much as possible allow the user to
define multiple pools and to associate a pool with a specific
parallel/async operation.

Kind regards,
Arjan Tijms






>  and doesn't care, when slow one will be finished (eg. logging, ...). It
> will cause to take unnecessary time for request processing.
>
> If application will be able to tell to async event "dispatcher", process
> this type of events on this executor, another type by this one and rest by
> this one, they won't be mixed in queue of one executor. Application will be
> then able to dedicate executor for processing of events needed for
> finishing of request processing and another for events which could be done
> even after request processing will be finished.
>
> King regards,
> Martin Fryč
>
> On Sun, Mar 15, 2015 at 6:46 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>> Hi,
>>
>> On Sun, Mar 15, 2015 at 11:21 AM, Martin Fryč <martin at fryc.eu> wrote:
>>
>>> If async events will be processed in similar way as async EJB methods -
>>> usually implemented in app servers as one shared thread pool with limited
>>> application control (discard policy, ...), both of these events will share
>>> one thread pool and some type of events could fully blocked it and "stop"
>>> application.
>>>
>>
>> Indeed, especially if it will be possible to wait for all async events to
>> have completed, the risk for deadlock is very real.
>>
>> This was explained in some more detail here:
>> https://java.net/jira/browse/EJB_SPEC-9?focusedCommentId=345825&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345825
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>>
>>> If threre will be some policy API like:
>>>
>>> java.util.concurrent.ExecutorService dispatch(T event, Annotation...
>>> qualifiers)
>>>
>>> it will allow application to decide which thread pool should be used for
>>> which type of event.
>>> In EE environment, it must be ManagedExecutorService looked it up from
>>> JNDI, in SE environment it could be ExecutorService created for
>>> applications needs.
>>>
>>> Martin
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (
>>> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual property rights inherent in such information.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150316/cc8ad0f8/attachment.html