【问题标题】:Tomcat sessions expiring unexpectedlyTomcat 会话意外到期
【发布时间】:2009-06-06 07:23:53
【问题描述】:

我们正在运行处理超过 100 个并发会话的 tomcat 应用程序服务器。 在过去的 2 个月中,最活跃的用户注意到有时他们会被系统踢出。

据我了解,tomcat 会话无故过期。

我认为 Web 应用程序方面没有问题。 从tomcat方面有什么问题吗?

Tomcat 6.0.18.

【问题讨论】:

  • 您发现原因是什么?

标签: java session tomcat


【解决方案1】:

如果没有触发此事件的代码机会,我会查看内存使用情况。这可能是 Tomcat 内存不足和恢复会话无效的结果。

尽可能监控垃圾收集,和/或使用 jconsole 或 jvisualvm 进行监控。

【讨论】:

    【解决方案2】:

    一个可能的原因是您在会话中放入了一个没有实现 Serializable 接口的对象。 Tomcat 偶尔会在磁盘上写入一些会话。如果会话包含不可序列化的对象,它将简单地从容器中删除(因为 NotSerializableException)。如果发生这种情况,您应该会在 tomcat 日志文件中看到异常。

    【讨论】:

    • 在什么情况下tomcat将会话写入磁盘?在基于集群的环境中或内存不足时?
    【解决方案3】:

    我会总体上增加对服务器的监控,特别是会话。

    一个好的监控应用程序是lambda probe - 它允许您查看当前会话及其数据。我还会添加一个HttpSessionListener 来记录会话的创建和销毁。

    编辑

    是否有可能您将一些不可序列化的对象添加到会话中,而 Tomcat 无法将它们钝化到磁盘?

    编辑 2

    Lambda 探测似乎已经死了,在http://code.google.com/p/psi-probe/ 上有一个更好的项目分支@

    【讨论】:

      【解决方案4】:

      有一个超时,你可以在你的 web.xml 中配置:

      <web-app>
        ...
        <session-config>
          <session-timeout>-1</session-timeout> 
        </session-config>
      </web-app>
      

      使用 -1 表示没有超时

      【讨论】:

      • 问题不存在。当前超时设置为一小时。但是用户在积极使用该应用程序时被踢了
      【解决方案5】:

      增加您的会话记录,这可能会对您的问题有所了解。

      Tomcat 配置页面的Logging in Tomcat 包含一个增加会话记录的示例。

      【讨论】:

        【解决方案6】:

        我们刚刚使用 tomcat 6_0_18 和 ibm 1.5 jvm 遇到了这个问题

        原来是原子操作的 ibm jvm 问题。

        在大于 6_0_19 的 tomcats 中有一个修复程序来处理它。

        在 sun 1.5 jvm 中也不会出现

        这里有更多细节

        tomcat bugzilla case

        【讨论】:

          【解决方案7】:

          当存在以下先决条件时,我遇到过类似的问题:

          • tomcat 应用程序的多个实例跨多个 JVM 安装
          • 负载平衡(在 Web 服务器和 Tomcat JVM 之间)配置不正确。
          • Tomcat 的会话复制功能启用

          由于不正确的负载平衡配置,Web 服务器可能会随机决定中断会话亲和性并将传入请求发送到以前从未见过会话的 Tomcat JVM。 Tomcat JVM 将发出一个新会话,用户将丢失所有之前的会话数据并有效地重新开始。

          【讨论】:

          • 您能否更具体地说明负载均衡配置不正确的原因?
          【解决方案8】:

          您可以搜索 Tomcat 的错误数据库,但最好先再看看您的 Web 应用程序。 Tomcat 出现问题的可能性非常低。

          尝试调查导致会话失效的原因。你在使用过滤器吗?你有跨上下文请求吗?尝试为每个请求添加日志信息,以找出会话丢失的确切时间。

          【讨论】:

            【解决方案9】:

            尽管我不知道问题的原因,但一种可能的解决方法(我在之前的项目中做过)是在 tomcat 集群上运行应用程序并进行会话故障转移。默认情况下,会话可以是粘性的,当一个节点出现故障时,健康节点会接收会话,所有这些对最终用户都是透明的。

            【讨论】:

            • 似乎集群更容易导致会话问题而不是修复它们。
            猜你喜欢
            • 2012-10-18
            • 2013-10-07
            • 2013-01-28
            • 2013-06-13
            • 2011-08-13
            • 1970-01-01
            • 1970-01-01
            • 2013-12-16
            • 2013-11-20
            相关资源
            最近更新 更多