3 Replies Latest reply on Jan 13, 2014 7:57 AM by Wolf-Dieter Fink

    Jboss EAP 6.0.2 EJB 3 Configuration

    sudhananthan B Newbie

      From the document provided in Red Hat "Accelerate Your JBoss" in order to tune JBOSS EJB configuration.

       

      In that pdf EJB3 Config value is as below:

       

      <pools>

      <bean-instance-pools>

      <strict-max-pool name="slsb-strict-max-pool" max-pool-size="1300" instance-acquisition-timeout="1" instance-acquisition-

      timeout-unit="MILLISECONDS"/>

      <strict-max-pool name="mdb-strict-max-pool" max-pool-size="180" instance-acquisition-timeout="1" instance-acquisition-

      timeout-unit="MILLISECONDS"/>

      </bean-instance-pools>

      </pools>

      ...

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

      <channel-creation-options>

      <option name="WORKER_READ_THREADS" value="2" type="xnio"/>

      <option name="WORKER_WRITE_THREADS" value="2" type="xnio"/>

      <option name="MAX_INBOUND_MESSAGES" value="165" type="remoting"/>

      <option name="MAX_OUTBOUND_MESSAGES" value="165" type="remoting"/>

      </channel-creation-options>

      </remote>

      ...

      <thread-pools>

      <thread-pool name="default">

      <max-threads count="165"/>

      <keepalive-time time="75" unit="minutes"/>

      </thread-pool>

      </thread-pools>

       

       

      Please any clear my following doubts:

       

      1.       Why keep alive time out is very high "75 Min" where as in default config it is "100 MilliSec"
      2.       Instance-acquisition-timeout is "1 MilliSec" where as in default it is "5 Minutes"

       

       

      Thanks in advance,

      Sudhananthan B

        • 1. Re: Jboss EAP 6.0.2 EJB 3 Configuration
          Wolf-Dieter Fink Master

          There is no EAP6.0.2, which version do you mean?

           

          From the configuration perspective it depends on your requirements how to tune the subsystem and it might be different for you.

           

          1. the number of pooled threads can be keept that long time to avoid permanent destroy/create it

          2. if there in no instance this thread is blocked 5mins by default to wait for a free instance, this might too long. In a well configured environment you may have a warning if you reach a resource bottleneck

          1 of 1 people found this helpful
          • 2. Re: Jboss EAP 6.0.2 EJB 3 Configuration
            sudhananthan B Newbie

            Wolf-Dieter Fink wrote:

             

            There is no EAP6.0.2, which version do you mean?

             

            Sorry the version im using is JBoss-eap-6.1.

             

             

            1. the number of pooled threads can be keept that long time to avoid permanent destroy/create it

            Could you please brief this like what is the purpose of these threads.

             

             

             

            Wolf-Dieter Fink wrote:

            2. if there in no instance this thread is blocked 5mins by default to wait for a free instance, this might too long. In a well configured environment you may have a warning if you reach a resource bottleneck

            "1  MilliSec" is like no wait time. What happens if all bean gets busy and not available to serve.

            • 3. Re: Jboss EAP 6.0.2 EJB 3 Configuration
              Wolf-Dieter Fink Master

              To prevent from creating and destroying threads there is a pool and after an invocation is done the thread will be back to pool and the next invocation can use it.

              So you can configure different thread-pools and set the beans/timers/etc. to work with that pools.

              So you have a bit control how many threads can be run concurrent.

               

              The time to wait come into play if you have more requests than pooled threads. In that case the incomming invocation will wait for this time for a free thread.

              So it depends on your requirement what you configure. In test I prefer 1ms to see imediately that the configuration is too small.

              For production you might give a bit more time to be stable uner load. But be aware that the wait is not fair, you might have an invocation which wait forever.

               

              So you need to find a balance between the warning and the 'slower' handling of incomming calls

              1 of 1 people found this helpful