The new real-time logging additions need the ability to stage deployment, basically, to be able to bring up the system in stages or phases, to allow certain components to be actively running prior to others. The current deployers do not support this.
The basic problem is that the deployers are structured something like
load deployment file for all components listed in deployment file configure component if any component failed to configure then exit for all components listed in deployment file start component ...
The problem comes when one of your components is say a file logging component attached to the real-time logging, and some other component fails to configure. You get no logging output as the logging component hasn't had a chance to start yet! What you need is to be able to completely configure and start all your logging _service components_, and then attempt to configure/start your application components.
I think that this is a specific case of service-related components. These components need to be running before the application components start to come up, as the service components are essentially runtime additions to the Orocos framework. Future time/clock related services could fall into this category also. I also wonder whether some of the communciations services already in RTT (eg the corba::ApplicationServer) are essentially the same thing, but essentially "hard coded" into RTT.
I haven't yet looked into the implementation details, but I wanted to see what others in the community thought. Have others hit similar issues before? Does this seem to you to be a more general problem that needs a solution?
Cheers
Stephen
Staged deployment
On Thu, 3 Jun 2010, S Roderick wrote:
> The new real-time logging additions need the ability to stage deployment, basically, to be able to bring up the system in stages or phases, to allow certain components to be actively running prior to others. The current deployers do not support this.
I agree that this "staged deployment" should be an integral part of a
professional "component-based" software system...
> The basic problem is that the deployers are structured something like
>
>
>
> The problem comes when one of your components is say a file logging
> component attached to the real-time logging, and some other component
> fails to configure. You get no logging output as the logging component
> hasn't had a chance to start yet! What you need is to be able to
> completely configure and start all your logging _service components_, and
> then attempt to configure/start your application components.
In addition, there are the other (natural) two stages connected to the
"container" and "application" parts of each individual component.
There is some "prior art" in this problem from the "two-phase commit"
approach to keep databases consistent
<http://en.wikipedia.org/wiki/Two-phase_commit>.
The idea is to first set up all components, before the first component
starts doing something. This also explicitly allows a "roll back" feature.
Another (better!) source of inspiration is the SCA model
<http://en.wikipedia.org/wiki/Service_component_architecture>.
One of their documents (<http://www.oasis-opencsa.org/specifications>) deals with
deployment, and it refers to OSGi for doing that job right...
> I think that this is a specific case of service-related components. These
> components need to be running before the application components start to
> come up, as the service components are essentially runtime additions to
> the Orocos framework. Future time/clock related services could fall into
> this category also. I also wonder whether some of the communciations
> services already in RTT (eg the corba::ApplicationServer) are essentially
> the same thing, but essentially "hard coded" into RTT.
>
> I haven't yet looked into the implementation details, but I wanted to see
> what others in the community thought. Have others hit similar issues
> before? Does this seem to you to be a more general problem that needs a
> solution?
Yes! OSGi is the way to go...? (At least, to be inspired by best
practice...)
Herman
Staged deployment
On Jun 3, 2010, at 10:16 , Herman Bruyninckx wrote:
> On Thu, 3 Jun 2010, S Roderick wrote:
>
>> The new real-time logging additions need the ability to stage deployment, basically, to be able to bring up the system in stages or phases, to allow certain components to be actively running prior to others. The current deployers do not support this.
>
> I agree that this "staged deployment" should be an integral part of a
> professional "component-based" software system...
>
>> The basic problem is that the deployers are structured something like
>>
>>
>>
>> The problem comes when one of your components is say a file logging
>> component attached to the real-time logging, and some other component
>> fails to configure. You get no logging output as the logging component
>> hasn't had a chance to start yet! What you need is to be able to
>> completely configure and start all your logging _service components_, and
>> then attempt to configure/start your application components.
>
> In addition, there are the other (natural) two stages connected to the
> "container" and "application" parts of each individual component. There is some "prior art" in this problem from the "two-phase commit"
> approach to keep databases consistent
> <http://en.wikipedia.org/wiki/Two-phase_commit>.
> The idea is to first set up all components, before the first component
> starts doing something. This also explicitly allows a "roll back" feature.
>
> Another (better!) source of inspiration is the SCA model
> <http://en.wikipedia.org/wiki/Service_component_architecture>.
> One of their documents (<http://www.oasis-opencsa.org/specifications>) deals with
> deployment, and it refers to OSGi for doing that job right...
Lot of info in there ... will take time to wade through it. Was there a particularly document you had in mind re deployment specifications. At first glance, I couldn't find it.
>> I think that this is a specific case of service-related components. These
>> components need to be running before the application components start to
>> come up, as the service components are essentially runtime additions to
>> the Orocos framework. Future time/clock related services could fall into
>> this category also. I also wonder whether some of the communciations
>> services already in RTT (eg the corba::ApplicationServer) are essentially
>> the same thing, but essentially "hard coded" into RTT.
>>
>> I haven't yet looked into the implementation details, but I wanted to see
>> what others in the community thought. Have others hit similar issues
>> before? Does this seem to you to be a more general problem that needs a
>> solution?
>
> Yes! OSGi is the way to go...? (At least, to be inspired by best
> practice...)
This is a v2 issue IMHO. But you are right, it is needed, particularly when it comes to scaling to larger systems.
The existing v1 deployer almost supports what I need, but I'm having a couple of minor issues. I'll get those solved and send patches to the list. I don't think this is going to be a big deal.
Stephen
Staged deployment
On Jun 3, 2010, at 11:00 , Stephen Roderick wrote:
> On Jun 3, 2010, at 10:16 , Herman Bruyninckx wrote:
>
>> On Thu, 3 Jun 2010, S Roderick wrote:
<sni
>>> I think that this is a specific case of service-related components. These
>>> components need to be running before the application components start to
>>> come up, as the service components are essentially runtime additions to
>>> the Orocos framework. Future time/clock related services could fall into
>>> this category also. I also wonder whether some of the communciations
>>> services already in RTT (eg the corba::ApplicationServer) are essentially
>>> the same thing, but essentially "hard coded" into RTT.
>>>
>>> I haven't yet looked into the implementation details, but I wanted to see
>>> what others in the community thought. Have others hit similar issues
>>> before? Does this seem to you to be a more general problem that needs a
>>> solution?
>>
>> Yes! OSGi is the way to go...? (At least, to be inspired by best
>> practice...)
>
> This is a v2 issue IMHO. But you are right, it is needed, particularly when it comes to scaling to larger systems.
>
> The existing v1 deployer almost supports what I need, but I'm having a couple of minor issues. I'll get those solved and send patches to the list. I don't think this is going to be a big deal.
> Stephen
Attached patch allows two-phase component loading. It uses the existing site deployer file to load any service components (eg logging) and then loads the application components via the normal -s command line option. Note that shutdown is still a one-phase operation. It would take quite some work to change the deployer to truly support multi-phase start/stop.
NB you will still get warnings of the form
Component LoggingService doesn't need to be configured (already Running)Not much can do about this warning right now.
S