Re: Enforcing mandatory components for an application
On Wed, 2021-10-13 at 11:17 -0400, Raymond Augé wrote: > I don't think "readiness" is something you completely do inside an > app to > begin with. (assist with? sure!) > > This is why I proposed Condition Service; to model the details > required for > your application to be "ready", hoist that into an externally visible > (to > the java process) indicator (an open socket, REST endpoint, marker > file) > and THEN that can be used by any external readiness checker with > whatever > business logic. > > Apologies if my recommendation was unclear. But you're likely to have > an > orchestrator performing liveness/readiness checking anyway, why even > try to > model that entirely inside the application?!? I agree with your points for most scenarios. The one where I think the situation is not that clear-cut is when running batch/non-interactive applications which don't serve external requests. Running an HTTP service with a liveness check enforced by an orchestration platform or settings timeouts feels like a kludge when it is "obvious" that the application is not able to advance. Working with other DI frameworks was IMO simpler in this case - when a required object could not be instantiated they failed loudly and aborted the application. Again, I am aware that this is not the OSGi service model, but that doesn't mean I can't try and shoehorn it to fit my problem space. I will probably fight back, but I can try :-) Thanks, Robert - 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
On Tue, 2021-10-12 at 22:59 +0100, Neil Bartlett wrote: > 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. Right, I may end up doing something based on the following signals: - bundles failed to start -> abort - framework started -> start a timer - service registered after the framework started -> re-start the timer - after the timer fires if the mandatory components are not available - > abort I am aware that this is somewhat of an edge case and not fully mapped on the OSGi model, but I kind of like OSGi so I'm exploring different scenarios with it. Thanks, Robert > > > 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 > > > > > > > >
Re: Enforcing mandatory components for an application
I don't think "readiness" is something you completely do inside an app to begin with. (assist with? sure!) This is why I proposed Condition Service; to model the details required for your application to be "ready", hoist that into an externally visible (to the java process) indicator (an open socket, REST endpoint, marker file) and THEN that can be used by any external readiness checker with whatever business logic. Apologies if my recommendation was unclear. But you're likely to have an orchestrator performing liveness/readiness checking anyway, why even try to model that entirely inside the application?!? - Ray
Re: Enforcing mandatory components for an application
On Wed, 13 Oct 2021 at 10:06, Bertrand Delacretaz wrote: > On Tue, Oct 12, 2021 at 11:59 PM Neil Bartlett > wrote: > > ...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... > > In such cases, I think having a PERMANENT_FAILURE state for services > would be useful, and that's where you would decide to give up. > There is the FAILED_ACTIVATION state already, which would certainly be a specific error case that you can detect before waiting for a full timeout. Sadly it's not enough for the general case. If the component is waiting for a service reference then it will be UNSATISFIED, we don't know if it will become satisfied soon. Unsatisfied is not a failure state! You could dig deeper and try to work out why the referred service isn't available but this requires quite a bit of knowledge of bundle internals, e.g. "I know bundle X should provide this service but it is unresolved". > > I don't think there's such a concept for OSGI services, if I had to > implement that I would probably implement my own "failed services > registry" where services can indicate that they're hopelessly dead. > Each service can then decide on their own when that happens, probably > based on service-specific timeouts. > This would require abandoning a lot of Declarative Services and all of its advantages, instead doing all your service lookups directly in code. > > -Bertrand > > - > 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
On Tue, Oct 12, 2021 at 11:59 PM Neil Bartlett wrote: > ...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... In such cases, I think having a PERMANENT_FAILURE state for services would be useful, and that's where you would decide to give up. I don't think there's such a concept for OSGI services, if I had to implement that I would probably implement my own "failed services registry" where services can indicate that they're hopelessly dead. Each service can then decide on their own when that happens, probably based on service-specific timeouts. -Bertrand - 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
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]: > > &
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
