[GLASSFISH-20697] If JMS connection factory setting is changed, all pooled connections are disconnected Created: 12/Jul/13  Updated: 19/Sep/14  Resolved: 31/Jul/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: tak09 Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Windows 7
Glassfish 4.0


When a JMS connection is created on Web or EJB container, connections are pooled in the JMS connection factory.

If a JMS connection factory setting (ie, maximum pool size) is changed, all the pooled connections are disconnected.

Conditions for reproducing bug:
(1) Create a new connection using JMS connection factory on Web or EJB container. AND
(2) Update following settings for the first time.

  • Initial and Minimum Pool Size
  • Maximum Pool Size
  • Pool Resize Quantity
  • Idle Timeout
  • Max Wait Time
  • On Any Failure
  • Transaction Support
  • Additional Properties

Note that the connections are not disconnected when updating the JMS connection factory setting on second time or later while the server instance is running.

Steps reproduce:
1. Create a Connection Factory.
asadmin create-jms-resource --restype javax.jms.Queue --property Name=PhysicalQueue jms/Queue
asadmin create-jms-resource --restype javax.jms.ConnectionFactory jms/ConnectionFactory

2. Set the Connection Pool Initial and Minimum Pool Size. This is set as 8 so that it is easier to find bug which causes disconnection in pool.
asadmin set resources.connector-connection-pool.jms/ConnectionFactory-Connection-Pool.steady-pool-size=8

3. Check the number of connections.
imqcmd list cxn

4. Deploy the test program.
asadmin deploy cfdisconnected.war

5. Open web browser and connect to the Servlet.

6. Check the number of connections.
imqcmd list cxn
There are 8 more connections compared with step 3.

7. Change the Maximum Pool Size from default (250) to 16.
asadmin set resources.connector-connection-pool.jms/ConnectionFactory-Connection-Pool.max-pool-size=16

8. Check the number of connections.
imqcmd list cxn
The bug is found at the step. The 8 connections have been disconnected and not listed.
Expected result is that the 8 connections are maintained.

Comment by tak09 [ 12/Jul/13 ]

Test program

Comment by tak09 [ 12/Jul/13 ]

Please download the cfdisconnected.war from the above site.

Comment by David Zhao [ 15/Jul/13 ]

I think it is not a bug. If you repeat step 5 and 6 after step 8, then you will see the servlet can get new jms connections successfully and steady pool size becomes 8 again. The pooled connections are managed by JCA runtime internally, the number of active connections is dynamic based on an algorithm. So when the pool properties are changed, the behaviors of existing connections - whether the number changes, or destroy/recreate, are expected.

Comment by tak09 [ 25/Jul/13 ]

Hi David,

I still think it is a bug as the same problem does not ocurr in JDBC connection pool.

I have created a sample program which does the following.

  • Get Connction from JDBC Connection Pool.
  • Wait 60 sec. A user updates JDBC setting from Glassfish WebAdmin.
  • SQL is executed successfully as connection is maintained.

Caused by: org.apache.derby.client.am.SqlException
ocurrs if disconnected.

I have created a test program.

Please try this.
1. Start glassfish and database
asadmin start-domain
asadmin start-database

2. Deploy the test program.
asadmin deploy HelloJDBC.war

3. Open URL in browser.

4. Change JDBC connection pool setting while waiting 60 sec message is displayed.

5. SQL is executed successfully.

I have also done the same step in JMS.
Please try this.
1. Deploy the test program.
asadmin deploy HelloJMS.war

2. Open URL in browser.

3. Change JMS connection pool setting while waiting 60 sec message is displayed.

4. Error message is displayed due to disconnection.

If you repeat step 2-4 again, you will not see the error on second time and after. Why it does not work on 1st time?

Comment by tak09 [ 25/Jul/13 ]

Please download the test programs at this website.


Comment by David Zhao [ 29/Jul/13 ]


Should step 5.2 in your latest case be accessing HelloJMS instead?

5.2. Open URL in browser.

Comment by David Zhao [ 29/Jul/13 ]

The latest new added case shows a Connector Runtime issue that it filters out jmsra MCF addresslist=localhost property when pool is redeployed, but the property is not filtered out when the pool is initialized, thus the first pool redeployment will trigger recreating all the connections in the pool.

Comment by tak09 [ 30/Jul/13 ]

Hi David,

Sorry, I made mistake while writing the instructions. HelloJMS is correct.

Comment by Jagadish [ 31/Jul/13 ]

Thanks David and Tak09 for the investigation and steps to reproduce the issue.
I have now provided a fix.


svn log -v -r 62432
r62432 | jr158900 | 2013-07-31 10:56:57 +0530 (Wed, 31 Jul 2013) | 6 lines
Changed paths:
M /trunk/main/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/service/ConnectorConnectionPoolAdminServiceImpl.java
M /trunk/main/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/util/ConnectorDDTransformUtils.java
M /trunk/main/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/ConnectorConnectionPoolDeployer.java

GLASSFISH-20697 : If JMS connection factory setting is changed, all pooled connections are disconnected

+ Commented unused methods.

Generated at Fri Oct 09 07:14:11 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.