Re: Enforcing mandatory components for an application
I agree, you normally need a combination of timeout and maybe health check for the most essential services (with timeout and/or state monitoring). It’s a more annoying aspect of using OSGi as a application platform - especially for larger moduliths. Want there a health/readiness proposal to check for certain bundles or services? (We have a custom service which does that). Gruss Bernd -- http://bernd.eckenfels.net Von: Neil Bartlett Gesendet: Tuesday, October 12, 2021 11:59:12 PM An: users Betreff: Re: Enforcing mandatory components for an application This is an interesting problem and I'm also not clear on why Ray suggested the Condition Service as a solution, as I can't see how it helps. What you're trying to do is somewhat against the grain in OSGi. We assume that the world as open and that failure is never permanent. Just because the HTTP component has not started *yet* doesn't mean that it never will... if you could just install a bundle the right version of some dependency it might all spring into life! But you are building a closed world with a well-defined set of bundles. As the application assembler you know that there will never be another bundle to come along and save the day. Honestly, a launcher-based timeout may still be the best solution, e.g. "HTTP server failed to start within 30 seconds, terminating application". There may be some error conditions that you can detect without having to wait for the full timeout, but you cannot *in general* tell the difference between a component that will never be satisfied and a component that just isn't satisfied yet. On Tue, 12 Oct 2021 at 22:09, Robert Munteanu wrote: > Hello Ray, > > Thanks for your reply. I read through [1] and also the condition > service specification [3] and I am not sure how this will help me. > > I am looking for a way to say "component X did not come up and will not > come up" and at that moment halt the application. This is a bit of a > closed-world/static approach, but I am fine with it for limited > scenarios. E.g. if binding an HTTP server to port 8080 failed, I would > not like the application to linger and wait for the admin to solve it > and restart the component when done, but it should stop altogether. > > Where would you see the condition service helping here? > > Thanks, > Robert > > [3]: > https://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html > > On Tue, 2021-10-12 at 11:33 -0400, Raymond Augé wrote: > > Hello Robert, > > > > You probably want to use the DS support [1] for the **NEW** _Condition > > Service Specification_ which was added in OSGi Compendium R8 (currently > > in > > the release process). > > > > You can try this out with the current 2.2.0-RC1 of Felix SCR [2] on > > Maven > > Central. > > > > The Condition Service Specification lets you model your application > > conditions (as the name implies) using OSGi service filters. > > > > [1] > > > https://osgi.github.io/osgi/cmpn/service.component.html#service.component-satisfying.condition > > [2] > > > https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr/2.2.0-RC1/bundle > > > > On Tue, Oct 12, 2021 at 5:50 AM Robert Munteanu > > wrote: > > > > > Hi, > > > > > > I have written a couple of small OSGi apps where if a single top- > > > level > > > DS component, let's call it T, cannot start then the application > > > should > > > shut down immediately. One example are HTTP services where the HTTP > > > server port cannot be bound to. > > > > > > The causes of failures I have seen are: > > > - T activation fails > > > - the bundle providing T fails to resolve > > > - a dependency of T fails activation > > > - a dependency of T cannot be provided because the bundle providing > > > it > > > failed to staret > > > > > > I can think of several ways of approaching the problem, but none of > > > them perfect: > > > - using the Felix Health Checks[1], that seems wrong since it's a > > > polling-based approach and we very likely know when a dependency > > > fails > > > and stop immediately > > > - using the SCR introspection API [2], which is again based on > > > polling > > > - waiting for the framework to start and then looking up the service; > > > but we don't know when the SCR has 'settled' > > > > > > Are there any patterns or libraries that I can use to approach this > > > problem? > > > > > > Thanks, > > > Robert > > > > > > [1]: > > > > > > > https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html > > > [2]: > > > > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > > For additional commands, e-mail: users-h...@felix.apache.org > > > > > > > > > > > - > To unsubscribe,
Re: Enforcing mandatory components for an application
This is an interesting problem and I'm also not clear on why Ray suggested the Condition Service as a solution, as I can't see how it helps. What you're trying to do is somewhat against the grain in OSGi. We assume that the world as open and that failure is never permanent. Just because the HTTP component has not started *yet* doesn't mean that it never will... if you could just install a bundle the right version of some dependency it might all spring into life! But you are building a closed world with a well-defined set of bundles. As the application assembler you know that there will never be another bundle to come along and save the day. Honestly, a launcher-based timeout may still be the best solution, e.g. "HTTP server failed to start within 30 seconds, terminating application". There may be some error conditions that you can detect without having to wait for the full timeout, but you cannot *in general* tell the difference between a component that will never be satisfied and a component that just isn't satisfied yet. On Tue, 12 Oct 2021 at 22:09, Robert Munteanu wrote: > Hello Ray, > > Thanks for your reply. I read through [1] and also the condition > service specification [3] and I am not sure how this will help me. > > I am looking for a way to say "component X did not come up and will not > come up" and at that moment halt the application. This is a bit of a > closed-world/static approach, but I am fine with it for limited > scenarios. E.g. if binding an HTTP server to port 8080 failed, I would > not like the application to linger and wait for the admin to solve it > and restart the component when done, but it should stop altogether. > > Where would you see the condition service helping here? > > Thanks, > Robert > > [3]: > https://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html > > On Tue, 2021-10-12 at 11:33 -0400, Raymond Augé wrote: > > Hello Robert, > > > > You probably want to use the DS support [1] for the **NEW** _Condition > > Service Specification_ which was added in OSGi Compendium R8 (currently > > in > > the release process). > > > > You can try this out with the current 2.2.0-RC1 of Felix SCR [2] on > > Maven > > Central. > > > > The Condition Service Specification lets you model your application > > conditions (as the name implies) using OSGi service filters. > > > > [1] > > > https://osgi.github.io/osgi/cmpn/service.component.html#service.component-satisfying.condition > > [2] > > > https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr/2.2.0-RC1/bundle > > > > On Tue, Oct 12, 2021 at 5:50 AM Robert Munteanu > > wrote: > > > > > Hi, > > > > > > I have written a couple of small OSGi apps where if a single top- > > > level > > > DS component, let's call it T, cannot start then the application > > > should > > > shut down immediately. One example are HTTP services where the HTTP > > > server port cannot be bound to. > > > > > > The causes of failures I have seen are: > > > - T activation fails > > > - the bundle providing T fails to resolve > > > - a dependency of T fails activation > > > - a dependency of T cannot be provided because the bundle providing > > > it > > > failed to staret > > > > > > I can think of several ways of approaching the problem, but none of > > > them perfect: > > > - using the Felix Health Checks[1], that seems wrong since it's a > > > polling-based approach and we very likely know when a dependency > > > fails > > > and stop immediately > > > - using the SCR introspection API [2], which is again based on > > > polling > > > - waiting for the framework to start and then looking up the service; > > > but we don't know when the SCR has 'settled' > > > > > > Are there any patterns or libraries that I can use to approach this > > > problem? > > > > > > Thanks, > > > Robert > > > > > > [1]: > > > > > > > https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html > > > [2]: > > > > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > > For additional commands, e-mail: users-h...@felix.apache.org > > > > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
Re: Enforcing mandatory components for an application
Hello Ray, Thanks for your reply. I read through [1] and also the condition service specification [3] and I am not sure how this will help me. I am looking for a way to say "component X did not come up and will not come up" and at that moment halt the application. This is a bit of a closed-world/static approach, but I am fine with it for limited scenarios. E.g. if binding an HTTP server to port 8080 failed, I would not like the application to linger and wait for the admin to solve it and restart the component when done, but it should stop altogether. Where would you see the condition service helping here? Thanks, Robert [3]: https://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html On Tue, 2021-10-12 at 11:33 -0400, Raymond Augé wrote: > Hello Robert, > > You probably want to use the DS support [1] for the **NEW** _Condition > Service Specification_ which was added in OSGi Compendium R8 (currently > in > the release process). > > You can try this out with the current 2.2.0-RC1 of Felix SCR [2] on > Maven > Central. > > The Condition Service Specification lets you model your application > conditions (as the name implies) using OSGi service filters. > > [1] > https://osgi.github.io/osgi/cmpn/service.component.html#service.component-satisfying.condition > [2] > https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr/2.2.0-RC1/bundle > > On Tue, Oct 12, 2021 at 5:50 AM Robert Munteanu > wrote: > > > Hi, > > > > I have written a couple of small OSGi apps where if a single top- > > level > > DS component, let's call it T, cannot start then the application > > should > > shut down immediately. One example are HTTP services where the HTTP > > server port cannot be bound to. > > > > The causes of failures I have seen are: > > - T activation fails > > - the bundle providing T fails to resolve > > - a dependency of T fails activation > > - a dependency of T cannot be provided because the bundle providing > > it > > failed to staret > > > > I can think of several ways of approaching the problem, but none of > > them perfect: > > - using the Felix Health Checks[1], that seems wrong since it's a > > polling-based approach and we very likely know when a dependency > > fails > > and stop immediately > > - using the SCR introspection API [2], which is again based on > > polling > > - waiting for the framework to start and then looking up the service; > > but we don't know when the SCR has 'settled' > > > > Are there any patterns or libraries that I can use to approach this > > problem? > > > > Thanks, > > Robert > > > > [1]: > > > > https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html > > [2]: > > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection > > > > - > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > > > - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Enforcing mandatory components for an application
Hello Robert, You probably want to use the DS support [1] for the **NEW** _Condition Service Specification_ which was added in OSGi Compendium R8 (currently in the release process). You can try this out with the current 2.2.0-RC1 of Felix SCR [2] on Maven Central. The Condition Service Specification lets you model your application conditions (as the name implies) using OSGi service filters. [1] https://osgi.github.io/osgi/cmpn/service.component.html#service.component-satisfying.condition [2] https://search.maven.org/artifact/org.apache.felix/org.apache.felix.scr/2.2.0-RC1/bundle On Tue, Oct 12, 2021 at 5:50 AM Robert Munteanu wrote: > Hi, > > I have written a couple of small OSGi apps where if a single top-level > DS component, let's call it T, cannot start then the application should > shut down immediately. One example are HTTP services where the HTTP > server port cannot be bound to. > > The causes of failures I have seen are: > - T activation fails > - the bundle providing T fails to resolve > - a dependency of T fails activation > - a dependency of T cannot be provided because the bundle providing it > failed to staret > > I can think of several ways of approaching the problem, but none of > them perfect: > - using the Felix Health Checks[1], that seems wrong since it's a > polling-based approach and we very likely know when a dependency fails > and stop immediately > - using the SCR introspection API [2], which is again based on polling > - waiting for the framework to start and then looking up the service; > but we don't know when the SCR has 'settled' > > Are there any patterns or libraries that I can use to approach this > problem? > > Thanks, > Robert > > [1]: > > https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html > [2]: > https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection > > - > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- *Raymond Augé* (@rotty3000) Senior Software Architect *Liferay, Inc.* (@Liferay) OSGi Fellow, Java Champion
Enforcing mandatory components for an application
Hi, I have written a couple of small OSGi apps where if a single top-level DS component, let's call it T, cannot start then the application should shut down immediately. One example are HTTP services where the HTTP server port cannot be bound to. The causes of failures I have seen are: - T activation fails - the bundle providing T fails to resolve - a dependency of T fails activation - a dependency of T cannot be provided because the bundle providing it failed to staret I can think of several ways of approaching the problem, but none of them perfect: - using the Felix Health Checks[1], that seems wrong since it's a polling-based approach and we very likely know when a dependency fails and stop immediately - using the SCR introspection API [2], which is again based on polling - waiting for the framework to start and then looking up the service; but we don't know when the SCR has 'settled' Are there any patterns or libraries that I can use to approach this problem? Thanks, Robert [1]: https://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html [2]: https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-introspection - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
