JBAS-6689 add support for activation policy metadata on Mana

[ccrouch]

Starting this thread to discuss how best to address the issues brought up in the http://jira.jboss.com/jira/browse/JBAS-6689. We can certainly discuss what we want to do in the future but I think the immediate priority is what can be done for the 5.1.CR1.

So starting off I'm not sure adding support for activation policy to the JBAS layer and the console is not practical in the current timeframe (Scott/Emanuel can you comment on the JBAS side?). Even if support was added to JBAS as Ian describes in 6689, there is currently no way for the console to indicate that value A of a property is whats currently running and value B is what will be running after a restart.

Looking at the troublesome properties...

11:11:42,488 WARN [QueueService] Clustered can only be changed when destination is stopped
11:11:42,488 WARN [QueueService] PageSize can only be changed when destination is stopped
11:11:42,488 WARN [QueueService] Cannot change the value of associated server's ObjectName after initialization!
11:11:42,488 WARN [QueueService] FullSize can only be changed when destination is stopped
11:11:42,488 WARN [QueueService] Cannot change the value of the JNDI name after initialization!
11:11:42,488 WARN [QueueService] DownCacheSize can only be changed when destination is stopped


From the above its clear that JNDI name and ObjectName should be readonly from the console perspective. In addition having looked at http://jira.jboss.com/jira/browse/JBMESSAGING-1368
and http://jira.jboss.com/jira/browse/JBMESSAGING-1235 its clear that the "Clustered" property is effectively readonly too. [In fact it worse than that since you need to make updates to the JBM_POSTOFFICE table if you want to change this value, but making something readonly is about as far as we can go right now].

That leaves PageSize, FullSize and DownCacheSize properties which require the destination to be stopped in order for the change to be successfully applied. I don't think the current situation is tenable, i.e. a user tries to change the PageSize property when the queue is running and the profile service responds back with success and when the console queries the ManagedComponent its gets the new value, which does *not* reflect what is actually running in the JBAS instance.

I think the least that can be done here is to have the profile service return back failure from the update if the values we supplied it didn't actually get applied (Is it possible for the profile service to query the underlying component to check that the suggested updates have been applied?).

Further if I'm not changing PageSize, FullSize and DownCacheSize properties, but one of the properties which can be updated fine while the destination is running, then I should clearly not get any sort of warning or failure.

Regardless of what we ultimately end up doing in the short term I think the JBM1.4 destinations provide an excellent example of the sort of configurations we're going to need to support in the future.

Cheers

[ips]

Further if I'm not changing PageSize, FullSize and DownCacheSize properties, but one of the properties which can be updated fine while the destination is running, then I should clearly not get any sort of warning or failure.

To prevent the warnings from being logged by JBM, the Profile Service could do the following when updating the underlying Queue:

if (queueService.getPageSize() != pageSizeManagedPropertyValue)
 queueService.setPageSize(pageSizeManagedPropertyValue);

rather than just:

queueService.setPageSize(pageSizeManagedPropertyValue);

[emuckenhuber]

From the above its clear that JNDI name and ObjectName should be readonly from the console perspective. In addition having looked at http://jira.jboss.com/jira/browse/JBMESSAGING-1368
and http://jira.jboss.com/jira/browse/JBMESSAGING-1235 its clear that the "Clustered" property is effectively readonly too. [In fact it worse than that since you need to make updates to the JBM_POSTOFFICE table if you want to change this value, but making something readonly is about as far as we can go right now].

Well from a profileservice standpoint those values are not readOnly, as you can change them and it will be persisted. So when you restart AS the application will have the changed JNDIName and clustered config.
But yes, i also think it could make sense to have something like the ActivationConfig to know when those changes get applied.

[ccrouch]

"emuckenhuber" wrote:
So when you restart AS the application will have the changed JNDIName and clustered config.

Well this maybe technically true, but for all practical purposes when you restart the AS you will just have a non-functional destination whose configuration has been updated. When the AS starts I would expect you to see something like the following...

java.lang.IllegalArgumentException: Queue quickstart_helloworld_Request_esb is already deployed as clustered = true so cannot redeploy as clustered=false . You must delete the destination first before redeploying

as described in https://jira.jboss.org/jira/browse/JBMESSAGING-1368

So given there is no way, without resorting to executing SQL, to actually update this 'clustered' property in a way that is going to leave a functional destination I think it should be readonly from a management perspective. Or we should work with the messaging team to provide a management interface which supports updates.

[starksm64]

So starting off I'm not sure adding support for activation policy to the JBAS layer and the console is not practical in the current timeframe (Scott/Emanuel can you comment on the JBAS side?).

Its a simple matter to add an actionvation config value on the property, but tieing it into the lifecycle of the runtime component as a pending config change that is to be applied if the component is restarted is not.

Looking at the troublesome properties...

From the above its clear that JNDI name and ObjectName should be readonly from the console perspective.

I think these are warnings coming from updates post template creation of the destination. They can't be read-only as in ignored because the template uses the same properties. These should have a activation config value of SERVER_RESTART or DEPLOYMENT_RESTART (which is another level of activation we should have).

That leaves PageSize, FullSize and DownCacheSize properties which require the destination to be stopped in order for the change to be successfully applied. I don't think the current situation is tenable, i.e. a user tries to change the PageSize property when the queue is running and the profile service responds back with success and when the console queries the ManagedComponent its gets the new value, which does *not* reflect what is actually running in the JBAS instance.

I think the least that can be done here is to have the profile service return back failure from the update if the values we supplied it didn't actually get applied (Is it possible for the profile service to query the underlying component to check that the suggested updates have been applied?).

We don't know if the component has failed to apply the change without an exception being thrown here. This does not seem to be the case as the change is ignored and the log message the only indication of failure.

Further if I'm not changing PageSize, FullSize and DownCacheSize properties, but one of the properties which can be updated fine while the destination is running, then I should clearly not get any sort of warning or failure.

There is too much of a disconnect between the component and its management object at this point to be able to ensure this behavior. If the properties are updated to be *_RESTART, then we can avoid dispatching the change to the runtime component at the profileservice level and avoid the warning it emits.

[ccrouch]

I think these are warnings coming from updates post template creation of the destination. They can't be read-only as in ignored because the template uses the same properties.

I think its fine for the ObjectName, JNDIName, Clustered properties to be read-only in the console since we support being able to set read-only properties once at creation time and then not edit them later.

We don't know if the component has failed to apply the change without an exception being thrown here. This does not seem to be the case as the change is ignored and the log message the only indication of failure.

From trying to make changes to properties such as DownCacheSize via the jmx-console its clear, as you say, that any updates that are attempted are ignored by the underlying messaging implementation, i.e. the old value remains after the update. Given that, would it not be possible for the profile service to try to make a change on a property, then requery that property to see if that change had "stuck"? If not an exception would be raised. This seems like a bit of hack to support this one particular case, (where really the managed resource itself should be throwing the exception) but I dont think its practical to expect the JBM team to change how this is implemented at this stage.

If the properties are updated to be *_RESTART, then we can avoid dispatching the change to the runtime component at the profileservice level and avoid the warning it emits.

If this is achievable quickly then it sounds like a reasonable use for the activation policies, since we're not really going to be able to use them elsewhere yet.

Thanks

[ips]

From https://jira.jboss.org/jira/browse/JBAS-6689:

The profile service update of a component is now only dispatching updates to runtime beans if the property ActivationPolicy is marked as IMMEDIATE (which is the default). I have updated the indicated jms destination properties to use a policy of DEPLOYMENT_RESTART.

It doesn't look like for the DEPLOYMENT_RESTART properties that have been updated, that the profile service applies the values the next time the topic or queue is restarted. Do you plan on implementing that piece?

[starksm64]

It should already be the case as only the update being written through to the runtime component should be skipped, not the update of the deployment attachment. I have reopened JBAS-6689 for Emanuel to verify.