9:23 p.m.
Hi
A general question on which services we can assume are available in a
sever configuration and which we cannot.
When installing services, we often need to add in service dependencies.
If a dependency is marked as required and it does not exist, the service
will not start correctly. So, when setting up a service and its
dependencies, if possible, I would like to know which dependencies are
guaranteed to be available and which I may need to optionally check for.
The OPTIONAL flag for dependencies was meant to address this but it now
deprecated as it doesn't work so well when you are unlucky enough to
have your dependency start after your dependent service.
The web profile is intended to be a slimmed down version of the full
profile, and in the case of the EJB subsystem, the spec says that it
need not implement certain EJB feature subsets, among which are
asynchronous method invocations, timer service and remote invocations.
However, our web profile EJB subsystem includes all of these. It is
conceivable that an admin would want to create a slimmed down version of
the EJB subsystem and remove some of these services. All three of these
can be easily removed by deleting configuration elements.
What to do here?
- assume that all subsystems and services defined in the shipped web
profile will be present and no dependency checking is required?
- assume that a certain minimal subset of subsystems and services
defined in the shipped web profile will be present and that an admin may
"turn off" some services, for example the features not part of EJB Lite
and so some form of dependency checking is required? And which services
can we assume are present?
In the case of the EJB subsystem, I would expect that dependencies like
the Remoting system endpoint can be assumed to be present, but the
optional features above and beyond EJB Lite may not be. But this is all
pretty much ad hoc.
Any thoughts?
9:43 p.m.
I think everyone is probably familiar with the danger of optional
dependencies, and the reason they've been deprecated, but I'll reiterate
it just to make sure nobody has lingering questions about it.
When a service A has an optional dependency on service B, whether or not
that dependency is filled depends not on the simple presence of B, but
also on whether B is installed before A. This is a necessary
consequence of our algorithm, which in turn is what gives us the
performance that we have (which is tied directly to the algorithmic
complexity of the MSC service installation process).
So given that we have to externally control the order of installation,
such that we know B will come before A, there's actually no reason to
even have optional dependencies, since if you already know that B is
missing, you can simply opt to exclude the dependency in the first
place. Optional dependencies merely become a minor convenience, saving
you from having to do one "if" statement, at this point. Yet their mere
presence has resulted in 100% misuse.
So, there is a different preferred strategy. Here's how it is supposed
to work, conceptually.
Imagine I have a subsystem X, which optionally consumes subsystem Y.
The correct time to detect the presence or absence of Y is related to
the lifecycle of the management model data. When X is added to the
model, and that transaction completes, we know that we have X with no Y.
All the services produced on behalf of X would then statically be
aware of this information, and would elide any dependency on Y.
One obvious question with this scheme is: what happens when Y is added,
after the fact? The answer to this question depends on X. X must, in
the same transaction, detect the addition of Y and decide what to do.
Several actions are possible, depending on how X works and how its
dependency on Y works. Options include automatically removing and
rebuilding services with the new dependency, retroactively modifying X
in some way so as to update it without stopping it, or simply ignoring
the addition of Y, using a "reload-required" or similar state to
indicate to the user that the running system is inconsistent with the
stored model.
I know we don't really have any APIs to directly facilitate these
concepts, but this is a part of what the management SPI redesign is all
about. In the new model, one will be able to express optional
dependencies at a resource level rather than a service level.
On 06/03/2014 02:23 PM, Richard Achmatowicz wrote:
Hi
A general question on which services we can assume are available in a
sever configuration and which we cannot.
When installing services, we often need to add in service dependencies.
If a dependency is marked as required and it does not exist, the service
will not start correctly. So, when setting up a service and its
dependencies, if possible, I would like to know which dependencies are
guaranteed to be available and which I may need to optionally check for.
The OPTIONAL flag for dependencies was meant to address this but it now
deprecated as it doesn't work so well when you are unlucky enough to
have your dependency start after your dependent service.
The web profile is intended to be a slimmed down version of the full
profile, and in the case of the EJB subsystem, the spec says that it
need not implement certain EJB feature subsets, among which are
asynchronous method invocations, timer service and remote invocations.
However, our web profile EJB subsystem includes all of these. It is
conceivable that an admin would want to create a slimmed down version of
the EJB subsystem and remove some of these services. All three of these
can be easily removed by deleting configuration elements.
What to do here?
- assume that all subsystems and services defined in the shipped web
profile will be present and no dependency checking is required?
- assume that a certain minimal subset of subsystems and services
defined in the shipped web profile will be present and that an admin may
"turn off" some services, for example the features not part of EJB Lite
and so some form of dependency checking is required? And which services
can we assume are present?
In the case of the EJB subsystem, I would expect that dependencies like
the Remoting system endpoint can be assumed to be present, but the
optional features above and beyond EJB Lite may not be. But this is all
pretty much ad hoc.
Any thoughts?
--
- DML
9:51 p.m.
Yes just to be clear:
OPTIONAL SHOULD NEVER BE USED FOR CROSS SUBSYSTEM DEPENDENCIES!
It’s very hard to use OPTIONAL correctly, so avoid it like the plague (this is why it’s
deprecated).
There are other strategies that work in many cases. For example you can use PASSIVE
services.
However, the thing we are really missing is cross-subsystem negotiation (capabilities).
This is actually a trivial thing to implement, Kabir had a prototype at one point, and we
should introduce it in 9.
The classic problem example is jacorb and tx. They require circular configuration.
The general notion is that you have a set of detyped flags that convey various
configuration relevant info like:
tx subsystem: SUPPORTS_TRANSACTIONS
SUPPORTS_JTS
corba subsytem: SUPPORTS_CORBA
These can be assembled in quickly after parsing but before services are assembled. Then
subsystem service assembly can begin in parallel, as today. So for example, corba can see
that JTS is enabled, and install the proper interceptors. TX can see Corba and create the
proper service dependency.
On Jun 3, 2014, at 2:23 PM, Richard Achmatowicz <rachmato(a)redhat.com> wrote:
Hi
A general question on which services we can assume are available in a
sever configuration and which we cannot.
When installing services, we often need to add in service dependencies.
If a dependency is marked as required and it does not exist, the service
will not start correctly. So, when setting up a service and its
dependencies, if possible, I would like to know which dependencies are
guaranteed to be available and which I may need to optionally check for.
The OPTIONAL flag for dependencies was meant to address this but it now
deprecated as it doesn't work so well when you are unlucky enough to
have your dependency start after your dependent service.
The web profile is intended to be a slimmed down version of the full
profile, and in the case of the EJB subsystem, the spec says that it
need not implement certain EJB feature subsets, among which are
asynchronous method invocations, timer service and remote invocations.
However, our web profile EJB subsystem includes all of these. It is
conceivable that an admin would want to create a slimmed down version of
the EJB subsystem and remove some of these services. All three of these
can be easily removed by deleting configuration elements.
What to do here?
- assume that all subsystems and services defined in the shipped web
profile will be present and no dependency checking is required?
- assume that a certain minimal subset of subsystems and services
defined in the shipped web profile will be present and that an admin may
"turn off" some services, for example the features not part of EJB Lite
and so some form of dependency checking is required? And which services
can we assume are present?
In the case of the EJB subsystem, I would expect that dependencies like
the Remoting system endpoint can be assumed to be present, but the
optional features above and beyond EJB Lite may not be. But this is all
pretty much ad hoc.
Any thoughts?
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10:01 p.m.
On 6/3/14, 2:43 PM, David M. Lloyd wrote:
I think everyone is probably familiar with the danger of optional
dependencies, and the reason they've been deprecated, but I'll reiterate
it just to make sure nobody has lingering questions about it.
When a service A has an optional dependency on service B, whether or not
that dependency is filled depends not on the simple presence of B, but
also on whether B is installed before A. This is a necessary
consequence of our algorithm, which in turn is what gives us the
performance that we have (which is tied directly to the algorithmic
complexity of the MSC service installation process).
So given that we have to externally control the order of installation,
such that we know B will come before A, there's actually no reason to
even have optional dependencies, since if you already know that B is
missing, you can simply opt to exclude the dependency in the first
place. Optional dependencies merely become a minor convenience, saving
you from having to do one "if" statement, at this point.
A bit more than that though, as it's really
if (readModelFromOtherSubystemToSeeIfFooIsSet(...))
Yet their mere
presence has resulted in 100% misuse.
So, there is a different preferred strategy. Here's how it is supposed
to work, conceptually.
Imagine I have a subsystem X, which optionally consumes subsystem Y.
The correct time to detect the presence or absence of Y is related to
the lifecycle of the management model data. When X is added to the
model, and that transaction completes, we know that we have X with no Y.
This should be done in the OperationStepHandler that adds the service,
in Stage.RUNTIME. In Stage.RUNTIME you know that all changes that will
be made to the model during the current transaction are present, even
during boot when we do a lot of work concurrently.
All the services produced on behalf of X would then statically be
aware of this information, and would elide any dependency on Y.
One obvious question with this scheme is: what happens when Y is added,
after the fact? The answer to this question depends on X. X must, in
the same transaction, detect the addition of Y and decide what to do.
Several actions are possible, depending on how X works and how its
dependency on Y works. Options include automatically removing and
rebuilding services with the new dependency, retroactively modifying X
in some way so as to update it without stopping it, or simply ignoring
the addition of Y, using a "reload-required" or similar state to
indicate to the user that the running system is inconsistent with the
stored model.
I know we don't really have any APIs to directly facilitate these
concepts, but this is a part of what the management SPI redesign is all
about. In the new model, one will be able to express optional
dependencies at a resource level rather than a service level.
Jeff Mesnil -- I'm curious how useful the internal notification stuff
you've added in the existing code will be for this use case. Prior to
that there was nothing at all that X could count on to become aware of
the later addition Y.
On 06/03/2014 02:23 PM, Richard Achmatowicz wrote:
> Hi
>
> A general question on which services we can assume are available in a
> sever configuration and which we cannot.
>
> When installing services, we often need to add in service dependencies.
> If a dependency is marked as required and it does not exist, the service
> will not start correctly. So, when setting up a service and its
> dependencies, if possible, I would like to know which dependencies are
> guaranteed to be available and which I may need to optionally check for.
> The OPTIONAL flag for dependencies was meant to address this but it now
> deprecated as it doesn't work so well when you are unlucky enough to
> have your dependency start after your dependent service.
>
> The web profile is intended to be a slimmed down version of the full
> profile, and in the case of the EJB subsystem, the spec says that it
> need not implement certain EJB feature subsets, among which are
> asynchronous method invocations, timer service and remote invocations.
> However, our web profile EJB subsystem includes all of these. It is
> conceivable that an admin would want to create a slimmed down version of
> the EJB subsystem and remove some of these services. All three of these
> can be easily removed by deleting configuration elements.
>
> What to do here?
> - assume that all subsystems and services defined in the shipped web
> profile will be present and no dependency checking is required?
> - assume that a certain minimal subset of subsystems and services
> defined in the shipped web profile will be present and that an admin may
> "turn off" some services, for example the features not part of EJB Lite
> and so some form of dependency checking is required? And which services
> can we assume are present?
>
> In the case of the EJB subsystem, I would expect that dependencies like
> the Remoting system endpoint can be assumed to be present, but the
> optional features above and beyond EJB Lite may not be. But this is all
> pretty much ad hoc.
>
> Any thoughts?
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:06 p.m.
On 6/3/14, 2:51 PM, Jason Greene wrote:
Yes just to be clear:
OPTIONAL SHOULD NEVER BE USED FOR CROSS SUBSYSTEM DEPENDENCIES!
It’s very hard to use OPTIONAL correctly, so avoid it like the plague (this is why it’s
deprecated).
There are other strategies that work in many cases. For example you can use PASSIVE
services.
However, the thing we are really missing is cross-subsystem negotiation (capabilities).
This is actually a trivial thing to implement, Kabir had a prototype at one point, and we
should introduce it in 9.
The classic problem example is jacorb and tx. They require circular configuration.
The general notion is that you have a set of detyped flags that convey various
configuration relevant info like:
tx subsystem: SUPPORTS_TRANSACTIONS
SUPPORTS_JTS
corba subsytem: SUPPORTS_CORBA
These can be assembled in quickly after parsing but before services are assembled. Then
subsystem service assembly can begin in parallel, as today. So for example, corba can see
that JTS is enabled, and install the proper interceptors. TX can see Corba and create the
proper service dependency.
To expand a bit on what you said, the way parallel boot works is all the
MODEL stage stuff is done in parallel. All of it completes before the
RUNTIME stuff starts. So this data can (and logically should) be
populated during the MODEL stage. The service assembly work that needs
it is done in RUNTIME, and can count the data being available.
On Jun 3, 2014, at 2:23 PM, Richard Achmatowicz
<rachmato(a)redhat.com> wrote:
> Hi
>
> A general question on which services we can assume are available in a
> sever configuration and which we cannot.
>
> When installing services, we often need to add in service dependencies.
> If a dependency is marked as required and it does not exist, the service
> will not start correctly. So, when setting up a service and its
> dependencies, if possible, I would like to know which dependencies are
> guaranteed to be available and which I may need to optionally check for.
> The OPTIONAL flag for dependencies was meant to address this but it now
> deprecated as it doesn't work so well when you are unlucky enough to
> have your dependency start after your dependent service.
>
> The web profile is intended to be a slimmed down version of the full
> profile, and in the case of the EJB subsystem, the spec says that it
> need not implement certain EJB feature subsets, among which are
> asynchronous method invocations, timer service and remote invocations.
> However, our web profile EJB subsystem includes all of these. It is
> conceivable that an admin would want to create a slimmed down version of
> the EJB subsystem and remove some of these services. All three of these
> can be easily removed by deleting configuration elements.
>
> What to do here?
> - assume that all subsystems and services defined in the shipped web
> profile will be present and no dependency checking is required?
> - assume that a certain minimal subset of subsystems and services
> defined in the shipped web profile will be present and that an admin may
> "turn off" some services, for example the features not part of EJB Lite
> and so some form of dependency checking is required? And which services
> can we assume are present?
>
> In the case of the EJB subsystem, I would expect that dependencies like
> the Remoting system endpoint can be assumed to be present, but the
> optional features above and beyond EJB Lite may not be. But this is all
> pretty much ad hoc.
>
> Any thoughts?
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
10:15 p.m.
On 6/3/14, 2:51 PM, Jason Greene wrote:
Yes just to be clear:
OPTIONAL SHOULD NEVER BE USED FOR CROSS SUBSYSTEM DEPENDENCIES!
It’s very hard to use OPTIONAL correctly, so avoid it like the plague (this is why it’s
deprecated).
There are other strategies that work in many cases. For example you can use PASSIVE
services.
However, the thing we are really missing is cross-subsystem negotiation (capabilities).
This is actually a trivial thing to implement, Kabir had a prototype at one point, and we
should introduce it in 9.
The classic problem example is jacorb and tx. They require circular configuration.
The general notion is that you have a set of detyped flags that convey various
configuration relevant info like:
tx subsystem: SUPPORTS_TRANSACTIONS
SUPPORTS_JTS
corba subsytem: SUPPORTS_CORBA
These can be assembled in quickly after parsing but before services are assembled. Then
subsystem service assembly can begin in parallel, as today. So for example, corba can see
that JTS is enabled, and install the proper interceptors. TX can see Corba and create the
proper service dependency.
Perhaps we should do something more sophisticated than a simple string.
The string is fine for providing information that something is present,
but I don't like the way things work once that info is present. Too much
stuff where subsystem X is depending on details of subsystem Y to wire
things up. I'd like to see this stuff converted into proper APIs exposed
by each subsystem.
If tx and corba associated an impl of a relevant API with those
SUPPORTS... keys, that's more useful.
On Jun 3, 2014, at 2:23 PM, Richard Achmatowicz
<rachmato(a)redhat.com> wrote:
> Hi
>
> A general question on which services we can assume are available in a
> sever configuration and which we cannot.
>
> When installing services, we often need to add in service dependencies.
> If a dependency is marked as required and it does not exist, the service
> will not start correctly. So, when setting up a service and its
> dependencies, if possible, I would like to know which dependencies are
> guaranteed to be available and which I may need to optionally check for.
> The OPTIONAL flag for dependencies was meant to address this but it now
> deprecated as it doesn't work so well when you are unlucky enough to
> have your dependency start after your dependent service.
>
> The web profile is intended to be a slimmed down version of the full
> profile, and in the case of the EJB subsystem, the spec says that it
> need not implement certain EJB feature subsets, among which are
> asynchronous method invocations, timer service and remote invocations.
> However, our web profile EJB subsystem includes all of these. It is
> conceivable that an admin would want to create a slimmed down version of
> the EJB subsystem and remove some of these services. All three of these
> can be easily removed by deleting configuration elements.
>
> What to do here?
> - assume that all subsystems and services defined in the shipped web
> profile will be present and no dependency checking is required?
> - assume that a certain minimal subset of subsystems and services
> defined in the shipped web profile will be present and that an admin may
> "turn off" some services, for example the features not part of EJB Lite
> and so some form of dependency checking is required? And which services
> can we assume are present?
>
> In the case of the EJB subsystem, I would expect that dependencies like
> the Remoting system endpoint can be assumed to be present, but the
> optional features above and beyond EJB Lite may not be. But this is all
> pretty much ad hoc.
>
> Any thoughts?
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
2:39 p.m.
On 3 Jun 2014, at 22:01, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
> One obvious question with this scheme is: what happens when Y is
added,
> after the fact? The answer to this question depends on X. X must, in
> the same transaction, detect the addition of Y and decide what to do.
> Several actions are possible, depending on how X works and how its
> dependency on Y works. Options include automatically removing and
> rebuilding services with the new dependency, retroactively modifying X
> in some way so as to update it without stopping it, or simply ignoring
> the addition of Y, using a "reload-required" or similar state to
> indicate to the user that the running system is inconsistent with the
> stored model.
>
> I know we don't really have any APIs to directly facilitate these
> concepts, but this is a part of what the management SPI redesign is all
> about. In the new model, one will be able to express optional
> dependencies at a resource level rather than a service level.
Jeff Mesnil -- I'm curious how useful the internal notification stuff
you've added in the existing code will be for this use case. Prior to
that there was nothing at all that X could count on to become aware of
the later addition Y.
Notifications would work a the resource level.
Notifications for added/removed resources are emitted[1] at the end of the step that
adds/removes a resource in the MODEL stage.
So a resource X could register a notification listener on the resource Y's path
address.
When the Y resource is added, the listener will be notified and X would be notified of the
addition of Y and act accordingly.
If I understand the example correctly, when a resource X is added, it could check whether
the resource Y is already there and use it if that’s the case.
Otherwise, it would register a notification listener and postpone this execution until the
resource Y is added (with no guarantee it ever will).
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-266_WFLY-3159_notificatio...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
3:57 p.m.
Another issue would be if service A has an optional dependency (as described, not using
the actual optional dependency) on service B.
We’re describing allowing A to react if B shows up. Should we also react if B goes away?
On 4 Jun 2014, at 13:39, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
On 3 Jun 2014, at 22:01, Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
>> One obvious question with this scheme is: what happens when Y is added,
>> after the fact? The answer to this question depends on X. X must, in
>> the same transaction, detect the addition of Y and decide what to do.
>> Several actions are possible, depending on how X works and how its
>> dependency on Y works. Options include automatically removing and
>> rebuilding services with the new dependency, retroactively modifying X
>> in some way so as to update it without stopping it, or simply ignoring
>> the addition of Y, using a "reload-required" or similar state to
>> indicate to the user that the running system is inconsistent with the
>> stored model.
>>
>> I know we don't really have any APIs to directly facilitate these
>> concepts, but this is a part of what the management SPI redesign is all
>> about. In the new model, one will be able to express optional
>> dependencies at a resource level rather than a service level.
>
> Jeff Mesnil -- I'm curious how useful the internal notification stuff
> you've added in the existing code will be for this use case. Prior to
> that there was nothing at all that X could count on to become aware of
> the later addition Y.
Notifications would work a the resource level.
Notifications for added/removed resources are emitted[1] at the end of the step that
adds/removes a resource in the MODEL stage.
So a resource X could register a notification listener on the resource Y's path
address.
When the Y resource is added, the listener will be notified and X would be notified of
the addition of Y and act accordingly.
If I understand the example correctly, when a resource X is added, it could check whether
the resource Y is already there and use it if that’s the case.
Otherwise, it would register a notification listener and postpone this execution until
the resource Y is added (with no guarantee it ever will).
[1]
https://github.com/jmesnil/wildfly/commits/WFLY-266_WFLY-3159_notificatio...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:09 p.m.
On 4 Jun 2014, at 15:57, Kabir Khan <kabir.khan(a)jboss.com> wrote:
Another issue would be if service A has an optional dependency (as
described, not using the actual optional dependency) on service B.
We’re describing allowing A to react if B shows up. Should we also react if B goes away?
That is no different that the current case. A would have to react if B goes away whether B
is added there before A or after (by using hypothetical notification listener).
From my experience on the messaging subsystem, I have a resource A
that is to know whether another subsystem resource B exist before adding a dependency on
its service (typical example is the
messaging’s http-connector that depends on the
existence of the http-upgrade handler of the undertow subsystem)
If Y is removed, its corresponding service will be stopped and the service that I have
started when A was added will be transitively stopped.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
3615
days inactive
3616
days old
8 comments
6 participants
participants (6)
-
Brian Stansberry -
David M. Lloyd -
Jason Greene -
Jeff Mesnil -
Kabir Khan -
Richard Achmatowicz