Hi, thank you for offering your help. I tried to create a more simple use case (with non-business logic bundles) however I could not reproduce the problem. This is good news as blueprint works :).
I will try to add every dependency we use in our system (hibernate, myfaces, ...) and try to find the cause of the problem. If I can reproduce it but cannot find the cause I will prepare a sample application with a full testing environment (ready to use equinox with libraries inside). I will not have time in the following couple of days but I will get back to this. If I find the cause I will drop a mail anyway to let others know what caused the hangs. Thanks and regards, Balazs On Fri, Jul 20, 2012 at 6:01 PM, Timothy Ward <timothyjw...@apache.org>wrote: > 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 > service > - Servlet bundle: > - Contains Servlet classes > - Contains 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 method > - The 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 > >
