[
http://issues.ops4j.org/browse/PAXEXAM-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13349#action_13349
]
Toni Menzel commented on PAXEXAM-174:
-------------------------------------
haha, okay.
Will let you know when the 2.0 stuff has this strategy implemented.
> non-JRMP server at remote endpoint
> ----------------------------------
>
> Key: PAXEXAM-174
> URL: http://issues.ops4j.org/browse/PAXEXAM-174
> Project: Pax Exam
> Issue Type: Bug
> Affects Versions: 1.2.0
> Environment: Linux, Java 1.6_u16
> Reporter: Bartosz Kowalewski
> Assignee: Toni Menzel
>
> We observe the following problem when running pax exam tests on build machine
> (which runs Linux OS). It doesn't happen every time. This problem doesn't
> occur on our Windows laptops.
> {code}
> org.ops4j.pax.exam.spi.container.TestContainerException: Cannot get the
> remote bundle context
> at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.getRemoteBundleContext(RemoteBundleContextClient.java:324)
> at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.waitForState(RemoteBundleContextClient.java:265)
> at
> org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.waitForState(PaxRunnerTestContainer.java:317)
> at
> org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.start(PaxRunnerTestContainer.java:272)
> at
> org.ops4j.pax.exam.junit.internal.JUnit4TestMethod.invoke(JUnit4TestMethod.java:142)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:105)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
> at
> org.ops4j.pax.exam.junit.internal.JUnit4MethodRoadie.runBeforesThenTestThenAfters(JUnit4MethodRoadie.java:60)
> at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
> at
> org.ops4j.pax.exam.junit.JUnit4TestRunner.invokeTestMethod(JUnit4TestRunner.java:246)
> at
> org.ops4j.pax.exam.junit.JUnit4TestRunner.runMethods(JUnit4TestRunner.java:196)
> at
> org.ops4j.pax.exam.junit.JUnit4TestRunner$2.run(JUnit4TestRunner.java:186)
> at
> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
> at
> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
> at
> org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:182)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
> 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:289)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
> Caused by: java.rmi.ConnectIOException: non-JRMP server at remote endpoint
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:230)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
> at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
> at
> org.ops4j.pax.exam.rbc.client.RemoteBundleContextClient.getRemoteBundleContext(RemoteBundleContextClient.java:302)
> ... 25 more
> {code}
> This might be a timing issue - something related to releasing OS /socket/
> resources, etc. We thought that several tests (test methods) run in a row
> might cause this problem. The second Pax Exam test could be influenced by the
> first one. This was just a hypothesis. We then reproduced this issue in the
> first of the series of tests (test methods), so it could not be caused by
> resources left by other tests.
> This issue is observed on a CI server. We also tried to verify if other
> builds that are run on this machine do not influence Pax Exam operation. We
> added some customizations to Pax Exam and changed the port number used for
> RMI communication between the OSGi container and the process that launches
> the test. Instead of 1099, a different port was used. We still observed this
> issue.
> I finally a applied a _brute force_ workaround, but I'm not sure why does Pax
> Exam behave differently after this change was applied.
> I hooked a custom org.ops4j.pax.exam.spi.container.TestContainerFactory
> implementation using Pax Exam's SPI mechanisms. I'm using a slightly modified
> version of org.ops4j.pax.exam.container.def.internal.PaxRunnerTestContainer.
> After reading Pax Exam source code and analyzing our log files I came to a
> conclusion that there might be some issue with synchronization and timing
> inside Pax Exam. The test container waits for a change in the state of the
> system bundle. This mechanism works over RMI - the container connects to an
> RMI registry that is started by the Pax Exam activator. It seems that
> sometimes the server side of the RMI connection is not yet prepared to handle
> any requests when waiting is being started. I added a sleep time to
> PaxRunnerTestContainer:
> {code}
> long startedAt = System.currentTimeMillis();
> URLUtils.resetURLStreamHandlerFactory();
> Run.start( m_javaRunner, m_arguments.getArguments() );
> LOG.info( "Test container (Pax Runner " + Info.getPaxRunnerVersion()
> + ") started in "
> + ( System.currentTimeMillis() - startedAt ) + " millis" );
> // XXX yah :-/
> try
> {
> Thread.sleep(15000);
> }
> catch (InterruptedException e1)
> {
> // ignore
> }
>
> LOG.info( "Wait for test container to finish its initialization "
> + ( m_startTimeout == WAIT_FOREVER ? "without timing out" : "for
> " + m_startTimeout + " millis" ) );
> try
> {
> waitForState( SYSTEM_BUNDLE, Bundle.ACTIVE, m_startTimeout );
> }
> catch ( TimeoutException e )
> {
> throw new TimeoutException( "Test container did not initialize in
> the expected time of " + m_startTimeout
> + " millis" );
> }
> {code}
> And I haven't reproduced the issue even though I ran the build 5 times. Of
> course:
> - it's a brute force workaround that attempts to show where the problem might
> be
> - I'm not _100%_ sure that this timing issue was the source of our problems
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
