[back from vacation]
Where does this stand? AMX has no multithreading constraints.
The AMX ProxyFactory.java class uses two HashMaps:
- one indirectly via an internal ProxyCache object (ProxyCache is an
implementation detail). ProxyCache uses a synchronized HashMap as
part of its implementation (Collections.synchronizedMap).
- a static INSTANCES HashMap, which is also a synchronized HashMap
(Collections.synchronizedMap).
The possibility of a bug exists of course, but I need a stack crawl
showing the involvement of the ProxyFactory to understand what is
going on; nothing in the stack crawl is of any use in that regard.
BTW previous comments about "it being pretty obvious that it's in
AMX" are incorrect--the only AMX involvement that I see in the
example is the invocation by an AMX dynamic proxy of some request via
the usual invoke() mechanism on the JMXConnector. There is no other
AMX involvement that I see, and I am certain that this portion of the
stack crawl is quite irrelevant.
Lloyd
On Sep 20, 2006, at 4:53 AM, Tim Quinn wrote:
> I created a small test program that creates a single JSR-88
> deployment manager and attempts to use it from multiple threads
> concurrently. While the JSR-88 code itself is concurrently
> reusable, depending on how long a delay I introduced between the
> starts of the threads I was able to trigger at least two different
> errors at or below the AMX layer, including a very tight apparently
> infinite loop, a ConcurrentModificationException of a HashMap from
> inside com.sun.appserv.management.client.ProxyFactory, or an error
> very similar to the one Vince noted.
>
> It looks as if attempts to reuse the AMX infrastructure for
> multiple concurrent calls will fail, and the JSR-88 implementation
> in GlassFish reuses the AMX root proxy. I don't know all the
> details of how NetBeans uses the JSR-88 interface but if it can do
> so from multiple threads in response to user actions (Vince
> described pressing F6 repeatedly as a way of reproducing the
> problem he initially wrote about) then that might trigger multiple
> concurrent invocations into the JSR-88 implementation and,
> therefore, AMX.
>
> Is this a documented restriction of AMX or a lower layer of the
> infrastructure?
> - Tim
> vince kraemer wrote:
>> Jerome Dochez wrote:
>>> From the stack trace, it is pretty obvious it is an AMX problem,
>>> most likely residing in the JMX HTTP connector. did you talk to
>>> Lloyd about this ?
>>
>> I haven't yet. I don't know whether Tim has asked Lloyd about
>> this yet.
>>
>> I will ping him directly.
>>
>> vbk
>>>
>>> Jerome
>>>
>>> vince kraemer wrote:
>>>> I am using GF V1 U1 Build 11.
>>>>
>>>> I have got an intermittent problem when I use JSR-88 APIs to do
>>>> deployment on multi-processor boxes.
>>>>
>>>> Here is one of the stack traces that I have seen...
>>>>
>>>> javax.enterprise.deploy.spi.exceptions.TargetException: Error
>>>> getting required modules
>>>> at
>>>> com.sun.enterprise.deployapi.SunDeploymentManager.getModules
>>>> (SunDeploymentManager.java:380)
>>>> at
>>>> com.sun.enterprise.deployapi.SunDeploymentManager.getAvailableModul
>>>> es(SunDeploymentManager.java:315)
>>>> at
>>>> org.netbeans.modules.j2ee.sun.ide.dm.SunDeploymentManager.getAvaila
>>>> bleModules(SunDeploymentManager.java:506)
>>>> at
>>>> org.netbeans.modules.j2ee.deployment.impl.TargetServer.getAvailable
>>>> TMIDsMap(TargetServer.java:298)
>>>> at
>>>> org.netbeans.modules.j2ee.deployment.impl.TargetServer.processLastT
>>>> argetModules(TargetServer.java:334)
>>>> at
>>>> org.netbeans.modules.j2ee.deployment.impl.TargetServer.init
>>>> (TargetServer.java:108)
>>>> at
>>>> org.netbeans.modules.j2ee.deployment.impl.TargetServer.deploy
>>>> (TargetServer.java:445)
>>>> [catch] at
>>>> org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.depl
>>>> oy(Deployment.java:106)
>>>> at org.netbeans.modules.j2ee.ant.Deploy.execute
>>>> (Deploy.java:82)
>>>> at org.apache.tools.ant.UnknownElement.execute
>>>> (UnknownElement.java:275)
>>>> at org.apache.tools.ant.Task.perform(Task.java:364)
>>>> at org.apache.tools.ant.Target.execute(Target.java:341)
>>>> at org.apache.tools.ant.Target.performTasks(Target.java:369)
>>>> at org.apache.tools.ant.Project.executeSortedTargets
>>>> (Project.java:1216)
>>>> at org.apache.tools.ant.Project.executeTarget
>>>> (Project.java:1185)
>>>> at
>>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets
>>>> (DefaultExecutor.java:40)
>>>> at org.apache.tools.ant.Project.executeTargets
>>>> (Project.java:1068)
>>>> at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run
>>>> (BridgeImpl.java:240)
>>>> at org.apache.tools.ant.module.run.TargetExecutor.run
>>>> (TargetExecutor.java:293)
>>>> at org.netbeans.core.execution.RunClassThread.run
>>>> (RunClassThread.java:131)
>>>> Caused by: java.lang.reflect.UndeclaredThrowableException
>>>> at $Proxy14.waitAMXReady(Unknown Source)
>>>> at
>>>> com.sun.enterprise.deployapi.SunDeploymentManager.getRootProxy
>>>> (SunDeploymentManager.java:1627)
>>>> at
>>>> com.sun.enterprise.deployapi.SunDeploymentManager.getModulesOnATarg
>>>> et(SunDeploymentManager.java:397)
>>>> at
>>>> com.sun.enterprise.deployapi.SunDeploymentManager.getModules
>>>> (SunDeploymentManager.java:366)
>>>> ... 19 more
>>>> Caused by: java.io.IOException
>>>> at java.io.ObjectInputStream$PeekInputStream.readFully
>>>> (ObjectInputStream.java:2232)
>>>> at java.io.ObjectInputStream
>>>> $BlockDataInputStream.readShort(ObjectInputStream.java:2698)
>>>> at java.io.ObjectInputStream.readStreamHeader
>>>> (ObjectInputStream.java:750)
>>>> at java.io.ObjectInputStream.<init>
>>>> (ObjectInputStream.java:268)
>>>> at
>>>> com.sun.enterprise.admin.jmx.remote.comm.ServletConnection.receive(
>>>> ServletConnection.java:107)
>>>> at
>>>> com.sun.enterprise.admin.jmx.remote.comm.MBeanServerMessageConducto
>>>> r.invoke(MBeanServerMessageConductor.java:62)
>>>> at
>>>> com.sun.enterprise.admin.jmx.remote.internal.RemoteMBeanServerConne
>>>> ction.invoke(RemoteMBeanServerConnection.java:408)
>>>> at javax.management.MBeanServerInvocationHandler.invoke
>>>> (MBeanServerInvocationHandler.java:201)
>>>> at
>>>> com.sun.appserv.management.util.jmx.MBeanProxyHandler.invoke
>>>> (MBeanProxyHandler.java:647)
>>>> at
>>>> com.sun.appserv.management.client.handler.AMXProxyHandler._invoke
>>>> (AMXProxyHandler.java:1091)
>>>> at
>>>> com.sun.appserv.management.client.handler.AMXProxyHandler.invoke
>>>> (AMXProxyHandler.java:1002)
>>>> ... 23 more
>>>>
>>>>
>>>> Are the JSR-88 apis supposed to be safe for use in real
>>>> multithreaded conditions?
>>>>
>>>> Thanks,
>>>> vbk
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>