Issue Details (XML | Word | Printable)

Key: GLASSFISH-17684
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Rajiv Mordani
Reporter: easarina
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

AIX, richAccess stress test with new IBM SDK, after three days of running severe error messages appeared in server.log of one instance.

Created: 09/Nov/11 08:30 PM   Updated: 07/Dec/11 12:13 AM   Resolved: 07/Dec/11 12:13 AM
Component/s: ejb_container
Affects Version/s: 3.1.2_b08
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Text File server.log (179 kB) 09/Nov/11 08:30 PM - easarina

Participants: easarina and Rajiv Mordani

 Description  « Hide

AIX machines, run richAccess stress test with new SDK from IBM with a fix for the bug 16707. Three instances in a cluster, three machines, one instance plus DAS on one machine, then one instance per a machine. Problems that were described in the bug 16707 appeared almost immediately after the test was started. Within 3 days of running I did not see any issues. Then I saw in server.log files of all instances such warnings:

[#|2011-11-07T00:01:37.191-0800|WARNING|glassfish3.1.2|javax.jms|_ThreadID=14;_ThreadName=Thread-9;|[I500]: Caught JVM Exception: Trying to read 72 bytes. Already read 0 bytes.|#]

Later more severe errors appeared in server.log of one instance and for that instance 35 requests failed. The new severe error messages started with that message.

[#|2011-11-07T18:47:28.195-0800|SEVERE|glassfish3.1.2|com.s1as.e2e.richAccess.servlet.sendorder|_ThreadID=15;_ThreadName=Thread-9;|Exception e java.lang.NullPointerException|#]

I've attached a server.log for that instance.

Rajiv Mordani added a comment - 14/Nov/11 06:46 PM

There seems to be a problem in the app. There is an NPE based on the log at -

at com.s1as.e2e.richAccess.servlet.SendOrder.processRequest(
at com.s1as.e2e.richAccess.servlet.SendOrder.doPost(
at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(
at org.apache.catalina.core.StandardWrapper.service(
at org.apache.catalina.core.StandardWrapperValve.invoke(
at org.apache.catalina.core.StandardContextValve.invoke(
at org.apache.catalina.core.StandardPipeline.doInvoke(
at org.apache.catalina.core.StandardPipeline.invoke(
at com.sun.enterprise.web.WebPipeline.invoke(
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.connector.CoyoteAdapter.doService(
at org.apache.catalina.connector.CoyoteAdapter.service(
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(
at com.sun.grizzly.http.ProcessorTask.doProcess(
at com.sun.grizzly.http.ProcessorTask.process(
at com.sun.grizzly.http.DefaultProtocolFilter.execute(
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.DefaultProtocolChain.execute(
at com.sun.grizzly.http.HttpProtocolChain.execute(
at com.sun.grizzly.ProtocolChainContextTask.doCall(
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(
at com.sun.grizzly.util.AbstractThreadPool$

easarina added a comment - 07/Dec/11 12:13 AM

If it is an app issue, I'm closing the bug.