aspose file tools*
The moose likes Tomcat and the fly likes NullPointerException caused by session.getAttributeNames() thrown in Enumerator Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "NullPointerException caused by session.getAttributeNames() thrown in Enumerator" Watch "NullPointerException caused by session.getAttributeNames() thrown in Enumerator" New topic
Author

NullPointerException caused by session.getAttributeNames() thrown in Enumerator

Oliver Meiser
Greenhorn

Joined: Nov 10, 2005
Posts: 9
Dear All,

have following problem.
I get a NullPointerException calling session.getAttributeNames().
Running jboss-3.2.6 on AIX.
the session variable is of type HttpSession.
Allways thought that we ll never have this situation
cos the subsequent calls are as follows:
StandardSession.getAttributeNames() causes
the subsequent call on the constructor with
new Enumerator(sessionhashtable.keySet()) which always should
contain a valid set of keys without null pointers.
but the constructor of Enumerator fails,
(do not know where exactly ) and moreover it is not able to
produce such a NullPointerException cos a set is iterateted
with hasMoreElements ... nextElement so there shouldnt be any
problem.

Any ideas? Anyone knows about the real and only links to the source
used for catalina which is used in jboss-3.2.6. Cos i might
look into the wrong version of Enumerator, StandardSessionFacade,
StandardSession, ...

Had a look on the web and the only thing people seem to have
problems with is the ConcurrentModifactionException which, I think,
has nothing to do with my problem.

Ahhh ... we were able to produce this error only on when two
concurrent requests are coming in - but request.getSession.getId()
is retrieving different ids.

Thanks heaps for any suggestions.

Thanks
Mr. Oakly
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61198
    
  66

"Mr Oakley",

There aren't many rules that you need to worry about here on the Ranch, but one that we take very seriously regards the use of proper names. Please take a look at the JavaRanch Naming Policy and adjust your display name to match it.

In particular, your display name must be a first and a last name separated by a space character, and must not be obviously fictitious.

Thanks!
bear
JavaRanch Sheriff


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Oliver Meiser
Greenhorn

Joined: Nov 10, 2005
Posts: 9
Thanks, changed my name.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

You may want to check for the existence of a non-null session before interrogating for session variables.



Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Oliver Meiser
Greenhorn

Joined: Nov 10, 2005
Posts: 9
Thanks for your help.
But we never have a session == null

William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12781
    
    5
Exactly where in that code is that exception being thrown?
Does any other code in the application remove references from the Session?
If this was my problem I would synchronize on session all code that could possibly modify the session.
Bill
Oliver Meiser
Greenhorn

Joined: Nov 10, 2005
Posts: 9
Bill, Thanks for your answer. I think we are getting a bit closer.

The stacktrace is below: the exact line where the NullPointerException is
thrown:



Back to your idea. so - you would synchronize all methods where I
do something with the httpSession obj? in other words: will it be
enough to just say


on all methods where the HttpSession is used?

This problem drives me crazy. cos it happens after
roughly 2 hours usage of the application and it s hard
to check if there is any progress.

So what might help: we use URL rewriting. after we produce
once this error it does
not matter how the request looks like (not even different
jsessionid s help) - the server throws this
exception on any request and there is no way to get the
server out of this state. well - except a restart of the
whole jboss.

another thing concerning the stacktrace: why is there no
exact line given in the Enumerator class where the Exception
is actually thrown?



13:49:54,477 (1C0AAC426BF90D163E4314F35A18778A) INFO LoginInitAC CLEANSESSION SESSIONID=1C0AAC426BF90D163E4314F35A18778A
13:49:54,478 (1C0AAC426BF90D163E4314F35A18778A) ERROR LoginInitAC Caught unexpected Exception=java.lang.NullPointerException
13:49:54,478 (1C0AAC426BF90D163E4314F35A18778A) ERROR LoginInitAC at Enumerator.java:<init>:-3
13:49:54,478 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT java.lang.NullPointerException
13:49:54,478 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.util.Enumerator.<init>(Enumerator.java(Compiled Code))
13:49:54,478 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.util.Enumerator.<init>(Enumerator.java(Compiled Code))
13:49:54,478 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.session.StandardSession.getAttributeNames(StandardSession.java:996)
13:49:54,478 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.session.StandardSessionFacade.getAttributeNames(StandardSessionFacade.java:123)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at de.steria.ignis3web.webapp.action.GenericAction.cleanSession(GenericAction.java:128)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at de.steria.ignis3web.webapp.action.GenericAction.cleanSession(GenericAction.java:102)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at de.steria.ignis3web.webapp.action.LoginInitAC.executeInitImpl(LoginInitAC.java:37)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at de.steria.ignis3web.webapp.action.GenericInitAction.executeImpl(GenericInitAction.java:56)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at de.steria.ignis3web.webapp.action.GenericAction.execute(GenericAction.java:259)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java(Compiled Code))
13:49:54,479 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at de.steria.ignis3web.webapp.util.RequestFilter.doFilter(RequestFilter.java:141)
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java(Compiled Code))
13:49:54,480 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java(Compiled Code))
13:49:54,481 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java(Compiled Code))
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java(Compiled Code))
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java(Compiled Code))
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java(Compiled Code))
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
13:49:54,482 (1C0AAC426BF90D163E4314F35A18778A) INFO STDOUT at java.lang.Thread.run(Thread.java:568)
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12781
    
    5
It certainly looks like something is happening to that session object that causes the enumeration constructor to blow up. I can only think that some other thread has modified it - possibly by invalidating the whole session. There is no line number because the library classes are compiled without them for compactness.

I would try synchronizing on the actual session object, not the whole method in all places where references are added or removed.
synchronize( session ){
.. modify the session..
}

Are you sure that all references in the session are to Serializable objects? Perhaps this only occurs if the server tries to serialize the session and fails?
Bill
Oliver Meiser
Greenhorn

Joined: Nov 10, 2005
Posts: 9
Bill, thanks for your help!

It certainly looks like something is happening to that session object that causes the enumeration constructor to blow up. I can only think that some other thread has modified it - possibly by invalidating the whole session.

- This seems to be the problem. Wherever we change something on the
session from OUR code, we use not 'null' String constants as keys for the HashMap. I think struts is doing something strange on the session, using 'null' keys for the HashMap. I think I could just make a change to another
Jboss which is using another tomcat that uses Hashtable instead of the
bloody HashMap (that accepts 'null' keys) within the StandardSession class. So then I could see at least when Struts is doing something buggy.

There is no line number because the library classes are compiled without them for compactness.

-well - I compiled the Enumerator class again myself, updated catalina.jar
and there is still no line number.


I would try synchronizing on the actual session object, not the whole method in all places where references are added or removed.
synchronize( session ){
.. modify the session..
}

-as I said, i think Struts is the bad guy, and I dont want to start
synchronizing the session with the struts ActionSerlvet. the synchronisation
is done in OUR code, but the problem is still there.

Are you sure that all references in the session are to Serializable objects? Perhaps this only occurs if the server tries to serialize the session and fails?

-no, I am not sure. At what time is the session serialized? I always thought that the session is alive and in memory for the specified time and then
released. I would say that we are only setting Strings and attach them to the session object. But I have to check first to find out.


The funny thing is that another installation for another customer is
working fine with the same application. The session timeout is different
thought. Might that be an explanation?


Thanks for your help again.
Oliver
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12781
    
    5
Are you sure that all references in the session are to Serializable objects? Perhaps this only occurs if the server tries to serialize the session and fails?

-no, I am not sure. At what time is the session serialized? I always thought that the session is alive and in memory for the specified time and then
released. I would say that we are only setting Strings and attach them to the session object. But I have to check first to find out.


The funny thing is that another installation for another customer is
working fine with the same application. The session timeout is different
thought. Might that be an explanation?


A servlet container is allowed to serialize a session to storage any time it wants to - I think this decision is based on memory available, load, etc.

I really don't know how to interpret the bit with the different bahavior on another machine, are the loads similar?

Bill
Oliver Meiser
Greenhorn

Joined: Nov 10, 2005
Posts: 9
Bill, I ll still have to check if all keys/value within the session
are serializable. but I doubt that this is the problem 'cos I would rather
expect a NotPossibleToSerializeException at serialization time , when
something is in there that is not serializable.


I really don't know how to interpret the bit with the different bahavior on another machine, are the loads similar?


All I want to say with that is that there is another production
machine where this problem does not occur. The first thing I recognized
in this context is that the sessiontimeouts are different.

Oliver
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NullPointerException caused by session.getAttributeNames() thrown in Enumerator