search

OpenHFT / Chronicle-Queue

Micro second messaging that stores everything to disk
http://chronicle.software/products/chronicle-queue/
Apache License 2.0
3.3k stars 532 forks source link

Appender's resetPosition uses approximate last sequence number #1269

Open alamar opened 1 year ago

alamar commented 1 year ago

Found when debugging ChronicleEnterprise/Chronicle-Queue-Enterprise#333

StoreAppender.writeBytesInternal() will call resetPosition every time (which may be wasteful), but it will also assign wire.headerNumber to store.approximateLastSequenceNumber, which is as its name implies approximate, and may return invalid value when queue is closed after process crash.

This does not seem optimal, but for some reason store.exactLastSequenceNumber call is prohibitively expensive to be used there. In many cases it would resort to sequential scanning of queue, which should be almost always unnecessary.

If this problem is fixed then check introduced in ChronicleEnterprise/Chronicle-Queue-Enterprise#333 may be removed.

yevgenp commented 4 months ago

Is it still an issue after @nicktindall fixed https://github.com/OpenHFT/Chronicle-Queue/issues/1538 ? There is no store.approximateLastSequenceNumber anymore.

nicktindall commented 4 months ago

All calls to lastSequenceNumber while holding a read lock should be accurate after #1537. There's no approximate/exact anymore.