index ordering issue with elastic max-conns greater than 1 about monstache HOT 5 CLOSED

@battle-mage I've just now published a new release which hopefully should fix this issue.

from monstache.

Thank you for fast reaction!
I did not test the code yet, but when I'm looking at changes - I see that you use only timestamp itself. As we noticed - mongo uses timestamp accurate to 1 second, but if we use this timestamp - issue with document updated twice in a period of 1 second still exists.
As I noticed - mongo stores timestamps in format Timestamp(X, Y), where X - is the timestamp and Y - is the counter for this exact timestamp, so if there will be 2 changes in a short period - they will have
Timestamp(X, 1)
Timestamp(X, 2)
Shouldn't we also use this Y number for versioning?

from monstache.

@battle-mage I think the MongoDB Timestamp already accounts for the counter within a second in the ordinal bits. Unless I am missing something, if two events where recorded to the oplog within the same second, they would both have the same time_t component of the timestamp, but the 2nd event would have a higher ordinal component than the 1st, and thus a higher value of the entire 64 bit timestamp.

from monstache.

This makes sense, about 64-bit resulting timestamp.
We've been testing the last changes with some stress testing and looks like everything syncs just as it should. Versioning works fine :) Think we can close this issue, thanks for your work!

from monstache.

Thanks for bringing up this issue as well as the lack of support for sharded clusters. That was a pretty significant gap that has now been filled. I appreciate your contributions!

from monstache.