[
https://issues.apache.org/jira/browse/DERBY-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401339#comment-13401339
]
Dag H. Wanvik edited comment on DERBY-4269 at 7/2/12 10:21 PM:
---------------------------------------------------------------
I instrumented all calls to propertyNames while in the slave boot code running
ReplicationRun_Local_3_p6-sb1. It turns out the only place where
DoubleProperties#propertyNames
is called is here in BaseMonitor#getImplementations (cf also the original
backtrace above):
nextModule:
for (Enumeration e = moduleList.propertyNames(); e.hasMoreElements(); ) {
String key = (String) e.nextElement();
// module tagged name in the modules.properties file.
// used as the tag for dependent properties.
String tag;
// Dynamically loaded code is defined by a property of
// the form:
// derby.module.<modulename>=<class name>
// or
// derby.subSubProtocol.<modulename>=<classname>
if (key.startsWith(Property.MODULE_PREFIX)) {
tag = key.substring(Property.MODULE_PREFIX.length());
} else if (key.startsWith(Property.SUB_SUB_PROTOCOL_PREFIX)) {
tag = key.substring(Property.MODULE_PREFIX.length());
} else {
continue nextModule;
}
This means that all properties that do not start with MODULE_PREFIX
("derby.module.") or SUB_SUB_PROTOCOL_PREFIX ("derby.subProtocol.") are
skipped. None of those are legal URL properties, and could thus stem from the
contested info properties object acclocated int EmbedConnection.
I therefore believe we can avoid doing the explicit synchronization when
DERBY-5830 goes in.
I'll run the instrumented versions on all the replication tests for good
measure before I conclude, though.
[Comment edited 2012-07-03: completed tests, the above theory holds.]
was (Author: dagw):
I instrumented all calls to propertyNames while in the slave boot code
running ReplicationRun_Local_3_p6-sb1. It turns out the only place where
DoubleProperties#propertyNames
is called is here in BaseMonitor#getImplementations (cf also the original
backtrace above):
nextModule:
for (Enumeration e = moduleList.propertyNames(); e.hasMoreElements(); ) {
String key = (String) e.nextElement();
// module tagged name in the modules.properties file.
// used as the tag for dependent properties.
String tag;
// Dynamically loaded code is defined by a property of
// the form:
// derby.module.<modulename>=<class name>
// or
// derby.subSubProtocol.<modulename>=<classname>
if (key.startsWith(Property.MODULE_PREFIX)) {
tag = key.substring(Property.MODULE_PREFIX.length());
} else if (key.startsWith(Property.SUB_SUB_PROTOCOL_PREFIX)) {
tag = key.substring(Property.MODULE_PREFIX.length());
} else {
continue nextModule;
}
This means that all properties that do not start with MODULE_PREFIX
("derby.module.") or SUB_SUB_PROTOCOL_PREFIX ("derby.subProtocol.") are
skipped. None of those are legal URL properties, and could t
hus stem from the contested info properties object acclocated int
EmbedConnection.
I therefore believe we can avoid doing the explicit synchronization when
DERBY-5830 goes in.
I'll run the instrumented versions on all the replication tests for good
measure before I conclude, though.
> Failover did not succeed in 2 min.: testReplication_Local_3_p6_autocommit_OK
> ----------------------------------------------------------------------------
>
> Key: DERBY-4269
> URL: https://issues.apache.org/jira/browse/DERBY-4269
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0,
> 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2
> Environment: OS:
> Microsoft© Windows VistaT Ultimate - 6.0.6001 Service Pack 1 - WindowsNT 0 6
> JVM:
> Sun Microsystems Inc.
> java version "1.4.2_16"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_16-b05)
> Java HotSpot(TM) Client VM (build 1.4.2_16-b05 mixed mode 32-bit)
> Reporter: Ole Solberg
> Assignee: Dag H. Wanvik
> Labels: derby_triage10_5_2
> Attachments: 4269-client-jstack.txt, 4269-master.txt,
> 4269-slave-jstack-before-failover.txt, 4269-slave.txt, DERBY-4269.diff,
> DERBY-4269.stat, DERBY-4269b.diff, db_master-derby.log,
> db_slave-derby.log.gz, derby-4269-explicit-synch-2.diff,
> derby-4269-explicit-synch-3.diff, derby-4269-explicit-synch-3.status,
> derby-4269-explicit-synch.diff, derby-4269-typo.diff,
> fix-ignored-runtime-exceptions-a.diff,
> fix-ignored-runtime-exceptions-instr.diff, keys-only.diff
>
>
> Failover did not succeed.
> 2)
> testReplication_Local_3_p6_autocommit_OK(org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p6)junit.framework.AssertionFailedError:
> Failover did not succeed.
> at
> org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.connectPing(ReplicationRun.java:270)
> at
> org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p6.derby_3896(ReplicationRun_Local_3_p6.java:200)
> at
> org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local_3_p6.testReplication_Local_3_p6_autocommit_OK(ReplicationRun_Local_3_p6.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:106)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> See
> http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/testlog/vista-64/782274-suitesAll_diff.txt
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
