quality@glassfish.java.net

Re: v3 not deploying huge EAR anymore

From: Tim Quinn <Timothy.Quinn_at_Sun.COM>
Date: Thu, 29 Oct 2009 10:10:14 -0500

Hi, again, Matthias.

The stack trace might turn out to have been very useful.

The GenericAnnotationDetector's scanArchive method invokes the
InputJarArchive's entries method which returns an Enumeration of the
entries in the archive - the JAR in this case. The current
implementation of InputJarArchive.entries is inefficient and could
account for the problem you are seeing.

Hong and I are talking to see about how that method might be improved.

Stay tuned!

- Tim

matthias.fraass_at_tricoder.net wrote:
> Hi Tim,
>
> yes, it's windows.
>
> jstack after 20 minutes:
>
> "http-thread-pool-4848-(2)" daemon prio=10 tid=0x4fc09400 nid=0x1428
> runnable [0x50cae000]
> java.lang.Thread.State: RUNNABLE
> at java.util.zip.Inflater.inflateBytes(Native Method)
> at java.util.zip.Inflater.inflate(Inflater.java:223)
> - locked <0x041efb50> (a java.util.zip.Inflater)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:135)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:146)
> at java.util.jar.JarInputStream.read(JarInputStream.java:177)
> at java.util.zip.ZipInputStream.closeEntry(ZipInputStream.java:92)
> at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:70)
> at java.util.jar.JarInputStream.getNextEntry(JarInputStream.java:118)
> at java.util.jar.JarInputStream.getNextJarEntry(JarInputStream.java:149)
> at
> com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getEntry(InputJarArchive.java:239)
> at
> org.glassfish.deployment.common.GenericAnnotationDetector.scanArchive(GenericAnnotationDetector.java:60)
> at
> org.glassfish.deployment.common.GenericAnnotationDetector.hasAnnotationInArchive(GenericAnnotationDetector.java:39)
> at
> com.sun.enterprise.connectors.connector.module.ConnectorHandler.handles(ConnectorHandler.java:92)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:160)
> at
> org.glassfish.javaee.full.deployment.EarHandler.expand(EarHandler.java:139)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.getContext(ApplicationLifecycle.java:1053)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.access$100(ApplicationLifecycle.java:99)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle$DeploymentContextBuidlerImpl.build(ApplicationLifecycle.java:989)
> at
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:226)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1159)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1218)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1207)
> at
> com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:362)
> at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:201)
> at
> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
> at
> com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
> at
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:241)
> at
> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:789)
> at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697)
> at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:952)
> at
> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
> at
> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
> at
> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
> at
> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
> at
> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
> at
> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
> at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
> at
> com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
> at
> com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
> at java.lang.Thread.run(Thread.java:619)
>
> ...still chewing on the EAR after 20 minutes?!
>
> My temp dir has about 300 files. Not too big, I'd say.
>
> I'll clean it up and retry with --upload=false now.
>
> Thanks for the support so far!
>
> -Matthias
>
>
> 2009/10/29 Tim Quinn <Timothy.Quinn_at_sun.com
> <mailto:Timothy.Quinn_at_sun.com>>
>
> Hi, Matthias.
>
> Does this happen to be on a Windows system?
>
> If so, we've seen cases in the past in which operations in the
> temporary directory - such as creating new files there - can take
> a very long time if the temporary directory itself has many
> entries in it.
>
> You can also specify --upload=false on the deploy command if you
> are executing the deploy command on the same system where the
> server runs to skip the upload step entirely.
>
> In addition to the patch, it might be helpful for you to use
> jstack to capture the current stack of the server process when it
> seems stuck.
>
> - Tim
>