4 Replies Latest reply on Dec 29, 2001 6:35 PM by Adrian Brock

    JBOSS EJB Container Bug ?!

    jeff andrews Newbie

      I have been trying to post my problem, looking for an answer for some time now on defferent forums now, with no answer yet... Please help provide any feedback if you can. As I'm not sure if my current problem is due to a JBOSS container bug, or configuration requirements that I have missed some where.

      ------ My previously posted message -----

      Due to a previouse recommendation on one of these
      Forums,I have upgraded from JBoss_2.4.0-Tomcat_3.2.3
      to JBoss_2.4.3-Jetty_3.1.3-1. I'm running my JBoss
      on Linux.

      My problem/question is; How can I force the container
      configuration size of JBoss for a deployed stateless
      session bean (for example)to not exceed a specified
      MaximumSize, based on what I have defined it to be
      in the jboss.xml file used for deployment??

      I tried many defferent kind of MaximumSizes, but it
      seems to me (from actual performance tests), that no
      matter what I specify as a MaximumSize for my deployed
      stateless session bean, JBoss will always allocate
      a bean instance for each request, even if the number
      of concurrent (client) requests to that bean (pool)
      exceeded the MaximumSize specified for the bean's
      container pool configuration (specified within
      jboss.xml at deployment time)....The same kind of behaviour problem was also found with deployed stateful session beans type as well as deployed entity beans type!!!

      For example:
      If I set the container pool configuration (of my bean)
      MinimumSize = 1, and MaximumSize = 1 (Meaning that
      there should ONLY be one bean instance in the pool to
      be shared among requesting clients).....And then I had
      8 concurrent (clients) requests (at the same time).
      All 8 of those requests were able to get a remote
      reference to a bean instance (and uses it) at the same
      time. As apposed to all 8 sharing the single bean
      instance that should have ONLY bean in the pool...

      What am I messing ?!! Please help.... As I have bean
      struggling with this kind of a problem for over a month


        • 1. Re: JBOSS EJB Container Bug ?!
          Adrian Brock Master


          To answer your question directly. What you are doing
          is correct. By setting the maximum pool size to 8
          there is only ever a maximum of 8 beans in the pool.

          This is not what you want though. Because if all 8 are
          in use, the container will create a further bean to
          process a new request. The point is, it won't put the
          new one back in the pool. It will just discard it.

          What you actually want to control is the number of
          connections, not the pool size.

          I'm not sure of the detailed implementation, but it
          might be possible to do this by using a custom

          See http://www.jboss.org/online-manual/HTML/ch13s131.html

          It should be possible to monitor the number of active
          connections by sub-classing ServerSocket.

          When your server socket is asked to accept()
          you look down previously accepted sockets to see if
          they are closed.
          Provided there are less than eight
          unclosed you accept() on the real server socket.
          Otherwise let the backlog build up until there are
          less than 8 sockets unclosed.

          I've never done anything like this myself, this is just an idea. There may be an easier way to control
          the number of active connections :-)


          • 2. Re: JBOSS EJB Container Bug ?!
            jeff andrews Newbie

            Thanks Adrian;

            "What you actually want to control is the number of
            connections, not the pool size."

            Why not control the pool size instead?
            Otherwise, the purpose of the pool would just be to
            make available a number of instances (pre-
            instantiated) of a bean, in order to save (JUST) the
            cost of it's instantiation when needed. As opposed to
            allowing a control on the maximum number of bean instances that can be allowed to exist (running) within a pool.

            THough what you have suggested could work, I would believe that it would make greater since to allow for
            the option of control where you could always
            explicitly spicify a cap for the maximum number of
            concurrent clients that could run concurrently trying
            to access JBoss's bean resources. This is ofcourse to
            insure performance qualities of a deployed JBoss J2EE
            application, on a specific machine (where it has
            limited resources always). Otherwise, it would be easy
            then (under concurrent client's requests stress), to run over the limited resources that are available within a server that hosts JBoss and it's deployed
            J2EE application. The thing that would easily lead to
            performance degradation, and possibly crashing the


            • 3. Re: JBOSS EJB Container Bug ?!
              Adrian Brock Master


              Having delved a bit deeper, there is an
              that nearly does what you want.
              It only allows one client to access the bean at any
              given time when it is "synchronized".

              This could be used as a basis for a custom instance
              pool to do what you want.
              Except there would be an array of Enterprise Contexts
              and in use flags rather than just one of each.

              The importXml would load the maximum number of clients.

              I wouldn't change the default instance pool.


              • 4. Re: JBOSS EJB Container Bug ?!
                Adrian Brock Master

                Hi Jeff,

                I see from 2.4.4 a new boolean policy flag has been
                added "strictmaximumsize".
                This means the maximumsize controls the active as well
                as the inactive pooled beans.