geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-3815) Entries are incorrectly removed from the index map during parallel gateway queue conflation
Date Tue, 24 Oct 2017 16:52:00 GMT

    [ https://issues.apache.org/jira/browse/GEODE-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217234#comment-16217234
] 

ASF subversion and git services commented on GEODE-3815:
--------------------------------------------------------

Commit 547f0cbaa916e4a155c969493924c244ec647e27 in geode's branch refs/heads/develop from
[~barry.oglesby]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=547f0cb ]

GEODE-3815: Changed to remove the conflation index only if its for the same event



> Entries are incorrectly removed from the index map during parallel gateway queue conflation
> -------------------------------------------------------------------------------------------
>
>                 Key: GEODE-3815
>                 URL: https://issues.apache.org/jira/browse/GEODE-3815
>             Project: Geode
>          Issue Type: Bug
>          Components: wan
>            Reporter: Barry Oglesby
>
> When an event is sent to a {{Gateway}} queue, it does a put into a map of indexes tracking
realKey to queueKey if conflation is enabled. This put returns the previous queueKey which
sent to a separate {{WAN Queue Conflation Thread}} thread to be removed from the queue. The
{{WAN Queue Conflation Thread}} also removes the key from the map of indexes. This is not
correct behavior. Its always going to remove a current index.
> Here is some logging that shows the behavior. In this case, the {{ServerConnection}}
thread is updating key=0. The previousTailKey=726 (thats the key in the queue), which the
{{WAN Queue Conflation Thread}} removes from the queue. It also removes index=839 from the
index map. This causes the next update for key=0 into the queue to not find anything in the
index map (previousTailKey=null), so the previous event is not removed from the queue.
> {noformat}
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry putting keyToConflate=0;
tailKey=839
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry previousTailKey=726
> WAN Queue Conflation Thread: ConflationHandler.run previousTailKey=726
> WAN Queue Conflation Thread: ParallelGatewaySenderQueue.destroyEventFromQueue about to
destroyKey key=726
> WAN Queue Conflation Thread: BucketRegionQueue.removeIndex index=839
> WAN Queue Conflation Thread: ParallelGatewaySenderQueue.destroyEventFromQueue done destroyKey
key=726
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry putting keyToConflate=0;
tailKey=952
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry previousTailKey=null
> {noformat}
> If I remove this code from {{BucketRegionQueue.basicDestroy}} which is called by the
{{WAN Queue Conflation Thread}}, conflation works fine:
> {noformat}
> if (getPartitionedRegion().isConflationEnabled()) {
>   removeIndex((Long)event.getKey());
> }
> {noformat}
> The {{WAN Queue Conflation Thread}} handles {{EntryNotFoundException}}, so if the entry
doesn't exist (meaning it already was sent), its ok. Since this method is also called during
normal queue removal, I'm not sure if there are consequences to removing this code, though.
Also, I haven't looked to see if the serial queue has this same issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message