dev@glassfish.java.net

Re: Interesting stack trace

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Tue, 19 Sep 2006 10:16:25 -0700

Kedar Mhaswade wrote:
>
>> most likely residing in the JMX HTTP connector.
>
> Do you have any definitive reasons to believe so, or is it just a (wild)
> guess based on stack trace?
As I used "likely" it is obviously not definitive, but looking at the
stack trace, it's in AMX, knowing there is little testing with the JMX
connector and it's a communication error, it is a good start but Lloyd
needs to chip in anyhow.
>
> As an aside, does JSR-88 talk about thread-safety of the deployment
> operations?
why should it ? after all Java is a multithreaded language and unless
there is explicit provision for things to not be multithreaded, it is
considered as being capable of handling something as drastically
complicated as deploying two applications simultaneously.

now if you look at the stack trace carefully, netbeans is trying to get
the list of modules through the getModules API of JSR88, this is not
even an official "deployment operation" yet.

Jerome

> Pardon my ignorance here.
>
> Kedar
>
>> did you talk to Lloyd about this ?
>>
>> 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
>