[
https://issues.apache.org/jira/browse/S4-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13411333#comment-13411333
]
Matthieu Morel commented on S4-62:
----------------------------------
Matt Welsh's feedback on SEDA (
http://matt-welsh.blogspot.com/2010/07/retrospective-on-seda.html ) could be
taken into account. S4 follows a similar stage-driven architecture. Whereas it
might be difficult to scale out by grouping stages into a single "thread pool
domain" as suggested in the blog post, an interesting recommendation is to put
"_a separate thread pool and queue in front of a group of stages that have long
latency or nondeterministic runtime, such as performing disk I/O._" This
corresponds to the proposal of this ticket.
The platform could even provide this feature automatically when streams or PEs
are identified as I/O consumers.
> Multithreaded Streams
> ---------------------
>
> Key: S4-62
> URL: https://issues.apache.org/jira/browse/S4-62
> Project: Apache S4
> Issue Type: Improvement
> Affects Versions: 0.5
> Reporter: Daniel Gómez Ferro
> Attachments: S4-62-multithreaded-streams.patch,
> S4-62-multithreaded-streams.patch
>
>
> Currently, each Stream has one Thread in charge of processing the incoming
> events on the appropriate PE. If one PE blocks it's execution while
> processing an event, the whole Stream would be blocked. The current solution
> is for a PE to manage his own async thread, which I don't think it's nice.
> It would be better to have a configurable number of threads that would take
> care of the execution of the incoming events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
