[
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 message transition between multiple queues.
addMessageHandler should be extended with a 3-d argument: a pool for submitting
a callback for execution, or an executorSelector like in jraft.
inboundExecutor should be changed to striped, use more than one thread, and
serve messages without explicit executor. 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 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 message transition between multiple queues.
addMessageHandler should be extended with a 3-d argument: a pool for submitting
a callback for execution, or an executorSelector like in jraft.
inboundExecutor should be changed to striped, use more than one thread, and
serve messages without explicit executor
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
> 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 message transition between multiple queues.
> addMessageHandler should be extended with a 3-d argument: a pool for
> submitting a callback for execution, or an executorSelector like in jraft.
> inboundExecutor should be changed to striped, use more than one thread, and
> serve messages without explicit executor. 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)
