="galder.zamarreno(a)jboss.com" wrote : In the case of clustered invokers, I think disconnecting the current client before creating/connecting a new one would make sense as otherwise you're leaking clients (this probably needs a jira, FAO Brian thoughts?)
There are really 2 cases here:
a) switching to a new Client due to failover. In that case the InvokerLocator is removed from the set of targets and disconnecting seems like an obvious right thing to do.
b) switching to a new Client due to normal load balancing (e.g. RoundRobin) with an expectation that we may end up creating another Client later for the same InvokerLocator. That, if I understand the code correctly, will end up using the already-existing ClientInvoker
The b) case is more tricky. If in the non-clustered case we end up deciding to call disconnect after every invocation, then the clustered case should as well. If non-clustered doesn't disconnect on every invocation, we can revisit. Sounds like disconnecting is necessary though, with the "invokerDestructionDelay" as the workaround to cut down on the waste associated with that.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222123#4222123
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222123
"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.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222083#4222083
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222083
"emuckenhuber" wrote : Although i still think doing managedProperty.setValue(null); should not replace it with a default value.
Ok, so what should we use?
In use case 1) we need to specify "I want to use the default" and in use case 3) we need to specify "I want to use null/nothing/blank".
So maybe for use case 1) we have
and for 3) we have
or alternatively (but this seems even more of a hack)
Because the template will specify an actual value for the default, e.g. 20, its of no use to us when the user wants to persist the "default value" since the "default value" may change over time. This is exactly analogous to the case of defining the resources configuration via xml. If you had a template with every xml element specified in there and persisted that, it would be a different value than if you just included the xml elements you wanted to specify, letting the server set the other ones as it saw fit.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222081#4222081
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222081