Hi,<br><br>On Monday, March 16, 2015, Martin Fryč <<a href="javascript:_e(%7B%7D,'cvml','martin@fryc.eu');" target="_blank">martin@fryc.eu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div>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</div><div></div></div></blockquote><div><br></div><div>Sure, you are right. There are many use cases for seperate thread pools. The one you described above is essentially a QoS one.</div><div><br></div><div>The bottom line is that APIs should as much as possible <span></span>allow the user to define multiple pools and to associate a pool with a specific parallel/async operation.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div> </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> and doesn't care, when slow one will be finished (eg. logging, ...). It will cause to take unnecessary time for request processing.<div><br></div><div>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.<br><div><br></div><div>King regards,</div><div>Martin Fryč</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 15, 2015 at 6:46 PM, arjan tijms <span dir="ltr"><<a>arjan.tijms@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sun, Mar 15, 2015 at 11:21 AM, Martin Fryč <span dir="ltr"><<a>martin@fryc.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote><div><br></div></span><div>Indeed, especially if it will be possible to wait for all async events to have completed, the risk for deadlock is very real.</div><div><br></div><div>This was explained in some more detail here: <a href="https://java.net/jira/browse/EJB_SPEC-9?focusedCommentId=345825&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345825" target="_blank">https://java.net/jira/browse/EJB_SPEC-9?focusedCommentId=345825&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-345825</a></div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><div dir="ltr"><div></div><div><br></div><div>If threre will be some policy API like:</div><div><br></div><div>java.util.concurrent.ExecutorService dispatch(T event, Annotation... qualifiers)</div><div><br></div><div>it will allow application to decide which thread pool should be used for which type of event.</div><div>In EE environment, it must be ManagedExecutorService looked it up from JNDI, in SE environment it could be ExecutorService created for applications needs.</div><span><font color="#888888"><div><br></div><div>Martin</div></font></span></div>
<br></span>_______________________________________________<br>
cdi-dev mailing list<br>
<a>cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div><br></div></div>
</blockquote></div><br></div>
</blockquote>