1 Reply Latest reply on Apr 9, 2013 1:57 AM by jaikiran

    Thread Pool for EJB works unexpectedly

    erhard

      Hi,

      I looked at /subsystem=ejb3/thread-pool=default. It is used when EJBs are invoked from a remote client:

      After the starting JBoss it shows:

       

      /subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true)

      {

          "outcome" => "success",

          "result" => {

              "active-count" => 0,

              "completed-task-count" => 0L,

              "current-thread-count" => 0,

              "keepalive-time" => {

                  "time" => 100L,

                  "unit" => "MILLISECONDS"

              },

              "largest-thread-count" => 0,

              "max-threads" => 10,

              "name" => "default",

              "queue-size" => 0,

              "rejected-count" => 0,

              "task-count" => 0L,

              "thread-factory" => undefined

          }

       

      I have an ejb that just waits for a few seconds and I start a client that uses two paralles threads which loop and call the ejb.

      I would expect that I get the following values while the client runs:

              "active-count" => 2,

              "current-thread-count" => 2,

              "largest-thread-count" => 2,

              "max-threads" => 10,

       

      The thread-count should not be larger than 2 (or a little higher) since I expect the threads to be reused. However I get:

       

              "active-count" => 2,

              "completed-task-count" => 2L,

              "current-thread-count" => 4,

              "keepalive-time" => {

                  "time" => 100L,

                  "unit" => "MILLISECONDS"

              },

              "largest-thread-count" => 4,

              "max-threads" => 10,

              "name" => "default",

              "queue-size" => 0,

              "rejected-count" => 0,

              "task-count" => 4L,

       

      Next:

              "active-count" => 2,

              "completed-task-count" => 4L,

              "current-thread-count" => 6,

              "keepalive-time" => {

                  "time" => 100L,

                  "unit" => "MILLISECONDS"

              },

              "largest-thread-count" => 6,

              "max-threads" => 10,

              "name" => "default",

              "queue-size" => 0,

              "rejected-count" => 0,

              "task-count" => 6L,

       

      Next:

              "active-count" => 2,

              "completed-task-count" => 6L,

              "current-thread-count" => 8,

              "keepalive-time" => {

                  "time" => 100L,

                  "unit" => "MILLISECONDS"

              },

              "largest-thread-count" => 8,

              "max-threads" => 10,

              "name" => "default",

              "queue-size" => 0,

              "rejected-count" => 0,

              "task-count" => 8L,

       

      Next:

              "active-count" => 2,

              "completed-task-count" => 8L,

              "current-thread-count" => 10,

              "keepalive-time" => {

                  "time" => 100L,

                  "unit" => "MILLISECONDS"

              },

              "largest-thread-count" => 10,

              "max-threads" => 10,

              "name" => "default",

              "queue-size" => 0,

              "rejected-count" => 0,

              "task-count" => 10L,

       

      Indeed 10 threads are created even when only two are used at the same time:

       

      jstack 4381 | grep EJB

      "EJB default - 10" prio=10 tid=0x00007fef540bb800 nid=0x12dc waiting on condition [0x00007fef4d6c1000]

      "EJB default - 9" prio=10 tid=0x0000000041f4a800 nid=0x12db waiting on condition [0x00007fef4d8c3000]

      "EJB default - 8" prio=10 tid=0x00007fef3805f800 nid=0x12da waiting on condition [0x00007fef4d3a7000]

      "EJB default - 7" prio=10 tid=0x00007fef3805e000 nid=0x12d9 waiting on condition [0x00007fef4ce17000]

      "EJB default - 6" prio=10 tid=0x00007fef540b9000 nid=0x12d8 waiting on condition [0x00007fef4c50d000]

      "EJB default - 5" prio=10 tid=0x0000000041fd3000 nid=0x12d7 waiting on condition [0x00007fef4cb31000]

      "EJB default - 4" prio=10 tid=0x00007fef44047000 nid=0x12d4 waiting on condition [0x00007fef4cf61000]

      "EJB default - 3" prio=10 tid=0x00007fef38067800 nid=0x12d3 waiting on condition [0x00007fef4d7c2000]

      "EJB default - 2" prio=10 tid=0x00007fef540ae800 nid=0x12d2 waiting on condition [0x00007fef4c89a000]

      "EJB default - 1" prio=10 tid=0x00007fef540a4000 nid=0x12d1 waiting on condition [0x00007fef4d1a3000]

       

      The second unexpeded beehavior is that the threads are not removed after keepalive-time:

      "keepalive-time"

                      "description" => "Used to specify the amount of time that pool threads should be kept running when idle; if not specified, threads will run until the executor is shut down."

       

      Although the time is specified, the threads stay forever.

       

       

      The third thing is related to the documentation of max-threads:

                  "max-threads" => {

                      "restart-required" => "no-services"

       

      When I change this without restart and start a client with lots of parallel threads, I get:

              "active-count" => 10,

              "completed-task-count" => 155L,

              "current-thread-count" => 10,

              "keepalive-time" => {

                  "time" => 100L,

                  "unit" => "MILLISECONDS"

              },

              "largest-thread-count" => 10,

              "max-threads" => 33,

              "name" => "default",

              "queue-size" => 17,

              "rejected-count" => 0,

              "task-count" => 182L,

              "thread-factory" => undefined

       

       

      active-count and largest-thread-count are still 10 althought queue-size is 17 and max-threads is 33. After a restart more than 10 threads are started.

       

      Btw. The behavior is the same in EAP 6.0.1.

       

       

      Regards

      Erhard