Matthew Serrano wrote:
> I figured out how to replicate my issue:
> If I log in to my application, deploy a war file to webapps, and then 
> refresh my page at the same time the app is automatically reloading, I 
> can cause the error. This is fairly difficult to do consistently but 
> given a few tries I can make it happen. I changed my dependency-check 
> internal to 30 seconds (instead of default 2s) and it was more 
> difficult to replicate because I would refresh my page before the 
> server automatically redeployed which would then trigger the 
> redeployment and everything would work properly. It only seems to 
> happen if you magically access the session as resin is reloading but 
> given that I am able to replicate it pretty easily it seems like 
> something that will definitely happen if we use autodeploy.
> Is there a recommendation or guideline not to use autodeploy in 
> production? If not, perhaps there is a bug here that needs to be 
> addressed?

Thanks. That makes more sense. It looks like a timing bug during deployment.

I've added a bug report at, 
although the fix would need to wait until 4.0.11.

-- Scott

> matt
> On Aug 16, 2010, at 11:25 AM, Matthew Serrano wrote:
>> 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) 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 mailing list
>>>> <>
>>> _______________________________________________
>>> resin-interest mailing list
>>> <>
>> _______________________________________________
>> resin-interest mailing list
>> <>
> ------------------------------------------------------------------------
> _______________________________________________
> resin-interest mailing list

resin-interest mailing list

Reply via email to