[
https://issues.apache.org/jira/browse/DIRSERVER-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100240#comment-13100240
]
Emmanuel Lecharny commented on DIRSERVER-1655:
----------------------------------------------
the problem is that the CSN is created way before the modification is inserted.
Locking the log could last for a (relative) long time. The other problem is
that we have no clue about which log we should lock, before processing the
replication filter, so we may have to lock blindly *all* the consumer logs.
Can't we use a mechanism where each thread acquire a unique number, which will
be used by the consumer log when it will process the mdoifications ? Something
like :
get an order number from the log
do the modification
post modification, push the modififcation to the log system
the modification is inserted into the log if all the previous numbers have been
processed
ie if a mod has a number N, then it can only be inserted into the log if the
N-1, N-2, ... mods have already been processed. The log will keep the latest N
it has processed.
> Possible incorrect insertion of modifications in the consumer log
> -----------------------------------------------------------------
>
> Key: DIRSERVER-1655
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1655
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 2.0.0-M2
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Fix For: 2.0.0-M4
>
>
> The way we process modifications in the EventInterceptor, creating a new
> thread, make it possible that the modifications may be inserted into a
> consumer log in the wrong order.
> A possoble solution could be to use the same thread to insert modifications
> in the log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
