Blueprint, gbeans, and activemq

[David Jencks <da...@yahoo.com>]

I've discovered that there's a timing problem using bueprint in  
geronimo.  Blueprint uses a separate thread to fire up the beans in a  
bundle, whereas geronimo uses the calling thread to start a  
configuration.  This means that if a gbean needs something supplied by  
a blueprint bean in an "earlier" configuration, there's no guarantee  
the blueprint stuff will have been processed at all yet.

A simple way to deal with this is with a WaitForBlueprintGBean that  
registers as a BlueprintListener and blocks until it gets a  
BlueprintEvent indicating that the blueprint stuff either started or  
failed to start.

While all comments are welcome, I'd appreciate it if Jarek or Rick  
could take a look to see if I missed any events that need to be  
considered.  The new class is framework/modules/geronimo-blueprint/src/ 
main/java/org/apache/geronimo/blueprint/WaitForBlueprintGBean.java

I put this in a new module since we may not want a dependency on  
blueprint-api for every module in geronimo.  The only other place that  
seems reasonable to me is geronimo-system but this will drag in  
blueprint everywhere.

Anyway.....  with the help of this gbean, slightly modified aries  
blueprint, xbean-blueprint, karaf modified to use aries blueprint, and  
a couple minor activemq changes to eliminate needless spring-isms, I  
appear to have an activemq broker starting up under blueprint, and our  
regular activemq-ra connector starting.  I plan to work on getting all  
these bits committed or into patches.

thanks
david jencks

Re: Blueprint, gbeans, and activemq

[David Jencks <da...@yahoo.com>]

On Feb 8, 2010, at 4:36 AM, Rick McGuire wrote:

> On 2/8/2010 3:48 AM, David Jencks wrote:
>> I've discovered that there's a timing problem using bueprint in  
>> geronimo.  Blueprint uses a separate thread to fire up the beans in  
>> a bundle, whereas geronimo uses the calling thread to start a  
>> configuration.  This means that if a gbean needs something supplied  
>> by a blueprint bean in an "earlier" configuration, there's no  
>> guarantee the blueprint stuff will have been processed at all yet.
> Is your dependency actually on the entire blueprint configuration or  
> on individual services that the configuration is exporting?  It  
> would seem more appropriate to wait on the dependent service rather  
> than on the entire blueprint configuration.

In this case the activemq-ra is looking for a server socket opened by  
an anonymous nested bean in the xbean plan.

I actually don't agree that waiting for individual blueprint beans is  
more appropriate.  The WaitForBlueprintGBean has to go in the same  
geronimo plugin as the blueprint plan, and it has the effect of making  
blueprint startup act the same as gbean plugin startup.  As long as we  
keep gbean/plugin startup in the same thread as whatever asked the  
plugin to start, this is going to be much more reliable than trying to  
mix timing models.

In this particular case there's another possible solution that would  
be very desirable to implement.... the activemq-ra is trying to open a  
connection to the broker to do recovery.  It would be even better to  
fix the transaction manager to keep trying recovery until it can  
successfully get a connection.  However I think getting the timing  
models to be more compatible will prove useful in a lot of places.  I  
think I'm seeing occasional jndi startup failures that may well be a  
similar timing issue.

thanks
david jencks

>
>>
>> A simple way to deal with this is with a WaitForBlueprintGBean that  
>> registers as a BlueprintListener and blocks until it gets a  
>> BlueprintEvent indicating that the blueprint stuff either started  
>> or failed to start.
>>
>> While all comments are welcome, I'd appreciate it if Jarek or Rick  
>> could take a look to see if I missed any events that need to be  
>> considered.  The new class is framework/modules/geronimo-blueprint/ 
>> src/main/java/org/apache/geronimo/blueprint/ 
>> WaitForBlueprintGBean.java
>>
>> I put this in a new module since we may not want a dependency on  
>> blueprint-api for every module in geronimo.  The only other place  
>> that seems reasonable to me is geronimo-system but this will drag  
>> in blueprint everywhere.
>>
>> Anyway.....  with the help of this gbean, slightly modified aries  
>> blueprint, xbean-blueprint, karaf modified to use aries blueprint,  
>> and a couple minor activemq changes to eliminate needless spring- 
>> isms, I appear to have an activemq broker starting up under  
>> blueprint, and our regular activemq-ra connector starting.  I plan  
>> to work on getting all these bits committed or into patches.
>>
>> thanks
>> david jencks
>>
>

Re: Blueprint, gbeans, and activemq

[Rick McGuire <ri...@gmail.com>]

On 2/8/2010 3:48 AM, David Jencks wrote:
> I've discovered that there's a timing problem using bueprint in 
> geronimo.  Blueprint uses a separate thread to fire up the beans in a 
> bundle, whereas geronimo uses the calling thread to start a 
> configuration.  This means that if a gbean needs something supplied by 
> a blueprint bean in an "earlier" configuration, there's no guarantee 
> the blueprint stuff will have been processed at all yet.
Is your dependency actually on the entire blueprint configuration or on 
individual services that the configuration is exporting?  It would seem 
more appropriate to wait on the dependent service rather than on the 
entire blueprint configuration.

>
> A simple way to deal with this is with a WaitForBlueprintGBean that 
> registers as a BlueprintListener and blocks until it gets a 
> BlueprintEvent indicating that the blueprint stuff either started or 
> failed to start.
>
> While all comments are welcome, I'd appreciate it if Jarek or Rick 
> could take a look to see if I missed any events that need to be 
> considered.  The new class is 
> framework/modules/geronimo-blueprint/src/main/java/org/apache/geronimo/blueprint/WaitForBlueprintGBean.java 
>
>
> I put this in a new module since we may not want a dependency on 
> blueprint-api for every module in geronimo.  The only other place that 
> seems reasonable to me is geronimo-system but this will drag in 
> blueprint everywhere.
>
> Anyway.....  with the help of this gbean, slightly modified aries 
> blueprint, xbean-blueprint, karaf modified to use aries blueprint, and 
> a couple minor activemq changes to eliminate needless spring-isms, I 
> appear to have an activemq broker starting up under blueprint, and our 
> regular activemq-ra connector starting.  I plan to work on getting all 
> these bits committed or into patches.
>
> thanks
> david jencks
>