Re: Derby Encryption AND Replication

[Jørgen Løland <Jo...@Sun.COM>]

Andrew Lawrenson wrote:
> Ok, I understand - many thanks!
> 
>         Andy
> 
> -----Original Message-----
> From: Jorgen.Loland@Sun.COM [mailto:Jorgen.Loland@Sun.COM]
> Sent: 30 September 2008 15:50
> To: Derby Discussion
> Subject: Re: Derby Encryption AND Replication
> 
> Andrew,
> 
> Right, this kind of problem (the NPE) is a good example of things that would need to be fixed. As I said, encryption/backup hasn't been tested together and can only be considered experimental functionality at this stage.
> 
> Regarding the question: Yes, it makes sense to me why startSlave has to be called before recover. Replication is based on not letting the slave leave recovery while replication is running. I.e, the slave is constantly doing recovery of the log records received from the master.
> The startSlave method does some initialization work that is needed before log can be received from the master.
> 
> That being said, the NPE problem can be fixed by setting the rawStoreFactory variable in LTF before parsing the log files (the second while loop in LTF#initializeReplicationSlaveRole). I tested this by writing a little hack: SlaveController#startSlave already knows about rawStore, so I just passed it to LTF#initializeReplicationSlaveMode and set it there. That removed the NPE. I created a bug report for this issue:
> 
> https://issues.apache.org/jira/browse/DERBY-3890
> 
> You are more than welcome to create a patch for it if you think the suggested solution is sound. However, I think maybe the LTF#rawStoreFactory should be initialized somewhere else than through SlaveController.

Hi Andrew,

A patch for this problem has been committed to the repository. It will 
be part of the next Derby release. If you don't want to wait, you can 
also try it out by downloading the source code from the repository.

-- 
Jørgen Løland