|Title|IPlanet HTTP session incompatibility
|Date|30-Oct-2006 13:44:38 EET
|[Bug criticality]|BadBug
|Browser version|
|[Bug status]|NewBug
|[PageProvider] used|
|Servlet Container|iPlanet
|Operating System|Solaris
|Java version|

(Moved from [JSPWikiSupport], as it seems to be a bug of some sorts.)


Here's my situation.  I am running jspWiki v2.4.21 and everything works great on my local machine using Tomcat.  I moved it over to our production unix servers running iplanet/sunone version 6.1 (FYI... I don't have any control over this server either or its configuration), and the authorization and login no longer seemed to worked.  I tried numerous thing and added a lot of debugging statements to figure out what was going on.  It seemed like the user would be logged in correctly, but then the user principal just vanished and everything would revert back to the guest account.  

I was eventually able to track down what was going on, but i still don't understand why.  

I traced the problem to the WikiSession class and the getWikiSession method.  I discovered here that each time the HttpSession was retrieved from the HttpServletRequest object it was a new instance of StandardSessionFacade rather than the same instance like Tomcat provided locally.  I dug a little deeper into the SessionMonitor (and the find method) next to discover that the HttpSession object itself is used as the key of a httpSessions map (m_sessions) whose value was the associated WikiSession. After some more debugging I realized that every time the getWikiSession was called it was never finding a match in the map because the HttpSession was a new instance.  Therefore, it would return a new guest WikiSession each time.  Not Good.

To fix the issue I ended up adding in a chunk of code to the SessionMonitor's find method that, after the normal map lookup failed to find a match, it would loop through all the map keys(sessions) and compare the session Ids and find a match that way.  Those session ids always remained the same on each call.  Once that was added everything started working.

Hopefully this makes some sense the way I explained it...

My real question is why was I getting back a new HttpSession instance each time?  I am guessing this has something to do with how Iplanet/SunOne works, but I haven't found any explanation yet. Has anyone else seen this? Can anyone shed some light on this? If not... hopefully someone else will find this useful down the road and help solve their problem.

Any info/help/explanation you can provide is appreciated.

-- Tim Bass

This makes perfect sense. A foreign object should not be used as a key to the WikiSession map. There is no guarantee that the HttpSession object provided by the container will be the same between HTTP requests. An examples of this is the JDBC Session Store that can be used with Tomcat.

My question is why the WikiSession isn't stored in the HttpSession. That would seem to be the natural way to do things. Then if you need to take some action on session creation/expiration you use HttpSessionListener's.

-- Glenn Nielsen


I uploaded two patch files which fix this bug.

SessionMonitor.java was modified to use the container for storing
WikiSession's. With this change it no longer needs to run as a
background thread. This simplifies the management of WikiSession's
and allows it to work no matter how a container might manage HttpSession's
internally. This also will allow WikiSessions to survive container or web application restarts. WikiSession was modified to remove the code to start
the SessionMonitor background thread.

You need to add the following to the web.xml after the filter-mappings.
       HttpSessionListener used for managing WikiSession's.
One additional change is needed. WikiSession should implement java.io.Serializable so that it can be marshalled out with the HttpSession by the container to persistent storage during a container or web application restart or if HttpSession's are clustered between multiple application servers or stored in a database.

--Glenn Nielsen, 01-Nov-2006


One final note. I subscribed using mailman to both the JSPWiki dev and user lists. I never received an subscription e-mails. It sure would be easier to discuss these types of bugs and patches on a mailing list.

--Glenn Nielsen, 01-Nov-2006

Yes, they would be.  I'm a bit worried that you didn't receive the subscription emails.  Can you try again?  If it still does not work, send me private email.

Andrew, do you have a comment on these?

(From my side I don't think WikiSession can be marshalled because it includes a reference to a WikiEngine, and that most certainly is not serializable.)

-- JanneJalkanen, 01-Nov-2006


This seems like a pretty good set of revisions. Certainly, it's a good idea to use existing J2EE methods rather than cook up our own scheme. (Although, if we wanted to use less radical surgery we could simply use the session ID as a key rather than the HttpSession.) We would need to make sure that it works as advertised on the most popular web app servers, although I can't see why it wouldn't.

As for the reason why WikiSession isn't stored in the HTTP session - it's because there are a LOT of strong references that we'd bring in to the HTTP session if we did that. It would cause a memory leak. In fact, in previous versions it WAS in the HttpSession -- after a bunch of memory profiling I figured it would be better to remove it.

--Andrew Jaquith, 01-Nov-2006