blocks|key|890929|text|如果没有触发这个的代码机会，我会查看内存使用情况。这可能是Tomcat耗尽内存并使会话失效而无法恢复的结果。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|890930|如果可能，则监视垃圾收集，和/或使用jconsole或jvisualvm进行监视。|890931|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If there has been no code chance triggering this, I would look at memory usage. This might be the effect of Tomcat running out of memory and invalidating sessions to recover.

If at all possible monitor garbage collections, and/or put surveillance on with jconsole or jvisualvm.

blocks|key|1311723|text|一个可能的原因是您在会话中放入了一个没有实现Serializable接口的对象。Tomcat偶尔会在磁盘上写入一些会话。如果一个会话包含不可序列化的对象，那么它将被简单地从容器中删除(因为NotSerializableException)。如果发生这种情况，您应该会在tomcat日志文件中看到异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1311724|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

A possible cause is that you put in the session an object that does NOT implement the Serializable interface. Tomcat occasionally writes some of the sessions on the disk. If a session contains non-serializable objects it will simply be removed from the container (because of the NotSerializableException). If this is happening you should see the Exception in the tomcat log file.

blocks|key|1311701|text|我一般会增加对服务器的监控，特别是对会话的监控。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1311702|lambda+probe是一个很好的监控应用程序，它允许您查看当前会话及其数据。我还会添加一个HttpSessionListener来记录会话的创建和销毁。|offset|length|1311703|编辑|style|BOLD|1311704|有没有可能，您将一些不可序列化的对象添加到会话中，而Tomcat无法将它们钝化到磁盘？|1311705|编辑2|1311706|Lambda探测器似乎已经死了，在http://code.google.com/p/psi-probe/上有一个更好的项目分支|1311707|entityMap|0|LINK|mutability|MUTABLE|url|http://www.google.com/search?q=lambda%2Bprobe&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a|1|http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpSessionListener.html|2|http://code.google.com/p/psi-probe/^0|0|0|C|0|1B|J|1|0|0|2|0|0|0|3|0|H|Z|2|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|12|8|@]|9|@$D|13|E|14|1|15]|$D|16|E|17|1|18]]|A|$]]|$1|F|3|G|5|6|7|19|8|@$D|1A|E|1B|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@$D|1E|E|1F|H|I]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1G|8|@]|9|@$D|1H|E|1I|1|1J]]|A|$]]|$1|P|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]]|Q|$R|$5|S|T|U|A|$V|W]]|X|$5|S|T|U|A|$V|Y]]|Z|$5|S|T|U|A|$V|10]]]]

I would increase the monitoring of the server in general and the sessions specifically.
A good monitoring application is <a href="http://www.google.com/search?q=lambda+probe&amp;ie=utf-8&amp;oe=utf-8&amp;aq=t&amp;rls=com.ubuntu:en-US:unofficial&amp;client=firefox-a" rel="nofollow noreferrer">lambda probe</a> - it allows you to view the current sessions and their data. I would also add a <a href="http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpSessionListener.html" rel="nofollow noreferrer">HttpSessionListener</a> to log session creation and destruction.
Edit
Is is possible that you add some non serializble objects to the session and Tomcat fails to passivate them to the disk?
Edit 2
Lambda probe seems to be dead, and there a much better fork of the project over at <a href="http://code.google.com/p/psi-probe/" rel="nofollow noreferrer">http://code.google.com/p/psi-probe/</a>

blocks|key|8514|text|有一个超时，您可以在web.xml中配置：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|8515|<web-app>
++...
++<session-config>
++++<session-timeout>-1</session-timeout>+
++</session-config>
</web-app>|code-block|syntax|javascript|8516|使用-1表示无超时|8517|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

there is a timeout, that you can configure in your web.xml:

<pre><code>&lt;web-app&gt;
 ...
 &lt;session-config&gt;
 &lt;session-timeout&gt;-1&lt;/session-timeout&gt; 
 &lt;/session-config&gt;
&lt;/web-app&gt;
</code></pre>

use -1 for no timeout

blocks|key|891014|text|增加你的会话记录，这可能会让你的问题变得更清晰。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|891015|Tomcat配置页面的Logging+in+Tomcat包含一个增加会话日志记录的示例。|offset|length|891016|entityMap|0|LINK|mutability|MUTABLE|url|http://tomcat.apache.org/tomcat-6.0-doc/logging.html^0|0|B|H|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Increase your logging of sessions, which may shed some light onto your problem.

The Tomcat config page's <a href="http://tomcat.apache.org/tomcat-6.0-doc/logging.html" rel="nofollow noreferrer">Logging in Tomcat</a> includes an example of increasing logging of sessions.

blocks|key|4109178|text|我们刚刚在tomcat+6__18和IBM1.5JVM中遇到了这个问题|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4109179|事实证明，这是一个原子操作的ibm+jvm问题。|4109180|tomcats中有一个比6__19更强大的修复程序来处理它。|4109181|在SUN1.5JVM中也不会出现这种情况|4109182|以下是更多细节|4109183|tomcat+bugzilla+case|offset|length|4109184|entityMap|0|LINK|mutability|MUTABLE|url|https://issues.apache.org/bugzilla/show_bug.cgi?id=46085^0|0|0|0|0|0|0|K|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@$L|11|M|12|1|13]]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

We just ran into this with tomcat 6_0_18 and ibm 1.5 jvm

turns out it was an ibm jvm issue with atomic operations.

There is a fix in tomcats greater than 6_0_19 to handle it.

It also doesn't occur in sun 1.5 jvm

here are some more details

<a href="https://issues.apache.org/bugzilla/show_bug.cgi?id=46085" rel="nofollow noreferrer">tomcat bugzilla case</a>

blocks|key|8710|text|当满足以下前提条件时，我也看到过类似的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|8711|8712|在多个JVM上安装了tomcat应用程序的多个实例|unordered-list-item|8713|负载平衡(在web服务器和Tomcat之间)配置不正确。|8714|Tomcat的会话复制功能是not+enabled+|offset|length|style|BOLD|8715|8716|由于不正确的负载平衡配置，web服务器可能会随机决定中断会话关联，并将传入请求发送到以前从未见过该会话的Tomcat+JVM。Tomcat+JVM将发出一个新会话，用户将丢失所有previouS会话数据并有效地重新开始。|8717|entityMap^0|0|0|0|0|E|3|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|W|8|@$J|X|K|Y|L|M]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

I have seen similar problems when the following prerequisites exist:

<ul>
<li>multiple instances of the tomcat app are installed across multiple JVMs</li>
<li>load balancing (between the web server and the Tomcat JVMs) is not configured correctly. </li>
<li>Tomcat's session replication feature is not enabled </li>
</ul>

Due to the incorrect load balancing config, the web server may randomly decide to break session affinity and send an incoming request to a Tomcat JVM that has never seen the session before. The Tomcat JVM will issue a new session and the user will lose all of their previouS session data and effectively start over.

blocks|key|1309340|text|您可以搜索Tomcat的bug数据库，但最好先重新查看您的web应用程序。Tomcat出现问题的可能性非常低。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1309341|尝试调查导致会话无效的原因。你在使用过滤器吗？您是否有跨上下文请求？尝试为每个请求添加日志记录信息，以找出会话丢失的确切时间。|1309342|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You can search Tomcat's bug database, but it would be better to have another look at your web application first. The chances that there is something wrong with Tomcat are very low.

Try to investigate what causes session invalidation. Are you using filters? Do you have cross-context requests? Try adding logging information for every request to find out, when exactly the session is lost.

blocks|key|4108999|text|尽管我不知道问题的原因，但一种可能的修复方法(我在上一个项目中已经做过)是在tomcat集群上运行应用程序并进行会话故障转移。默认情况下，会话可能是粘性的，当一个节点出现故障时，健康的节点会恢复会话，所有这一切对最终用户都是透明的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4109000|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Eventhough I do not know the cause of the problem, one possible fix (which I had done at my previous project) would be to run the application on a tomcat cluster and have session failover. Sessions can be by default sticky and when one node goes down, the healthy nodes pick up the sessions and all this is transparent to the end user.

We are running tomcat application server that handle over 100 concurrent sessions.
In the last 2 months the most active users noticed that sometimes they are getting kicked off from the system. 

As I understood from the log tomcat sessions are getting expired without any reason. 

I see no problems from the web application side.
Is there any problem from the tomcat side?

Tomcat 6.0.18.

Tomcat sessions expiring unexpectedly

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我们运行的tomcat应用服务器可以处理100多个并发会话。在过去的两个月里，最活跃的用户注意到，有时他们会被踢出系统。据我从日志中了解到，tomcat会话正在无缘无故地过期。我认为web应用程序方面没有任何问题。tomcat方面有什么问题吗？Tomcat 6.0.18。

问Tomcat会话意外过期
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Tomcat会话意外过期EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Tomcat会话意外过期
EN