Hi,
I have just checked the new GBean implementation and I do have the feeling that there are - potentially - some concurrency issues with the CollectionProxy:
If I understand correctly, this proxy implements its own Collection in order to solve some previous lifecycle limitations. This Collection returns an Iterator directly backed by an Iterator directly backed by the values of the endpoint name to proxy Map of CollectionProxy.
Unfortunately, it means that a service can not iterate safely over such an Iterator without risking a ConcurrentModificationException under some specific race conditions.
For instance, DeploymentController could iterate over its Collection of DeploymentPlanner and, at the same time, a DeploymentPlanner could be unregistered, which should cause a ConcurrentModificationException.
One could return an Iterator backed by a copy of the actual Map. However, this implementation does not work:
Indeed, this Iterator could returned a disconnected ProxyMethodInterceptor if at the same time an endpoint is unregistered. One could use the GeronimoMBeanEndpointListener feature in order to detect such a case.
However, as endpoints are inter-connected by listening to JMX notifications, it is also possible to have a connected ProxyMethodInterceptor, which reflects a JMX invocation against an already unregistered MBean.
Hence, I would like to know if the following could fix the previous issues - if there are indeed some concurrency issues:
I propose to add a Mediator, whose responsibility is to track synchronously (no notifications involved) the availability of components and contact synchronously the interested components when a GBean switch from the offline to the online state and conversaly.
Could anyone confirm or disprove my concern and approach?
Thanks, Gianny
_________________________________________________________________
Let the new MSN Premium Internet Software make the most of your high-speed experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1
