[
https://issues.apache.org/jira/browse/IGNITE-20373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-20373:
---------------------------------------
Description:
Currently IO is resubmitted to inboundExecutor for further processing (even
there are corner cases then a message handler called in IO thread)
It makes message processing essentially single threaded and introduces
additional lag due to multiple queues message transaction.
addMessageHandler should be extended with a 3-d argument: a pool for submitting
a callback for execution.
Some kind of message header can be passed along the way for precise pool
selection (similar to jraft IO model)
inbound pool should be removed
IMPORTANT: delivery guaranties should be preserved: if a message A is send
before B, B can't be processed on a receiver before A
outboundExecutor also looks like a contention point - need to be addressed as
well
was:
Currently IO is resubmitted to inbound pool for further processing (even there
are corner cases then a message handler called in IO thread)
It makes message processing essentially single threaded and introduces
additional lag due to multiple queues message transaction.
addMessageHandler should be extended with a 3-d argument: a pool for submitting
a callback for execution.
Some kind of message header can be passed along the way for precise pool
selection (similar to jraft IO model)
inbound pool should be removed
IMPORTANT: delivery guaranties should be preserved: if a message A is send
before B, B can't be processed on a receiver before A
> Fix IO threading model
> ----------------------
>
> Key: IGNITE-20373
> URL: https://issues.apache.org/jira/browse/IGNITE-20373
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Alexey Scherbakov
> Priority: Major
> Labels: ignite-3, ignite3_performance
> Fix For: 3.0
>
>
> Currently IO is resubmitted to inboundExecutor for further processing (even
> there are corner cases then a message handler called in IO thread)
> It makes message processing essentially single threaded and introduces
> additional lag due to multiple queues message transaction.
> addMessageHandler should be extended with a 3-d argument: a pool for
> submitting a callback for execution.
> Some kind of message header can be passed along the way for precise pool
> selection (similar to jraft IO model)
> inbound pool should be removed
> IMPORTANT: delivery guaranties should be preserved: if a message A is send
> before B, B can't be processed on a receiver before A
> outboundExecutor also looks like a contention point - need to be addressed as
> well
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
