Sure.
On Fri, Nov 6, 2015 at 6:12 PM, Till Westmann <[email protected]> wrote: > Thanks, Young-Seek. > I think that I might take you up on your offer to chat next week :) > > Cheers, > Till > > > On 6 Nov 2015, at 15:36, Young-Seok Kim wrote: > > 1. LogManager.log() ignores the exception in order for the caller not to >> return unless the log is flushed regardless of the exception. This >> guarantee must be provided for those JOB_COMMIT and ABORT log records. >> 2. LogManager.getAndInitNewPage() also ignores it since unless the >> logManager can get any available log tail page, the system should not >> proceed. >> 3. LogManger.terminateLogFlusher() --> LogFlusher.terminate() >> >> In general, all of these ignorance are to provide a certain guarantee that >> the system should provide as long as the system is alive. >> >> If you have further questions, we can chat. >> >> Best, >> Young-Seok >> >> >> On Fri, Nov 6, 2015 at 2:11 PM, Till Westmann <[email protected]> wrote: >> >> Hi, >>> >>> in the methods “log”, “getAndInitNewPage”, and “terminateLogFlusher” in >>> LogManager and “terminate” and “call” in LogFlusher InterruptedExceptions >>> are being caught and mostly ignored (at least the thread is not stopped). >>> While that seems to be ok in LogManager.terminateLogFlusher (as the >>> method >>> will end anyway), for the other methods this happens in a loop that >>> depends >>> on modifications in another thread and so this might never happen if the >>> other thread is stopped before performing those modifications. >>> Now I think that this has been done carefully and that this all works >>> fine, but it’s not obvious by looking at the code, and I’d like to >>> understand if/why the current behavior is correct in the way we use it. >>> Who could help me with that? >>> >>> Thanks, >>> Till >>> >>>
