[
https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jørgen Løland updated DERBY-3184:
---------------------------------
Attachment: derby-3184-1.stat
derby-3184-1.diff
The attached patch, v1, adds boolean inReplicationSlaveMode to TopService. When
Module.findService is called, TopService.isInReplicationSlaveMode is called,
and an exception is raised if the method returns true.
Also modifies classes that call Monitor.findService to handle the new exception.
The patch is ready for review and has passed all tests except triggerGeneral,
which has already been reported in
http://article.gmane.org/gmane.comp.apache.db.derby.devel/50419
> Replication: Connection attempts to a database in slave mode must fail
> ----------------------------------------------------------------------
>
> Key: DERBY-3184
> URL: https://issues.apache.org/jira/browse/DERBY-3184
> Project: Derby
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 10.4.0.0
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
> Attachments: derby-3184-1.diff, derby-3184-1.stat
>
>
> When a database 'X' is booted in slave mode, the call to
> Monitor.startPersistentService("X",...) will not complete because the call
> gets stuck in LogToFile#recover. This is intentional.
> For as long as startPersistentService is blocked, however, other threads that
> try to connect to 'X' (effectively calling Monitor.findService("X", ...))
> will also hang. This is unacceptable, and needs to raise an error.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
