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?
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)...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
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
