[
https://issues.apache.org/jira/browse/DERBY-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399808#comment-13399808
]
Dag H. Wanvik commented on DERBY-4269:
--------------------------------------
Knut: <good explanation of the thread-safety guarantees of Properties>
Part of the problem here is that the old (i.e. pre-replication code) might not
be prepared for thread concurrency on the Properties object, viz the fact the
buggy overload wasn't detected before.
Still, I am tempted to go for your solution (modulo the weakness you pointed
out) to get rid of the ugly explicit synchronization, and wrong use issues
if/when they surface. My fear is, though, that could be hard to track down.. so
the explicit synch is safer if we can't be sure how this is used. I'' try to
analyze the usages of the overloaded propertyNames..
> 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, 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
