[
https://issues.apache.org/jira/browse/DERBY-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5937:
--------------------------------------
Attachment: d5937-2a-close.diff
Thanks for verifying the test, Kristian.
I'm attaching a new patch (d5937-2a-close.diff) which attempts to fix the bug.
While a slave is running, LogToFile blocks in recover() waiting for fail-over
to happen. When it is notified that fail-over has happened, it continues with
ordinary recovery as a first step in booting the database, and in this process
it reads the log files. In a "normal" boot process, the log file isn't already
open when recovery runs, so recover() doesn't care about closing the currently
active log file first. This causes a problem when promoting a slave database,
which holds a log file open, as the re-opening of the log file will make
LogToFile forget about the old file handle without ever closing it.
The fix makes recover() check if a log file is open, and close that file,
before re-opening the log. It also enables the regression test case for the bug
in ReplicationSuite.
I've verified that the test case passes on Windows when the fix is applied. I'm
also running the full regression test suite on Solaris and Windows. Will report
back when all the tests have completed.
> File handle is leaked when a Slave replication is shutdown with failover=true
> -----------------------------------------------------------------------------
>
> Key: DERBY-5937
> URL: https://issues.apache.org/jira/browse/DERBY-5937
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.8.2.2
> Environment: Windows 7
> Reporter: Glenn McGregor
> Assignee: Knut Anders Hatlen
> Labels: derby_triage10_10
> Attachments: d5937-1a-test.diff, d5937-2a-close.diff
>
>
> As part of our use of derby replication, we shut the slave down if we detect
> reachability issues with the master. Normally we shut it down, and bring it
> back up as a regular database in read-only mode. Then when the master can,
> it tries to push a fresh copy back to the slave system. However, during the
> failover=true shutdown on the slave, the log file ".../name/log/log1.dat" is
> still open.
> Because of this open file, at least on Windows, it's impossible to move the
> database file out of the way, and to install a fresh copy from the master.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
