一个session引发的血案
问题描述
用户登出的时候页面出现500错误,后台打印错误有两个:一个是session失效,getAttribute不可用;二是,Struts进入死循环跳转,无法定位正确的location。
bug定位
最开始想到可能是登出的时候session处理有问题。于是将代码定位到logout方法中,该方法只有三行,第一行是获取session,第二行是调用session.invalidate()使session失效,第三行返回字符串使页面跳转到Struts指定位置。
解决过程
多次调用session.invalidate(),导致退出调用失败抛出异常。确认方法,将session.invalidate()注释掉,方法正确返回无报错。但是通过全文搜索,发现只有logout方法调用invalidate(),并且打断点调试发现,错误并非在调用invalidate()的时候抛出而是在return的时候抛出。
检查struts.xml,确认是否是文件配置错误。通过网络搜索发现,struts死循环很有可能是type=”chain”,导致的,修改为redirection,虽然页面正常跳转但是bug1依然存在(注:type=”chain”是配置的全局转发,当出现expection时调用)。所以问题没有从根本上解决。
最后查看logout对应跳转方法,对应的只有一个页面login.jsp,尝试修改为重新定向到login.jsp,页面正常显示,后台无报错。确定问题出在login.jsp中。打开login.jsp,发现并没有调用session,仔细查看发现login.jsp引用了in.jsp页面,注释in.jsp,成功解决问题。然后打开in.jsp发现问题所在:var server = “${session.server}”。当logout的时候返回login.jsp,此时session已经失效,调用.server会调用getAttribute就会出现报错,报错之后就会返回到type=”chain”的result,该result也是返回到login.jsp,由于type=”chain”会将上一个action的内容带到下一个action中,然后同样session失效,从而造成死循环。
问题解决
最后,在in.jsp开头写了一段判断此时session是否存在对应的attribute,存在即复制给server,不存在就不返回。成功解决该问题。后来同事过来看了一眼,说方法太迂回,可以直接让var server = “${server}”,他会按照当前的环境逐层寻找改名字的变量找到就返回,找不到就为空。最后一行代码解决了这个看了半天的bug。
写在最后
经过此次debug,增加了对struts机制的了解吧,同时以后对session的操作也要更小心的处理,避免发生同样的问题。因为这是公司的项目,才来不久没仔细了解为什么不把session直接销毁,而是选择让它失效,这个问题后面在补吧。最后,一家之言,欢迎拍砖。