-
1. Re: Need to get going on a ProfileService api
One of the ideas about the profile service for jboss 5 is touch on here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73653
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelBootstrap
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossKernelDefinitions
There are the definitions of how services/beans are embedded in the MC, along with the profile that determines how the configuration is obtained:<!-- What the developer codes --> <deployment> ... <bean name="DefaultPartition" class="org.jboss.clustering.ClusterPartition"> <property name="MulticastAddress"><policy name="Clustering" item="udp.address"/></property> </bean> <!-- WHAT THE USER SEES --> <deployment> <policy name="Clustering"> // Plain value (1) <item name="udp.address">228.1.2.3</item> // Plain value with system property override (2) <item name="udp.address">{228.1.2.3:jboss.server.udp.address}</item> // Some other POJO (3) <item name="udp.address"><inject bean="MyConfig" property="udpAddress"/></item> // The repository (4) <item name="udp.address"><repository level="Server" name="jboss.server.udp.address"/></item> </policy> </deployment>
The profile service/bootstrap service provide the bean definitions for a given configuration name, along with the policy for populating the configurable elements of the beans.
In terms of management tools, the policy that is selected for loading configuration needs a mechanism for saving changes made to the beans via management toosl. -
2. Re: Need to get going on a ProfileService api
"the policy that is selected for loading configuration needs a mechanism for saving changes made to the beans via management toosl."
Does this mean changing a bean should directly update its associated policy?
If the policy looks like| <deployment> | <policy name="Clustering"> | | // Plain value (1) | <item name="udp.address">228.1.2.3</item> | | </policy> | </deployment>
then I could see us needing to persist changes made to the bean by updating its associated policy
but if its like| <deployment> | <policy name="Clustering"> | | // The repository (4) | <item name="udp.address"><repository level="Server" name="jboss.server.udp.address"/></item> | | </policy> | </deployment>
then if a change is made to the bean, does that want to replace the original setting in our policy, i.e. stop referencing the repository?
Presumably in this case the alternative to updating the bean would be to update the repository itself, e.g.repository.addMetaData( new Key("jboss.server.udp.address:SERVER"), new BasicMetaData(1, "127.0.0.1" ) )
Cheers -
3. Re: Need to get going on a ProfileService api
Yes to "Does this mean changing a bean should directly update its associated policy", but no to modifying the repository metadata for example. We have to define the policy via an API that allows for any persistent backing representation to be updated. The policy implementation should deal with how that is done. The management tools should just be asking for an update to policy controlled value without knowing the make up of the policy.
What I'm looking to get out of this discussion is an abstraction such that admin tools can be written against the profile service abstraction and be deployed in jboss5.x, 4.x, 3.x using the same api. Maybe there will have to be extended interfaces in 5.x that cannot be practially implemented in 4.x, but the basic notion of a profile service with persistent policies should be achievable. -
4. Re: Need to get going on a ProfileService api
the above looks fine to me.. Is there a point of contention?
-
5. Re: Need to get going on a ProfileService api
I don't think so. The next step is just to start fleshing out some candidate apis/interfaces. I'll throw together my thoughts this weekend. Since the JBossON team already is dealing with multi-version issues and the admin console their input on the common denominator is needed.
-
6. Re: Need to get going on a ProfileService api
"scott.stark@jboss.org" wrote:
The policy implementation should deal with how that is done. The management tools should just be asking for an update to policy controlled value without knowing the make up of the policy.
That is correct. However there does need to be some interaction with the management
tool in terms of whether the policy change creates a new version of the policy,
whether that should be committed immediately, which version they are working on
and how to rollback the change(s). -
7. Re: Need to get going on a ProfileService api
All using the repository api (either directly or via plugins).
-
8. Re: Need to get going on a ProfileService api
"adrian@jboss.org" wrote:
That is correct. However there does need to be some interaction with the management tool in terms of whether the policy change creates a new version of the policy, whether that should be committed immediately, which version they are working on and how to rollback the change(s).
All using the repository api (either directly or via plugins).
Where repository reference used here is the profile service repository of policy profiles, not the metadata repository referenced via the policy example I take it? Agreed, but I view this as seperate mode of operation in the management tool. The two modes of operation are:
1. I am "changing" the value of a property setting. What actually happens is a function of the policies in effect. This may or may not have an immeadiate impact, it may or may not be persisted. Our default implementation will most likely always persist the change. Maybe this is where you were actually referring to the metadata repository in terms of actually versioning persisted data.
2. I am editing the policy definition of a component to change how its properties are loaded. -
9. Re: Need to get going on a ProfileService api
So the stated aim above is to define the "Profile Service API" so that a single admin tool could eventually be able to administer JBoss3/4/5 through a single API.
The goal being to actually ship a Profile Service implementation for each of these different platforms.
So lets assume we come up with an API and ship an implementation in JBoss5 which allows you to make persistent updates to beans in running systems. The other goal for the Profile Service API is to allow other people to supply other implementations with a different Quality of Service, e.g. an implementation which also allows you to make updates to beans when the system is shutdown (and those updates will be picked up when the system starts).
The key thing for these other implementors is that the Profile Service API is rich enough that they don't need to develop a whole separate framework just to support their additional QoS requirements, i.e. that the Profile Service doesn't need to be worked around to achieve higher QoS. Clearly a different QoS implies a different implementation but it should be complementary to what we have as a base. -
10. Re: Need to get going on a ProfileService api
Currently I don't have a consistent vision for what Quality of Service the administration features we intend to ship with JBoss5 will have. If I've missed use cases or requirements please let me know.
Building off my example above what do you think of this following use case which resembles '1. I am "changing" the value of a property setting. ', but also goes beyond it, e.g. System is not running.
A) An administrator uses a Management Tool to update a Property of a Bean:
i) the user specifies the new Value for a Property of a Bean in the System
ii) the user indicates that the update should be made persistent and take effect
Here are the different scenarios (timelines) which could be supported concerning when the System is running, shutdown, when the new Value is specified and when that change is actually made persistent (and takes effect). (Time runs left to right, a dash indicates nothing interesting happened in that time period.)01 r--U-----s--------r---- update never made persistent 02 r--U-P---s--------r---- update made persistent when indicated 03 r--UP----s--------r---- update made persistent as soon as it is made 04 r--U-----s--P-----r---- update made persistent prior to restart, takes effect on restart 05 r--U-----s--------r---P update made persistent when indicated, a while after a restart 06 r--U-----s--------rP--- update made persistent and takes effect on restart 07 r--------s--U--P--r---- update made persistent prior to restart, takes effect on restart 08 r--------s--U-----r---- update never made persistent 09 r--------s--U-----r---P update made persistent when indicated, on restart old value used 10 r--------s--U-----rP--- update made persistent and takes effect on restart
r: start the System running
s: shutdown the System
U: specify an Update is to be made to a Property of a Bean (corresponds to i)
P: the update is made Persistent (corresponds to ii). If the System is running the change should take effect at the same time it is persisted, otherwise it should take effect when the System next starts.
Does this use case make sense? Like it? Hate it?
Note: The "taking effect" part could have been separated from the "making persistent" part, but I don't believe it really buys you anything. Since if you don't like the change after its taken effect you should be able to revert back to the previous version whenever you like (another use case), which seems more flexible than just having the option to automatically revert back to the old value on restart.
-
11. Re: Need to get going on a ProfileService api
"scott.stark@jboss.org" wrote:
1. I am "changing" the value of a property setting. SNIP
2. I am editing the policy definition of a component to change how its properties are loaded.
I understand why 1) above is a valid mode of operation for the Management tool, since it gives the user something they want, i.e. a changed property, e.g. more connections in the pool. But I'm less clear on 2). What does "editing the policy definition of a component to change how its properties are loaded" actually buy a user? What is the higher level description that shows the benefit the user actually gets from doing this? -
12. Re: Need to get going on a ProfileService api
"charles.crouch@jboss.com" wrote:
Currently I don't have a consistent vision for what Quality of Service the administration features we intend to ship with JBoss5 will have. If I've missed use cases or requirements please let me know.
I expect to have support for a profile service implementation that allows for single node editing of running/shutdown systems. Initially probably only an editor for a running system will exist. Latter I'm thinking of a configuration aspect of the installer which allows for creating/editing profiles independent of the server being running. The api will allow users to customize how the profile is loaded/stored."charles.crouch@jboss.com" wrote:
Does this use case make sense? Like it? Hate it?
It does make sense, but I don't see all these scenarios being implemented in practise. There is also the issue of batching updates together in a transaction such that they are either applied and persisted, or all rolled back if any fail.
Also, whether or not a runtime update of a property actually has any effect depends on the service. Today updating the tomcat listening port has no effect until the connectors are restarted. So a runtime update from the perspective of achieving the semantic of having the service running with that change in effect may require logic in addition to just setting the property. This is also related to the transaction/bulk update issue. Generally you don't want a service immeadiately reacting to a single property update. A service also does not in general know how to correctly deal with cycling to apply updates. For example, if the detached invoker listening port is changed from 4444 to 14444 and all active requests should succeed, some aspect(s) is going to have to handle this. This is really a service dependency issue.
A problem related to this dependency issue is that the dependency is all the defines that the 4444 port has anything to do with the ejb container. The 4444 invoker can be used by services other than the ejb container as well. I don't know how to deal with this arbitrary wiring of services together from the perspective of an admin console tool. To start with we will just provide the service to console mappings, but at some point the ejb container console should be a composition of portlets generated based on metadata exposed by profile service based on the wiring of the service dependencies. This also has to work when the server is not even running. -
13. Re: Need to get going on a ProfileService api
"scott.stark@jboss.org" wrote:
whether or not a runtime update of a property actually has any effect depends on the service
+1. The impact of this I think cannot be emphasized enough. The only role that the Profile Service can play is to make sure a change is persistent or not, i.e. that it gets applied repeatedly in the future, or it does not.
Really when we say "specify a Value for a Property of a Bean" we mean, amongst other things, that we will "call the setProperty method on the instance of the Bean the MC has a reference to passing in Value", correct?
It is obviously entirely upto the Bean with respect to how it handles its setter method being called. For instance during the Beans "lifetime" it may only call getProperty once, before we made an update, so making our update would have no effect until the Bean was re-created.
The derivative example is an "immutable" Bean, i.e no setter methods. The MC obviously supports dealing with such things, e.g.<bean name="Name1" class=com.acme.Example"> <constructor> <parameter>example string</parameter> </constructor> </bean>
I suspected that if it had no setters, then we would have no mechanism to change the properties of the Bean? But then I saw this http://docs.jboss.org/nightly/microkernel/docs/reference/en/html/joinpoint.html#d0e1053.1.2. Overridding Definition
The joinpoint allows the mechanism of dispatch to be overridden either through configuration or implementation. Examples would be not using get/set to define a property either because it is a different method name or it should use direct field access.
This sounds like something which could help, but I'm not clear on how/when this could be used.
I think eventually it would be good to document some common-sense suggestions on how Beans could play "nice" with the Profile Service, e.g. availability of setter methods, use of getter methods rather than caching a property in a local variable e.g. the following code would never pick up a runtime change made through setProperty()Object prop = getProperty(); for (i = 1; i<100; i++) { Thread.sleep(10000) doSomethingElse(prop); }
Thanks -
14. Re: Need to get going on a ProfileService api
Given the previous comment about the role of the Profile Service, I think that it really impacts some of the use cases I described earlier. In reality I think that from the perspective of the Profile Service there is essentially no distinction between steps U(update) and P(persist). So the 10 scenarios really just boil down to two
01 r--C-----s--------r---- change made persistent and applied immediately 02 r--------s--C-----r---- change made persistent prior to restart, it will be applied on restart
C=The update is made Persistent. If the System is running the change should be applied at the same time it is persisted, otherwise it should be applied when the System next starts up.
It is really the job of the "Management Tool" to batch together multiple changes and push them through to the Profile Service in one go, e.g. the user can click around making changes, and when they are happy say "commit". The Profile Service will then take the changes, persist them, and apply them to the appropriate Beans if the MC the Beans are associated with is running. Alternatively the "Management Tool" could pass through each change made by the user immediately to the Profile Service.
As was mentioned above, but it bears repeating, the impact of any change made to a running Bean, will be entirely dependent upon how the Bean itself is implemented. I guess this is similar to what we have today with changes applied via JMX, right?