Knut Anders Hatlen wrote:

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
effect.

I've removed the setting of the derby.system.home property entirely but
the problem still persists. It seems to be that within a single JVM, if
the master is opened before the slave the slave open fails. That looks a bit like there is some left-over state from the master open that is affecting the slave open, but I have no idea a what.

There's another bizarre issue, I'm connecting to the master database
using the username & password of the database owner (the app uses a
different username & schema) and although the application gets back a
valid connection (the subsequent syscs_util.syscs_freeze_database works)
I see the following exception in derby.log:

ERROR 08004: Database connection refused.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
        at org.apache.derby.impl.sql.conn.GenericAuthorizer.refresh(Unknown 
Source)
        at org.apache.derby.impl.sql.conn.GenericAuthorizer.<init>(Unknown 
Source)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(Unknown Source)
        at org.apache.derby.impl.db.BasicDatabase.setupConnection(Unknown 
Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.checkUserIsNotARole(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
        at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
        at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
        at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
        at org.apache.derby.impl.drda.Database.makeDummyConnection(Unknown 
Source)
at org.apache.derby.impl.drda.DRDAConnThread.validateSecMecUSRSSBPWD(Unknown Source)
        at org.apache.derby.impl.drda.DRDAConnThread.parseACCSEC(Unknown Source)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
        at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)

How on earth can it be throwing that error yet still returning a successful connection to the client application? I'm totally confused...

DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE04, SQLERRMC:
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.)

Ah OK, thanks - that explains that, at least.

 > 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
port.

http://db.apache.org/derby/docs/10.5/adminguide/cadminreplicsecurity.html

I don't think so, as I said the server is being started from within a Java app rather than with the command-line utility, and security policies aren't enabled.

What I see in the slave's derby.log just after the startMaster is:

Database Class Loader started - derby.database.classpath=''
2009-07-07 14:12:18.932 GMT Thread[DRDAConnThread_4,5,derby.daemons] (XID = 529), (SESSIONID = 0), (DATABASE
 = opensolaris), (DRDAID = null), Cleanup action starting
ERROR 08004: Database connection refused.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.conn.GenericAuthorizer.refresh(Unknown Source) at org.apache.derby.impl.sql.conn.GenericAuthorizer.<init>(Unknown Source) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(Unknown Source) at org.apache.derby.impl.db.BasicDatabase.setupConnection(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.checkUserIsNotARole(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
        at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
        at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at org.apache.derby.impl.drda.Database.makeDummyConnection(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.validateSecMecUSRSSBPWD(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseACCSEC(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
        at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)

followed by a load more similar stack traces, then finally:

ERROR XRE09: Cannot start replication slave mode for database 'opensolaris'. The database has already been booted. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown Source)
        at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
        at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at org.apache.derby.impl.drda.Database.makeConnection(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)
        at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)

which is complete rubbish as the database clearly hasn't been booted - the startSlave causes the entire sequence of stack traces, and before that call is made all that is in the log is the network server startup message.

I'm wondering if this chaos is being caused by the fact that the derby database owner and the owner of the only schema in the database that is being replicated are different users? The database is created by user "admin", then the following DB configuration is done:

derby.database.propertiesOnly = true
derby.authentication.provider = BUILTIN
derby.database.defaultConnectionMode = noAccess
derby.database.requireAuthentication = true
derby.user.admin = admin
derby.user.auth = CHANGEME
derby.database.fullAccessUsers = admin,auth
create schema auth authorization auth

The application then creates its tables in the auth schema. Could that be the issue?

--
Alan Burlison
--

Reply via email to