You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Dan Smith (JIRA)" <ji...@apache.org> on 2015/09/18 18:20:04 UTC

[jira] [Created] (GEODE-343) Failure from ConcurrentMapOpsDUnitTest.testListenerNotInvokedForRejectedOperation

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)