Project

General

Profile

Task #3357

Story #3352: Production CNs are out of sync in object count

Address ISet iterator bug that only iterates over a subset of the ISet

Added by Chris Jones over 11 years ago. Updated over 11 years ago.

Status:
New
Priority:
Normal
Assignee:
Ben Leinfelder
Category:
Metacat
Start date:
2012-10-23
Due date:
% Done:

0%

Milestone:
None
Product Version:
*
Story Points:
Sprint:

Description

When bringing the CNs back into sync, Metacat's HazelcastService compares the local set of known pids with the shared set in the Hazelcast ISet structure (hzIdentifiers). However, a call to ISet.size() gives a higher number (328K) than the iterator provides (!208K). This is likely a bug in the Hazelcast implementation, and may be addressed in newer HZ versions, but for now we need a workaround. Perhaps doing a putAll() into another structure will get all of the listed pids, and then iterating over that structure locally?

History

#1 Updated by Ben Leinfelder over 11 years ago

Current plan of attack:
Investigate using ISet in place ISet with 300K+ records. If that works, we can convert Metacat and indexer to use this structure. If not...tbd.

#2 Updated by Ben Leinfelder over 11 years ago

I have been unable to replicate this behavior while testing locally (350K ISet records). I did momentarily see inconsistencies in the count when I had my heap memory too small -- we could double check that other nodes are not throwing exceptions like that when we request the iterator from the production ISet.
I want to try a few more things (adding duplicate Identifier objects, perhaps?).

#3 Updated by Ben Leinfelder over 11 years ago

With 350K test Identifiers on cn-dev, I still cannot replicate this issue -- .size() and counting the iterator items both give the expected number.

#4 Updated by Chris Jones over 11 years ago

  • Target version changed from Sprint-2012.41-Block.6.1 to Sprint-2012.50-Block.6.4

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)