[
https://issues.apache.org/jira/browse/HDDS-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467592#comment-16467592
]
Elek, Marton commented on HDDS-25:
----------------------------------
Thank you [~anu] the comments. You are right, and some of your questions were
also big questions for me and I am not sure If I found the final answers. I
would rather share how I was thinking.
4. [Future or not] I was also thinking about using Future and I have no answer
yet. For example akka supports both use cases: the one-way only and the async
request-resonse. But they suggest to use the one-way only. I think the it's
more simple to use just the one-way messaging but it's a big question if it's
enogh for all of our use cases. My guess is the one-way messaging could be
enogh if we handle the async message (such like heart beats and node reports)
and not RPC requests.
But even for RPC calls the request ID could be added to the event payload so
finally the answer could be sent back after a chain of event handlers.
My impression is that a simple send-only model is more easy to use (instead of
chaining Future and handling). This is the promise of the actor model: it's
more easy to understand the threads behind the code as every actor is executed
by the assigned thread pool. (Note: this patch is not a pure actor model)
2. [Event handling] It is also an open question. I am not sure if I understood
your question exactly but it's also question during the event chain. I think
most of the time it's enogh to break the event chain and log the error message.
Some actor systems use deferred queue where all the failed messages are landed
but I can't see real benefit of it in our simple use case.
It also depends from the question 4#. In case of using Future it provides a way
to send back the error information.
3. I am not sure what we would like to use. This design provides a separation
between the event handlers and the executors. You can add multiple handlers
where the executor is shared (even the different event type could use the same
executor) So it's possile to use the same thread pool for all the events
handling for example. By default the EventQueue creates a spearated single
thread pool for every handler but it could be modifed during the assembly of
the event queue. I think the key point here is that we can modify the
executor/thread setup independently from the event handler logic.
Summary: I think the important part is the EventHandler/EventPublisher which
should be nailed down (so the Future is a big question here). All the other
part (thread pool handling) could be improved independently.
> Simple async event processing for SCM
> -------------------------------------
>
> Key: HDDS-25
> URL: https://issues.apache.org/jira/browse/HDDS-25
> Project: Hadoop Distributed Data Store
> Issue Type: Improvement
> Components: SCM
> Reporter: Elek, Marton
> Assignee: Elek, Marton
> Priority: Major
> Fix For: 0.2.1
>
> Attachments: HDDS-25.001.patch
>
>
> For implementing all the SCM status changes we need a simple async event
> processing.
> Our use-case is very similar to an actor based system: we would like to
> communicate with full asny event/messages, process the different events on
> different threads, ...
> But a full Actor framework (such as Akka) would be overkill for this use
> case. We don't need distributed actor systems, actor hierarchy or complex
> resiliency.
> As a first approach we can use a very simple system where a common EventQueue
> entry point could route events to the async event handlers
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
