asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Young-Seok Kim <kiss...@gmail.com>
Subject Re: handling InterruptedException
Date Sat, 07 Nov 2015 02:30:42 GMT
Sure.


On Fri, Nov 6, 2015 at 6:12 PM, Till Westmann <tillw@apache.org> 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 <tillw@apache.org> 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
>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message