geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Smith (JIRA)" <j...@apache.org>
Subject [jira] [Created] (GEODE-343) Failure from ConcurrentMapOpsDUnitTest.testListenerNotInvokedForRejectedOperation
Date Fri, 18 Sep 2015 16:20:04 GMT
Dan Smith created GEODE-343:
-------------------------------

             Summary: Failure from ConcurrentMapOpsDUnitTest.testListenerNotInvokedForRejectedOperation
                 Key: GEODE-343
                 URL: https://issues.apache.org/jira/browse/GEODE-343
             Project: Geode
          Issue Type: Bug
            Reporter: Dan Smith
            Assignee: Swapnil Bawaskar


This used to be a gemfire ticket, but I still saw this in a recent geode build. From the old
gemfire ticket

{noformat}
java.lang.AssertionError: Suspicious strings were written to the log during this run.
Fix the strings or use DistributedTestCase.addExpectedException to ignore.
-----------------------------------------------------------------------
Found suspect string in log4j at line 967

[error 2015/05/29 03:12:54.379 PDT <Cache Client Updater Thread  on gluon(21311)<v654>:55830
port 24631> tid=0x2f97] Exception occurred in CacheListener
junit.framework.AssertionFailedError: should not be called.  Event=EntryEventImpl[op=CREATE;key=105;oldValue=null;newValue=VMCachedDeserializable@879320980;callbackArg=null;originRemote=true;originMember=gluon<v654>:55830;callbacksInvoked;version={v1;
rv106; mbr=gluon(21311)<v654>:55830; time=1432894374357; remote};id=EventID[threadID=4;sequenceID=3938];isFromServer]
	at junit.framework.Assert.fail(Assert.java:57)
	at junit.framework.TestCase.fail(TestCase.java:227)
	at com.gemstone.gemfire.internal.cache.ConcurrentMapOpsDUnitTest$NotInvokedListener.validate(ConcurrentMapOpsDUnitTest.java:186)
	at com.gemstone.gemfire.internal.cache.ConcurrentMapOpsDUnitTest$AbstractConcMapOpsListener.afterCreate(ConcurrentMapOpsDUnitTest.java:157)
	at com.gemstone.gemfire.internal.cache.EnumListenerEvent$AFTER_CREATE.dispatchEvent(EnumListenerEvent.java:97)
	at com.gemstone.gemfire.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:9223)
	at com.gemstone.gemfire.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7693)
	at com.gemstone.gemfire.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6459)
	at com.gemstone.gemfire.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2615)
	at com.gemstone.gemfire.internal.cache.ProxyRegionMap$ProxyRegionEntry.dispatchListenerEvents(ProxyRegionMap.java:581)
	at com.gemstone.gemfire.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:6309)
	at com.gemstone.gemfire.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:237)
	at com.gemstone.gemfire.internal.cache.LocalRegion.virtualPut(LocalRegion.java:6122)
	at com.gemstone.gemfire.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:118)
	at com.gemstone.gemfire.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:6097)
	at com.gemstone.gemfire.internal.cache.LocalRegion.basicBridgeClientUpdate(LocalRegion.java:5795)
	at com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientUpdater.handleUpdate(CacheClientUpdater.java:782)
	at com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientUpdater.processMessages(CacheClientUpdater.java:1717)
	at com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientUpdater.run(CacheClientUpdater.java:491)
{noformat}

>From Darrel:
 The test testListenerNotInvokedForRejectedOperation has no logic to wait for the ha region
queue to be sent to the client and processed.
It was added as test coverage for #42164. Since all of the events are async perhaps you should
end the test by doing something that will send an ha region queue event to the client and
invoke the clients listener (perhaps a different region with a difference listener). Then
you could wait until both clients see that event and know that they would have already seen
the other events if they are going to be sent.
Also it seems like the listener should set some other test state besides throw the AssertionFailedError?
since we catch everything thrown by a CacheLIstener and just log it.

Ok, I think I know what is wrong with this test. Note that it is failing on key=112.
The test starts out before the listener is added by doing puts of keys 0..112. It does these
puts on the server. It then registers the listeners. But the events my still be in the ha
region queue at this time.
So I think after these puts you need to wait for your clients to get all these create events
before you register the listeners that say no creates allowed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message