db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5283) Crash / process termination during SYSCS_DISABLE_LOG_ARCHIVE_MODE can leave service.properties broken
Date Mon, 10 Oct 2011 14:01:30 GMT

    [ 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

        

Mime
View raw message