You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org> on 2011/10/10 16:01:30 UTC
[jira] [Commented] (DERBY-5283) Crash / process termination during
SYSCS_DISABLE_LOG_ARCHIVE_MODE can leave service.properties broken
[ https://issues.apache.org/jira/browse/DERBY-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124117#comment-13124117 ]
Knut Anders Hatlen commented on DERBY-5283:
-------------------------------------------
The suggested approach sounds good to me.
One possible simplification:
Instead of materializing the entire service.properties file in prepareServicePropertiesContents() outside of the try block in saveServiceProperties(), we could move it into the existing try block:
try
{
os = servicePropertiesFile.getOutputStream();
properties.store( os, serviceName + MessageService.getTextMessage(MessageId.SERVICE_PROPERTIES_DONT_EDIT));
storageFactory.sync( os, false);
os.close();
os = null;
}
and call something like os.write(SERVICE_PROPERTIES_END_TOKEN.getBytes("US-ASCII")) between properties.store() and storageFactory.sync(). That would allow us to remove the error handling in prepareServicePropertiesContents() (well, actually, we could remove the entire method), since the same error handling seems to be performed by the try/catch in saveServiceProperties().
What would be a good way to test this fix? Creating a database, shutting it down, and then modifying service.properties/service.propertiesold before booting it?
It might also be useful to link to the original exception in the cases where we re-throw SecurityException and IOException as StandardException (in handleSecPrivException() and resolveServicePropertiesFiles()).
> Crash / process termination during SYSCS_DISABLE_LOG_ARCHIVE_MODE can leave service.properties broken
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-5283
> URL: https://issues.apache.org/jira/browse/DERBY-5283
> Project: Derby
> Issue Type: Bug
> Components: Miscellaneous
> Affects Versions: 10.6.1.0, 10.8.1.2
> Environment: >sysinfo
> ------------------ Java Information ------------------
> Java Version: 1.6.0_26
> Java Vendor: Sun Microsystems Inc.
> Java home: C:\Program Files (x86)\Java\jre6
> Java classpath: .;C:\Program Files (x86)\Java\jre6\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin\../lib/derbytools.jar
> OS name: Windows 7
> OS architecture: x86
> OS version: 6.1
> Java user name: bmason
> Java user home: C:\Users\BMASON
> Java user dir: C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\bin
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> java.runtime.version: 1.6.0_26-b03
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derby.jar] 10.6.1.0 - (938214)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbytools.jar] 10.6.1.0 - (938214)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbynet.jar] 10.6.1.0 - (938214)
> [C:\Users\BMASON\Sandbox\libs\db-derby-10.6.1.0-bin\lib\derbyclient.jar] 10.6.1.0 - (938214)
> ------------------------------------------------------
> ----------------- Locale Information -----------------
> Current Locale : [English/New Zealand [en_NZ]]
> Found support for locale: [cs]
> version: 10.6.1.0 - (938214)
> Found support for locale: [de_DE]
> version: 10.6.1.0 - (938214)
> Found support for locale: [es]
> version: 10.6.1.0 - (938214)
> Found support for locale: [fr]
> version: 10.6.1.0 - (938214)
> Found support for locale: [hu]
> version: 10.6.1.0 - (938214)
> Found support for locale: [it]
> version: 10.6.1.0 - (938214)
> Found support for locale: [ja_JP]
> version: 10.6.1.0 - (938214)
> Found support for locale: [ko_KR]
> version: 10.6.1.0 - (938214)
> Found support for locale: [pl]
> version: 10.6.1.0 - (938214)
> Found support for locale: [pt_BR]
> version: 10.6.1.0 - (938214)
> Found support for locale: [ru]
> version: 10.6.1.0 - (938214)
> Found support for locale: [zh_CN]
> version: 10.6.1.0 - (938214)
> Found support for locale: [zh_TW]
> version: 10.6.1.0 - (938214)
> ------------------------------------------------------
> Reporter: Brett Mason
> Assignee: Kristian Waagan
> Attachments: derby-5283-1a-recover.diff
>
>
> If Derby is terminated while SYSCS_DISABLE_LOG_ARCHIVE_MODE is being called service.properties can be left in a broken state.
> Depending on timing either of the two cases can happen:
> Case 1:
> "ERROR XBM0S: Unable to rename file 'C:\PATH_TO_DB\service.properties' to 'C:\PATH_TO_DB\service.propertiesold' " is thrown when next trying to call
> SYSCS_DISABLE_LOG_ARCHIVE_MODE(1). Both "service.properties" and "service.propertiesold" are present in the database directory. Removing "service.propertiesold" corrects the problem.
> Case 2:
> "SQLException: Database 'C:\PATH_TO_DB' not found" is thrown when booting the database. The file service.properties does not exist in the database directory but service.propertiesold does exist. Renaming the file back to "service.properties" corrects the problem.
> As mentioned above both cases have workarounds but they require manual intervention which is a problem for applications installed to a customer site. It would be great if a more reliable method to update the file could be found.
> The following sample code will reproduce the issue fairly reliably by terminating the java process:
> import java.sql.*;
> import org.apache.derby.jdbc.*;
> public class DerbyLogArchiveModeTest {
>
> public static void main(String[] args) {
> final EmbeddedDataSource ds = new EmbeddedDataSource();
> ds.setDatabaseName("derbyTest");
> ds.setCreateDatabase("create");
> try {
> final Connection conn = ds.getConnection();
> try {
> final Statement stmt = conn.createStatement();
> try {
> while (true) {
> stmt.execute("call SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE(1)");
> }
> } finally {
> stmt.close();
> }
> } finally {
> conn.close();
> }
> } catch (SQLException e) {
> e.printStackTrace();
> }
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira