direct-vm in OSGI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

direct-vm in OSGI

Antoni Myłka
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
[hidden email]


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: direct-vm in OSGI

Raul Kripalani
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
> [hidden email]
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: direct-vm in OSGI

Charles Moulliard-2
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 <[hidden email]> 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
> > [hidden email]
> >
> >
>
>


--
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: direct-vm in OSGI

Guillaume Nodet
Administrator
In reply to this post by Raul Kripalani
On Wed, Mar 6, 2013 at 2:17 AM, Raúl Kripalani <[hidden email]> 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.
>

This is available in 2.3.x too fwiw.


>
> 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?
>

Another way would be to use OSGi services in order to make sure the route
is not started before the other bundle is ready.
This may need to be improved, and we could have the VM  component not fail
in such a case, though the risk is really not keep  messages and run OOM.


>
> 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
> > [hidden email]
> >
> >
>
>


--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: direct-vm in OSGI

Antoni Myłka
2013/3/6 Guillaume Nodet <[hidden email]>:

> On Wed, Mar 6, 2013 at 2:17 AM, Raúl Kripalani <[hidden email]> 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.
>>
>
> This is available in 2.3.x too fwiw.
>

Great! So a short-term workaround would be to upgrade from 2.2.9 to
2.3.1 and include the
org.apache.aries.blueprint.synchronous=true
in etc/config.properties

This is still not a real solution though.

>> 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?
>>
>
> Another way would be to use OSGi services in order to make sure the route
> is not started before the other bundle is ready.
> This may need to be improved, and we could have the VM  component not fail
> in such a case, though the risk is really not keep  messages and run OOM.

First of all thanks very much for the responses, Let me summarize.

AFAIU I have the following options:

1. Use https://github.com/szhem/camel-osgi
to("osgi:consumer");
OK but the doc makes no mention of the grace period. Moreover that
project seems dormant and it's part of the "official" distribution.

2. Use NMR:
to("nmr:consumer")
I'd like a fully synchronous call with grace period. AFAIU NMR is
asynchronous by default. The 'synchronous' parameter can only be made
on the consumer URI. Does this mean that the same thread will push the
message from one bundle to the other?

3. Hack with camel-osgi
On the consumer side use
from("osgi:endpointId&endpointName=coolEndpoint")
On the producer side use
<reference id="someId"
   interface="org.apache.camel.Processor"
   filter="(endpointName=coolEndpoint)" />
and then in the bundle
<bean ref="someId" />

Seems OK - pushes the message from one bundle to another, uses the
grace period. The route I'm calling does a little transformation and
returns the message back - that's what I need (hence <bean> and not
<to>.) Is this likely to work? What about the Exchange.getContext()
method - an exchange is tied to a concrete context, isn't it?
direct-vm doesn't do anything with this, so perhaps it's not much of a
problem.

--
Antoni Myłka
Loading...