reddycharan commented on issue #570: Multiple active entrylogs URL: https://github.com/apache/bookkeeper/issues/570#issuecomment-368597767 Hey Ivan.. Sijie, JV and our internal team had long conversation about the same and I responded to community aswell in one of the mail Initially when we designed to implement this feature by providing config for number of entrylogs per ledgerdir and because of that the logic was convoluted with slot mapping management and Sijie felt that it is complicated and questioned about it. But now with entrylog per ledger, the management logic in entrylogger is simpler and straightforward. The same amount of complication will be applicable even in the case of composition at LedgerStorage level. When we get addEntry at ComposedLedgerStorage there should be logic to which LedgerStorage it should goto. So with this fact I can say that composing at LedgerStorage level it will be atleast as complicated as composing at EntryLogger level. with the ComposedLedgerStorage approach (Composite Pattern), ComposedLedgerStorage managing N InterleavedLedgerStorage/SortedLedgerStorages, there is going to be considerable change in the way the resources and state information are handled. Each Interleaved/SortedLedgerStorage will have its own EntryLogger (to serve our MultipleEntryLogs feature), but rest all needs to be shared, mainly 'LedgerCache', 'gcThread' and 'activeLedgers'. So there is going to be major churn in the code for moving the operations dealing with shared resources and state to ComposedLedgerStorage and leave the rest in InterleavedLedgerStorage. Amount of changes required in testcode to deal with these changes is even more. We have to do this while providing backward compatibility (Single EntryLog). Now this should make one question where should the composition happen. As far as I can say, it is supposed to happen at the lowest possible level rather than at higher level, which needs extra band-aid efforts to deal separately for the common resources/state and multiplexable resources. with composition at EntryLogger level, currently in my implementation getEntry/readEntry path, index manager and GC components are unchanged. but with composition at LedgerStorage even for readEntry/getEntry the multiplexing/redirection needs to happen. This is dealbreaker for me. Things get very messy with SortedLedgerSotrage entries in Memtable when Ledgerdir of the entryLog becomes full (we have to rotate current entrylog and create new one in writableledgerdir) while simulataneous writes and read are happening. Also this needs instance of LedgerStorage class for each entryLog in readpath and corresponding EntryMemTable if it is SortedLedgerStorage, though Memtable is not needed in read case. Most importantly we need to provide this feature with backward compatibility (we should be able to read previous data) and also provide existing behaviour (single entrylog) with config option. and mainly LedgerStorage is not the only consumer of EntryLogger, but also GarbageCollectorThread. It calls quite a few methods of EntryLogger - (entryLogger.addEntry, entryLogger.flush, entryLogger.removeEntryLog, entryLogger.scanEntryLog, entryLogger.getLeastUnflushedLogId, entryLogger.logExists, entryLogger.getEntryLogMetadata). It is going to be an issue with ComposedLedgerStorage, because with that EntryLogger is going to be responsible for just one EntryLog. For GarbageCollectorThread to work correctly with multiple EntryLogs, composition is required here as well. Which is double whammy when it comes down to implementation. Anyhow the only posiible shortcoming i see with multiplexing at Entrylogger level is that we are having single MemTable in the case of SortedLedgerStorage, but we mitigated that issue by doing parallel flushes. In terms of complexity and code churn if we go with multiplexing at ledgerstorage class level it will be several times higher than the current implementation with not much benefits.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
