public class LogoutHttpSessionListener implements HttpSessionListener {
/**
* {@inheritDoc}
*/
public void sessionCreated(HttpSessionEvent event) {
}
/**
* {@inheritDoc}
*/
public void sessionDestroyed(HttpSessionEvent event) {
HttpSession session = event.getSession();
if (GeneralUtils.isNotNull(session.getAttribute(PortalConstants.SESSION_USER_INFO))) {
session.removeAttribute(PortalConstants.SESSION_USER_INFO);
}
}
}
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
看看发送的链接是什么,是不是在什么页面上配置了。
没发什么链接啊,就推送了一个桌面消息,而且按道理只在某些动作下才会执行推送
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
看看发送的链接是什么,是不是在什么页面上配置了。
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
服务器推也只是针对特定的页面推送, 你不打开这个页面就不会有长连接或者ajax轮询,session失效还是会的, 难道你一定要留在推送的页面等session失效么。
还有你弄清楚你的推送是哪种实现方式,ajax长轮询比较多, 它要一直请求怎么可能session过期呢
的确是这样的,我们就是加了一个像CSDN这种通知,(CSDN也是无刷新的),这个通知就是在每一个页面都能看见得,所以长连接在main页面开启的。那按道理CSDN也是不超时的?
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
服务器推也只是针对特定的页面推送, 你不打开这个页面就不会有长连接或者ajax轮询,session失效还是会的, 难道你一定要留在推送的页面等session失效么。
还有你弄清楚你的推送是哪种实现方式,ajax长轮询比较多, 它要一直请求怎么可能session过期呢
firebug会用不,前台肯定是发送Reauest了,否则不会不超时
是的,发送的是DWR的推送
firebug会用不,前台肯定是发送Reauest了,否则不会不超时
你自己不请求后台它自己推送,不会吧,它知道地址是什么就推送啊
是的,发送的是DWR的推送
firebug会用不,前台肯定是发送Reauest了,否则不会不超时
不算是请求的,它是在后台直接调用Js,所以一直处于交互状态
你自己不请求后台它自己推送,不会吧,它知道地址是什么就推送啊
是的,发送的是DWR的推送
firebug会用不,前台肯定是发送Reauest了,否则不会不超时
你看到了?
不算是请求的,它是在后台直接调用Js,所以一直处于交互状态
你自己不请求后台它自己推送,不会吧,它知道地址是什么就推送啊
是的,发送的是DWR的推送
firebug会用不,前台肯定是发送Reauest了,否则不会不超时
的确是这样的,我们就是加了一个像CSDN这种通知,(CSDN也是无刷新的),这个通知就是在每一个页面都能看见得,所以长连接在main页面开启的。那按道理CSDN也是不超时的?
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
服务器推也只是针对特定的页面推送, 你不打开这个页面就不会有长连接或者ajax轮询,session失效还是会的, 难道你一定要留在推送的页面等session失效么。
还有你弄清楚你的推送是哪种实现方式,ajax长轮询比较多, 它要一直请求怎么可能session过期呢
csdn是长轮询实现的, 每次请求一分钟完了继续请求。 这样session肯定不会超时的。
但是CSDN是会超时的啊,它怎么实现的
的确是这样的,我们就是加了一个像CSDN这种通知,(CSDN也是无刷新的),这个通知就是在每一个页面都能看见得,所以长连接在main页面开启的。那按道理CSDN也是不超时的?
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
服务器推也只是针对特定的页面推送, 你不打开这个页面就不会有长连接或者ajax轮询,session失效还是会的, 难道你一定要留在推送的页面等session失效么。
还有你弄清楚你的推送是哪种实现方式,ajax长轮询比较多, 它要一直请求怎么可能session过期呢
csdn是长轮询实现的, 每次请求一分钟完了继续请求。 这样session肯定不会超时的。
但是CSDN是会超时的啊,它怎么实现的
的确是这样的,我们就是加了一个像CSDN这种通知,(CSDN也是无刷新的),这个通知就是在每一个页面都能看见得,所以长连接在main页面开启的。那按道理CSDN也是不超时的?
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
服务器推也只是针对特定的页面推送, 你不打开这个页面就不会有长连接或者ajax轮询,session失效还是会的, 难道你一定要留在推送的页面等session失效么。
还有你弄清楚你的推送是哪种实现方式,ajax长轮询比较多, 它要一直请求怎么可能session过期呢
csdn是长轮询实现的, 每次请求一分钟完了继续请求。 这样session肯定不会超时的。
csdn会超时么? 我好像没遇到过,你怎么知道csdn会超时的? 让你重新登录了?
CSDN超时时间是七天
但是CSDN是会超时的啊,它怎么实现的
的确是这样的,我们就是加了一个像CSDN这种通知,(CSDN也是无刷新的),这个通知就是在每一个页面都能看见得,所以长连接在main页面开启的。那按道理CSDN也是不超时的?
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
服务器推也只是针对特定的页面推送, 你不打开这个页面就不会有长连接或者ajax轮询,session失效还是会的, 难道你一定要留在推送的页面等session失效么。
还有你弄清楚你的推送是哪种实现方式,ajax长轮询比较多, 它要一直请求怎么可能session过期呢
csdn是长轮询实现的, 每次请求一分钟完了继续请求。 这样session肯定不会超时的。
csdn会超时么? 我好像没遇到过,你怎么知道csdn会超时的? 让你重新登录了?
CSDN超时时间是七天
但是CSDN是会超时的啊,它怎么实现的
的确是这样的,我们就是加了一个像CSDN这种通知,(CSDN也是无刷新的),这个通知就是在每一个页面都能看见得,所以长连接在main页面开启的。那按道理CSDN也是不超时的?
那有什么办法解决吗
现在问题已经定位了,是dwr推送引起的
下个抓包工具,看看你的页面是不是定时在发请求。
服务器推送session基本上是不会失效的
服务器推也只是针对特定的页面推送, 你不打开这个页面就不会有长连接或者ajax轮询,session失效还是会的, 难道你一定要留在推送的页面等session失效么。
还有你弄清楚你的推送是哪种实现方式,ajax长轮询比较多, 它要一直请求怎么可能session过期呢
csdn是长轮询实现的, 每次请求一分钟完了继续请求。 这样session肯定不会超时的。
csdn会超时么? 我好像没遇到过,你怎么知道csdn会超时的? 让你重新登录了?
你说的这个是自动登录功能,是通过COOKIE控制的, 7天是COOKIE的保存时间,跟session不搭嘎