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
matthias.fraass_at_tricoder.net wrote:
> Hi Hong,
>
> thanks for the quick response - unfortunately I cannot share that
> application with you :).
>
> Please send the patch - even with
> javax.enterprise.system.tools.deployment.level=DEBUG
> the only thing I can see is "Created temporary upload folder ...." and
> that's it.
>
> Cheers,
>
> Matthias
>
>
> 2009/10/29 Hong Zhang <Hong.Zhang_at_sun.com <mailto:Hong.Zhang_at_sun.com>>
>
> Hi, Matthias
> Sorry to hear that the huge EAR is causing problem for you in v3.
> It's probably not easy to share your application for us to
> reproduce from our end. I can send you a patch (with some
> additional log messages to find out the time spent in each part of
> the deployment). You can apply the patch (update some jar with the
> patch in your glassfish installation) and try to deploy the
> application again and then send me the server.log. This will help
> us narrow down where the problem is and then ask the corresponding
> engineer to take a look. Will this work for you?
> Thanks,
> - Hong
>
>
> I'm perplexed:
> An EAR that deploys fine under GF v2 doesn't deploy at all
> under v3 (b70). It sits there consuming CPU time and timeouts
> after 10 minutes:
>
> >asadmin deploy whow-thats-a-huge.ear
> I/O Error: Read timed out
> Command deploy failed.
>
> I have set javax.enterprise.system.tools.deployment=FINE but
> get no server.log entries, nothing.
> It seems that the deployment is still going on after the
> timeout, though. But I didn't have the patience to wait for
> more than 20minutes after that.
>
> Originally it was a 100+MB EAR containing, amongst other JARs,
> an ejb-jar with 45.000+ classes.
>
> Please don't ask if the design is alright :). We have plans to
> do refatoring but we have to do things one by one.
> - It's my task to migrate that behemoth from Weblogic to
> Glassfish.
> - It's deploying fine under a stock GF v2.1, so it should work
> under v3 or at least give some hints what went wrong
>
> I've stripped down the EAR so that it only contains the
> ejb-jar with a minmal ejb-jar.xml (stripped from 5MB to only 1
> SessionBean) - that's still 60MB.
> Still, it won't deploy unless I remove most of the classes
> from that ejb-jar, leaving only about 1000 classes. And for
> every 10 classes I add, the deployment takes 15s longer!
>
> Again: v2 chews on this without a grumble and deploys it
> within 2-3 minutes!
>
> -> As I've heard that v3 contains major rewrites - is there
> something wrong with the scan processes during deployment?
>
> Sorry for these unclear statements, but this is a showstopper :/.
>
> I appreciate any ideas on this very much.
>
> Cheers,
>
> Matthias
>
> --
> http://twitter.com/MatthiasFraass
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
> <mailto:quality-unsubscribe_at_glassfish.dev.java.net>
> For additional commands, e-mail:
> quality-help_at_glassfish.dev.java.net
> <mailto:quality-help_at_glassfish.dev.java.net>
>
>