[
https://issues.apache.org/jira/browse/GEODE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15555984#comment-15555984
]
ASF subversion and git services commented on GEODE-1926:
--------------------------------------------------------
Commit fbbdb824b824bd169aaff7a6898b104e25e7069b in incubator-geode's branch
refs/heads/develop from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=fbbdb82 ]
Revert "GEODE-1926"
* Precehckin completion pending
This reverts commit 7b88c6cf7ad96675f81a138b2d03f8f3375168cf.
> The function peekAhead function puts the queue key into peekedIDs even though
> it was not in the batch to be dispatched
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: GEODE-1926
> URL: https://issues.apache.org/jira/browse/GEODE-1926
> Project: Geode
> Issue Type: Bug
> Components: wan
> Reporter: nabarun
>
> The function peekAhead peeks the serial sender queue and if its able to get
> an object in the queue, returns the object to the peek function to be
> dispatched and adds the key to the peekedIds list.
> The peek function tries to make a heap copy of the object returned , but
> conflation may have kicked in the object may have been removed - hence the
> object will not be placed in the dispatch batch.
> However now the size of the peeked Ids and dispatched batch do not match,
> hence when the remove thread starts removing the elements from the key using
> the keys in peekedIds and using the size of the dispatched batch, there will
> be lingering objects in the queue because the size of dispatched batch is
> less than Ids that were peeked.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
