See https://issues.jboss.org/browse/AS7-4330.  You'll either have to use a nightly build or pull JBoss AS and build it yourself to get the fix at this point since there is no release which contains it.

That said, I'm curious what your threads are doing with the connections from the JmsXA connection factory.  Typically a thread will use a connection and then release it quickly so that other threads can use it.  Doing so typically allows more threads to run without issue than connections exist in the pool (e.g. 40 threads accessing a pool of 20 connections with minimal waiting).  However, it sounds like your threads are holding on to the connections and not releasing them.  Can you clarify?

Lastly, the HornetQ doc doesn't specifically address the JmsXA connection factory because it is a JCA connection factory and is therefore managed by the application server (i.e. all the pooling is provided by the server's JCA implementation, not by the HornetQ JCA RA).  See the AS7 docs for more info on it.

hi,

I think I run into the same issue off the pool size, basically I didn't get it so far, but right now I am doing a stress test that basically tries to open up 1000s of threads.

I have 2 questions:

1. do you know how I can extract this fix only? because I took the latest nightly build and although I configured my messaging to work without security I get errors saying that MDBs cannot be open because user null is not authenticated and it doesn't recognize an alternate deployment folder I set - so I look for a way not to introduce many changes and just try out this change
2. I was using the JmsXA because I thought it will cause the transaction to fail if the sending or reading from the queue failed - am I using it wrong?
   1. I see that in the wiki you wrote that the JmsXA is rrecommended  for reading messages - which connection factory is recommended for writing messages?

thanks,

Noa

The fix appears to be spread across 2 different commits:

1. https://source.jboss.org/changelog/JBossAS?cs=12d8a7345df6e4bd353a90c851f3e7d1a9a21a59
2. https://source.jboss.org/changelog/JBossAS?cs=2f08d5a2874926f7a139386fafe0bd1247397138

I believe that the JmsXA pooled-connection-factory supports XA by default (it can certainly be configured this way if it isn't this way by default) so if one of the other resources in the transactions fails then the commit on JmsXA should fail as well.

Where did you see that I wrote that JmsXA is recommended for reading messages?  The opposite is true.  JmsXA should only be used for sending messages.

Hi,

I applied this fix to my env but i still get this error.

this is the code i merged:

...

package org.jboss.as.messaging.jms;
 ...
public class PooledConnectionFactoryService implements Service<Void> {

 ...
    private static CommonConnDef createConnDef(String jndiName) throws ValidateException {
              /*
               * Start Code change
               *
               * The purpose of the change is to enable setting the min and max thread pool size for a pooled connection factory
               * 
               * Old Line : CommonPoolImpl pool = new CommonPoolImpl(null, null, false, false, FlushStrategy.FAILING_CONNECTION_ONLY);
               * 
               */

              // Get the values from the system properties 
              String minPoolSizeStr = System.getProperty("min.pool.size");
              String maxPoolSizeStr = System.getProperty("max.pool.size");

              // Convert the values to Integer
              Integer minPoolSize = minPoolSizeStr==null ? null : new Integer(minPoolSizeStr);
              Integer maxPoolSize = maxPoolSizeStr==null ? null : new Integer(maxPoolSizeStr);



              CommonPoolImpl pool = new CommonPoolImpl(minPoolSize, maxPoolSize, false, false, FlushStrategy.FAILING_CONNECTION_ONLY);

              /*
               * End  code change
               */

        ...
    }

 ...
}

If I look at the java process in perfmon i see that it has about 250 threads in total - and i set the max thread pool to 1000.

so i thought this should be OK - but turns out it doesn't.

can you help me find other areas to look for in order to resolve this issue?

Thanks,

Noa

The default max pool size is 20 so if you are seeing upwards of 250 threads concurrently using connections from JmsXA then I would conclude that your changes are working.  Whether or not you can push it to 1000 depends on your testing procedure. 

Remember, a pooled-connection-factory is a pool of objects, not threads.  Whatever you're doing to push the thread count up needs to be able to get to 1000 threads if you expect to use 1000 connections.