If you want to avoid downtime then you can simply install and start the
new service and stop the old one later.
The question is though if a short downtime is a big problem at all. You
typically will have failover with two machines so if one is not
available for a short time it typically will not hurt. Additionally your
service clients will typically have some means of retrying if a call
fails as this can happen at any time.
When I do remote services I often use JMS this has the advantage that it
is no problem if a service goes down for some time. It also provides
some nice failover and load balancing out of the box. So that may also
be an option for you to scale well.
Christian
Am 13.06.2012 19:17, schrieb fabiolf:
Hi Christian,
You got it all right, except for one scenery that is the reason why I think
I need to wait to the instance to be valid, considering I want to avoid
application downtime at all costs, that is, I want to avoid the application
to be restarted as it could lose requests during the restarts.
Imagine I want to change the behavior of one component by exchanging it for
another one that implements the same interface. The steps I would have to do
are simple: stop the old component bundle and start the new component
bundle. Then iPOJO would rebind everything and the application would be
valid again.
But, depending on the order of the steps above, the application may have to
be restarted or not. If I call the stop before the start, then iPOJO will
process the stop, and the other application components would be invalidated
as a side effect.
If I start the new component before stopping the old one, the application
may have to be restarted or not, depending how I achieve this. If I stop the
old components bundle just after the new component bundle starts (which is
synchronous) the application may end up with no implementation available for
a specific service (for a shot period of time), which means that the
application would be invalidated and restarted. That's why I need to wait
for the new component to be up and valid to iPOJO. By doing this, iPOJO will
just change the implementation of the service without stopping the
application, because no components ever get invalidated (except the ones
being exchanged).
I am trying to achieve this by issuing the Bundle.start() for the new
component and waiting until I got a callback to a method that listens to new
Architectures appearing (by creating a aggregate attribute in other
component and configuring a method to be called whenever a new bind to this
attribute is made) and the Architecture reference is the one of the new
component instance. But I am still trying to figure out how to deal with the
concurrency issues. I think I'm going to get there sometime still in this
life. :-)
But the the original question for this thread was if anyone knew some
easier/more efficient way, different of the one I am trying to achieve,
because I was afraid of having to deal with all the concurrency issues. This
is all new to me.
Regards,
Fabio
--
View this message in context:
http://apache-felix.18485.n6.nabble.com/How-is-the-most-efficient-way-to-know-when-a-bundle-is-started-tp4997996p4998057.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
