Andrew Lawrenson wrote:
Ok, I understand - many thanks!
Andy
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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
