at java.lang.Thread.run(Unknown Source)

ACDC

I get this error from time to time when testing an application. Could this be a memory leak issue, because it seems to go away for a while once I reboot the server. eg:

javax.servlet.ServletException
Unhandled Exception thrown: class javax.servlet.ServletException

christopherb

You can take a peek at your log files to get a beter idea on what maybe going on.

Good luck,
Chris

ACDC

This is from the log file

aware_support

Which log file is this?

You need to check:

Tomcat output
Latest Tomcat log file located in AwareIM/Tomcat/logs directory

ACDC

This was from the Tomcat server log
here it is
2008-01-03 21:11:25 StandardWrapperValve[action]: Servlet.service() for servlet action threw exception
java.lang.NullPointerException
at com.bas.webapp.actions.EntityActionUtils$c.a(Unknown Source)
at com.bas.webapp.actions.EntityActionUtils.populateReferences(Unknown Source)
at com.bas.webapp.actions.EntityAction.populateReference(Unknown Source)
at com.bas.webapp.actions.EntityAction.populateSectionReferences(Unknown Source)
at com.bas.webapp.actions.EntityAction.a(Unknown Source)
at com.bas.webapp.actions.EntityAction.newForm(Unknown Source)
at com.bas.webapp.actions.UpdateEntityAction.doExecute(Unknown Source)
at com.cc.framework.adapter.struts.ActionUtil.execute(Unknown Source)
at com.cc.framework.adapter.struts.FWAction.execute(Unknown Source)
at com.cc.framework.adapter.struts.FWAction.execute(Unknown Source)
at com.cc.framework.adapter.struts.RequestProcessorUtil.processAction(Unknown Source)
at com.cc.framework.adapter.struts.FWRequestProcessor.processActionPerform(Unknown Source)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198-)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118-)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Unknown Source)

aware_support

This has nothing to do with memory and could be a bug. Do you know how to reliably reproduce it?

ACDC

I start to get this once I get to the 20th or so Test run in the configurator.
I resolve this by rebooting the server. (thats the only way)

I have not yet discovered whether it happens once the application is published - that really would be a train smash.

Also, in the windows task manager, under performance totals, I have noted the gradual increase in the file handles over time. Right now the handles are 115065. It will rise gradually to 126000 and then bomb out. This indicates to me some application between the Configurator, and Tomcat etc is not flushing out memory correctly - hence the memory leak assumption

ACDC

B.T.W, at the moment the log file is clean and I have carried out about 7 Test runs

ACDC

I have carried out some more testing and placed a performance monitor on the JAVAW.exe process and the JAVA.exe process to establish if there is a handle leak on these processes. (The handles are gradually increasing)

While I am still awaiting some more test data i have noticed in the task manager, another 2 instances of the Java.exe process loading, so now I have 3 Java.exe and 1 Javaw.exe ( This is after I accesses the web server via a remote browser)

Can support comment on this because something looks really funny here and I think this is why I am forced to reboot the server from time to time as I am sure periodically at least one should be flushed out

Please can you confirm which processes should be running and if this is normal behavior.
Thank You

aware_support

Normally you should have one javaw.exe process (Aware IM server) and two java.exe processes (JBoss and Tomcat). If you are running the Configuration Tool on the same machine, its another java.exe process. When you access forms from a browser another java.exe will be occasionally started to compile the forms - this process should only be temporary while the forms are being compiled. There SHOULD NOT BE ANY LEAKS. Aware IM has been extensively tested for this. If you do establish this not to be true, it would be a huge bug.