[GLASSFISH-15416] [STRESS] specjent2010 run against b36 failed Created: 03/Jan/11  Updated: 05/Jan/11  Resolved: 05/Jan/11

Status: Closed
Project: glassfish
Component/s: performance
Affects Version/s: future release
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: zorro Assignee: amitagarwal
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

solaris sparc jdk 6u22



 Description   

The following is the logs and configuration of a faild specjent2010 run against b36.
configuration.

Please note that there are exceptions which are specj's
business logic related (they do not relate to the appserver)
i.e. java.io.NotSerializableException: java.util.Formatter is specj
But some exceptions like java.lang.StackOverflowError seems to be a bug.

http://aras2.us.oracle.com:8080/logs/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/logs/jed-asqe-29/

Physical location: /net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/logs/jed-asqe-29/

Please evaluate the logs for addressing possible issues.

This is the log and configuration of a successful 7-day longevity run of specjent10 against b33.
http://aras2.us.oracle.com:8080/logs/alacrity.logs_dec_28_7_Day_Run/results.specjent2010/results_1/driver-results/34/logs/bigapp-opteron-3/
Physical location: /net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_28_7_Day_Run/results.specjent2010/results_1/driver-results/34/logs/bigapp-opteron-3/



 Comments   
Comment by Nazrul [ 03/Jan/11 ]

Amit: Are you seeing this type of issues when you run SPECj?

Comment by zorro [ 03/Jan/11 ]

Note: Specj determines pass/fail according to the information in the summary.xml as stated below.
(look for <passed>false</passed> and <passed>true</passed> in the summary.xml below).

b33

39 passed true
0 passed false
/net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_28_7_Day_Run/results.specjent2010/results_1/driver-results/34/summary.xml

b36

33 passed true
6 passed false
/net/asqe-logs.us.oracle.com/export1/gms/alacrity.logs_dec_30_solaris_single_run2/results.specjent2010/results_1/driver-results/37/summary.xml

Comment by Nazrul [ 04/Jan/11 ]

We are not supposed to run SPECj application in HA mode.

Looking at the server log, it looks like we are running into serialization issues:

[#|2010-12-30T20:15:50.516-0800|INFO|oracle-glassfish3.1|org.apache.catalina.session.ManagerBase|_ThreadID=78;_ThreadName=Thread-1;|PWC2785: Cannot serialize session attribute specUtils for session aa2a28e143662004d431d1cb7a4a
java.io.NotSerializableException: java.util.Formatter

Do you use manual steps to setup the SPECj application?

Comment by zorro [ 04/Jan/11 ]

There is no manual setup.
All configurations are done internally in specjent10.

Comment by amitagarwal [ 05/Jan/11 ]

First of all I am not seeing this issue in our setup.
As per logs Stackoverflow exception happens just once, and before appserver could start completely. This does not seem to be related to specj. I see org.glassfish.gmbal.impl.* calls going into loop thats results into stackoverflow.
One way to resolve this overflow error is to change -Xss128k to -Xss198k or someone responsible for org.glassfish.gmbal.impl.* needs to see why call sequence is so long.
Perhaps this happens only in sparc setup.

Other exceptions are harmless, they are part of specj runs.

I could run specj against b36 on OEL setup without any issues.

Comment by Nazrul [ 05/Jan/11 ]

Closing this as a duplicate of GLASSFISH-15422

Generated at Sun Aug 02 04:20:31 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.