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.getAvailableModules(SunDeploymentManager.java:315)
>>>
>>> at
>>> org.netbeans.modules.j2ee.sun.ide.dm.SunDeploymentManager.getAvailableModules(SunDeploymentManager.java:506)
>>>
>>> at
>>> org.netbeans.modules.j2ee.deployment.impl.TargetServer.getAvailableTMIDsMap(TargetServer.java:298)
>>>
>>> at
>>> org.netbeans.modules.j2ee.deployment.impl.TargetServer.processLastTargetModules(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.deploy(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.getModulesOnATarget(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.MBeanServerMessageConductor.invoke(MBeanServerMessageConductor.java:62)
>>>
>>> at
>>> com.sun.enterprise.admin.jmx.remote.internal.RemoteMBeanServerConnection.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
>