Fix for BTM-138

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Fix for BTM-138

Kazuya Uno
Hello,

I stumbled on the bug BTM-138(http://jira.codehaus.org/browse/BTM-138).

I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.

This simply close and re-open the disk journal when ClosedChannelException
was detected.

This hack seems to work for me, but I am afraid that this might cause some
undesirable side effects.

What do you think about this? Is there someone who has the better idea?

Best Regards.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

DiskJournal.java (23K) Download Attachment
DiskJournalInterruptTest.java (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fix for BTM-138

Ludovic Orban-2
Hi,

I think that bug has been long fixed in BTM 3.0.0. Have you checked it?

--
Ludovic

On Fri, Apr 3, 2015 at 11:13 AM, Kazuya Uno <[hidden email]> wrote:

> Hello,
>
> I stumbled on the bug BTM-138(http://jira.codehaus.org/browse/BTM-138).
>
> I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
> fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.
>
> This simply close and re-open the disk journal when ClosedChannelException
> was detected.
>
> This hack seems to work for me, but I am afraid that this might cause some
> undesirable side effects.
>
> What do you think about this? Is there someone who has the better idea?
>
> Best Regards.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Fix for BTM-138

Kazuya Uno
Hi Ludovic,

Thank you for reply.
Unfortunately, our product depends on BTM 2.1.4.
And I think the latest stable version of Bitronix is 2.1.4, isn't it?

My hack close/open the disk journal when ClosedChannelException is occured,
and re-throw caught exception. I hope this approach prevent corrupt log
entry written to journal, but not sure.

How did you prevent channel closing when interrupted in 3.0.0?

On 2015/04/03 18:58, Ludovic Orban wrote:

> Hi,
>
> I think that bug has been long fixed in BTM 3.0.0. Have you checked it?
>
> --
> Ludovic
>
> On Fri, Apr 3, 2015 at 11:13 AM, Kazuya Uno <[hidden email]> wrote:
>> Hello,
>>
>> I stumbled on the bug BTM-138(http://jira.codehaus.org/browse/BTM-138).
>>
>> I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
>> fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.
>>
>> This simply close and re-open the disk journal when ClosedChannelException
>> was detected.
>>
>> This hack seems to work for me, but I am afraid that this might cause some
>> undesirable side effects.
>>
>> What do you think about this? Is there someone who has the better idea?
>>
>> Best Regards.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>      http://xircles.codehaus.org/manage_email
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Fix for BTM-138

Brett Wooldridge-2
Hi Kazuya,

The patch, as implemented, will not prevent log corruption.  3.0.0 also does not prevent corruption due to thread interruption.  My suggestion would be to surround the "fc.write(...)" call in TransactionLogAppender.writeLog() with a try/catch and re-open the file there.  Whatever write operation was in progress needs to be retried, otherwise the log will be in a corrupt state.

Something like:

while (buf.hasRemaining()) {

   try {

      this.fc.write(buf);

   }

   catch (ClosedChannelException cce) {

      // re-open

   }

}


This assumes that Java does not advance the ByteBuffer position in the case that ClosedChannelException is thrown.

Regards,
Brett


On Mon, Apr 6, 2015 at 9:50 AM, Kazuya Uno <[hidden email]> wrote:
Hi Ludovic,

Thank you for reply.
Unfortunately, our product depends on BTM 2.1.4.
And I think the latest stable version of Bitronix is 2.1.4, isn't it?

My hack close/open the disk journal when ClosedChannelException is occured,
and re-throw caught exception. I hope this approach prevent corrupt log
entry written to journal, but not sure.

How did you prevent channel closing when interrupted in 3.0.0?


On 2015/04/03 18:58, Ludovic Orban wrote:
Hi,

I think that bug has been long fixed in BTM 3.0.0. Have you checked it?

--
Ludovic

On Fri, Apr 3, 2015 at 11:13 AM, Kazuya Uno <[hidden email]> wrote:
Hello,

I stumbled on the bug BTM-138(http://jira.codehaus.org/browse/BTM-138).

I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.

This simply close and re-open the disk journal when ClosedChannelException
was detected.

This hack seems to work for me, but I am afraid that this might cause some
undesirable side effects.

What do you think about this? Is there someone who has the better idea?

Best Regards.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

     http://xircles.codehaus.org/manage_email


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

     http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Fix for BTM-138

Kazuya Uno
Hi Berret,

Thanks for reply!

 > The patch, as implemented, will not prevent log corruption.

So, You think the patch will work ?

 > My suggestion would be to surround the "fc.write(...)" call in
 > TransactionLogAppender.writeLog() with a try/catch and re-open the file there.

I thought this too. But I have a thing to worry abount.
With that aproach, if the events occurred in the following order,

1. transaction.setStatus(Status.STATUS_PREPARING);
2. transaction.setStatus(Status.STATUS_PREPARED);
3. thread.interrupt();  // this cause channel close!
4. transaction.setStatus(Status.STATUS_COMMITTING); // re-open here and flush to disk.
5. transaction.setStatus(Status.STATUS_COMMITTED, committedAndNotInterestedUniqueNames);

I think that this may result in the COMMITNG/COMMITED records
without corresponding PREPARING/PREPARED in the disk journal.

I'm afraid that this might cause something undesirable side effects.
Or Bitronix is smart enough to handle it gracefully?

Best Regards.

On 2015/04/06 14:37, Brett Wooldridge wrote:

> Hi Kazuya,
>
> The patch, as implemented, will not prevent log corruption.  3.0.0 also does not prevent corruption
> due to thread interruption.  My suggestion would be to surround the "fc.write(...)" call in
> TransactionLogAppender.writeLog() with a try/catch and re-open the file there.  Whatever write
> operation was in progress needs to be retried, otherwise the log will be in a corrupt state.
>
> Something like:
>
> while (buf.hasRemaining()) {
>
>     try {
>
> this.fc.write(buf);
>
>     }
>
>     catch (ClosedChannelException cce) {
>
>        // re-open
>
>     }
>
> }
>
>
> This assumes that Java does not advance the ByteBuffer position in the case that
> ClosedChannelException is thrown.
>
> Regards,
> Brett
>
>
> On Mon, Apr 6, 2015 at 9:50 AM, Kazuya Uno <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Ludovic,
>
>     Thank you for reply.
>     Unfortunately, our product depends on BTM 2.1.4.
>     And I think the latest stable version of Bitronix is 2.1.4, isn't it?
>
>     My hack close/open the disk journal when ClosedChannelException is occured,
>     and re-throw caught exception. I hope this approach prevent corrupt log
>     entry written to journal, but not sure.
>
>     How did you prevent channel closing when interrupted in 3.0.0?
>
>
>     On 2015/04/03 18:58, Ludovic Orban wrote:
>
>         Hi,
>
>         I think that bug has been long fixed in BTM 3.0.0. Have you checked it?
>
>         --
>         Ludovic
>
>         On Fri, Apr 3, 2015 at 11:13 AM, Kazuya Uno <[hidden email]
>         <mailto:[hidden email]>> wrote:
>
>             Hello,
>
>             I stumbled on the bug BTM-138(http://jira.codehaus.__org/browse/BTM-138
>             <http://jira.codehaus.org/browse/BTM-138>).
>
>             I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
>             fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.
>
>             This simply close and re-open the disk journal when ClosedChannelException
>             was detected.
>
>             This hack seems to work for me, but I am afraid that this might cause some
>             undesirable side effects.
>
>             What do you think about this? Is there someone who has the better idea?
>
>             Best Regards.
>
>
>             ------------------------------__------------------------------__---------
>             To unsubscribe from this list, please visit:
>
>             http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>
>
>         ------------------------------__------------------------------__---------
>         To unsubscribe from this list, please visit:
>
>         http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>
>
>
>
>
>     ------------------------------__------------------------------__---------
>     To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Fix for BTM-138

Kazuya Uno
 > So, You think the patch will work

Oops, Sorry. You said that my hack will not work and 3.0.0 too.
Then, how about my worries about your suggestion?

On 2015/04/06 15:59, Kazuya Uno wrote:

> Hi Berret,
>
> Thanks for reply!
>
>  > The patch, as implemented, will not prevent log corruption.
>
> So, You think the patch will work ?
>
>  > My suggestion would be to surround the "fc.write(...)" call in
>  > TransactionLogAppender.writeLog() with a try/catch and re-open the file there.
>
> I thought this too. But I have a thing to worry abount.
> With that aproach, if the events occurred in the following order,
>
> 1. transaction.setStatus(Status.STATUS_PREPARING);
> 2. transaction.setStatus(Status.STATUS_PREPARED);
> 3. thread.interrupt();  // this cause channel close!
> 4. transaction.setStatus(Status.STATUS_COMMITTING); // re-open here and flush to disk.
> 5. transaction.setStatus(Status.STATUS_COMMITTED, committedAndNotInterestedUniqueNames);
>
> I think that this may result in the COMMITNG/COMMITED records
> without corresponding PREPARING/PREPARED in the disk journal.
>
> I'm afraid that this might cause something undesirable side effects.
> Or Bitronix is smart enough to handle it gracefully?
>
> Best Regards.
>
> On 2015/04/06 14:37, Brett Wooldridge wrote:
>> Hi Kazuya,
>>
>> The patch, as implemented, will not prevent log corruption.  3.0.0 also does not prevent corruption
>> due to thread interruption.  My suggestion would be to surround the "fc.write(...)" call in
>> TransactionLogAppender.writeLog() with a try/catch and re-open the file there.  Whatever write
>> operation was in progress needs to be retried, otherwise the log will be in a corrupt state.
>>
>> Something like:
>>
>> while (buf.hasRemaining()) {
>>
>>     try {
>>
>> this.fc.write(buf);
>>
>>     }
>>
>>     catch (ClosedChannelException cce) {
>>
>>        // re-open
>>
>>     }
>>
>> }
>>
>>
>> This assumes that Java does not advance the ByteBuffer position in the case that
>> ClosedChannelException is thrown.
>>
>> Regards,
>> Brett
>>
>>
>> On Mon, Apr 6, 2015 at 9:50 AM, Kazuya Uno <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Hi Ludovic,
>>
>>     Thank you for reply.
>>     Unfortunately, our product depends on BTM 2.1.4.
>>     And I think the latest stable version of Bitronix is 2.1.4, isn't it?
>>
>>     My hack close/open the disk journal when ClosedChannelException is occured,
>>     and re-throw caught exception. I hope this approach prevent corrupt log
>>     entry written to journal, but not sure.
>>
>>     How did you prevent channel closing when interrupted in 3.0.0?
>>
>>
>>     On 2015/04/03 18:58, Ludovic Orban wrote:
>>
>>         Hi,
>>
>>         I think that bug has been long fixed in BTM 3.0.0. Have you checked it?
>>
>>         --
>>         Ludovic
>>
>>         On Fri, Apr 3, 2015 at 11:13 AM, Kazuya Uno <[hidden email]
>>         <mailto:[hidden email]>> wrote:
>>
>>             Hello,
>>
>>             I stumbled on the bug BTM-138(http://jira.codehaus.__org/browse/BTM-138
>>             <http://jira.codehaus.org/browse/BTM-138>).
>>
>>             I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
>>             fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.
>>
>>             This simply close and re-open the disk journal when ClosedChannelException
>>             was detected.
>>
>>             This hack seems to work for me, but I am afraid that this might cause some
>>             undesirable side effects.
>>
>>             What do you think about this? Is there someone who has the better idea?
>>
>>             Best Regards.
>>
>>
>>             ------------------------------__------------------------------__---------
>>             To unsubscribe from this list, please visit:
>>
>>             http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>>
>>
>>         ------------------------------__------------------------------__---------
>>         To unsubscribe from this list, please visit:
>>
>>         http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>>
>>
>>
>>
>>
>>     ------------------------------__------------------------------__---------
>>     To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Fix for BTM-138

Brett Wooldridge-2
My understanding is ... if these two calls succeed:

1. transaction.setStatus(Status.STATUS_PREPARING);
2. transaction.setStatus(Status.STATUS_PREPARED);

... even if the thread is interrupted and the channel is closed, these writes to the filesystem will eventually be flushed (in FIFO order).  Therefore, these two calls

4. transaction.setStatus(Status.STATUS_COMMITTING); // re-open here and flush to disk.
5. transaction.setStatus(Status.STATUS_COMMITTED, committedAndNotInterestedUniqueNames);

should result in a valid committed transaction in the logs.



On Mon, Apr 6, 2015 at 4:07 PM, Kazuya Uno <[hidden email]> wrote:
> So, You think the patch will work

Oops, Sorry. You said that my hack will not work and 3.0.0 too.
Then, how about my worries about your suggestion?


On 2015/04/06 15:59, Kazuya Uno wrote:
Hi Berret,

Thanks for reply!

 > The patch, as implemented, will not prevent log corruption.

So, You think the patch will work ?

 > My suggestion would be to surround the "fc.write(...)" call in
 > TransactionLogAppender.writeLog() with a try/catch and re-open the file there.

I thought this too. But I have a thing to worry abount.
With that aproach, if the events occurred in the following order,

1. transaction.setStatus(Status.STATUS_PREPARING);
2. transaction.setStatus(Status.STATUS_PREPARED);
3. thread.interrupt();  // this cause channel close!
4. transaction.setStatus(Status.STATUS_COMMITTING); // re-open here and flush to disk.
5. transaction.setStatus(Status.STATUS_COMMITTED, committedAndNotInterestedUniqueNames);

I think that this may result in the COMMITNG/COMMITED records
without corresponding PREPARING/PREPARED in the disk journal.

I'm afraid that this might cause something undesirable side effects.
Or Bitronix is smart enough to handle it gracefully?

Best Regards.

On 2015/04/06 14:37, Brett Wooldridge wrote:
Hi Kazuya,

The patch, as implemented, will not prevent log corruption.  3.0.0 also does not prevent corruption
due to thread interruption.  My suggestion would be to surround the "fc.write(...)" call in
TransactionLogAppender.writeLog() with a try/catch and re-open the file there.  Whatever write
operation was in progress needs to be retried, otherwise the log will be in a corrupt state.

Something like:

while (buf.hasRemaining()) {

    try {

this.fc.write(buf);

    }

    catch (ClosedChannelException cce) {

       // re-open

    }

}


This assumes that Java does not advance the ByteBuffer position in the case that
ClosedChannelException is thrown.

Regards,
Brett


On Mon, Apr 6, 2015 at 9:50 AM, Kazuya Uno <[hidden email]
<mailto:[hidden email]>> wrote:

    Hi Ludovic,

    Thank you for reply.
    Unfortunately, our product depends on BTM 2.1.4.
    And I think the latest stable version of Bitronix is 2.1.4, isn't it?

    My hack close/open the disk journal when ClosedChannelException is occured,
    and re-throw caught exception. I hope this approach prevent corrupt log
    entry written to journal, but not sure.

    How did you prevent channel closing when interrupted in 3.0.0?


    On 2015/04/03 18:58, Ludovic Orban wrote:

        Hi,

        I think that bug has been long fixed in BTM 3.0.0. Have you checked it?

        --
        Ludovic

        On Fri, Apr 3, 2015 at 11:13 AM, Kazuya Uno <[hidden email]
        <mailto:[hidden email]>> wrote:

            Hello,

            I stumbled on the bug BTM-138(http://jira.codehaus.__org/browse/BTM-138
            <http://jira.codehaus.org/browse/BTM-138>).

            I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
            fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.

            This simply close and re-open the disk journal when ClosedChannelException
            was detected.

            This hack seems to work for me, but I am afraid that this might cause some
            undesirable side effects.

            What do you think about this? Is there someone who has the better idea?

            Best Regards.


            ------------------------------__------------------------------__---------
            To unsubscribe from this list, please visit:

            http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>


        ------------------------------__------------------------------__---------
        To unsubscribe from this list, please visit:

        http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>





    ------------------------------__------------------------------__---------
    To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Fix for BTM-138

Kazuya Uno
Hi Berret,

Thank you for reply and sorry for my slow understanding.

> ... even if the thread is interrupted and the channel is closed, these writes to the filesystem
> /will/ eventually be flushed (in FIFO order).  Therefore, these two calls

You mean "these writes" exists in file system buffer, so eventually be flushed
to disk regardless of the re-open of the channel. Is this correct understanding?

I modified TransactionLogAppender as follows (attached file).

o Replace final to volatile of fc, lock, header.
o Add reopen() method to writeLog(), doForce()
o Add "synchronized" modifier to/remove synchronized(fc) from writeLog(), close(),
   doForce()


my reopen() method is as follows.
=================================
private void reopen() throws IOException {
     this.fc = new RandomAccessFile(file, "rw").getChannel();
     this.header = new TransactionLogHeader(fc, maxFileLength);
     this.lock = fc.tryLock(0, TransactionLogHeader.TIMESTAMP_HEADER, false);
     if (this.lock == null)
         throw new IOException("transaction log file " + file.getName() + " is locked. Is another
instance already running?");    
}

Hmm, Have I overlook something?

On 2015/04/06 17:23, Brett Wooldridge wrote:

> My understanding is ... if these two calls succeed:
>
> 1. transaction.setStatus(Status.__STATUS_PREPARING);
> 2. transaction.setStatus(Status.__STATUS_PREPARED);
>
> ... even if the thread is interrupted and the channel is closed, these writes to the filesystem
> /will/ eventually be flushed (in FIFO order).  Therefore, these two calls
>
> 4. transaction.setStatus(Status.__STATUS_COMMITTING); // re-open here and flush to disk.
> 5. transaction.setStatus(Status.__STATUS_COMMITTED, committedAndNotInterestedUniqu__eNames);
>
> should result in a valid committed transaction in the logs.
>
>
>
> On Mon, Apr 6, 2015 at 4:07 PM, Kazuya Uno <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     > So, You think the patch will work
>
>     Oops, Sorry. You said that my hack will not work and 3.0.0 too.
>     Then, how about my worries about your suggestion?
>
>
>     On 2015/04/06 15:59, Kazuya Uno wrote:
>
>         Hi Berret,
>
>         Thanks for reply!
>
>           > The patch, as implemented, will not prevent log corruption.
>
>         So, You think the patch will work ?
>
>           > My suggestion would be to surround the "fc.write(...)" call in
>           > TransactionLogAppender.__writeLog() with a try/catch and re-open the file there.
>
>         I thought this too. But I have a thing to worry abount.
>         With that aproach, if the events occurred in the following order,
>
>         1. transaction.setStatus(Status.__STATUS_PREPARING);
>         2. transaction.setStatus(Status.__STATUS_PREPARED);
>         3. thread.interrupt();  // this cause channel close!
>         4. transaction.setStatus(Status.__STATUS_COMMITTING); // re-open here and flush to disk.
>         5. transaction.setStatus(Status.__STATUS_COMMITTED, committedAndNotInterestedUniqu__eNames);
>
>         I think that this may result in the COMMITNG/COMMITED records
>         without corresponding PREPARING/PREPARED in the disk journal.
>
>         I'm afraid that this might cause something undesirable side effects.
>         Or Bitronix is smart enough to handle it gracefully?
>
>         Best Regards.
>
>         On 2015/04/06 14:37, Brett Wooldridge wrote:
>
>             Hi Kazuya,
>
>             The patch, as implemented, will not prevent log corruption.  3.0.0 also does not prevent
>             corruption
>             due to thread interruption.  My suggestion would be to surround the "fc.write(...)" call in
>             TransactionLogAppender.__writeLog() with a try/catch and re-open the file there.
>             Whatever write
>             operation was in progress needs to be retried, otherwise the log will be in a corrupt state.
>
>             Something like:
>
>             while (buf.hasRemaining()) {
>
>                  try {
>
>             this.fc.write(buf);
>
>                  }
>
>                  catch (ClosedChannelException cce) {
>
>                     // re-open
>
>                  }
>
>             }
>
>
>             This assumes that Java does not advance the ByteBuffer position in the case that
>             ClosedChannelException is thrown.
>
>             Regards,
>             Brett
>
>
>             On Mon, Apr 6, 2015 at 9:50 AM, Kazuya Uno <[hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email].__jp <mailto:[hidden email]>>> wrote:
>
>                  Hi Ludovic,
>
>                  Thank you for reply.
>                  Unfortunately, our product depends on BTM 2.1.4.
>                  And I think the latest stable version of Bitronix is 2.1.4, isn't it?
>
>                  My hack close/open the disk journal when ClosedChannelException is occured,
>                  and re-throw caught exception. I hope this approach prevent corrupt log
>                  entry written to journal, but not sure.
>
>                  How did you prevent channel closing when interrupted in 3.0.0?
>
>
>                  On 2015/04/03 18:58, Ludovic Orban wrote:
>
>                      Hi,
>
>                      I think that bug has been long fixed in BTM 3.0.0. Have you checked it?
>
>                      --
>                      Ludovic
>
>                      On Fri, Apr 3, 2015 at 11:13 AM, Kazuya Uno <[hidden email]
>             <mailto:[hidden email]>
>                      <mailto:[hidden email].__jp <mailto:[hidden email]>>> wrote:
>
>                          Hello,
>
>                          I stumbled on the bug BTM-138(http://jira.codehaus.____org/browse/BTM-138
>                          <http://jira.codehaus.org/__browse/BTM-138
>             <http://jira.codehaus.org/browse/BTM-138>>).
>
>                          I know the BTM 2.1.x is in maintenance mode, so I wrote a quick hack to
>                          fix this issue. I attached fixed version of DiskJournal.java of BTM 2.1.4.
>
>                          This simply close and re-open the disk journal when ClosedChannelException
>                          was detected.
>
>                          This hack seems to work for me, but I am afraid that this might cause some
>                          undesirable side effects.
>
>                          What do you think about this? Is there someone who has the better idea?
>
>                          Best Regards.
>
>
>                          ------------------------------____----------------------------__--__---------
>                          To unsubscribe from this list, please visit:
>
>             http://xircles.codehaus.org/____manage_email
>             <http://xircles.codehaus.org/__manage_email> <http://xircles.codehaus.org/__manage_email
>             <http://xircles.codehaus.org/manage_email>>
>
>
>                      ------------------------------____----------------------------__--__---------
>                      To unsubscribe from this list, please visit:
>
>             http://xircles.codehaus.org/____manage_email
>             <http://xircles.codehaus.org/__manage_email> <http://xircles.codehaus.org/__manage_email
>             <http://xircles.codehaus.org/manage_email>>
>
>
>
>
>
>                  ------------------------------____----------------------------__--__---------
>                  To unsubscribe from this list, please visit:
>
>             http://xircles.codehaus.org/____manage_email
>             <http://xircles.codehaus.org/__manage_email> <http://xircles.codehaus.org/__manage_email
>             <http://xircles.codehaus.org/manage_email>>
>
>
>
>
>
>         ------------------------------__------------------------------__---------
>         To unsubscribe from this list, please visit:
>
>         http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>
>
>
>
>
>     ------------------------------__------------------------------__---------
>     To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/__manage_email <http://xircles.codehaus.org/manage_email>
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

TransactionLogAppender.java (12K) Download Attachment