Hi, Could you send the manifests of the three bundles, and the manifest of the updated core bundle? I'd like to check for class-space issues.
Regards, Tim Date: Fri, 20 Jul 2012 10:20:25 +0200 Subject: ReferenceRecipe waits although service is available again From: balazs.zsol...@everit.biz To: user@aries.apache.org Hi, I have a problem. Please help me finding out if this is a bug or my use case is wrong. There are three bundles:API bundle: Contains an interface A Core bundle: Contains the implementation of A and provides it as a serviceServlet bundle:Contains Servlet classesContains a ServletActivator class that has init, destroy method and A property A blueprint configuration that sets the A property in the ServletActivator and calls the init methodThe init method instantiates the servlet and passes it to org.osgi.service.http.HttpService I start Equinox, everything is fine. I can see the servlet running well. I say an update command on the Core bundle and I see that the service is unregistered and registered again provided by this bundle. After an http request will stop at the line below until a timeout: "qtp1313052129-27" prio=6 tid=0x000000000873d800 nid=0x2498 in Object.wait() [0x000000001105d000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:202) - locked <0x0000000782888a68> (a java.lang.Object) at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:56) at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:290) at Proxy18044d63_3609_456d_82b5_803c25785628.getCurrentPresenseForAdspace(Unknown Source) at ..................................MyServlet.service(MyServlet.java:76) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:350) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:620) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) In two of my applications it is always reproducable. Please let me know if you see the problem based on the stacktrace by looking at it or if I should provide a sample applicaiton. It would be really nice to solve this before 1.0.0 release comes out as this really stops our TDD development workflow. There is another problem based on this: If I update the Servlet bundle just after updating the core bundle everything works fine. However if I update the Core bundle, make an http request and than try updating the web bundle will be locked until the timeout (basically I cannot process any osgi related command in the container as a bundle stopping is locked). Thanks and regards,Balazs Zsoldos