3 Replies Latest reply on Jun 1, 2018 11:19 AM by Jeremy Whiting

    Widlfly 10.1.0 final Memory Leak Suspect.

    Sumeeth Tewar Newbie

      I have deployed my application on Wildfly 10.1.0 final, and after 1 hour of performance testing, the system goes extremely slow.

      I extracted a heapdump and analysed seems there is a memory leak suspect :

       

       

      8,443 instances of "io.undertow.server.session.InMemorySessionManager$SessionImpl", loaded by "org.jboss.modules.ModuleClassLoader @ 0x68050b0b8" occupy 2,946,969,904 (59.05%) bytes.

       

      Keywords

      org.jboss.modules.ModuleClassLoader @ 0x68050b0b8

      io.undertow.server.session.InMemorySessionManager$SessionImpl

       

       

      Can you please let me know if there is any fix for this issue? Seems there was a issue reported on it earlier via bug ID:

       

      https://issues.jboss.org/browse/UNDERTOW-657

       

      however this should be fixed in undertow version 1.3.18 but I have version 1.40.22 bundled in the Wildfly.

      Can you please guide?

        • 1. Re: Widlfly 10.1.0 final Memory Leak Suspect.
          Tomaz Cerar Master

          1.4.22 bundled in WildFly? how did you do that? replace the io.undertow.* modules? or in your application?

           

          in any case, best solution, would be to upgrade WildFly to newer version.

          • 2. Re: Widlfly 10.1.0 final Memory Leak Suspect.
            Sumeeth Tewar Newbie

            Bundled 1.4.22 in the Wildfly modules.

            Upgrading Wildfly is not an option at this point unfortunately.

            • 3. Re: Widlfly 10.1.0 final Memory Leak Suspect.
              Jeremy Whiting Expert

              Hi,

              It is very likely you are seeing the live sessions consuming memory. Which is perfectly normal situation.

               

              There is a configuration option in Wildfly to manage when a session will be timed out. Using this avoids large numbers of sessions hanging around.

               

              Try setting session-timeout in your web application web.xml

               

                  <session-config>

                      <session-timeout>CHANGE_ME</session-timeout>

                  </session-config>

               

              The default timeout is 30 minutes.

               

              Try reducing that to a smaller value than 30. Then try running your performance test again.

              What you are aiming for is a stable number of live sessions and stable server performance. You discovered the amount using a heapdump. To find the optimal number you might have to repeat the test with different values until you achieve acceptable performance over a long period of time.