db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Derby replication seems to be mostly useless
Date Tue, 07 Jul 2009 12:46:28 GMT
Alan Burlison <Alan.Burlison@Sun.COM> writes:

> Knut Anders Hatlen wrote:
>> I think it should work, at least it did when I tested it in what I think
>> is a similar scenario. See the attached script which creates a database
>> with authentication and authorization enabled, starts slave and master
>> servers, and performs failover.
>> Are you running the network server in a separate process, or is it
>> embedded inside another Java process? If the latter, it may be that the
>> database has already been booted when the server is started.
> The network server is a separate process, started from the command-line.
> I *think* I've partially figured out what the problem is.  I'm running
> with two databases on the same machine, set up under two different
> Derby system directories, e.g.
> Master in /tmp/auth, containing database 'opensolaris', data files in
> /tmp/auth/opensolaris
> Slave in /tmp/auth1, containing database 'opensolaris' data files in
> /tmp/auth1/opensolaris
> I'm connecting to the master and the slave to start the replication
> from inside the same JVM, and although I'm setting derby.system.home
> before the connect calls, the derby docs say that derby.system.home is
> static so the first setting before I open a connection wins, and
> that's to the master - and I think that's what is causing the issues
> with the slave. In your test script you are doing the startSlave from
> a separate JVM, which is I guess why you aren't seeing the same
> problem.
> What is puzzling me is that I'm connecting to the slave using the
> network driver to databases running in a separate JVMs, so I would
> have expected the derby.system.home setting to be irrelevant, but it
> seems not.

That is indeed strange. The derby.system.home property should only be
used by the embedded driver (and by the network server since it uses the
embedded driver). Setting it on the client side should not have any

> To confirm that I've set up the slave on a separate machine, using the
> same derby.system.home as the master.  If I do that the startSlave
> works just fine, which points to the issue being related to having the
> master and slave on the same machine but with different
> derby.system.home settings.  As I said, I'm puzzled as to why
> derby.system.home should have any effect when I'm connecting with the
> network driver, but the evidence does seem to point in that direction.
> However even if I run with the slave on a different machine and get
> past the startSlave step, the subsequent startMaster fails with a
> bizarre-looking error message full of control characters:
> opensolaris.bleaklow.4851.XRE04.U.1 [XRE04]
> So there's obviously something else amiis as well.

This error message is supposed to say

Could not establish a connection to the peer of the replicated database
'opensolaris' on address 'bleaklow:4851'.

(The unreadable message was fixed in DERBY-3417, but wasn't back-ported
to 10.5.)

I'm wondering if this could be because the network server's default
security policy doesn't allow connections to port 4851. If the root
cause (found in derby.log on the server) is an AccessControlException
that's probably the case. Either start the network server with
-noSecurityManager or install a custom security policy which opens that


Knut Anders

View raw message