-
1. Re: Colocation and local optimization - JBAS-57
starksm64 Dec 17, 2004 3:28 PM (in response to adrian.brock)If there is going to be a check for an entry in the collocation map, then effectively the GUID becomes irrelevant. Other cleanup than could be done is removal of the unused remoteInvoker instance variable.
-
2. Re: Colocation and local optimization - JBAS-57
adrian.brock Dec 17, 2004 3:39 PM (in response to adrian.brock)Only if the non HA invoker deployment also maintained the colocation info.
-
3. Re: Colocation and local optimization - JBAS-57
starksm64 Dec 17, 2004 3:52 PM (in response to adrian.brock)Ok, I thought you were indicating that the base InvokerInterceptor was going to be checking for existence in the collocation map which would require the non-ha proxy factories to maintain this info. Its a less intrusive change if the GUID continues to be a marker for non-ha collocation and only ha proxy factories maintain the explicit collocation mapping. This would require one new HAInvokerInterceptor as far as I can see.
-
4. Re: Colocation and local optimization - JBAS-57
adrian.brock Dec 20, 2004 4:32 PM (in response to adrian.brock)Actually implementing this, there is no need for a Colocation object.
This object already exists in the form of org.jboss.system.Registry
(it should needs adding to the client jar where it will be empty on a client).
Also, looking at org.jboss.proxy.ejb.ProxyFactory
This looks wrong. It creates and binds the proxy in start(), but doesn't remove it
until destroy(). I can see circumstances where it or a subclass/dependency
needs some service that is no longer there.
Anything in done start() should be reversed in stop()! -
5. Re: Colocation and local optimization - JBAS-57
starksm64 Dec 22, 2004 1:25 AM (in response to adrian.brock)So are you ready to pull the commit action on this?