It is a struts2 application, so the requests obviously run through the StrutsFilter.
The user details can remain on the client machine with cookies but if the session times out and the user comes back I want the HttpSessionlistener to reinstate the details on the session that the actions rely upon. So I want...
1. user hits link
2. No session found
3. HttpSessionlistener gets called when session is created
4. HttpSessionlistener populates session with user details from cookies.
5. action class is called
1. user hits link
2. action class is called
3. No session found
4. exception as no user details on session
I had this on an interceptor but I thought there were performance issues, if the run order cannot be found then I suppose then I will have to go back to that way.
Bear Bibeault wrote:The interaction with Struts-specific filters and interceptors makes this a Struts issue which may have a standard Struts solution.
But in the general case, no one I know relies on a listener for this. They check for a valid session authentication token in a filter and redirect to a login page as necessary.
The site deals with 2 million + hits per day, average hits per session is about 2000.
I want to set up the user one time when the session is created than call a filter 2000 times to check.
As i said I know there is a struts solution, I had one, in my instance I believed it could be improved with the SessionListener example. I put it on the Tomcat forum in case there was a tomcat specific solution beyond the J2EE spec.
It does not matter if it was a spring filter, a hibernate filter or a struts filter, my opening question is framework independant
Bear Bibeault wrote:You are not going to be able to get a listener to execute in a synchronous manner. That's just not they way that they work.
Are you 100% certain that the filter approach, used by 99.99999% of web apps is a performance issue?
If the server is set to always make a session and If you have the possibility to create one and set up your session details then there is no need to filter each request there after for session details, it becomes an anti pattern.
When you write a website that takes 2 million hits per day everything is a performance issue, if you consider that there are probably about 100 objects created each time a filter is called then that stacks up to 200 million object instanications each day, a not inconsiderable amount. I am prepared to do something different and against the norm if it improves my application.
If doing that saves me one virtual instance, or at least gives it a good chance that part of the time it will not use an extra instance then I am willing to go there.
Now ironically the application partly contains JForum or at least a refactoring of JForum, it has over 1000 sites holding a minimum of 5 forums each, we all know how much this Jforum site drags with 1 site holding 50 forums.
Run some profiling. You're over-estimating filter overhead. You're almost always better served by optimizing the app, load-balancing, asset serving, and so on. I'll almost guarantee you that it's not an issue of a filter checking for a session value.
(On a side note, instantiation is insanely cheap in Java; an off-the-cuff guess would be a second to create 2 million objects. It's a matter of a few cycles. I'm sure there are any number of JVM articles that cover stuff like this.)