[
https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232433#comment-17232433
]
ASF GitHub Bot commented on GEODE-8706:
---------------------------------------
kohlmu-pivotal commented on pull request #5750:
URL: https://github.com/apache/geode/pull/5750#issuecomment-727668794
Whilst the change LGTM... I cannot help but feel that the whole logic of
(un)/locking of the `connectionLifeCycleLock` should really be a little more
hidden. This locking logic proliferates throughout the whole
`GatewaySenderEventRemoteDispatcher`. Which makes it way too easy to actually
miss logic where the connection lock needs to be used.
@boglesby @gesterzhou maybe we should be locking at moving all this logic to
another location.
There is also no indication of WHY this lock is required? Is it protecting
the accessing of `connection` properties or is it avoiding the accidental
setting of the `connection` field with another instance? It is not clear.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure
> in CI
> -----------------------------------------------------------------------------------
>
> Key: GEODE-8706
> URL: https://issues.apache.org/jira/browse/GEODE-8706
> Project: Geode
> Issue Type: Bug
> Reporter: John Hutchison
> Assignee: Xiaojian Zhou
> Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest
> > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run
> in VM 4 running on Host 3e4042fb1cd7 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined
> as a lambda expression in org.apache.geode.internal.cache.wan.WANTestBase
> that uses java.util.Set, java.util.Setint Expected queue entries: 0 but
> actual entries: 8000 expected:<0> but was:<8000> within 5 minutes.
> Caused by:
> java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000
> expected:<0> but was:<8000>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ----------------------------------------------------------------------
> Found suspect string in 'dunit_suspect-vm4.log' at line 68
> [fatal 2020/11/13 18:09:30.989 GMT <AckReaderThread for : Event Processor
> for GatewaySender_ln> tid=619] Stopping the processor because the following
> exception occurred while processing a batch:
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
