Issue Details (XML | Word | Printable)

Key: MULE-3660
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Piotr Czerwinski
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Mule

MuleMessageProtocolChunkingTestCase failure

Created: 10/Sep/08 07:23 AM   Updated: 12/Dec/08 10:29 AM
Component/s: Transport: TCP / UDP / SSL / Multicast
Affects Version/s: 2.0.2
Fix Version/s: 2.1.x Backlog

Time Tracking:
Not Specified

File Attachments: 1. Text File MuleMessageProtocolChunkingTestCase-timeout.patch (0.5 kB)

Environment: jdk 1.6

Labels:
User impact: Low
Effort points: 4


 Description  « Hide
test case passes on jdk 1.5 but failes on jdk 1.6

-------------------------------------------------------------------------------
Test set: org.mule.transport.tcp.integration.MuleMessageProtocolChunkingTestCase
-------------------------------------------------------------------------------
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 12.113 sec <<< FAILURE!
custom object (org.mule.transport.tcp.integration.MuleMessageProtocolChunkingTestCase) Time elapsed: 9.382 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertNotNull(Assert.java:217)
at junit.framework.Assert.assertNotNull(Assert.java:210)
at org.mule.transport.tcp.integration.MuleMessageProtocolChunkingTestCase.testCustomObject(MuleMessageProtocolChunkingTestCase.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at org.mule.tck.AbstractMuleTestCase.runBare(AbstractMuleTestCase.java:238)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at org.mule.tck.AbstractMuleTestCase.run(AbstractMuleTestCase.java:218)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997)



 All   Comments   Work Log   Change History   Transitions   FishEye      Sort Order: Ascending order - Click to sort in descending order
Piotr Czerwinski added a comment - 10/Sep/08 07:37 AM
increasing timeout value resolves this issue (patch attached)

Dirk Olmes added a comment - 22/Sep/08 08:32 AM
I'm pretty sure that increasing the timeout will not fix the problem. The log entries that show up during test failure suggest that there might be an ordering problem with the two socket endpoints in the test: the sending side actually tries to send before the receiving endpoint is actually ready for listening.

Daniel Feist added a comment - 23/Oct/08 08:26 AM
Seems this is caused because two there two tcp endpoints talking to each other in the same mule instance and sender sends message before receiver has been started, in which there may not be any easy fix for this one.

Ken Yagen added a comment - 07/Nov/08 01:10 PM
Moving issues regarding test case failures/disabled/needed to Technical Debt Backlog