db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Updated: (DERBY-3890) Replication: NPE for startSlave of encrypted database
Date Mon, 27 Oct 2008 10:00:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jørgen Løland updated DERBY-3890:
---------------------------------

    Attachment: derby-3890-1.diff
                derby-3890-1.stat

The attached patch removes the NPE by setting RawStoreFactory in LogFactory before starting
slave replication mode. The patch removes the only currently known problem related to replication
of encrypted databases.

A separate jira has been created for testing replication of encrypted databases, so this patch
does not include any test cases.

> Replication: NPE for startSlave of encrypted database
> -----------------------------------------------------
>
>                 Key: DERBY-3890
>                 URL: https://issues.apache.org/jira/browse/DERBY-3890
>             Project: Derby
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 10.4.1.3, 10.4.2.0
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>            Priority: Minor
>         Attachments: derby-3890-1.diff, derby-3890-1.stat
>
>
> If slave replication mode is started on an encrypted database, derby fails with a NPE
and then hangs. The reason for the hang is that LogToFile#initializeSlaveReplicationMode needs
to scan the log to find the end. For encrypted databases, this scan uses RawStoreFactory#decrypt.
At this stage, LTF#rawStoreFactory variable has not been set. 
> A solution may be to set this variable in LTF before scanning the log.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message