You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Alex Parvulescu (JIRA)" <ji...@apache.org> on 2016/06/07 17:45:21 UTC

[jira] [Updated] (OAK-4083) Simplify concurrency when loading data from the primary

     [ https://issues.apache.org/jira/browse/OAK-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alex Parvulescu updated OAK-4083:
---------------------------------
    Fix Version/s: 1.4.1

> Simplify concurrency when loading data from the primary
> -------------------------------------------------------
>
>                 Key: OAK-4083
>                 URL: https://issues.apache.org/jira/browse/OAK-4083
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: tarmk-standby
>            Reporter: Francesco Mari
>            Assignee: Francesco Mari
>             Fix For: 1.4.1, 1.5.0
>
>         Attachments: OAK-4083-01.patch
>
>
> The cold standby client is overly complicated and potentially buggy when segments are loaded from the primary.
> In particular:
> - when the {{StandbyClientHandler}} is removed from the pipeline, its {{EventExecutorGroup}} is passed to the {{SegmentLoaderHandler}} to signal a surrogate of the "channel close" event. It would be more sensible for {{SegmentLoaderHandler}} to listen to the proper "channel close" event instead.
> - after the {{SegmentLoaderHandler}} is added to the pipeline, the "channel active" callback method is called directly using the {{ChannelHandlerContext}} of the {{StandbyClientHandler}}. It would be better for {{SegmentLoaderHandler}} to use a proper initialisation point like, in example, the "handler added" callback method. The {{SegmentLoaderHandler}} should also use its own {{ChannelHandlerContext}}, instead of owning one from another handler.
> - {{SegmentLoaderHandler}} saves and uses the {{ChannelHandlerContext}} of the {{StandbyClientHandler}}. The only purpose for it is to use the {{EventExecutorGroup}} of the {{StandbyClientHandler}} to issue "write messages" events. The {{SegmentLoaderHandler}} should use Netty's event loop to issue I/O operations, and instead use a different thread for business logic - in this case, the synchronization process between primary and standby instances.
> - The {{StandbyClientHandler}} is registered with its own {{EventExecutorGroup}} with four threads. This is overkill, since the synchronization process should run anyway in a separate thread (see below). The {{StandbyClientHandler}} should use the default event loop.
> - The {{SegmentLoaderHandler}} is registered with its own {{EventExecutorGroup}} with four threads. This is overkill, since request/response cycle between the standby and the primary instances is synchronous. The {{SegmentLoaderHandler}} should instead use the default event loop for I/O events and run another (single) thread to execute the synchronization process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)