3 Replies Latest reply on Apr 10, 2006 10:40 PM by starksm64

    JBAS-3089, JBAS-2500 PooledInvokerProxy issues

    starksm64

      The change to the PooledInvokerProxy for JBAS-2500 essentially broke pooling: http://jira.jboss.com/jira/browse/JBAS-3089
      There is also no testcase for the JBAS-2500 issue.

      Every ejb create now results in a PooledInvokerProxy that has its own connection pool, and so the max number of connections is 300 x Ncreates by default. More typically what ends up happening is that there are several unpooled connections when there is a rapid ejb create, single method use, remove cycle.

      The better fix would be to use an HA award ServerAddress as the key into the PooledInvokerProxy connection map. Need to investigate how this can be done with backward compatibility.

        • 1. Re: JBAS-3089, JBAS-2500 PooledInvokerProxy issues
          starksm64

          The ServerAddress is not a function of HA/non-HA and is a valid key. The problem is that the PooledInvokerProxy keeps a reference to the pool for the first ServerAddress that results in a connection lookup. What should happen is that the connection pool is looked up each time, and the ClientSocket should know what pool its associated with.

          • 2. Re: JBAS-3089, JBAS-2500 PooledInvokerProxy issues

            I agree that change for JBAS-2500 could have been better (and think adding pooling over the different clients should be added back in). However, I don't see this as being a major issue because the client pool populated as needed (meaning if only make one call on the client, only one connection in the pool). The pool only grows when making concurrent calls using the same client. Biggest problem is that if do have a burst of concurrent calls on the client, those connections stored in the pool won't go away till there is a timeout on the connection.

            I noticed you assigned to yourself. Do you want to handle it or can I take it?

            • 3. Re: JBAS-3089, JBAS-2500 PooledInvokerProxy issues
              starksm64

              It is not just concurrent access that causes the problem. If I just have a loop creating ejbs I create a connection per loop iteration. There is no pooling which is what a user reported. I'm in the middle of the change so I'll do it.