org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the timeout?

Best regards,
Alex soto




Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
Anybody knows what causes this exception?

I am increasing the timeout with the following options:

systemTimeout(240_000),
RBCRemoteTargetOptions.waitForRBCFor(240_000),

but it does not seem to help.  Are there other options to adjust the timeout waiting for ProbeInvoker ?


Best regards,
Alex soto




On Apr 29, 2019, at 12:09 PM, Alex Soto <[hidden email]> wrote:

Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the timeout?

Best regards,
Alex soto





Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
In reply to this post by Alex Soto
Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:

> Hello,  
>
> I am using pax-exam 4.11.0 for integration tests. I am consistently
> getting the following exception. 
>
>
> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
> for service org.ops4j.pax.exam.ProbeInvoker
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
> at
> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at
> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
> at com.sun.proxy.$Proxy15.call(Unknown Source)
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
> at
> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
> at
> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
> at
> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
> at
> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>
>
> What causes this? How to troubleshoot or how to increase the timeout?
>
> Best regards,
> Alex soto
>
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
Thanks JB, no there are no errors in the log file, besides this one.

Best regards,
Alex soto




On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:
Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently
getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvoker
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at
org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the timeout?

Best regards,
Alex soto





--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
Are you waiting for the service in your test explicitly or does it come
from pax exam itself ?

What JDK and Karaf version are you using ?

As reminder, Pax Exam is used in Karaf itests themselves, and I don't
have such issue. It could be related to JDK 11 if you are using this JDK
version.

Regards
JB

On 01/05/2019 17:13, Alex Soto wrote:

> Thanks JB, no there are no errors in the log file, besides this one.
>
> Best regards,
> Alex soto
>
>
>
>
>> On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi Alex,
>>
>> Most of the time, this is a consequence of another error.
>>
>> Can you take a look in the target/exam karaf.log to see if there's
>> something special there ?
>>
>> Regards
>> JB
>>
>> On 29/04/2019 18:09, Alex Soto wrote:
>>> Hello,  
>>>
>>> I am using pax-exam 4.11.0 for integration tests. I am consistently
>>> getting the following exception. 
>>>
>>>
>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>> for service org.ops4j.pax.exam.ProbeInvoker
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
>>> at
>>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>> at
>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
>>> at
>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
>>> at
>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at
>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> at java.lang.Thread.run(Thread.java:748)
>>> at
>>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>>> at
>>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>>> at
>>> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
>>> at
>>> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
>>> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
>>> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
>>> at com.sun.proxy.$Proxy15.call(Unknown Source)
>>> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
>>> at
>>> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
>>> at
>>> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
>>> at
>>> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
>>> at
>>> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>> at
>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>> at
>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
>>> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>> at
>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>>> at
>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>>>
>>>
>>> What causes this? How to troubleshoot or how to increase the timeout?
>>>
>>> Best regards,
>>> Alex soto
>>>
>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email] <mailto:[hidden email]>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
No, I am not waiting for the service explicitly,  it comes from Pax Exam itself (AFIK, based on the stack trace below).  
My tests have a bunch of @Injected  services, but they are all decorated with @Filter(timeout = SERVICE_TIMEOUT) where SERVICE_TIMEOUT = 240_000.

Java version is 8.
Karaf version is 4.2.0.
The exception:

2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 | BundleWatcher                    | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 | Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvokerFactory
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161) ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104) ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87) ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69) ~[?:?]
at org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226) [202:org.ops4j.pax.swissbox.extender:1.8.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


These integration tests have been working in the past, so I suspect, as the application complexity increased (i.e.,  more services being added overtime), it now takes more time for the container to finish initialization (my guess).   I would like to increase the timeout value to accommodate for a longer startup time, but so far, what I've tried has not made a difference.


Best regards,
Alex soto




On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Are you waiting for the service in your test explicitly or does it come
from pax exam itself ?

What JDK and Karaf version are you using ?

As reminder, Pax Exam is used in Karaf itests themselves, and I don't
have such issue. It could be related to JDK 11 if you are using this JDK
version.

Regards
JB

On 01/05/2019 17:13, Alex Soto wrote:
Thanks JB, no there are no errors in the log file, besides this one.

Best regards,
Alex soto




On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:
Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently
getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvoker
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at
org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the timeout?

Best regards,
Alex soto





-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net
Talend - http://www.talend.com


-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
You can increase the startup timeout on the @Configuration method (on
the distribution).

Regards
JB

On 01/05/2019 17:46, Alex Soto wrote:

> No, I am not waiting for the service explicitly,  it comes from Pax Exam
> itself (AFIK, based on the stack trace below).  
> My tests have a bunch of /@Inject/ed  services, but they are all
> decorated with /@Filter(timeout = SERVICE_TIMEOUT)
> /where SERVICE_TIMEOUT = 240_000.
>
> Java version is 8.
> Karaf version is 4.2.0.
> The exception:
>
> 2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 | BundleWatcher     
>               | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
> Exception in executor thread
> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
> for service org.ops4j.pax.exam.ProbeInvokerFactory
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
> at
> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
> ~[?:?]
> at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
> at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
> ~[?:?]
> at
> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
> ~[?:?]
> at
> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
> [202:org.ops4j.pax.swissbox.extender:1.8.2]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:?]
> at java.lang.Thread.run(Thread.java:748) [?:?]
>
>
> These integration tests have been working in the past, so I suspect, as
> the application complexity increased (i.e.,  more services being added
> overtime), it now takes more time for the container to finish
> initialization (my guess).   I would like to increase the timeout value
> to accommodate for a longer startup time, but so far, what I've tried
> has not made a difference.
>
>
> Best regards,
> Alex soto
>
>
>
>
>> On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Are you waiting for the service in your test explicitly or does it come
>> from pax exam itself ?
>>
>> What JDK and Karaf version are you using ?
>>
>> As reminder, Pax Exam is used in Karaf itests themselves, and I don't
>> have such issue. It could be related to JDK 11 if you are using this JDK
>> version.
>>
>> Regards
>> JB
>>
>> On 01/05/2019 17:13, Alex Soto wrote:
>>> Thanks JB, no there are no errors in the log file, besides this one.
>>>
>>> Best regards,
>>> Alex soto
>>>
>>>
>>>
>>>
>>>> On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré <[hidden email]
>>>> <mailto:[hidden email]>
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> Most of the time, this is a consequence of another error.
>>>>
>>>> Can you take a look in the target/exam karaf.log to see if there's
>>>> something special there ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 29/04/2019 18:09, Alex Soto wrote:
>>>>> Hello,  
>>>>>
>>>>> I am using pax-exam 4.11.0 for integration tests. I am consistently
>>>>> getting the following exception. 
>>>>>
>>>>>
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>>>> for service org.ops4j.pax.exam.ProbeInvoker
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
>>>>> at
>>>>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>> at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>>>> at
>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
>>>>> at
>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
>>>>> at
>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>> at
>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>> at
>>>>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>>>>> at
>>>>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>>>>> at
>>>>> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
>>>>> at
>>>>> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
>>>>> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
>>>>> at
>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
>>>>> at com.sun.proxy.$Proxy15.call(Unknown Source)
>>>>> at
>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
>>>>> at
>>>>> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
>>>>> at
>>>>> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
>>>>> at
>>>>> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
>>>>> at
>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>>> at
>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>>> at
>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>>> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
>>>>> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
>>>>> at
>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>> at
>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>> at
>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>> at
>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>> at
>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
>>>>> at
>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
>>>>> at
>>>>> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>>>>> at
>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>>>>>
>>>>>
>>>>> What causes this? How to troubleshoot or how to increase the timeout?
>>>>>
>>>>> Best regards,
>>>>> Alex soto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -- 
>>>> Jean-Baptiste Onofré
>>>> [hidden email]
>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
>> [hidden email] <mailto:[hidden email]>
>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>> Talend - http://www.talend.com <http://www.talend.com/>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
Do you mean any of  these options?

RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
CoreOptions.systemTimeout(systemTimeout(final long timeoutInMillis)



Best regards,
Alex soto




On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]> wrote:

You can increase the startup timeout on the @Configuration method (on
the distribution).

Regards
JB

On 01/05/2019 17:46, Alex Soto wrote:
No, I am not waiting for the service explicitly,  it comes from Pax Exam
itself (AFIK, based on the stack trace below).  
My tests have a bunch of /@Inject/ed  services, but they are all
decorated with /@Filter(timeout = SERVICE_TIMEOUT)
/where SERVICE_TIMEOUT = 240_000.

Java version is 8.
Karaf version is 4.2.0.
The exception:

2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 | BundleWatcher     
              | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[202:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


These integration tests have been working in the past, so I suspect, as
the application complexity increased (i.e.,  more services being added
overtime), it now takes more time for the container to finish
initialization (my guess).   I would like to increase the timeout value
to accommodate for a longer startup time, but so far, what I've tried
has not made a difference.


Best regards,
Alex soto




On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

Are you waiting for the service in your test explicitly or does it come
from pax exam itself ?

What JDK and Karaf version are you using ?

As reminder, Pax Exam is used in Karaf itests themselves, and I don't
have such issue. It could be related to JDK 11 if you are using this JDK
version.

Regards
JB

On 01/05/2019 17:13, Alex Soto wrote:
Thanks JB, no there are no errors in the log file, besides this one.

Best regards,
Alex soto




On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>
<[hidden email]>> wrote:

Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:
Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently
getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvoker
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at
org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the timeout?

Best regards,
Alex soto





-- 
Jean-Baptiste Onofré
[hidden email]
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
Still having this problem. I am setting log level:

logLevel(LogLevel.TRACE),

And

log4j2.logger.paxexam.name=org.ops4j.pax.exam
log4j2.logger.paxexam.level=TRACE

And

static final long SERVICE_TIMEOUT = 300_000;
systemTimeout(SERVICE_TIMEOUT),
RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),

I removed all services references that used the @Inject annotation, and replaced them with service lookup code.
Logs don’t show any error or warning that can help pinpoint the cause of this error.

Increasing the timeout just delays the reporting of the error by the FailSafe driver, but the error is logged a lot earlier in the Karaf log file.

For easy reference, here is the stack trace again:

2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher                    | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 | Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvokerFactory
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161) ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104) ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87) ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69) ~[?:?]
at org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226) [201:org.ops4j.pax.swissbox.extender:1.8.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


Any hint?

Best regards,
Alex soto




On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]> wrote:

Do you mean any of  these options?

RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
CoreOptions.systemTimeout(systemTimeout(final long timeoutInMillis)



Best regards,
Alex soto




On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]> wrote:

You can increase the startup timeout on the @Configuration method (on
the distribution).

Regards
JB

On 01/05/2019 17:46, Alex Soto wrote:
No, I am not waiting for the service explicitly,  it comes from Pax Exam
itself (AFIK, based on the stack trace below).  
My tests have a bunch of /@Inject/ed  services, but they are all
decorated with /@Filter(timeout = SERVICE_TIMEOUT)
/where SERVICE_TIMEOUT = 240_000.

Java version is 8.
Karaf version is 4.2.0.
The exception:

2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 | BundleWatcher     
              | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[202:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


These integration tests have been working in the past, so I suspect, as
the application complexity increased (i.e.,  more services being added
overtime), it now takes more time for the container to finish
initialization (my guess).   I would like to increase the timeout value
to accommodate for a longer startup time, but so far, what I've tried
has not made a difference.


Best regards,
Alex soto




On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

Are you waiting for the service in your test explicitly or does it come
from pax exam itself ?

What JDK and Karaf version are you using ?

As reminder, Pax Exam is used in Karaf itests themselves, and I don't
have such issue. It could be related to JDK 11 if you are using this JDK
version.

Regards
JB

On 01/05/2019 17:13, Alex Soto wrote:
Thanks JB, no there are no errors in the log file, besides this one.

Best regards,
Alex soto




On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>
<[hidden email]>> wrote:

Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:
Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently
getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvoker
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at
org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the timeout?

Best regards,
Alex soto





-- 
Jean-Baptiste Onofré
[hidden email]
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com


Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
Hi Alex,

Can you share your itest ? I'm not able to reproduce the issue, so hard
to investigate.

Regards
JB

On 08/05/2019 15:31, Alex Soto wrote:

> Still having this problem. I am setting log level:
>
> logLevel(LogLevel.TRACE),
>
> And
>
> log4j2.logger.paxexam.name=org.ops4j.pax.exam
> log4j2.logger.paxexam.level=TRACE
>
> And
>
> static final long SERVICE_TIMEOUT = 300_000;
> systemTimeout(SERVICE_TIMEOUT),
> RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),
>
> I removed all services references that used the /@Inject/ annotation,
> and replaced them with service lookup code.
> Logs don’t show any error or warning that can help pinpoint the cause of
> this error.
>
> Increasing the timeout just delays the reporting of the error by the
> FailSafe driver, but the error is logged a lot earlier in the Karaf log
> file.
>
> For easy reference, here is the stack trace again:
>
> 2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher     
>               | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
> Exception in executor thread
> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
> for service org.ops4j.pax.exam.ProbeInvokerFactory
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
> at
> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
> at
> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
> ~[?:?]
> at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
> at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
> ~[?:?]
> at
> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
> ~[?:?]
> at
> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
> [201:org.ops4j.pax.swissbox.extender:1.8.2]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [?:?]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:?]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
> at java.lang.Thread.run(Thread.java:748) [?:?]
>
>
> Any hint?
>
> Best regards,
> Alex soto
>
>
>
>
>> On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Do you mean any of  these options?
>>
>> RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
>> CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)
>>
>>
>>
>> Best regards,
>> Alex soto
>>
>>
>>
>>
>>> On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>> You can increase the startup timeout on the @Configuration method (on
>>> the distribution).
>>>
>>> Regards
>>> JB
>>>
>>> On 01/05/2019 17:46, Alex Soto wrote:
>>>> No, I am not waiting for the service explicitly,  it comes from Pax Exam
>>>> itself (AFIK, based on the stack trace below).  
>>>> My tests have a bunch of /@Inject/ed  services, but they are all
>>>> decorated with /@Filter(timeout = SERVICE_TIMEOUT)
>>>> /where SERVICE_TIMEOUT = 240_000.
>>>>
>>>> Java version is 8.
>>>> Karaf version is 4.2.0.
>>>> The exception:
>>>>
>>>> 2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 | BundleWatcher     
>>>>               | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>>> Exception in executor thread
>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>>> at
>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>> at
>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>> at
>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>> at
>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>>> ~[?:?]
>>>> at
>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>>> ~[?:?]
>>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>>> ~[?:?]
>>>> at
>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>>> ~[?:?]
>>>> at
>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>>> [202:org.ops4j.pax.swissbox.extender:1.8.2]
>>>> at
>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>> [?:?]
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>> at
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>> [?:?]
>>>> at
>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>> [?:?]
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>> [?:?]
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> [?:?]
>>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>>
>>>>
>>>> These integration tests have been working in the past, so I suspect, as
>>>> the application complexity increased (i.e.,  more services being added
>>>> overtime), it now takes more time for the container to finish
>>>> initialization (my guess).   I would like to increase the timeout value
>>>> to accommodate for a longer startup time, but so far, what I've tried
>>>> has not made a difference.
>>>>
>>>>
>>>> Best regards,
>>>> Alex soto
>>>>
>>>>
>>>>
>>>>
>>>>> On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré <[hidden email]
>>>>> <mailto:[hidden email]>
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> Are you waiting for the service in your test explicitly or does it come
>>>>> from pax exam itself ?
>>>>>
>>>>> What JDK and Karaf version are you using ?
>>>>>
>>>>> As reminder, Pax Exam is used in Karaf itests themselves, and I don't
>>>>> have such issue. It could be related to JDK 11 if you are using
>>>>> this JDK
>>>>> version.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 01/05/2019 17:13, Alex Soto wrote:
>>>>>> Thanks JB, no there are no errors in the log file, besides this one.
>>>>>>
>>>>>> Best regards,
>>>>>> Alex soto
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
>>>>>>> <[hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> Most of the time, this is a consequence of another error.
>>>>>>>
>>>>>>> Can you take a look in the target/exam karaf.log to see if there's
>>>>>>> something special there ?
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 29/04/2019 18:09, Alex Soto wrote:
>>>>>>>> Hello,  
>>>>>>>>
>>>>>>>> I am using pax-exam 4.11.0 for integration tests. I am consistently
>>>>>>>> getting the following exception. 
>>>>>>>>
>>>>>>>>
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
>>>>>>>> waiting
>>>>>>>> for service org.ops4j.pax.exam.ProbeInvoker
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>> at
>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>> at
>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>>>> at
>>>>>>>> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>>>>>>> at
>>>>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
>>>>>>>> at
>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
>>>>>>>> at
>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>> at
>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>>>> at
>>>>>>>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>>>>>>>> at
>>>>>>>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>>>>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>>>>>>>> at
>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
>>>>>>>> at
>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
>>>>>>>> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
>>>>>>>> at com.sun.proxy.$Proxy15.call(Unknown Source)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
>>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>>>>>> at
>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>>>>>> at
>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>>>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
>>>>>>>> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>>>>>>>> at
>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>>>>>>>>
>>>>>>>>
>>>>>>>> What causes this? How to troubleshoot or how to increase the
>>>>>>>> timeout?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Alex soto
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Jean-Baptiste Onofré
>>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>> http://blog.nanthrax.net
>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>> Talend - http://www.talend.com
>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Jean-Baptiste Onofré
>>>>> [hidden email]
>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>> http://blog.nanthrax.net
>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>> Talend - http://www.talend.com
>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>
>>>
>>> -- 
>>> Jean-Baptiste Onofré
>>> [hidden email] <mailto:[hidden email]>
>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>> Talend - http://www.talend.com <http://www.talend.com/>
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
Hi JB, 

Thanks for the offer, but I am afraid it would be too complex to share.  The application is made of many projects and bundles, including native libraries, etc. it would be very hard to set up the environment.  I can share the entire Karaf log if needed.

What I am looking for is help on how to troubleshoot this issue.
Any information (given the provided stack trace) about what setting controls this timeout, and what exactly is the code waiting for?
How to enable more logging?
Is there something failing and not logging an error perhaps?
How can I figure out what is blocking, or not finishing?

Best regards,
Alex soto




On May 8, 2019, at 9:35 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Hi Alex,

Can you share your itest ? I'm not able to reproduce the issue, so hard
to investigate.

Regards
JB

On 08/05/2019 15:31, Alex Soto wrote:
Still having this problem. I am setting log level:

logLevel(LogLevel.TRACE),

And

log4j2.logger.paxexam.name=org.ops4j.pax.exam
log4j2.logger.paxexam.level=TRACE

And

static final long SERVICE_TIMEOUT = 300_000;
systemTimeout(SERVICE_TIMEOUT),
RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),

I removed all services references that used the /@Inject/ annotation,
and replaced them with service lookup code.
Logs don’t show any error or warning that can help pinpoint the cause of
this error.

Increasing the timeout just delays the reporting of the error by the
FailSafe driver, but the error is logged a lot earlier in the Karaf log
file.

For easy reference, here is the stack trace again:

2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher     
              | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[201:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


Any hint?

Best regards,
Alex soto




On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]
<[hidden email]>> wrote:

Do you mean any of  these options?

RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)



Best regards,
Alex soto




On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

You can increase the startup timeout on the @Configuration method (on
the distribution).

Regards
JB

On 01/05/2019 17:46, Alex Soto wrote:
No, I am not waiting for the service explicitly,  it comes from Pax Exam
itself (AFIK, based on the stack trace below).  
My tests have a bunch of /@Inject/ed  services, but they are all
decorated with /@Filter(timeout = SERVICE_TIMEOUT)
/where SERVICE_TIMEOUT = 240_000.

Java version is 8.
Karaf version is 4.2.0.
The exception:

2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 | BundleWatcher     
              | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[202:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


These integration tests have been working in the past, so I suspect, as
the application complexity increased (i.e.,  more services being added
overtime), it now takes more time for the container to finish
initialization (my guess).   I would like to increase the timeout value
to accommodate for a longer startup time, but so far, what I've tried
has not made a difference.


Best regards,
Alex soto




On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>
<[hidden email]>> wrote:

Are you waiting for the service in your test explicitly or does it come
from pax exam itself ?

What JDK and Karaf version are you using ?

As reminder, Pax Exam is used in Karaf itests themselves, and I don't
have such issue. It could be related to JDK 11 if you are using
this JDK
version.

Regards
JB

On 01/05/2019 17:13, Alex Soto wrote:
Thanks JB, no there are no errors in the log file, besides this one.

Best regards,
Alex soto




On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
<[hidden email] <[hidden email]>
<[hidden email]>
<[hidden email]>> wrote:

Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:
Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently
getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
waiting
for service org.ops4j.pax.exam.ProbeInvoker
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at
org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the
timeout?

Best regards,
Alex soto





-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net
<http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
Talend - http://www.talend.com
<http://www.talend.com/> <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email]
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net
<http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
Talend - http://www.talend.com
<http://www.talend.com/> <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>



-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
It's weird you don't have anything in the karaf log (in target/exam folder).

Maybe you can execute service:list commaand in the itest to check the
actual service available.

Regards
JB

On 08/05/2019 15:52, Alex Soto wrote:

> Hi JB, 
>
> Thanks for the offer, but I am afraid it would be too complex to share.
>  The application is made of many projects and bundles, including native
> libraries, etc. it would be very hard to set up the environment.  I can
> share the entire Karaf log if needed.
>
> What I am looking for is help on how to troubleshoot this issue.
> Any information (given the provided stack trace) about what setting
> controls this timeout, and what exactly is the code waiting for?
> How to enable more logging?
> Is there something failing and not logging an error perhaps?
> How can I figure out what is blocking, or not finishing?
>
> Best regards,
> Alex soto
>
>
>
>
>> On May 8, 2019, at 9:35 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi Alex,
>>
>> Can you share your itest ? I'm not able to reproduce the issue, so hard
>> to investigate.
>>
>> Regards
>> JB
>>
>> On 08/05/2019 15:31, Alex Soto wrote:
>>> Still having this problem. I am setting log level:
>>>
>>> logLevel(LogLevel.TRACE),
>>>
>>> And
>>>
>>> log4j2.logger.paxexam.name=org.ops4j.pax.exam
>>> log4j2.logger.paxexam.level=TRACE
>>>
>>> And
>>>
>>> static final long SERVICE_TIMEOUT = 300_000;
>>> systemTimeout(SERVICE_TIMEOUT),
>>> RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),
>>>
>>> I removed all services references that used the /@Inject/ annotation,
>>> and replaced them with service lookup code.
>>> Logs don’t show any error or warning that can help pinpoint the cause of
>>> this error.
>>>
>>> Increasing the timeout just delays the reporting of the error by the
>>> FailSafe driver, but the error is logged a lot earlier in the Karaf log
>>> file.
>>>
>>> For easy reference, here is the stack trace again:
>>>
>>> 2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher     
>>>               | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>> Exception in executor thread
>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>> at
>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>> ~[?:?]
>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>> ~[?:?]
>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>> ~[?:?]
>>> at
>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>> ~[?:?]
>>> at
>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>> [201:org.ops4j.pax.swissbox.extender:1.8.2]
>>> at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>> [?:?]
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>> [?:?]
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>> [?:?]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> [?:?]
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>
>>>
>>> Any hint?
>>>
>>> Best regards,
>>> Alex soto
>>>
>>>
>>>
>>>
>>>> On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]
>>>> <mailto:[hidden email]>
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> Do you mean any of  these options?
>>>>
>>>> RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
>>>> CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)
>>>>
>>>>
>>>>
>>>> Best regards,
>>>> Alex soto
>>>>
>>>>
>>>>
>>>>
>>>>> On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]
>>>>> <mailto:[hidden email]>
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> You can increase the startup timeout on the @Configuration method (on
>>>>> the distribution).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 01/05/2019 17:46, Alex Soto wrote:
>>>>>> No, I am not waiting for the service explicitly,  it comes from
>>>>>> Pax Exam
>>>>>> itself (AFIK, based on the stack trace below).  
>>>>>> My tests have a bunch of /@Inject/ed  services, but they are all
>>>>>> decorated with /@Filter(timeout = SERVICE_TIMEOUT)
>>>>>> /where SERVICE_TIMEOUT = 240_000.
>>>>>>
>>>>>> Java version is 8.
>>>>>> Karaf version is 4.2.0.
>>>>>> The exception:
>>>>>>
>>>>>> 2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 |
>>>>>> BundleWatcher     
>>>>>>               | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>>>>> Exception in executor thread
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>>>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>>>>> [202:org.ops4j.pax.swissbox.extender:1.8.2]
>>>>>> at
>>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>>>> [?:?]
>>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>>> [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>>> [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>> [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>> [?:?]
>>>>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>>>>
>>>>>>
>>>>>> These integration tests have been working in the past, so I
>>>>>> suspect, as
>>>>>> the application complexity increased (i.e.,  more services being added
>>>>>> overtime), it now takes more time for the container to finish
>>>>>> initialization (my guess).   I would like to increase the timeout
>>>>>> value
>>>>>> to accommodate for a longer startup time, but so far, what I've tried
>>>>>> has not made a difference.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Alex soto
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré
>>>>>>> <[hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> Are you waiting for the service in your test explicitly or does
>>>>>>> it come
>>>>>>> from pax exam itself ?
>>>>>>>
>>>>>>> What JDK and Karaf version are you using ?
>>>>>>>
>>>>>>> As reminder, Pax Exam is used in Karaf itests themselves, and I don't
>>>>>>> have such issue. It could be related to JDK 11 if you are using
>>>>>>> this JDK
>>>>>>> version.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 01/05/2019 17:13, Alex Soto wrote:
>>>>>>>> Thanks JB, no there are no errors in the log file, besides this one.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Alex soto
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
>>>>>>>>> <[hidden email] <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Alex,
>>>>>>>>>
>>>>>>>>> Most of the time, this is a consequence of another error.
>>>>>>>>>
>>>>>>>>> Can you take a look in the target/exam karaf.log to see if there's
>>>>>>>>> something special there ?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 29/04/2019 18:09, Alex Soto wrote:
>>>>>>>>>> Hello,  
>>>>>>>>>>
>>>>>>>>>> I am using pax-exam 4.11.0 for integration tests. I
>>>>>>>>>> am consistently
>>>>>>>>>> getting the following exception. 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
>>>>>>>>>> waiting
>>>>>>>>>> for service org.ops4j.pax.exam.ProbeInvoker
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>> at
>>>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>>> at
>>>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
>>>>>>>>>> at
>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>>>>>> at
>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>>>>>>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>>>>>>>>>> at
>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
>>>>>>>>>> at
>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
>>>>>>>>>> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
>>>>>>>>>> at com.sun.proxy.$Proxy15.call(Unknown Source)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
>>>>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>>>>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>>>>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
>>>>>>>>>> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What causes this? How to troubleshoot or how to increase the
>>>>>>>>>> timeout?
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Alex soto
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> [hidden email]
>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Jean-Baptiste Onofré
>>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Jean-Baptiste Onofré
>>>>> [hidden email]
>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>> http://blog.nanthrax.net
>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>> Talend - http://www.talend.com
>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
>> [hidden email] <mailto:[hidden email]>
>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>> Talend - http://www.talend.com <http://www.talend.com/>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
In reply to this post by jbonofre
After the integration test finished (with error) I ran Karaf in the same Pax-Exam directory:


target/exam/621f714b-cc7e-4a0c-91cc-b8ce65d02340/bin/karaf

The command list shows everything as ACTIVE.
Also command scr:list  shows all components either as active or satisfied.

The only anomaly in the logs is:

2019-05-08T09:57:46,133 | WARN  | Thread-47        | Activator                        | 196 - org.ops4j.pax.exam.rbc - 4.11.0 | Registration of RBC failed: 
java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: 
java.net.ConnectException: Connection refused (Connection refused)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619) ~[?:?]
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216) ~[?:?]
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202) ~[?:?]
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338) ~[?:?]
at sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:147) ~[?:?]
at org.ops4j.pax.exam.rbc.internal.Activator.bindRBC(Activator.java:145) ~[?:?]
at org.ops4j.pax.exam.rbc.internal.Activator.access$600(Activator.java:47) ~[?:?]
at org.ops4j.pax.exam.rbc.internal.Activator$2.call(Activator.java:121) ~[?:?]
at org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60) ~[200:org.ops4j.pax.swissbox.core:1.8.2]
at org.ops4j.pax.exam.rbc.internal.Activator.register(Activator.java:105) [196:org.ops4j.pax.exam.rbc:4.11.0]
at org.ops4j.pax.exam.rbc.internal.Activator.access$000(Activator.java:47) [196:org.ops4j.pax.exam.rbc:4.11.0]
at org.ops4j.pax.exam.rbc.internal.Activator$1.run(Activator.java:85) [196:org.ops4j.pax.exam.rbc:4.11.0]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.net.ConnectException: Connection refused (Connection refused)
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:?]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:?]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:?]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:?]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:?]
at java.net.Socket.connect(Socket.java:589) ~[?:?]
at java.net.Socket.connect(Socket.java:538) ~[?:?]
at java.net.Socket.<init>(Socket.java:434) ~[?:?]
at java.net.Socket.<init>(Socket.java:211) ~[?:?]
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40) ~[?:?]
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148) ~[?:?]
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613) ~[?:?]
... 12 more


But I think that is expected, since the Integration Test is not running.


On May 8, 2019, at 9:35 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Hi Alex,

Can you share your itest ? I'm not able to reproduce the issue, so hard
to investigate.

Regards
JB

On 08/05/2019 15:31, Alex Soto wrote:
Still having this problem. I am setting log level:

logLevel(LogLevel.TRACE),

And

log4j2.logger.paxexam.name=org.ops4j.pax.exam
log4j2.logger.paxexam.level=TRACE

And

static final long SERVICE_TIMEOUT = 300_000;
systemTimeout(SERVICE_TIMEOUT),
RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),

I removed all services references that used the /@Inject/ annotation,
and replaced them with service lookup code.
Logs don’t show any error or warning that can help pinpoint the cause of
this error.

Increasing the timeout just delays the reporting of the error by the
FailSafe driver, but the error is logged a lot earlier in the Karaf log
file.

For easy reference, here is the stack trace again:

2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher     
              | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68) ~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[201:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


Any hint?

Best regards,
Alex soto




On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]
<[hidden email]>> wrote:

Do you mean any of  these options?

RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)



Best regards,
Alex soto




On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

You can increase the startup timeout on the @Configuration method (on
the distribution).

Regards
JB

On 01/05/2019 17:46, Alex Soto wrote:
No, I am not waiting for the service explicitly,  it comes from Pax Exam
itself (AFIK, based on the stack trace below).  
My tests have a bunch of /@Inject/ed  services, but they are all
decorated with /@Filter(timeout = SERVICE_TIMEOUT)
/where SERVICE_TIMEOUT = 240_000.

Java version is 8.
Karaf version is 4.2.0.
The exception:

2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 | BundleWatcher     
              | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[202:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


These integration tests have been working in the past, so I suspect, as
the application complexity increased (i.e.,  more services being added
overtime), it now takes more time for the container to finish
initialization (my guess).   I would like to increase the timeout value
to accommodate for a longer startup time, but so far, what I've tried
has not made a difference.


Best regards,
Alex soto




On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>
<[hidden email]>> wrote:

Are you waiting for the service in your test explicitly or does it come
from pax exam itself ?

What JDK and Karaf version are you using ?

As reminder, Pax Exam is used in Karaf itests themselves, and I don't
have such issue. It could be related to JDK 11 if you are using
this JDK
version.

Regards
JB

On 01/05/2019 17:13, Alex Soto wrote:
Thanks JB, no there are no errors in the log file, besides this one.

Best regards,
Alex soto




On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
<[hidden email] <[hidden email]>
<[hidden email]>
<[hidden email]>> wrote:

Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:
Hello,  

I am using pax-exam 4.11.0 for integration tests. I am consistently
getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
waiting
for service org.ops4j.pax.exam.ProbeInvoker
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at
org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the
timeout?

Best regards,
Alex soto





-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net
<http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
Talend - http://www.talend.com
<http://www.talend.com/> <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email]
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net
<http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
Talend - http://www.talend.com
<http://www.talend.com/> <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>



-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
Don't you have interface binding issue ?

What do you have in the pom.xml of your itest ?

Regards
JB

On 08/05/2019 16:06, Alex Soto wrote:

> After the integration test finished (with error) I ran Karaf in the same
> Pax-Exam directory:
>
>
> target/exam/621f714b-cc7e-4a0c-91cc-b8ce65d02340/bin/karaf
>
> The command /list/ shows everything as ACTIVE.
> Also command /scr:list/  shows all components either as /active/
> or /satisfied./
> /
> /
> The only anomaly in the logs is:
>
>     2019-05-08T09:57:46,133 | WARN  | Thread-47        | Activator     
>                       | 196 - org.ops4j.pax.exam.rbc - 4.11.0 |
>     Registration of RBC failed: 
>     java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
>     nested exception is: 
>     java.net.ConnectException: Connection refused (Connection refused)
>     at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>     ~[?:?]
>     at
>     sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>     ~[?:?]
>     at
>     sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>     ~[?:?]
>     at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338) ~[?:?]
>     at
>     sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:147) ~[?:?]
>     at
>     org.ops4j.pax.exam.rbc.internal.Activator.bindRBC(Activator.java:145) ~[?:?]
>     at
>     org.ops4j.pax.exam.rbc.internal.Activator.access$600(Activator.java:47)
>     ~[?:?]
>     at
>     org.ops4j.pax.exam.rbc.internal.Activator$2.call(Activator.java:121)
>     ~[?:?]
>     at
>     org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
>     ~[200:org.ops4j.pax.swissbox.core:1.8.2]
>     at
>     org.ops4j.pax.exam.rbc.internal.Activator.register(Activator.java:105)
>     [196:org.ops4j.pax.exam.rbc:4.11.0]
>     at
>     org.ops4j.pax.exam.rbc.internal.Activator.access$000(Activator.java:47)
>     [196:org.ops4j.pax.exam.rbc:4.11.0]
>     at
>     org.ops4j.pax.exam.rbc.internal.Activator$1.run(Activator.java:85)
>     [196:org.ops4j.pax.exam.rbc:4.11.0]
>     at java.lang.Thread.run(Thread.java:748) [?:?]
>     Caused by: java.net.ConnectException: Connection refused (Connection
>     refused)
>     at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:?]
>     at
>     java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
>     ~[?:?]
>     at
>     java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>     ~[?:?]
>     at
>     java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
>     ~[?:?]
>     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:?]
>     at java.net.Socket.connect(Socket.java:589) ~[?:?]
>     at java.net.Socket.connect(Socket.java:538) ~[?:?]
>     at java.net.Socket.<init>(Socket.java:434) ~[?:?]
>     at java.net.Socket.<init>(Socket.java:211) ~[?:?]
>     at
>     sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
>     ~[?:?]
>     at
>     sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
>     ~[?:?]
>     at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
>     ~[?:?]
>     ... 12 more
>
>
>
> But I think that is expected, since the Integration Test is not running.
>
>
>> On May 8, 2019, at 9:35 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi Alex,
>>
>> Can you share your itest ? I'm not able to reproduce the issue, so hard
>> to investigate.
>>
>> Regards
>> JB
>>
>> On 08/05/2019 15:31, Alex Soto wrote:
>>> Still having this problem. I am setting log level:
>>>
>>> logLevel(LogLevel.TRACE),
>>>
>>> And
>>>
>>> log4j2.logger.paxexam.name=org.ops4j.pax.exam
>>> log4j2.logger.paxexam.level=TRACE
>>>
>>> And
>>>
>>> static final long SERVICE_TIMEOUT = 300_000;
>>> systemTimeout(SERVICE_TIMEOUT),
>>> RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),
>>>
>>> I removed all services references that used the /@Inject/ annotation,
>>> and replaced them with service lookup code.
>>> Logs don’t show any error or warning that can help pinpoint the cause of
>>> this error.
>>>
>>> Increasing the timeout just delays the reporting of the error by the
>>> FailSafe driver, but the error is logged a lot earlier in the Karaf log
>>> file.
>>>
>>> For easy reference, here is the stack trace again:
>>>
>>> 2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher     
>>>               | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>> Exception in executor thread
>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>> at
>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>> at
>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>> ~[?:?]
>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>> ~[?:?]
>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>> ~[?:?]
>>> at
>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>> ~[?:?]
>>> at
>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>> [201:org.ops4j.pax.swissbox.extender:1.8.2]
>>> at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>> [?:?]
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>> [?:?]
>>> at
>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>> [?:?]
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> [?:?]
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>
>>>
>>> Any hint?
>>>
>>> Best regards,
>>> Alex soto
>>>
>>>
>>>
>>>
>>>> On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]
>>>> <mailto:[hidden email]>
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> Do you mean any of  these options?
>>>>
>>>> RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
>>>> CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)
>>>>
>>>>
>>>>
>>>> Best regards,
>>>> Alex soto
>>>>
>>>>
>>>>
>>>>
>>>>> On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]
>>>>> <mailto:[hidden email]>
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>> You can increase the startup timeout on the @Configuration method (on
>>>>> the distribution).
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 01/05/2019 17:46, Alex Soto wrote:
>>>>>> No, I am not waiting for the service explicitly,  it comes from
>>>>>> Pax Exam
>>>>>> itself (AFIK, based on the stack trace below).  
>>>>>> My tests have a bunch of /@Inject/ed  services, but they are all
>>>>>> decorated with /@Filter(timeout = SERVICE_TIMEOUT)
>>>>>> /where SERVICE_TIMEOUT = 240_000.
>>>>>>
>>>>>> Java version is 8.
>>>>>> Karaf version is 4.2.0.
>>>>>> The exception:
>>>>>>
>>>>>> 2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 |
>>>>>> BundleWatcher     
>>>>>>               | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>>>>> Exception in executor thread
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>>>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>>>>> ~[?:?]
>>>>>> at
>>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>>>>> [202:org.ops4j.pax.swissbox.extender:1.8.2]
>>>>>> at
>>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>>>> [?:?]
>>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>>> [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>>> [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>> [?:?]
>>>>>> at
>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>> [?:?]
>>>>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>>>>
>>>>>>
>>>>>> These integration tests have been working in the past, so I
>>>>>> suspect, as
>>>>>> the application complexity increased (i.e.,  more services being added
>>>>>> overtime), it now takes more time for the container to finish
>>>>>> initialization (my guess).   I would like to increase the timeout
>>>>>> value
>>>>>> to accommodate for a longer startup time, but so far, what I've tried
>>>>>> has not made a difference.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Alex soto
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré
>>>>>>> <[hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> Are you waiting for the service in your test explicitly or does
>>>>>>> it come
>>>>>>> from pax exam itself ?
>>>>>>>
>>>>>>> What JDK and Karaf version are you using ?
>>>>>>>
>>>>>>> As reminder, Pax Exam is used in Karaf itests themselves, and I don't
>>>>>>> have such issue. It could be related to JDK 11 if you are using
>>>>>>> this JDK
>>>>>>> version.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 01/05/2019 17:13, Alex Soto wrote:
>>>>>>>> Thanks JB, no there are no errors in the log file, besides this one.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Alex soto
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
>>>>>>>>> <[hidden email] <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Alex,
>>>>>>>>>
>>>>>>>>> Most of the time, this is a consequence of another error.
>>>>>>>>>
>>>>>>>>> Can you take a look in the target/exam karaf.log to see if there's
>>>>>>>>> something special there ?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 29/04/2019 18:09, Alex Soto wrote:
>>>>>>>>>> Hello,  
>>>>>>>>>>
>>>>>>>>>> I am using pax-exam 4.11.0 for integration tests. I
>>>>>>>>>> am consistently
>>>>>>>>>> getting the following exception. 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
>>>>>>>>>> waiting
>>>>>>>>>> for service org.ops4j.pax.exam.ProbeInvoker
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>> at
>>>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>>> at
>>>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
>>>>>>>>>> at
>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>>>>>> at
>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>>>>>>>>>> at
>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>>>>>>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>>>>>>>>>> at
>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
>>>>>>>>>> at
>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
>>>>>>>>>> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
>>>>>>>>>> at com.sun.proxy.$Proxy15.call(Unknown Source)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
>>>>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>>>>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>>>>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>>>>>>>> at
>>>>>>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>>>>>>>> at
>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
>>>>>>>>>> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>>>>>>>>>> at
>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What causes this? How to troubleshoot or how to increase the
>>>>>>>>>> timeout?
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Alex soto
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> [hidden email]
>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Jean-Baptiste Onofré
>>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Jean-Baptiste Onofré
>>>>> [hidden email]
>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>> http://blog.nanthrax.net
>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>> Talend - http://www.talend.com
>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
>> [hidden email] <mailto:[hidden email]>
>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>> Talend - http://www.talend.com <http://www.talend.com/>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
That error:   Registration of RBC failed:  only occurs when not running the Integration Test,  I suppose because Pax Exam driver is not running. I think this is how the driver communicates with the probe.  When running the integration test, there is no such error.

What do you want to see from the POM?

Best regards,
Alex soto




On May 8, 2019, at 10:10 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

Don't you have interface binding issue ?

What do you have in the pom.xml of your itest ?

Regards
JB

On 08/05/2019 16:06, Alex Soto wrote:
After the integration test finished (with error) I ran Karaf in the same
Pax-Exam directory:


target/exam/621f714b-cc7e-4a0c-91cc-b8ce65d02340/bin/karaf

The command /list/ shows everything as ACTIVE.
Also command /scr:list/  shows all components either as /active/
or /satisfied./
/
/
The only anomaly in the logs is:

   2019-05-08T09:57:46,133 | WARN  | Thread-47        | Activator     
                     | 196 - org.ops4j.pax.exam.rbc - 4.11.0 |
   Registration of RBC failed: 
   java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
   nested exception is: 
   java.net.ConnectException: Connection refused (Connection refused)
   at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
   ~[?:?]
   at
   sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
   ~[?:?]
   at
   sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
   ~[?:?]
   at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338) ~[?:?]
   at
   sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:147) ~[?:?]
   at
   org.ops4j.pax.exam.rbc.internal.Activator.bindRBC(Activator.java:145) ~[?:?]
   at
   org.ops4j.pax.exam.rbc.internal.Activator.access$600(Activator.java:47)
   ~[?:?]
   at
   org.ops4j.pax.exam.rbc.internal.Activator$2.call(Activator.java:121)
   ~[?:?]
   at
   org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
   ~[200:org.ops4j.pax.swissbox.core:1.8.2]
   at
   org.ops4j.pax.exam.rbc.internal.Activator.register(Activator.java:105)
   [196:org.ops4j.pax.exam.rbc:4.11.0]
   at
   org.ops4j.pax.exam.rbc.internal.Activator.access$000(Activator.java:47)
   [196:org.ops4j.pax.exam.rbc:4.11.0]
   at
   org.ops4j.pax.exam.rbc.internal.Activator$1.run(Activator.java:85)
   [196:org.ops4j.pax.exam.rbc:4.11.0]
   at java.lang.Thread.run(Thread.java:748) [?:?]
   Caused by: java.net.ConnectException: Connection refused (Connection
   refused)
   at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:?]
   at
   java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
   ~[?:?]
   at
   java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
   ~[?:?]
   at
   java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
   ~[?:?]
   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:?]
   at java.net.Socket.connect(Socket.java:589) ~[?:?]
   at java.net.Socket.connect(Socket.java:538) ~[?:?]
   at java.net.Socket.<init>(Socket.java:434) ~[?:?]
   at java.net.Socket.<init>(Socket.java:211) ~[?:?]
   at
   sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
   ~[?:?]
   at
   sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
   ~[?:?]
   at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
   ~[?:?]
   ... 12 more



But I think that is expected, since the Integration Test is not running.


On May 8, 2019, at 9:35 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

Hi Alex,

Can you share your itest ? I'm not able to reproduce the issue, so hard
to investigate.

Regards
JB

On 08/05/2019 15:31, Alex Soto wrote:
Still having this problem. I am setting log level:

logLevel(LogLevel.TRACE),

And

log4j2.logger.paxexam.name=org.ops4j.pax.exam
log4j2.logger.paxexam.level=TRACE

And

static final long SERVICE_TIMEOUT = 300_000;
systemTimeout(SERVICE_TIMEOUT),
RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),

I removed all services references that used the /@Inject/ annotation,
and replaced them with service lookup code.
Logs don’t show any error or warning that can help pinpoint the cause of
this error.

Increasing the timeout just delays the reporting of the error by the
FailSafe driver, but the error is logged a lot earlier in the Karaf log
file.

For easy reference, here is the stack trace again:

2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher     
              | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
~[?:?]
at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[201:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


Any hint?

Best regards,
Alex soto




On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]
<[hidden email]>
<[hidden email]>> wrote:

Do you mean any of  these options?

RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)



Best regards,
Alex soto




On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>
<[hidden email]>> wrote:

You can increase the startup timeout on the @Configuration method (on
the distribution).

Regards
JB

On 01/05/2019 17:46, Alex Soto wrote:
No, I am not waiting for the service explicitly,  it comes from
Pax Exam
itself (AFIK, based on the stack trace below).  
My tests have a bunch of /@Inject/ed  services, but they are all
decorated with /@Filter(timeout = SERVICE_TIMEOUT)
/where SERVICE_TIMEOUT = 240_000.

Java version is 8.
Karaf version is 4.2.0.
The exception:

2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 |
BundleWatcher     
              | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
Exception in executor thread
org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
for service org.ops4j.pax.exam.ProbeInvokerFactory
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
~[?:?]
at
org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
~[?:?]
at
org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
[202:org.ops4j.pax.swissbox.extender:1.8.2]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
[?:?]
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]


These integration tests have been working in the past, so I
suspect, as
the application complexity increased (i.e.,  more services being added
overtime), it now takes more time for the container to finish
initialization (my guess).   I would like to increase the timeout
value
to accommodate for a longer startup time, but so far, what I've tried
has not made a difference.


Best regards,
Alex soto




On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré
<[hidden email] <[hidden email]>
<[hidden email]>
<[hidden email]>> wrote:

Are you waiting for the service in your test explicitly or does
it come
from pax exam itself ?

What JDK and Karaf version are you using ?

As reminder, Pax Exam is used in Karaf itests themselves, and I don't
have such issue. It could be related to JDK 11 if you are using
this JDK
version.

Regards
JB

On 01/05/2019 17:13, Alex Soto wrote:
Thanks JB, no there are no errors in the log file, besides this one.

Best regards,
Alex soto




On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
<[hidden email] <[hidden email]> <[hidden email]>
<[hidden email]>
<[hidden email]>> wrote:

Hi Alex,

Most of the time, this is a consequence of another error.

Can you take a look in the target/exam karaf.log to see if there's
something special there ?

Regards
JB

On 29/04/2019 18:09, Alex Soto wrote:
Hello,  

I am using pax-exam 4.11.0 for integration tests. I
am consistently
getting the following exception. 


org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
waiting
for service org.ops4j.pax.exam.ProbeInvoker
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
at
org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
at
org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
at com.sun.proxy.$Proxy15.call(Unknown Source)
at
org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
at
org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
at
org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)


What causes this? How to troubleshoot or how to increase the
timeout?

Best regards,
Alex soto





-- 
Jean-Baptiste Onofré
[hidden email]
<[hidden email]> <[hidden email]>
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
<http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>
<http://www.talend.com/> <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
<[hidden email]> <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
<http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>
<http://www.talend.com/> <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email]
<mailto:[hidden email]> <mailto:[hidden email]>
http://blog.nanthrax.net
<http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
Talend - http://www.talend.com
<http://www.talend.com/> <http://www.talend.com/>



-- 
Jean-Baptiste Onofré
[hidden email] <[hidden email]>
http://blog.nanthrax.net <http://blog.nanthrax.net/>
Talend - http://www.talend.com <http://www.talend.com/>


-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
If you have:

        <dependency>
            <groupId>org.apache.karaf.itests</groupId>
            <artifactId>common</artifactId>
            <version>4.2.5</version>
        </dependency>
        <dependency>
            <groupId>javax.annotation</groupId>
            <artifactId>javax.annotation-api</artifactId>
        </dependency>
        <dependency>
            <groupId>org.ops4j.pax.exam</groupId>
            <artifactId>pax-exam-container-karaf</artifactId>
            <scope>compile</scope>
            <optional>true</optional>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.felix</groupId>
                    <artifactId>org.apache.felix.configadmin</artifactId>
                </exclusion>
            </exclusions>
        </dependency>


it should bring all required dependencies for you.

Else, you need at least:

        <dependency>
            <groupId>org.ops4j.pax.exam</groupId>
            <artifactId>pax-exam-container-karaf</artifactId>
            <scope>compile</scope>
            <optional>true</optional>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.felix</groupId>
                    <artifactId>org.apache.felix.configadmin</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>org.ops4j.pax.exam</groupId>
            <artifactId>pax-exam-junit4</artifactId>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.karaf.shell</groupId>
            <artifactId>org.apache.karaf.shell.core</artifactId>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-atinject_1.0_spec</artifactId>
            <scope>compile</scope>
        </dependency>

I also recommend to check if you have the following plugin execution in
your pom.xml:

            <plugin>
                <groupId>org.apache.servicemix.tooling</groupId>
                <artifactId>depends-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>generate-depends-file</id>
                        <goals>
                            <goal>generate-depends-file</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Regards
JB

On 08/05/2019 16:19, Alex Soto wrote:

> That error:  /Registration of RBC failed/:  only occurs when *not*
> running the Integration Test,  I suppose because Pax Exam driver is not
> running. I think this is how the driver communicates with the probe.
>  When running the integration test, there is no such error.
>
> What do you want to see from the POM?
>
> Best regards,
> Alex soto
>
>
>
>
>> On May 8, 2019, at 10:10 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Don't you have interface binding issue ?
>>
>> What do you have in the pom.xml of your itest ?
>>
>> Regards
>> JB
>>
>> On 08/05/2019 16:06, Alex Soto wrote:
>>> After the integration test finished (with error) I ran Karaf in the same
>>> Pax-Exam directory:
>>>
>>>
>>> target/exam/621f714b-cc7e-4a0c-91cc-b8ce65d02340/bin/karaf
>>>
>>> The command /list/ shows everything as ACTIVE.
>>> Also command /scr:list/  shows all components either as /active/
>>> or /satisfied./
>>> /
>>> /
>>> The only anomaly in the logs is:
>>>
>>>    2019-05-08T09:57:46,133 | WARN  | Thread-47        | Activator     
>>>                      | 196 - org.ops4j.pax.exam.rbc - 4.11.0 |
>>>    Registration of RBC failed: 
>>>    java.rmi.ConnectException: Connection refused to host: 127.0.0.1;
>>>    nested exception is: 
>>>    java.net.ConnectException: Connection refused (Connection refused)
>>>    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>>>    ~[?:?]
>>>    at
>>>    sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>>>    ~[?:?]
>>>    at
>>>    sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>>>    ~[?:?]
>>>    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338) ~[?:?]
>>>    at
>>>    sun.rmi.registry.RegistryImpl_Stub.rebind(RegistryImpl_Stub.java:147)
>>> ~[?:?]
>>>    at
>>>    org.ops4j.pax.exam.rbc.internal.Activator.bindRBC(Activator.java:145)
>>> ~[?:?]
>>>    at
>>>    org.ops4j.pax.exam.rbc.internal.Activator.access$600(Activator.java:47)
>>>    ~[?:?]
>>>    at
>>>    org.ops4j.pax.exam.rbc.internal.Activator$2.call(Activator.java:121)
>>>    ~[?:?]
>>>    at
>>>   
>>> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
>>>    ~[200:org.ops4j.pax.swissbox.core:1.8.2]
>>>    at
>>>    org.ops4j.pax.exam.rbc.internal.Activator.register(Activator.java:105)
>>>    [196:org.ops4j.pax.exam.rbc:4.11.0]
>>>    at
>>>    org.ops4j.pax.exam.rbc.internal.Activator.access$000(Activator.java:47)
>>>    [196:org.ops4j.pax.exam.rbc:4.11.0]
>>>    at
>>>    org.ops4j.pax.exam.rbc.internal.Activator$1.run(Activator.java:85)
>>>    [196:org.ops4j.pax.exam.rbc:4.11.0]
>>>    at java.lang.Thread.run(Thread.java:748) [?:?]
>>>    Caused by: java.net.ConnectException: Connection refused (Connection
>>>    refused)
>>>    at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:?]
>>>    at
>>>    java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
>>>    ~[?:?]
>>>    at
>>>    java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
>>>    ~[?:?]
>>>    at
>>>    java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
>>>    ~[?:?]
>>>    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:?]
>>>    at java.net.Socket.connect(Socket.java:589) ~[?:?]
>>>    at java.net.Socket.connect(Socket.java:538) ~[?:?]
>>>    at java.net.Socket.<init>(Socket.java:434) ~[?:?]
>>>    at java.net.Socket.<init>(Socket.java:211) ~[?:?]
>>>    at
>>>   
>>> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
>>>    ~[?:?]
>>>    at
>>>   
>>> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:148)
>>>    ~[?:?]
>>>    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
>>>    ~[?:?]
>>>    ... 12 more
>>>
>>>
>>>
>>> But I think that is expected, since the Integration Test is not running.
>>>
>>>
>>>> On May 8, 2019, at 9:35 AM, Jean-Baptiste Onofré <[hidden email]
>>>> <mailto:[hidden email]>
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> Can you share your itest ? I'm not able to reproduce the issue, so hard
>>>> to investigate.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 08/05/2019 15:31, Alex Soto wrote:
>>>>> Still having this problem. I am setting log level:
>>>>>
>>>>> logLevel(LogLevel.TRACE),
>>>>>
>>>>> And
>>>>>
>>>>> log4j2.logger.paxexam.name=org.ops4j.pax.exam
>>>>> log4j2.logger.paxexam.level=TRACE
>>>>>
>>>>> And
>>>>>
>>>>> static final long SERVICE_TIMEOUT = 300_000;
>>>>> systemTimeout(SERVICE_TIMEOUT),
>>>>> RBCRemoteTargetOptions.waitForRBCFor((int) SERVICE_TIMEOUT),
>>>>>
>>>>> I removed all services references that used the /@Inject/ annotation,
>>>>> and replaced them with service lookup code.
>>>>> Logs don’t show any error or warning that can help pinpoint the
>>>>> cause of
>>>>> this error.
>>>>>
>>>>> Increasing the timeout just delays the reporting of the error by the
>>>>> FailSafe driver, but the error is logged a lot earlier in the Karaf log
>>>>> file.
>>>>>
>>>>> For easy reference, here is the stack trace again:
>>>>>
>>>>> 2019-05-08T09:15:18,654 | ERROR | BundleWatcher: 1 | BundleWatcher     
>>>>>               | 201 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>>>> Exception in executor thread
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting
>>>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>> at
>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>>>> ~[204:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>> at
>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>>>> ~[?:?]
>>>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>>>> ~[?:?]
>>>>> at org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>>>> ~[?:?]
>>>>> at
>>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>>>> ~[?:?]
>>>>> at
>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>>>> [201:org.ops4j.pax.swissbox.extender:1.8.2]
>>>>> at
>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>>> [?:?]
>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>>> at
>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>> [?:?]
>>>>> at
>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>> [?:?]
>>>>> at
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>> [?:?]
>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>> [?:?]
>>>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>>>
>>>>>
>>>>> Any hint?
>>>>>
>>>>> Best regards,
>>>>> Alex soto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On May 1, 2019, at 3:47 PM, Alex Soto <[hidden email]
>>>>>> <mailto:[hidden email]>
>>>>>> <mailto:[hidden email]>
>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Do you mean any of  these options?
>>>>>>
>>>>>> RBCRemoteTargetOptions.waitForRBCFor(final Integer timeoutInMillis)
>>>>>> CoreOptions.systemTimeout(systemTimeout(finallongtimeoutInMillis)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Alex soto
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On May 1, 2019, at 12:12 PM, Jean-Baptiste Onofré
>>>>>>> <[hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>> You can increase the startup timeout on the @Configuration method (on
>>>>>>> the distribution).
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 01/05/2019 17:46, Alex Soto wrote:
>>>>>>>> No, I am not waiting for the service explicitly,  it comes from
>>>>>>>> Pax Exam
>>>>>>>> itself (AFIK, based on the stack trace below).  
>>>>>>>> My tests have a bunch of /@Inject/ed  services, but they are all
>>>>>>>> decorated with /@Filter(timeout = SERVICE_TIMEOUT)
>>>>>>>> /where SERVICE_TIMEOUT = 240_000.
>>>>>>>>
>>>>>>>> Java version is 8.
>>>>>>>> Karaf version is 4.2.0.
>>>>>>>> The exception:
>>>>>>>>
>>>>>>>> 2019-05-01T11:28:58,500 | ERROR | BundleWatcher: 1 |
>>>>>>>> BundleWatcher     
>>>>>>>>               | 202 - org.ops4j.pax.swissbox.extender - 1.8.2 |
>>>>>>>> Exception in executor thread
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
>>>>>>>> waiting
>>>>>>>> for service org.ops4j.pax.exam.ProbeInvokerFactory
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:161)
>>>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)
>>>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)
>>>>>>>> ~[205:org.ops4j.pax.swissbox.tracker:1.8.2]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)
>>>>>>>> ~[?:?]
>>>>>>>> at
>>>>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)
>>>>>>>> [202:org.ops4j.pax.swissbox.extender:1.8.2]
>>>>>>>> at
>>>>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>>>>>>> [?:?]
>>>>>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>>>>>> [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>>>>>> [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>>>> [?:?]
>>>>>>>> at
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>>>> [?:?]
>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:?]
>>>>>>>>
>>>>>>>>
>>>>>>>> These integration tests have been working in the past, so I
>>>>>>>> suspect, as
>>>>>>>> the application complexity increased (i.e.,  more services being
>>>>>>>> added
>>>>>>>> overtime), it now takes more time for the container to finish
>>>>>>>> initialization (my guess).   I would like to increase the timeout
>>>>>>>> value
>>>>>>>> to accommodate for a longer startup time, but so far, what I've
>>>>>>>> tried
>>>>>>>> has not made a difference.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Alex soto
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On May 1, 2019, at 11:31 AM, Jean-Baptiste Onofré
>>>>>>>>> <[hidden email] <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>>>
>>>>>>>>> Are you waiting for the service in your test explicitly or does
>>>>>>>>> it come
>>>>>>>>> from pax exam itself ?
>>>>>>>>>
>>>>>>>>> What JDK and Karaf version are you using ?
>>>>>>>>>
>>>>>>>>> As reminder, Pax Exam is used in Karaf itests themselves, and I
>>>>>>>>> don't
>>>>>>>>> have such issue. It could be related to JDK 11 if you are using
>>>>>>>>> this JDK
>>>>>>>>> version.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 01/05/2019 17:13, Alex Soto wrote:
>>>>>>>>>> Thanks JB, no there are no errors in the log file, besides
>>>>>>>>>> this one.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Alex soto
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On May 1, 2019, at 12:10 AM, Jean-Baptiste Onofré
>>>>>>>>>>> <[hidden email]
>>>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>>>> <mailto:[hidden email]>
>>>>>>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Alex,
>>>>>>>>>>>
>>>>>>>>>>> Most of the time, this is a consequence of another error.
>>>>>>>>>>>
>>>>>>>>>>> Can you take a look in the target/exam karaf.log to see if
>>>>>>>>>>> there's
>>>>>>>>>>> something special there ?
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>> On 29/04/2019 18:09, Alex Soto wrote:
>>>>>>>>>>>> Hello,  
>>>>>>>>>>>>
>>>>>>>>>>>> I am using pax-exam 4.11.0 for integration tests. I
>>>>>>>>>>>> am consistently
>>>>>>>>>>>> getting the following exception. 
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up
>>>>>>>>>>>> waiting
>>>>>>>>>>>> for service org.ops4j.pax.exam.ProbeInvoker
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
>>>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>>>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:200)
>>>>>>>>>>>> at sun.rmi.transport.Transport$1.run(Transport.java:197)
>>>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>>>> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:835)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
>>>>>>>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>>>>>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
>>>>>>>>>>>> at
>>>>>>>>>>>> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
>>>>>>>>>>>> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
>>>>>>>>>>>> at
>>>>>>>>>>>> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
>>>>>>>>>>>> at com.sun.proxy.$Proxy14.remoteCall(Unknown Source)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102)
>>>>>>>>>>>> at com.sun.proxy.$Proxy15.call(Unknown Source)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267)
>>>>>>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>>>>>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>>>>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98)
>>>>>>>>>>>> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:379)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:340)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:413)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> What causes this? How to troubleshoot or how to increase the
>>>>>>>>>>>> timeout?
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Alex soto
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>> [hidden email]
>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Jean-Baptiste Onofré
>>>>>>> [hidden email] <mailto:[hidden email]>
>>>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>>>> http://blog.nanthrax.net
>>>>>>> <http://blog.nanthrax.net/> <http://blog.nanthrax.net/>
>>>>>>> Talend - http://www.talend.com
>>>>>>> <http://www.talend.com/> <http://www.talend.com/>
>>>>>>
>>>>>
>>>>
>>>> -- 
>>>> Jean-Baptiste Onofré
>>>> [hidden email] <mailto:[hidden email]>
>>>> <mailto:[hidden email]>
>>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>>> Talend - http://www.talend.com <http://www.talend.com/>
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
>> [hidden email] <mailto:[hidden email]>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
Added:

<exclusions>
               <exclusion>
                   <groupId>org.apache.felix</groupId>
                   <artifactId>org.apache.felix.configadmin</artifactId>
               </exclusion>
           </exclusions>


To the pax-exam-container-karaf dependency, and it worked.  I am not sure if it is a fluke just yet; I will need to run it a few times, to make sure it is real fix.
Thank you, JB, for spending time with me chasing this issue down.
 
Best regards,
Alex soto




On May 8, 2019, at 10:25 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

<dependency>
           <groupId>org.apache.karaf.itests</groupId>
           <artifactId>common</artifactId>
           <version>4.2.5</version>
       </dependency>

Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

jbonofre
No problem. Happy it works ;)

Regards
JB

On 08/05/2019 16:58, Alex Soto wrote:

> Added:
>
> <exclusions>
>                <exclusion>
>                    <groupId>org.apache.felix</groupId>
>                    <artifactId>org.apache.felix.configadmin</artifactId>
>                </exclusion>
>            </exclusions>
>
>
> To the /_pax-exam-container-karaf_/ dependency, and it worked.  I am not
> sure if it is a fluke just yet; I will need to run it a few times, to
> make sure it is real fix.
> Thank you, JB, for spending time with me chasing this issue down.
>  
> Best regards,
> Alex soto
>
>
>
>
>> On May 8, 2019, at 10:25 AM, Jean-Baptiste Onofré <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> <dependency>
>>            <groupId>org.apache.karaf.itests</groupId>
>>            <artifactId>common</artifactId>
>>            <version>4.2.5</version>
>>        </dependency>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service org.ops4j.pax.exam.ProbeInvoker

Alex Soto
It fails intermittently, for example, if I run the entire set of tests, it fails in 2 classes, but if I run one of these failing classes by itself, then it does not fail.
These classes are all part of the same project, i.e., they share the same POM.

All the test classes are annotated:

@RunWith(PaxExam.class)
@ExamReactorStrategy(PerClass.class)

Best regards,
Alex soto




On May 8, 2019, at 10:59 AM, Jean-Baptiste Onofré <[hidden email]> wrote:

No problem. Happy it works ;)

Regards
JB

On 08/05/2019 16:58, Alex Soto wrote:
Added:

<exclusions>
               <exclusion>
                   <groupId>org.apache.felix</groupId>
                   <artifactId>org.apache.felix.configadmin</artifactId>
               </exclusion>
           </exclusions>


To the /_pax-exam-container-karaf_/ dependency, and it worked.  I am not
sure if it is a fluke just yet; I will need to run it a few times, to
make sure it is real fix.
Thank you, JB, for spending time with me chasing this issue down.
 
Best regards,
Alex soto




On May 8, 2019, at 10:25 AM, Jean-Baptiste Onofré <[hidden email]
<[hidden email]>> wrote:

<dependency>
           <groupId>org.apache.karaf.itests</groupId>
           <artifactId>common</artifactId>
           <version>4.2.5</version>
       </dependency>


-- 
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Karaf 4.2.5 - Hibernate 5.4.2 Second level cache with JCache-Ehcache 3

kleber
In reply to this post by Alex Soto
Hi Karaf users.

Is there any way to use 2L cache with karaf / hibernate 5.4.2 / Ehcache 3/ Jcache?

I´m trying to enable 2l cache but no luck, I'm not sure it is a misconfiguration or a bug on hibernate-osgi or karaf.

Hibernate 5.4.2
Karaf 4.2.5
Ehcache 3
Jcache


The application works fine if hibernate.cache.use_second_level_cache is false, 

but when is true there is. an:  java.lang.ClassNotFoundException: org.ehcache.jsr107.EhcacheCachingProvider

If I use 2l cache with Ehcache 2 works, but with some warnings  suggesting to use Ehcache 3/jcache.



A simple "hello world” project with more details to reproduce the issue is on https://github.com/klebeer/karaf-hibernate2Lcache-bug

Thanks

12