I think I found a way to replicate the issue: I autodeploy my war file (e.g.
copy updated war to webapps and let resin reload it). After a few deployments
this issue will occur so maybe there is some corruption caused by autodeploy?
matt
On Aug 16, 2010, at 9:57 AM, Matthew Serrano wrote:
> I am not intentionally making the call from another thread but would this be
> the case if the server had restarted? Maybe there is some combination of the
> session expiring and the server restarting that causes some issue? The code
> is:
> HttpSession mySession = req.getSession(false);
> if (mySession != null) {
> UserBean userBean = (UserBean)
> mySession.getAttribute(com.ordinate.common.auth.UserBean.SESSION_KEY);
> if (userBean != null) {
> logger.debug("User is already logged in. Redirecting to welcome page.");
> redirect(req, res, successUrl);
> } else {
> redirect(req, res, errorUrl);
> }
> }
>
> The exception occurs on the cast of the user object (line 3) so I tried
> removing the cast which allows the code to process past this point. However,
> the application then threw the same error later in a JSP when I try to get
> the user object from the session using JSTL.
>
> I have tried to replicate the issue by waiting for sessions to expire,
> restarting the server, deploying new apps (in multiple combinations)...so far
> I can't replicate it but it has now occurred on three separate servers (2
> Debian 64bit and 1 Mac OS X desktop). The only thing I am considering now is
> that a step before the above servlet executes, the session is invalidated and
> then immediately recreated using req.getSession(true). Is it possible this is
> randomly causing some issue?
>
> Btw, this same code has been running for years on Resin Pro 3.0.25.
>
> matt
>
> On Aug 16, 2010, at 8:49 AM, Scott Ferguson wrote:
>
>> Matthew Serrano wrote:
>>> I am running resin 4.0.7 and I store a user object in the session using
>>> "User_Bean" as a key. Everything works fine most of the time but it seems
>>> when my session expires and I have not logged out, every subsequent call to
>>> get this object returns some HashMap instead of my object or null. Since I
>>> am casting the object when I retrieve it from the session the message I get
>>> is:
>>>
>>> java.lang.ClassCastException: java.util.HashMap cannot be cast to
>>> com.ordinate.ppass.beans.UserBean
>>>
>>> Is there some reason why getting an object from the session would return a
>>> Map instead of the object? Is "User_Bean" some reserved word or something?
>>> The only way I have been able to get my application working again is to
>>> shutdown the server, delete everything in the resin-data folder and restart
>>> (deleting the exploded war, deploying the app again, restarting all do not
>>> work).
>>>
>> Is the session get/put in the normal request context? As opposed to
>> being read from some other thread or a different context class loader?
>>
>> That behavior sounds like it might be caused by a getAttribute call from
>> outside the web-app's context. In other words, if Resin can't find the
>> UserBean class when its deserializing. Is that at all possible in your
>> application?
>>
>> -- Scott
>>> Also, this seems to happen on resin 4.0.9 as well.
>>>
>>> thanks
>>> matt
>>>
>>> _______________________________________________
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
