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 http://bugs.caucho.com/view.php?id=4179, 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)...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 <mailto:resin-interest@caucho.com> >>>>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> resin-interest mailing list >>>> resin-interest@caucho.com <mailto:resin-interest@caucho.com> >>>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>> >>> _______________________________________________ >>> resin-interest mailing list >>> resin-interest@caucho.com <mailto:resin-interest@caucho.com> >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> _______________________________________________ >> resin-interest mailing list >> resin-interest@caucho.com <mailto: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
