Checking the method calls ordering in multi-thread environment.

[GoogleCodeExporter]

What steps will reproduce the problem?
Just run the test in attach.

What version of the product are you using? On what operating system?
Mockito 1.6

I have mocked my listener which is used in multi-threaded environment with
Mockito. I have a list of threads which are calling methods on the
listener. I need to check the order of methods calls on the listener, i.e.
that order is, for instance method1(), method2(), method3() regardless of
which thread exactly did the call. My tests always fail because as I see in
debug ThreadLocal is used to assign SequenceNumber to invocations, i.e.
invocation of method1() can have SequenceNumber =1 as well as invocation of
method2() can have SequenceNumber =1. So I lost one of the invocations with
SequenceNumber =1. 

Original issue reported on code.google.com by KhasDe...@gmail.com on 31 Oct 2008 at 4:12

Attachments:

• Tests.java

[GoogleCodeExporter]

Looking at it

Original comment by szcze...@gmail.com on 1 Nov 2008 at 12:07

[GoogleCodeExporter]

Very nice bug report. I guess I'll have to make the sequenceNumber really 
globally
unique so I cannot use the ThreadLocal for this. Let you know when it's ready.

Original comment by szcze...@gmail.com on 1 Nov 2008 at 12:12

[GoogleCodeExporter]

It's fixed in trunk. Your test case is included. Thanks a lot for reporting 
this bug!

Original comment by szcze...@gmail.com on 1 Nov 2008 at 1:18

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 14 Jan 2009 at 10:48

• Added labels: Milestone-Release1.7

[GoogleCodeExporter]

I use version 1.8 (I call Mockito from using the Java 1.4 interface) and the 
problem
still exists when the tests - all define on separate classes which do not share 
any
member as a static one - are run on our build server. While they all succeed on
developers' environments (where they are run sequentially), on the build server 
they
are probably run in parallel and fail, providing stacks like:

java.lang.AssertionError: sequence number has to be globally unique   
 at
org.mockito.internal.invocation.AllInvocationsFinder$SequenceNumberComparator.co
mpare(AllInvocationsFinder.java:36)

 at
org.mockito.internal.invocation.AllInvocationsFinder$SequenceNumberComparator.co
mpare(AllInvocationsFinder.java:33)

 at java.util.TreeMap.compare(TreeMap.java:1093)   
 at java.util.TreeMap.put(TreeMap.java:465)   
 at java.util.TreeSet.add(TreeSet.java:210)   
 at java.util.AbstractCollection.addAll(AbstractCollection.java:318)   
 at java.util.TreeSet.addAll(TreeSet.java:258)   
 at
org.mockito.internal.invocation.AllInvocationsFinder.getAllInvocations(AllInvoca
tionsFinder.java:27)

 at org.mockito.internal.verification.InOrderWrapper.verify(InOrderWrapper.java:26)   
 at org.mockito.internal.MockHandler.handle(MockHandler.java:75)   
 at
org.mockito.internal.creation.MethodInterceptorFilter.intercept(MethodIntercepto
rFilter.java:50)

 at
au.gov.vic.transport.vtd.accreditationservice.dao.AccreditationDao$$EnhancerByMo
ckitoWithCGLIB$$a1d8eb0f.save(<generated>)

 at
au.gov.vic.transport.vtd.fiextension.handler.FurtherInfoExtensionRejectHandlerTe
st.testUpdate(FurtherInfoExtensionRejectHandlerTest.java:58)

The call that fails (the last line above) is:

((AccreditationDao)inOrder.verify(getDaoService(),
Mockito.times(1))).save(getFurtherInfoExtension());

getDaoService() is the mock object that fails, and is a non-static class member.

Original comment by rburd...@gmail.com on 28 Oct 2009 at 4:39

[GoogleCodeExporter]

>I call Mockito from using the Java 1.4 interface

You mean you use the jdk14 Mockito distribution?

I'll have a look at this case.

Original comment by szcze...@gmail.com on 28 Oct 2009 at 7:51

[GoogleCodeExporter]

I removed an assertion from the code (because it should not make any difference
actually). You should not have such a problem again. It's fixed in trunk.

Original comment by szcze...@gmail.com on 28 Oct 2009 at 7:38