Thx for the response Raul. If that does not work, the alternative is to use the transversal camel-NMR component which is an OSGI service and will avoid that kind of issue. Exchanges will be asynchronous by default. Even if you can turn out the endpoint to synchronize the exchanges, this component suffers from lack of Transaction Support.
http://camel.apache.org/nmr.html On Wed, Mar 6, 2013 at 2:17 AM, Raúl Kripalani <r...@evosent.com> wrote: > Blueprint starts bundles asynchronously, which leads to the start level > not being honoured in most cases. And if it is honoured, it's by fluke and > not by design. > Aries Blueprint 0.4 introduces an option to make bundles start > synchronously [1] & [2], but it seems to be available only from Karaf 3.0.0 > onwards. > > Good news is that Spring DM *does* offer a way to make your bundles start > synchronously, thus honouring the start level. You need to add a > Spring-Context header to your OSGi MANIFEST, with the option > create-asynchronously=false. See [3] for more info. In practice, this > approach has worked nicely for me in extraordinary cases where observing > the start-level was critical. > > Does that help? > > Regards, > > [1] https://issues.apache.org/jira/browse/ARIES-536 > [2] https://issues.apache.org/jira/browse/KARAF-1002 > [3] > http://static.springsource.org/osgi/docs/1.1.0/reference/html/app-deploy.html#app-deploy:headers > > --- > Raúl Kripalani > Enterprise Architect, Program Manager, Open Source Integration specialist > Apache Camel Committer > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk > > On Mar 2, 2013, at 20:58, Antoni Mylka wrote: > > > Hi, > > > > I've been investigating an issue in our application. It works on Karaf, > uses Blueprint and has a number of bundles that start Camel contexts. We > use direct-vm endpoints to send messages between contexts residing in > different bundles and use karaf start levels to enforce startup ordering. > > > > The problem is that most of the time the direct-vm endpoints work, but > sometimes they don't. At startup, when the sending bundle sends a message > we sometimes get an exception saying that no consumers are available on the > endpoint. It looks like a race condition. > > > > After some investigation two questions arose: > > > > 1. Bundle Start, Blueprint Start, Camel start are done synchronously. > With start levels, the bundles on the higher level will start when all > camel contexts from all bundles on the previous level have been started. > Can assume that in my implementation? How do Aries and camel-blueprint work > in this respect? > > > > 2. If the above is true, then are direct-vm endpoints safe for > inter-bundle communication? Maybe they are a completely bad idea. If the > above is false, then I'd need some solution that would wait until consumers > become available. Can camel-osgi endpoints do that? > > > > Antoni Myłka > > antoni.my...@gmail.com > > > > > > -- Charles Moulliard Apache Committer / Sr. Enterprise Architect (RedHat) Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
