You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Jørgen Løland (JIRA)" <ji...@apache.org> on 2007/11/07 10:38:50 UTC
[jira] Created: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
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
Reporter: Jørgen Løland
Assignee: Jørgen Løland
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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555531#action_12555531 ]
Jørgen Løland commented on DERBY-3184:
--------------------------------------
No problem. Thanks for reviewing and committing :)
> 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, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland updated DERBY-3184:
---------------------------------
Derby Info: [Patch Available]
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland updated DERBY-3184:
---------------------------------
Derby Info: [Patch Available]
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Issue Comment Edited: (DERBY-3184) Replication: Connection
attempts to a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561329#action_12561329 ]
oysteing edited comment on DERBY-3184 at 1/22/08 4:49 AM:
-----------------------------------------------------------------
Error handling in SlaveDatabase looks good, but since ReplicationLogger does not contain any state, I think it would be better to make logError static. Then you would not have to instantiate in every class where you need error handling.
It also worries me a bit that you had to import StandardException in DRDAConnThread, but that is probably not your fault. It seems to me that validateSecMecUSRSSBPWD() does things that maybe should have been handled inside the database. Anyway, we should make sure to test this case. That is, try to connect to a slave database using SecMecUSRSSBPWD.
A minor issue: In EmbedConnection: No need to cast se, it is already a StandardException.
was (Author: oysteing):
Error handling in SlaveDatabase looks good, but since ReplicationLogger does not contain any state, I think it would be better to make logError static. Then you would not have to instantiate in every class where you need error handling.
It also worries me a bit that you had to import StandardException in DRDAConnThread, but that is probably not your fault. It seems to me that validateSecMecUSRSSBPWD() does things that maybe should have been handled inside the database. Anyway, we should make sure to test this case. That is, try to connect to a slave database using SecMecUSRSSBPWD.
A minor issue: In EmbedConnection: No need to case se, it is already a StandardException.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland updated DERBY-3184:
---------------------------------
Derby Info: [Patch Available]
> 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.
[jira] Closed: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland closed DERBY-3184.
--------------------------------
> 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
> Fix For: 10.4.0.0
>
> Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-3b.diff, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557239#action_12557239 ]
Øystein Grøvlen commented on DERBY-3184:
----------------------------------------
Thinking a bit more about this patch, I have a few more
questions/comments:
11. Have you verified that there is either no way that the different
BasicDataBase methods can be called on a SlaveDataBase while in
slave mode, or that for those methods that may be called, no harm
may happen?
12. The more I think about it, the less sure I am about what you are
trying to achieve by making local_startParams volatile. I do not
think a volatile reference will synchronize access to the referred
instance. I see there might be issues with concurrent access to
UpdateServiceProperties.storageFactory, but I think that needs to
be solved in that class.
13. A sleep a two seconds in the boot method between checking for
StorageFactory is unnecessary long I think. I think a good rule
of thumb is to make it as short as possible without significantly
affecting the performance, and I think you can check a reference
for null more often than every other second without affecting
performance. (While a two-second delay of a boot, is probably not
an issue in production settings, there might be testing scenarios
with repeated booting of database where the total duration of the
test may be an issue.)
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557221#action_12557221 ]
Øystein Grøvlen commented on DERBY-3184:
----------------------------------------
I have looked at derby-3184-2a.diff and the patch looks good. I do
not have any major issues. However, I am not able understand the
intention behind slavepremode, and this does not seem to be explained
anywhere either. Some documentation would be nice.
Some minor comments that you may consider for a follow-up patch:
SlaveDatabase:
1. The 'be' item 4 of class javadoc should probably be removed.
2. Why not use javadoc style for comment for inReplicationSlaveMode?
3. I think it is a bit confusing that inReplicationSlaveMode is
initialized both in declaration and in boot.
4. canSupport() lacks javadoc for parameter
5. Instead of making create and startParams volatile members,
why not pass it to a SlaveDatabaseThread constructor?
6. Did you consider making SlaveDatabaseBootThread a Runnable
instead of a Thread? It does not seem like your run method depend
on inheriting any behavior from the Thread class.
7. The call to currentThread() is not necessary since sleep is a
static member of Thread.
SlaveFactory:
8. The import of Property is no longer necessary
9. Some explanation of SLAVE_PRE_MODE would be good.
LogToFile:
10. (Not introduced by this patch) initializeReplicationSlaveRole()
javadoc violate the rule that the first sentence of a javadoc
should summarize the purpose of the method.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558004#action_12558004 ]
Øystein Grøvlen commented on DERBY-3184:
----------------------------------------
Jørgen Løland (JIRA) wrote:
> 5:
> AFAIK, inner classes don't have constructors, but I added a
> setParams method that does the same. Hence, removed local_*
I do not think this is true. The introductory example on inner classes
in Gosling et.al. 'Java Programming Language' (3rd edition) , shows
a non-static member class with constructor.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Øystein Grøvlen updated DERBY-3184:
-----------------------------------
Derby Info: (was: [Patch Available])
Patch 3b committed as revision 614549.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-3b.diff, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ 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-2c.diff
You are right - I have no idea why I had that impression. The attached patch sets the parameters in the constructor to the inner class.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland updated DERBY-3184:
---------------------------------
Component/s: Services
Affects Version/s: 10.4.0.0
> 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
>
> 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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ 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-2a.diff
derby-3184-2a.stat
The attached patch, v2a, adds a new implementation of Database to Derby. The new implementation is called SlaveDatabase and is booted if startSlave=true is specified in the connection url. The following files are modified:
A java/engine/org/apache/derby/impl/db/SlaveDatabase.java
M java/engine/org/apache/derby/modules.properties
The new Database implementation "SlaveDatabase" to Derby.
M java/engine/org/apache/derby/impl/db/BasicDatabase.java
Removed the old "if (inReplicationSlaveMode) throw exception" code. This is now handled in SlaveDatabase.
M java/engine/org/apache/derby/impl/store/raw/log/LogToFile.java
Adds slave replication pre mode
M java/engine/org/apache/derby/iapi/services/replication/slave/SlaveFactory.java
Minor changes
Testing:
--------
* all tests passed
* I have also run all the junit tests on a setup where SlaveDatabase was hardcoded to be used instead of BasicDatabase. This works [1], indicating that the new implementation works *after* the database has left slave mode (i.e., after the failover command has been run)
[1] Some encryption tests fail because they expect an exception to be thrown (from the rawstore module). Since the store modules of SlaveDatabase are booted in a separate thread, these exceptions are only reported in derby.log, not reported to the caller of connect '...'. However, when SlaveDatabase in not hardcoded to be used, this can only happen when dataEncryption=true and startSlave=true are specified at the same time. This combination will not be allowed.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561329#action_12561329 ]
Øystein Grøvlen commented on DERBY-3184:
----------------------------------------
Error handling in SlaveDatabase looks good, but since ReplicationLogger does not contain any state, I think it would be better to make logError static. Then you would not have to instantiate in every class where you need error handling.
It also worries me a bit that you had to import StandardException in DRDAConnThread, but that is probably not your fault. It seems to me that validateSecMecUSRSSBPWD() does things that maybe should have been handled inside the database. Anyway, we should make sure to test this case. That is, try to connect to a slave database using SecMecUSRSSBPWD.
A minor issue: In EmbedConnection: No need to case se, it is already a StandardException.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ 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-2b.stat
derby-3184-2b.diff
Øystein,
Thanks for reviewing the patch. I have addressed all your comments. Notes on the revised patch:
5:
AFAIK, inner classes don't have constructors, but I added a setParams method that does the same. Hence, removed local_*
11:
The methods of the Database interface are used in two scenarios:
1) After getting a connection to the database. This is taken care of by throwing an exception from setupConnection, and thereby never returning a connection.
2) When the connection is established, i.e. in the constructor of EmbedConnection. The only Database method used from EmbedConnection is getAuthenticationService, which is handled in SlaveDatabase by throwing an exception.
I think this should suffice.
12:
I made the storage factory of UpdateServiceProperties volatile. UpdateServiceProperties is only used during boot of a database, so this should not result in a noticeable performance degradation.
13:
I changed the sleep time to 500 millis. The previous setting was used for testing and I forgot to change it back.
Patch 2b is ready for review
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland updated DERBY-3184:
---------------------------------
Derby Info: [Patch Available]
> 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, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Resolved: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland resolved DERBY-3184.
----------------------------------
Resolution: Fixed
Fix Version/s: 10.4.0.0
> 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
> Fix For: 10.4.0.0
>
> Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-3b.diff, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Issue Comment Edited: (DERBY-3184) Replication: Connection
attempts to a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557221#action_12557221 ]
oysteing edited comment on DERBY-3184 at 1/9/08 2:41 AM:
----------------------------------------------------------------
I have looked at derby-3184-2a.diff and the patch looks good. I do
not have any major issues. However, I am not able understand the
intention behind slavepremode, and this does not seem to be explained
anywhere either. Some documentation would be nice.
Some minor comments that you may consider for a follow-up patch:
SlaveDatabase:
1. The 'be' in item 4 of class javadoc should probably be removed.
2. Why not use javadoc style for comment for inReplicationSlaveMode?
3. I think it is a bit confusing that inReplicationSlaveMode is
initialized both in declaration and in boot.
4. canSupport() lacks javadoc for parameter
5. Instead of making create and startParams volatile members,
why not pass it to a SlaveDatabaseThread constructor?
6. Did you consider making SlaveDatabaseBootThread a Runnable
instead of a Thread? It does not seem like your run method depend
on inheriting any behavior from the Thread class.
7. The call to currentThread() is not necessary since sleep is a
static member of Thread.
SlaveFactory:
8. The import of Property is no longer necessary
9. Some explanation of SLAVE_PRE_MODE would be good.
LogToFile:
10. (Not introduced by this patch) initializeReplicationSlaveRole()
javadoc violate the rule that the first sentence of a javadoc
should summarize the purpose of the method.
was (Author: oysteing):
I have looked at derby-3184-2a.diff and the patch looks good. I do
not have any major issues. However, I am not able understand the
intention behind slavepremode, and this does not seem to be explained
anywhere either. Some documentation would be nice.
Some minor comments that you may consider for a follow-up patch:
SlaveDatabase:
1. The 'be' item 4 of class javadoc should probably be removed.
2. Why not use javadoc style for comment for inReplicationSlaveMode?
3. I think it is a bit confusing that inReplicationSlaveMode is
initialized both in declaration and in boot.
4. canSupport() lacks javadoc for parameter
5. Instead of making create and startParams volatile members,
why not pass it to a SlaveDatabaseThread constructor?
6. Did you consider making SlaveDatabaseBootThread a Runnable
instead of a Thread? It does not seem like your run method depend
on inheriting any behavior from the Thread class.
7. The call to currentThread() is not necessary since sleep is a
static member of Thread.
SlaveFactory:
8. The import of Property is no longer necessary
9. Some explanation of SLAVE_PRE_MODE would be good.
LogToFile:
10. (Not introduced by this patch) initializeReplicationSlaveRole()
javadoc violate the rule that the first sentence of a javadoc
should summarize the purpose of the method.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557948#action_12557948 ]
Øystein Grøvlen commented on DERBY-3184:
----------------------------------------
I discovered the func. spec. needs to be updated to reflect this patch. Currently, the func spec says:
"A valid connection to the database is returned to the caller of the startSlave command."
I guess this is no longer true with the latest patch.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ 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-3a.stat
derby-3184-3a.diff
The attached patch, v3, adds error handling to SlaveDatabase. All tests passed - the patch is ready for review.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ 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-3b.diff
Hi Øystein,
Thanks for reviewing the patch. v3b addresses your comments. All tests pass - the patch is ready for review.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-3a.diff, derby-3184-3a.stat, derby-3184-3b.diff, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jørgen Løland updated DERBY-3184:
---------------------------------
Derby Info: (was: [Patch Available])
> 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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549456 ]
Daniel John Debrunner commented on DERBY-3184:
----------------------------------------------
> I must admit I feel a bit uneasy introducing knowledge about
> replication into the Monitor which currently does not seem to have any
> knowledge about databases (except something called a persistent
> service).
+1 to the uneasiness about adding replication knowledge to the monitor. I think Derby (&Cloudscape) has benefited over the years from isolating components from each other. Some future direction might to replace Derby's monitor with some other existing open-source IoC system that has a cleaner design and by definition will be separated from knowledge of Derby's code.
> 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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549407 ]
Dyre Tjeldvoll commented on DERBY-3184:
---------------------------------------
The patch looks good, and all tests pass for me, +1.
However, I'm not very familiar with the code being modified (the Monitor/Service system), so I'll wait a little longer before I commit it, just to give others a chance to get their comments in.
> 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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550071 ]
Jørgen Løland commented on DERBY-3184:
--------------------------------------
Øystein and Dan.
In light of your comments, I agree that this is not the right
solution to the problem. I have a new suggestion for how to solve
this without touching the monitor.
* Add a new implementation of Database, called something like
SlaveDatabase
* Modify canSupport of all instances of Database so that
SlaveDatabase is booted if slave replication is specified
* When booted, SlaveDatabase will spawn a new tread that calls
BasicDatabase#boot(). This thread will be blocked in
LogToFile#recover(). After spawning the thread,
SlaveDatabase#boot finishes. Calls to Monitor#findService will
return the SlaveDatabase object, but all method calls will
result in an SQL Exception with state
CANNOT_CONNECT_TO_DB_IN_SLAVE_MODE:
public LanguageConnectionContext setupConnection(..) {
if (inSlaveMode) {
throw StandardException (SQLState.CANNOT_CONNECT...)
}
return basicDatabase.setupConnection(...);
}
> 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.
[jira] Commented: (DERBY-3184) Replication: Connection attempts to
a database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549416 ]
Øystein Grøvlen commented on DERBY-3184:
----------------------------------------
Thanks for the patch, Jørgen.
I must admit I feel a bit uneasy introducing knowledge about
replication into the Monitor which currently does not seem to have any
knowledge about databases (except something called a persistent
service). However, I see that the current design would need a rewrite
to in order to be able to avoid this, since there is currently no way
of getting hold of a service where the booting has not completed.
Currently, if you try to find a service during booting, you will hang
waiting for the boot to complete.
I have not looked into the details, but it seems that it should be
possible to get a handle to a Database that is booting, through
BaseMonitor.findModule with some extra wiring in a static method in
Monitor. A Database object is definitely a better fit for replication
logic. However, I have not thought about the consequences of
providing such an access point. It would be useful if someone with
more experience with the Monitor framework, could provide a
recommendation here.
Given the approach of the current patch, I wonder whether it would be
better to isolate the "pollution" of replication logic that is
currently spread across the BaseMonitor and TopService classes, to
just the TopService class. It seems like all the necessary
information should be available there.
Some minor nits:
- Why are the added methods in TopService protected and not just
package private?
- Indentation in Monitor.findService looks a bit awkward due to
the line break before 'throws'.
> 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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Jørgen Løland (JIRA)" <ji...@apache.org>.
[ 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-bugfix-1a.diff
derby-3184-bugfix-1a.stat
I encountered a few bugs while working on a new implementation of the Database interface. The attached patch fixes these bugs, which are all part of the replication functionality and is not in use in non-replicated databases.
Bugfix patch v1a passes all tests and is ready for review.
> 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, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Øystein Grøvlen updated DERBY-3184:
-----------------------------------
Derby Info: (was: [Patch Available])
Committed patch, derby-3184-2c.diff, as revision 611759. Took the liberty of removing an unused import from SlaveDatabase.java.
> 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, derby-3184-2a.diff, derby-3184-2a.stat, derby-3184-2b.diff, derby-3184-2b.stat, derby-3184-2c.diff, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.
[jira] Updated: (DERBY-3184) Replication: Connection attempts to a
database in slave mode must fail
Posted by "Øystein Grøvlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Øystein Grøvlen updated DERBY-3184:
-----------------------------------
Derby Info: (was: [Patch Available])
Patch, derby-3184-bugfix-1a.diff, looks good. I took the liberty of correcting the message text a bit before committing the patch as revision 608419.
> 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, derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.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.