You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Quinn Stevenson <qu...@pronoia-solutions.com> on 2016/11/10 16:24:25 UTC
Proposed change to BlueprintCamelContext startup behaviour
I’d like to propose changing the BlueprintCamelContext such that the Camel Context is started when the Blueprint container is fully created.
While working on CAMEL-9570 ( https://issues.apache.org/jira/browse/CAMEL-9570 <https://issues.apache.org/jira/browse/CAMEL-9570> ), I noticed that the BlueprintCamelContext implements the OSGi ServiceLister interface and starts the Camel Context when it is notified that the BlueprintContainer service has been registered.
However, I’ve hit some problems with this behavior when there are issues with creation/initialization of some of the camel components. (NOTE - I caused these issues with my experiments, but the current startup behavior made them much more difficult to debug ).
I’d like to change the BlueprintCamelContext so that the Camel Context is started when it receives the BlueprintEvent.CREATED for the blueprint container, and also stop the Camel Context when it receives the BlueprintEvent.DESTROYING for the blueprint container.
BTW - This will also set the stage for another improvement I have in mind, where the BlueprintCamelContext will automatically suspend if an OSGi Service isn’t available, and resume once the service is available again.
If this sounds OK to the community, I’ll create a JIRA and a PR
Re: Proposed change to BlueprintCamelContext startup behaviour
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Thanks for the feedback Matt -
I’ve dealt with suspending the CamelContext when services aren’t available in a couple of ways. One way was to watch for the BlueprintEvent.WAITING, and suspend the camel context when that was received. This was a little problematic though because I don’t get another BlueprintEvent once the service is satisfied so I can resume the CamelContext. I hacked one up that just listened for new service registrations and tried to resume the context when it receive one, but that didn’t work very well.
The other method I tried was to use a Blueprint reference-listener on the service references. I didn’t complete this prototype, but it was actually working very well. I could suspend the CamelContext when the unbind method was called, and resume it when the bind method was called. This nice thing about this approach was I could detect service swaps as well, and I could restart the CamelContext if required - this worked well for JMS ConnectionFactory service references.
As far at the startup goes, I also think the right time to start the CamelContext is when the BlueprintEvent.CREATED is received. I also think the CamelContext should be stopped when the BlueprintEvent.DESTROYING is received. I’ve got a PR out there for CAMEL-9570 that implements this startup behavior. If you have time, I’d really appreciate it if you could take a look and offer any suggestions - I haven’t heard anything on that PR.
> On Nov 16, 2016, at 7:54 PM, Matt Pavlovich <ma...@gmail.com> wrote:
>
>
> I've had to work through these same issues by registering a service listener to a "service manager" thingie and having the CamelRoute passed into the "service manager" thingie.
>
> However, shouldn't the CamelContext be initialized when the BlueprintEvent.CREATED is sent? I could see it being problematic to know when the Context is done, since tCREATED the last BlueprintEvent.
>
> Perhaps implementing a standard service manager that you could register a list of services and a context would be a better approach?
>
> On 11/10/16 11:24 AM, Quinn Stevenson wrote:
>> I’d like to propose changing the BlueprintCamelContext such that the Camel Context is started when the Blueprint container is fully created.
>>
>> While working on CAMEL-9570 ( https://issues.apache.org/jira/browse/CAMEL-9570 <https://issues.apache.org/jira/browse/CAMEL-9570> ), I noticed that the BlueprintCamelContext implements the OSGi ServiceLister interface and starts the Camel Context when it is notified that the BlueprintContainer service has been registered.
>>
>> However, I’ve hit some problems with this behavior when there are issues with creation/initialization of some of the camel components. (NOTE - I caused these issues with my experiments, but the current startup behavior made them much more difficult to debug ).
>>
>> I’d like to change the BlueprintCamelContext so that the Camel Context is started when it receives the BlueprintEvent.CREATED for the blueprint container, and also stop the Camel Context when it receives the BlueprintEvent.DESTROYING for the blueprint container.
>>
>> BTW - This will also set the stage for another improvement I have in mind, where the BlueprintCamelContext will automatically suspend if an OSGi Service isn’t available, and resume once the service is available again.
>>
>> If this sounds OK to the community, I’ll create a JIRA and a PR
>>
>>
>>
>
Re: Proposed change to BlueprintCamelContext startup behaviour
Posted by Matt Pavlovich <ma...@gmail.com>.
I've had to work through these same issues by registering a service
listener to a "service manager" thingie and having the CamelRoute passed
into the "service manager" thingie.
However, shouldn't the CamelContext be initialized when the
BlueprintEvent.CREATED is sent? I could see it being problematic to know
when the Context is done, since tCREATED the last BlueprintEvent.
Perhaps implementing a standard service manager that you could register
a list of services and a context would be a better approach?
On 11/10/16 11:24 AM, Quinn Stevenson wrote:
> I\u2019d like to propose changing the BlueprintCamelContext such that the Camel Context is started when the Blueprint container is fully created.
>
> While working on CAMEL-9570 ( https://issues.apache.org/jira/browse/CAMEL-9570 <https://issues.apache.org/jira/browse/CAMEL-9570> ), I noticed that the BlueprintCamelContext implements the OSGi ServiceLister interface and starts the Camel Context when it is notified that the BlueprintContainer service has been registered.
>
> However, I\u2019ve hit some problems with this behavior when there are issues with creation/initialization of some of the camel components. (NOTE - I caused these issues with my experiments, but the current startup behavior made them much more difficult to debug ).
>
> I\u2019d like to change the BlueprintCamelContext so that the Camel Context is started when it receives the BlueprintEvent.CREATED for the blueprint container, and also stop the Camel Context when it receives the BlueprintEvent.DESTROYING for the blueprint container.
>
> BTW - This will also set the stage for another improvement I have in mind, where the BlueprintCamelContext will automatically suspend if an OSGi Service isn\u2019t available, and resume once the service is available again.
>
> If this sounds OK to the community, I\u2019ll create a JIRA and a PR
>
>
>