I'm affected, intermittently, by the same issue. My (appalling) workaround was to modify the default timeout in ServiceLookup.class and upload the hacked JAR to my local Nexus server.
Thanks for looking into this. Paul On Thursday, 31 August 2017 05:56:32 UTC+1, [email protected] wrote: > > Okay, I have created https://ops4j1.jira.com/browse/PAXEXAM-891 I'll try > to take a look at it the nex days.. > It seems the logic has already changed in PaxExam-5 for this, if you want > you can try our latest snapshot build? > > > Am Mittwoch, 30. August 2017 12:36:04 UTC+2 schrieb Martin Lichtin: >> >> Thanks, but unfortunately that setting has no effect in this situation. >> >> Parser.createInvoker calls >> >> public static <T> T getService( BundleContext bc, Class<T> type, >> Map<String, String> props ) >> { >> return getService( bc, type, DEFAULT_TIMEOUT, props ); >> } >> >> and that DEFAULT_TIMEOUT is set to 10 seconds. >> >> On Tuesday, August 29, 2017 at 3:42:01 PM UTC+2, [email protected] >> wrote: >>> >>> This can happen when your test-container is under stress e.g init >>> several things after startup. You can define a system-property >>> 'pax.exam.service.timeout' with a value of e.g. 30000 to wait longer. >>> using systemProperty() option. >>> >>> Am Sonntag, 27. August 2017 17:17:08 UTC+2 schrieb Martin Lichtin: >>>> >>>> Actually no, the @Injects are all ok, also they all have a 60s timeout >>>> on it. >>>> >>>> From the stacktrace you can see it's hitting an pax-exam internal 10s >>>> timeout. >>>> >>>> Parser.createInvoker calls ServiceLookup.getService(ctx, >>>> org.ops4j.pax.exam.ProbeInvokerFactory.class) >>>> That getService method waits up to 10 seconds for the >>>> "ProbeInvokerFactory" service. >>>> >>>> Would you understand what could cause a delay for that service to >>>> become registered? >>>> >>>> - Martin >>>> >>>> On Saturday, August 26, 2017 at 8:15:49 AM UTC+2, Achim Nierbeck wrote: >>>>> >>>>> Hi, >>>>> >>>>> is your test failing because an @Inject of your service fails? >>>>> I think you can add a timeout to the @Inject, in case you have a >>>>> rather big setup where the service does take a bit longer to be available >>>>> after start. >>>>> >>>>> regards, Achim >>>>> >>>>> 2017-08-24 10:51 GMT+02:00 Martin Lichtin <[email protected]>: >>>>> >>>>>> Sometimes, not always, a Pax test fails with >>>>>> >>>>>> 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)[304:org.ops4j.pax.swissbox.tracker:1.8.2] >>>>>> at >>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:104)[304:org.ops4j.pax.swissbox.tracker:1.8.2] >>>>>> at >>>>>> org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:87)[304:org.ops4j.pax.swissbox.tracker:1.8.2] >>>>>> at >>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.createInvoker(Parser.java:79)[296:org.ops4j.pax.exam.extender.service:4.11.0] >>>>>> at >>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.make(Parser.java:68)[296:org.ops4j.pax.exam.extender.service:4.11.0] >>>>>> at >>>>>> org.ops4j.pax.exam.raw.extender.intern.Parser.<init>(Parser.java:54)[296:org.ops4j.pax.exam.extender.service:4.11.0] >>>>>> at >>>>>> org.ops4j.pax.exam.raw.extender.intern.TestBundleObserver.addingEntries(TestBundleObserver.java:69)[296:org.ops4j.pax.exam.extender.service:4.11.0] >>>>>> at >>>>>> org.ops4j.pax.swissbox.extender.BundleWatcher$3.run(BundleWatcher.java:226)[301:org.ops4j.pax.swissbox.extender:1.8.2] >>>>>> at >>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_141] >>>>>> at >>>>>> java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_141] >>>>>> at >>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_141] >>>>>> at >>>>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_141] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_141] >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_141] >>>>>> at java.lang.Thread.run(Thread.java:748)[:1.8.0_141] >>>>>> >>>>>> Any ideas what could be wrong? In case it is a timing issue, which >>>>>> timeout parameter would that be? >>>>>> >>>>>> - Martin >>>>>> >>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "OPS4J" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Apache Member >>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>> Committer & Project Lead >>>>> blog <http://notizblog.nierbeck.de/> >>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>>> >>>>> Software Architect / Project Manager / Scrum Master >>>>> >>>>> -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
