No Session EJB pooling in WildFly?

[rsoika]

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

[wdfink]

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"  .....

[rsoika]

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?

[wdfink]

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.

[jameslivingston]

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.

[arhan]

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?

[jason.greene]

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.

[rsoika]

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

[rsoika]

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>

[wdfink]

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

[rsoika]

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

[wdfink]

Ralph, you might be right