I'm glad that you have a simple case working :)
The reason I wanted to see the manifests is that it sounds like you have an
inconsistent class space, and the new implementation cannot be used without
re-wiring the consumer. Does your service-providing bundle export any packages?
If so does your service-consuming bundle import them? They don't have to be
related to the service for it to start causing problems.
Tim
Date: Mon, 23 Jul 2012 20:34:27 +0200
Subject: Re: ReferenceRecipe waits although service is available again
From: balazs.zsol...@everit.biz
To: user@aries.apache.org
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
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
