11 Replies Latest reply on Apr 20, 2016 7:43 AM by Wolf-Dieter Fink

    No Session EJB pooling in WildFly?

    Ralph Soika Apprentice

      Hi,

      I am migrating an application from GlassFish to WildFly. I recognized that the application was a little bit slower in WildFly that it is in GlassFish. After a lot of performance analyzing (using visualVM) I find out that my Session EJBs seems not to be pooled in WildFly?.

      My application contains some central Session EJBs. These EJBs have a time consuming init method:

       

      @PostConstruct
        void initIndex() throws AccessDeniedException {
        // create necessary index entities
        entityService.addIndex("numProcessID", EntityIndex.TYP_INT);
        entityService.addIndex("numActivityID", EntityIndex.TYP_INT);
        entityService.addIndex("$modelversion", EntityIndex.TYP_TEXT);
        }
      

       

      In GlassFish this method is only called once the first time a method of this Session EJB is called. After that the bean is pooled and the initIndex() method will not be called again until a new bean instance is created.

      In WildFly each time a method is called also the initIndex() method is triggered? So it seems to me that there is no EJB Pool used by the container. Did I missed something in my configuration?

       

      Nevertheless, WildFly is much faster in any method call than GlassFish. This was one reason why it takes me so much time to recognize that my WIldFly did not use EJB pooling.

       

      Thanks for any help how to configure or verify my EJB container settings.

       

      ===
      Ralph

        • 1. Re: No Session EJB pooling in WildFly?
          Wolf-Dieter Fink Master

          Looks like it is removed in WildFly 8.

          Problem is that there is only a strict-max-pool implementation which limits the maximum numbers of beans. If you don*t have a expensive initialization it does not male a difference.

          But you should able to add the pool to your configuration (ejb3 subsystem) like followed

            <session-bean>

              <stateless>

                <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>

              </stateless>

              ...

              <bean-instance-pools>

                <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20"  .....

          • 2. Re: No Session EJB pooling in WildFly?
            Ralph Soika Apprentice

            Thank a lot!!!
            The speed of WildFly now is really impressive!
            But do you not think that pooling of stateless EJBs is a fundamental concept of the EJB container? Wouldn't it make sense to make this setting a default setting in the standalone.xml file?

            Should we therefore open a new issue?


            • 3. Re: No Session EJB pooling in WildFly?
              Wolf-Dieter Fink Master

              As I said in my last comment there is no big difference if you have no initialization. So the decision was to remove it, somewhere between the first version and WildFly9.

              • 4. Re: No Session EJB pooling in WildFly?
                James Livingston Apprentice

                In addition to what Wolf said, that if you only have EJBs with cheap initialization then not having pooling can be better, the obvious question is how large the pool should be. In prior versions, the default pool size was 30, which was a completely arbitrary number. For many real servers 30 is not a good value, so you probably should have adjusted it anyway.

                • 5. Re: No Session EJB pooling in WildFly?
                  Anton Arhipov Newbie

                  I'm playing with WildFly 8.2/9.1 and encountered the same issue. And by enabling the pooling support for stateless EJBs I still see that the invocations are executed in the same thread. I assume then that EJBs are still not pooled. Why's that?

                  • 6. Re: No Session EJB pooling in WildFly?
                    Jason Greene Master

                    Regardless of SFSB instance pooling the same thread is always used for local invocation (and also for remote invocation which calls beans on the same JVM), In the case of true remote invocation, the caller is always blocked until the invocation is returned. If you would like to keep the caller unblocked, there is an asynchronous  facility in EJB that schedules the work in a different thread pool.

                    • 7. Re: No Session EJB pooling in WildFly?
                      Ralph Soika Apprentice

                      I can confirm that EJB Pooling is not working in Wildfly 9.0.2.Final.

                      I use the following poos settings which worked great in Wildfly 8:

                       

                        <subsystem xmlns="urn:jboss:domain:ejb3:3.0">
                                  <session-bean>
                                      <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/>
                                      <singleton default-access-timeout="5000"/>
                                  </session-bean>
                                  <pools>
                                      <bean-instance-pools>
                                          <strict-max-pool name="slsb-strict-max-pool" max-pool-size="32" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                                          <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                                      </bean-instance-pools>
                                  </pools>
                      .......
                      

                       

                      ===
                      Ralph

                      • 8. Re: No Session EJB pooling in WildFly?
                        Ralph Soika Apprentice

                        Ok now figured out that my configuration was missing an important part. You need to make sure, that also the pool-name is set to 'slsb-strict-max-pool'. This is not the case for Wildfly 9.x per default. So you have to add this setting manually. The correct setting for the standalone.xml file in the jboss:domain:ejb section have to look like this:

                         

                         

                                  <session-bean>
                                        <stateless>
                                            <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
                                        </stateless>
                                        <stateful default-access-timeout="5000" cache-ref="simple" passivation-disabled-cache-ref="simple"/>
                                        <singleton default-access-timeout="5000"/>
                                    </session-bean>
                                    <pools>
                                        <bean-instance-pools>
                                            <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                                            <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                                        </bean-instance-pools>
                                    </pools>
                        
                        • 9. Re: No Session EJB pooling in WildFly?
                          Wolf-Dieter Fink Master

                          Note the drawback is that you block invocations if you have too many SFSB active, in oposite to SLSB the SFSB are blocked until the client call a @Remove annotated method or the bean is passivated. For SLSB the instance is back to pool after the invocation.

                           

                          So it can be a huge performance issue

                          • 10. Re: No Session EJB pooling in WildFly?
                            Ralph Soika Apprentice

                            Did you mean with SFSB Stateful Session Beans? If yes, I agree with you. But I did not make use of Stateful Session Beans. I am only dealing with Stateless Session Beans. What I have recognized is, that the default setting to activate the 'slsb-strict-max-pool' is missing in the standalone.xml file of WildFly 9.x and Wildfly 8.x but it is now defined in Wildfly 10.0.0.Final.

                            You can argue that it is untypically to use the '@PostConstruct' annotation for stateless session beans. But after all it brought me to the fact, that the pool settings are missing in older Wildfly releases. And however, after I did some profiling with visualvm I saw that activating a stateless session ejb in wildfly is not as fast as you may think. The activating of the stateless session bean took much more cpu time that my internal method call of my '@PostConstruct' init() method. So at the end I think activating the stateful session bean pool is a good choice and increases the response time of the wildfly ejb container dramatically.


                            ===

                            Ralph




                            • 11. Re: No Session EJB pooling in WildFly?
                              Wolf-Dieter Fink Master

                              Ralph, you might be right