[GLASSFISH-13556] Deployment of ear file fails on b19, b20 Created: 21/Sep/10  Updated: 06/Oct/10  Resolved: 06/Oct/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Sivakumar Thyagarajan
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: GZip Archive issue13556-no-cdi.tar.gz     GZip Archive issue13556.tar.gz     Text File stack.txt     Text File stack2.txt    
Issuezilla Id: 13,556

 Description   

The soon-to-be-attached test case fails to deploy on build 20.

The test case consists of an ear file. The ear file has a war file in it with a
Servlet. The ear file also contains two EJBs, one of which extends the other.
I believe that it is a valid deployment archive.



 Comments   
Comment by ljnelson [ 21/Sep/10 ]

Created an attachment (id=4928)
A maven project that produces an ear file that will not deploy.

Comment by ljnelson [ 21/Sep/10 ]

Created an attachment (id=4929)
The log fragment from attempting to deploy the attached .ear file.

Comment by ljnelson [ 21/Sep/10 ]

To build the project:

1. gunzip the attachment
2. tar xf the resulting .tar file
3. cd into the glassfish-weld directory
4. Type "mvn clean install"
5. The ear file will be built at glassfish-weld/frobnicator-ear/target.

I deployed the ear file with asadmin deploy --force.

Comment by ljnelson [ 21/Sep/10 ]

After this, I get "Inconsistent module state" errors if I try to re-run asadmin
deploy --force. I have to remove (I think) both my osgi-cache contents and my
generated/policy entry.

Comment by Hong Zhang [ 21/Sep/10 ]

From the discussions of the forum thread:
http://forums.java.net/jive/thread.jspa?messageID=483200

seems this is a CDI issue. Assign to cdi team for initial evaluation.

Comment by ljnelson [ 21/Sep/10 ]

Console output after a failed deployment:

Laird-Nelsons-MacBook-Pro:glassfish-weld ljnelson$ asadmin deploy --force
~/Projects/glassfish-weld/frobnicator-ear/target/frobnicator-ear-1.0-SNAPSHOT.ear
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
remote failure: Exception while loading the app :
org.glassfish.deployment.common.DeploymentException: Error in linking security
policy for frobnicator-ear-1.0-SNAPSHOT – Inconsistent Module State
Error in linking security policy for frobnicator-ear-1.0-SNAPSHOT –
Inconsistent Module State

Comment by ljnelson [ 21/Sep/10 ]

Please note the unusual but permitted practice of having one EJB extend another
one--but having the extended one NOT be listed as an EJB module. Glassfish
deploys both nonetheless. That's why I originally filed this under "deployment".

So FrobnicatorBean extends CaturgiatorBean--but in this partiuclar ear file, I
have only (deliberately) marked FrobnicatorBean as an EJB module. I have
included CaturgiatorBean's jar file as a library in the ear's lib directory.

Note that the deployer nevertheless appears to deploy the CaturgiatorBean,
even though I haven't listed it in the application.xml as an EJB module.
Frankly, I don't really care; if this bean is deployed it isn't really a
problem, though I'd like to keep it from being deployed if I can.

Comment by ljnelson [ 21/Sep/10 ]

Please also note that this deployment problem is different from the one that
hzhang_jn references in an earlier comment.

Comment by ljnelson [ 21/Sep/10 ]

This fails on b19 as well.

Comment by Hong Zhang [ 21/Sep/10 ]

Sorry, I thought this was about the other issue. Let me take a look at this
first.

Comment by ljnelson [ 21/Sep/10 ]

Thanks. This one is odd, because I'm gradually removing pieces over here, and
I'm still getting deployment errors with nothing in the log.

I've inserted printlns in the session scoped object's constructor, and the
session scoped object is never being constructed.

If I remove the @Inject point from within FrobnicatorServlet, the deployment
still fails, even though at this point I'm not using CDI (though my web
application still has the WEB-INF/beans.xml file in there).

I've fallen back to testing on b19 first.

Comment by Hong Zhang [ 21/Sep/10 ]

As discussed in the forum thread:
http://forums.java.net/jive/thread.jspa?messageID=483274

This still looks related to CDI. Assign to cdi team for initial evaluation.

Comment by ljnelson [ 21/Sep/10 ]

I am about to attach a simplified version of the already attached Maven project.

The simplified version does not use any features of CDI. It retains the
beans.xml file in the WEB-INF directory.

Deployment now fails on b19, b20 and b21-2010-09-21.

Comment by ljnelson [ 21/Sep/10 ]

Created an attachment (id=4931)
A simplified version of the existing project that does not use CDI and that produces an ear file that will not deploy

Comment by ljnelson [ 21/Sep/10 ]

In the simplified version (see latest attachment), which does not use CDI at
all, but which nevertheless retains the WEB-INF/beans.xml file, deployment fails.

If you remove the beans.xml file (I renamed it beans.xml.bak), deployment succeeds.

It appears that the mere PRESENCE of a beans.xml file in a web module in an ear
file will cause the ear file to be undeployable. Please bump the priority on
this one up.

Comment by ljnelson [ 21/Sep/10 ]

If you remove the beans.xml file--thus making this .ear file be a
straightforward Java EE 5 ear--deployment succeeds, but the first hit to the
servlet fails. I will attach this stack.

Comment by ljnelson [ 21/Sep/10 ]

Created an attachment (id=4932)
A stack showing what happens when you remove the beans.xml file from the simplified Maven project, build and deploy it, and attempt to access the successful deployment.

Comment by ljnelson [ 21/Sep/10 ]

Pilot error in here; going to correct it and retest. Duplicate entries for
caturgiator-ejb. My apologies....

Comment by ljnelson [ 21/Sep/10 ]

Mortally embarrassed. Apologies for wasting folks' time.

A duplicate jar entry in the top level of the ear project and the lib directory
was causing all of the issues.

(Does bring up an issue, though: if I have two EJB modules at the top level of
the ear file, is it guaranteed by specification that one of them will be able to
extend classes in the other?)

Comment by ljnelson [ 06/Oct/10 ]

Changed status to INVALID since this bug was due to pilot error.





[GLASSFISH-13456] OOME after multiple deployments of a sample app Created: 15/Sep/10  Updated: 08/Oct/10  Resolved: 08/Oct/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Critical
Reporter: arungupta Assignee: Sivakumar Thyagarajan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File twitter-demo-1.0-SNAPSHOT.war    
Issuezilla Id: 13,456

 Description   

After multiple (5-6) deployments of a sample application, the app server throws OOME with the
following stack trace:

INFO: java.lang.OutOfMemoryError: Java heap space
INFO: at sun.nio.cs.UTF_8.newEncoder(UTF_8.java:53)
INFO: at java.lang.StringCoding$StringEncoder.<init>(StringCoding.java:215)
INFO: at java.lang.StringCoding$StringEncoder.<init>(StringCoding.java:207)
INFO: at java.lang.StringCoding.encode(StringCoding.java:266)
INFO: at java.lang.String.getBytes(String.java:946)
INFO: at java.io.UnixFileSystem.getLastModifiedTime(Native Method)
INFO: at java.io.File.lastModified(File.java:826)
INFO: at org.apache.felix.fileinstall.internal.Scanner.checksum(Scanner.java:178)
INFO: at org.apache.felix.fileinstall.internal.Scanner.checksum(Scanner.java:169)
INFO: at org.apache.felix.fileinstall.internal.Scanner.scan(Scanner.java:113)
INFO: at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:228)
SEVERE: Exception in thread "DynamicReloader"
SEVERE: java.lang.OutOfMemoryError: Java heap space
SEVERE: Exception in thread "AutoDeployer"
SEVERE: java.lang.OutOfMemoryError: Java heap space

The app server has to be killed (kill -9) and restarted.



 Comments   
Comment by Hong Zhang [ 15/Sep/10 ]

arun: can you attach the sample application which cause this?

Comment by arungupta [ 15/Sep/10 ]

Created an attachment (id=4895)
WAR attachment

Comment by arungupta [ 15/Sep/10 ]

Running the app requires to configure a database, let me know if you need steps for that.

Comment by Hong Zhang [ 15/Sep/10 ]

Does the deployment need database too? The OOM happens with the multiple
deployments, not running right?

Comment by arungupta [ 15/Sep/10 ]

Deployment should not need database.

OOME occurs during this typical cycle ...

Deploy
Access the web app a few times
Deploy
Access the web app a few times
Deploy
So on ...

And then deployment fails with OOME - typically within 6-10 times.

Am using b17.

Comment by Hong Zhang [ 15/Sep/10 ]

I see. Yes, please attach the instruction for database as well (is it using
derby?).

If you just deploy the application many times without accessing it, do you get
the OOM?

Comment by Hong Zhang [ 20/Sep/10 ]

Arun: I could not reproduce this on my box if I just deploy multiple times. So
please attach the instruction how to run the application too. And if you could
collect some memory graphs while you are doing this sequence, that will be very
helpful so we will be able to get some information about which object(s) keep
growing.

Comment by arungupta [ 20/Sep/10 ]

Thanks Hong!

You can check out the workspace from:

CVSROOT :pserver:<SUN-LDAP-ID>@sunsw.sfbay.sun.com:/sw/wpts
Module: javaone2010/javaone2010/twitter-demo

All the instructions are in readme.txt.

How can I collect memory graphs for you ?

Comment by Hong Zhang [ 20/Sep/10 ]

After some initial investigation, this seems a simiar issue as issue 12368. The
number of WebappClassLoader instances increases with redeployment and cdi was
used in the application. Assign to Siva for further investigation.

Comment by Hong Zhang [ 20/Sep/10 ]

assign to Siva and add myself to Cc

Comment by Sivakumar Thyagarajan [ 08/Oct/10 ]

The memory leak issues are tracked as part 12368 and 11668. So marking this as a
duplicate
We are waiting for a fix to WELD-570 https://jira.jboss.org/browse/WELD-570 that
would resolve this and other memory leak issues. Targetting that issue for MS7

      • This issue has been marked as a duplicate of 12368 ***




Generated at Sat Aug 29 19:14:09 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.