1 Reply Latest reply on Sep 19, 2013 7:51 AM by Veit Guna

    JBoss 7.1.3 remote EJB call and strict-max-pool not respected?

    Veit Guna Newbie

      Hi.

       

      I'm using JBoss 7.1.3 with a SLSB and configured a separate strict-max-pool for this bean using standalone-full.xml.

      This pool is referenced by jboss-ejb3.xml for this specific bean. The pool is restricted to n instances and has a acquisition-timeout of 1 second.

      For a "pool test", the SLSB does a thread.sleep on the method that is invoked.

       

      When I call this bean locally on the server n+1 times with n+1 threads in parallel, the last invocation fails as expected (pool exhausted).

      But when I do the same via remote EJB Client, this exception is not thrown. All invocations are performed successfully. It seems that the

      configured pool is not respected for remote calls (as with local calls). I can see, that it "waits" after 20 invocations for the next bean to become available.

      Since n is < 20 it seems that it uses the default stateless pool (slsb-strict-max-pool) that is configured with 20 in standalone-full.xml.

       

      Can somebody confirm this behavior? Any idea what I'm doing wrong?

       

      Thanks.

        • 1. Re: JBoss 7.1.3 remote EJB call and strict-max-pool not respected?
          Veit Guna Newbie

          Ok, found the root of the problem.

           

          Since the call is from the remote client, an additional thread-pool exists for remote invocations:

           

          <remote connector-ref="remoting-connector" thread-pool-name="default"/>

           

          The default pool is configured with 10. In my tests, the separate SLSB pool was also configured with 10 .

          So it could never happen, that the SLSB got exhausted via remote calls, because the default thread pool already blocked and didn't allow the 11th call to be routed to the SLSB pool.

          It simply waited for the next thread to be freed. So I increased the thread pool to 20 and I got the expected result.

           

          Sorry for any inconvenience.