[jboss-jira] [JBoss JIRA] Updated: (JBAS-6689) add support for activation policy metadata on ManagedProperties

[ https://jira.jboss.org/jira/browse/JBAS-6689?page=com.atlassian.jira.plug... ] Charles Crouch updated JBAS-6689: --------------------------------- Description: Whenever I call updateComponent() for a Queue or Topic component, the following messages are printed to the log: 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 whether or not I've actually changed these properties. If I indeed have changed these properties and the topic or queue is not currently in the Stopped state, their values will be updated on the ManagedComponent but they will *not* be updated on the underlying topic or queue, even after stopping then starting the topic or (I confirmed this using jmx-console). So the ManagedComponent properties and up being inaccurate and the user of the profile service management API has no idea. Here's one idea on how to address this: Add an 'activationPolicy' enum field to the ManagedProperty interface. use this to determine what conditions if any are required to update the property, e.g.: enum ActivationPolicy { IMMEDIATE, COMPONENT_RESTART SERVER_RESTART } Then the profile service would have to refresh the property values on the underlying topic or queue at the appropriate times depending on the activation policy. For example, if the activation policy was COMPONENT_RESTART (as it would be for Clustered, PageSize, FullSize, and DownCacheSize props), then every time the underlying topic or queue was started, the profile service would call the setters for those properties. Also introduce either an 'active' boolean field and/or a 'pendingValue' MetaValue field on ManagedProperty to indicate that a new value has been specified but has not yet been activated (i.e. activation is pending a restart of either the component or the whole server). This would allow the client to know whether a new value has been set but is pending a restart. Of course, it would also be nice if JBoss Messaging was updated so that these properties can be updated while the topic or queue is in the Started state. was: Whenever I call updateComponent() for a Queue or Topic component, the following messages are printed to the log: 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 whether or not I've actually changed these properties. If I indeed have changed these properties and the topic or queue is not currently in the Stopped state, their values will be updated on the ManagedComponent but they will *not* be updated on the underlying topic or queue, even after stopping then starting the topic or (I confirmed this using jmx-console). So the ManagedComponent properties and up being inaccurate and the user of the profile service management API has no idea. Here's one idea on how to address this: Add an 'activationPolicy' enum field to the ManagedProperty interface. use this to determine what conditions if any are required to update the property, e.g.: enum ActivationPolicy { IMMEDIATE, COMPONENT_RESTART SERVER_RESTART } Then the profile service would have to refresh the property values on the underlying topic or queue at the appropriate times depending on the activation policy. For example, if the activation policy was COMPONENT_RESTART (as it would be for Clustered, PageSize, FullSize, and DownCacheSize props), then every time the underlying topic or queue was started, the profile service would call the setters for those properties. Also introduce either an 'active' boolean field and/or a 'pendingValue' MetaValue field on ManagedProperty to indicate that a new value has been specified but has not yet been activated (i.e. activation is pending a restart of either the component or the whole server). This would allow the client to know whether a new value has been set but is pending a restart. Of course, it would also be nice if JBoss Messaging was updated so that these properties can be updated while the topic or queue is in the Started state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira