ActiveMQ
  1. ActiveMQ
  2. AMQ-1928

Limit the maximum number of connections to a Broker

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.1, 4.1.2, 5.0.0, 5.1.0
    • Fix Version/s: 5.6.0
    • Component/s: None
    • Labels:
      None

      Description

      Add a property (maximumConnections) to TcpTransportSever to limit a maximum number of active connections

        Activity

        Rob Davies created issue -
        Hide
        Rob Davies added a comment -

        Fixed by SVN revision 692009

        Show
        Rob Davies added a comment - Fixed by SVN revision 692009
        Rob Davies made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Bruce Snyder added a comment -

        This issue was originally raised by me on the mailing list as a way to limit the number of client connections into the broker. A variable and a condition was added to provide this functionality and can be used as follows:

        <transportConnector name="openwire" uri="tcp://localhost:61616?maximumConnections=100" />
        

        Unfortunately, when the max number of connections is exceeded, there is no information to indicate what happened. Below is an example of the exception that is thrown:

        javax.jms.JMSException: Channel was inactive for too long: localhost/127.0.0.1:61616
          at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62)
          at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1255)
          at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1339)
          at org.apache.activemq.ActiveMQConnection.start(ActiveMQConnection.java:488)
          at ConsumerTool.run(Unknown Source)
          at ConsumerTool.main(Unknown Source)
        Caused by: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too long: localhost/127.0.0.1:61616
          at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:225)
          at org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:83)
          at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:100)
          at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
          at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:74)
          at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:79)
          at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1233)
          ... 4 more
        

        This exception is completely generic and provides no information about why the failure occurred. The reason for this that the conditional block is completely empty:

        try {
                    if (this.currentTransportCount >= this.maximumConnections) {
                        throw new ExceededMaximumConnectionsException(maximumConnections); 
                    }else {
        ...
        

        Therefore I'm reopening issue in order to create a good exception for the failure so that users can identify the specific failure.

        Show
        Bruce Snyder added a comment - This issue was originally raised by me on the mailing list as a way to limit the number of client connections into the broker. A variable and a condition was added to provide this functionality and can be used as follows: <transportConnector name= "openwire" uri= "tcp: //localhost:61616?maximumConnections=100" /> Unfortunately, when the max number of connections is exceeded, there is no information to indicate what happened. Below is an example of the exception that is thrown: javax.jms.JMSException: Channel was inactive for too long : localhost/127.0.0.1:61616 at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:62) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1255) at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1339) at org.apache.activemq.ActiveMQConnection.start(ActiveMQConnection.java:488) at ConsumerTool.run(Unknown Source) at ConsumerTool.main(Unknown Source) Caused by: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too long : localhost/127.0.0.1:61616 at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:225) at org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:83) at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:100) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40) at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:74) at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:79) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1233) ... 4 more This exception is completely generic and provides no information about why the failure occurred. The reason for this that the conditional block is completely empty: try { if ( this .currentTransportCount >= this .maximumConnections) { throw new ExceededMaximumConnectionsException(maximumConnections); } else { ... Therefore I'm reopening issue in order to create a good exception for the failure so that users can identify the specific failure.
        Bruce Snyder made changes -
        Status Resolved [ 5 ] Reopened [ 4 ]
        Assignee Rob Davies [ rajdavies ] Bruce Snyder [ bsnyder ]
        Resolution Fixed [ 1 ]
        Bruce Snyder made changes -
        Fix Version/s 5.3.0 [ 11914 ]
        Fix Version/s 5.2.0 [ 11841 ]
        Hide
        Bruce Snyder added a comment -

        Committed changes in revision 789520 .

        Show
        Bruce Snyder added a comment - Committed changes in revision 789520 .
        Bruce Snyder made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Bruce Snyder added a comment -

        Reopening again because I forgot to throw a better exception back to the client side.

        Show
        Bruce Snyder added a comment - Reopening again because I forgot to throw a better exception back to the client side.
        Bruce Snyder made changes -
        Status Resolved [ 5 ] Reopened [ 4 ]
        Resolution Fixed [ 1 ]
        Hide
        Bruce Snyder added a comment -

        Backed out revision 789520 because I mistakenly made a commit to the 5.2.0 tag.

        I've moved the change for the broker-side exception to the trunk via revision 789851.

        Show
        Bruce Snyder added a comment - Backed out revision 789520 because I mistakenly made a commit to the 5.2.0 tag. I've moved the change for the broker-side exception to the trunk via revision 789851 .
        Rob Davies made changes -
        Fix Version/s 5.4.0 [ 12110 ]
        Fix Version/s 5.3.0 [ 11914 ]
        Hide
        Konstantin Skaburskas added a comment -

        Hi,

        Could you please let us know what is the time line of providing the exception for clients?

        If I interpret "Fix Version/s: 5.4.0" correctly then, this means to be fixed in 5.4.0. What would be an approximate date for the release?

        We see there still no proper exception for client in apache-activemq-5.3.1, when setting this
        <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=2"/>

        after sometime client just bails out with
        javax.jms.JMSException: Wire format negotiation timeout: peer did not send his wire format.

        Will it work for STOMP as well?

        Thank you,
        Konstantin

        Show
        Konstantin Skaburskas added a comment - Hi, Could you please let us know what is the time line of providing the exception for clients? If I interpret "Fix Version/s: 5.4.0" correctly then, this means to be fixed in 5.4.0. What would be an approximate date for the release? We see there still no proper exception for client in apache-activemq-5.3.1, when setting this <transportConnector name="openwire" uri="tcp://0.0.0.0:61616?maximumConnections=2"/> after sometime client just bails out with javax.jms.JMSException: Wire format negotiation timeout: peer did not send his wire format. Will it work for STOMP as well? Thank you, Konstantin
        Rob Davies made changes -
        Fix Version/s 5.4.0 [ 12110 ]
        Fix Version/s NEEDS_REVIEWED [ 12186 ]
        Hide
        Gary Tully added a comment -

        It will work for stomp but the issue of returning an exception requires full connection setup, the server has to accept the socket connection, do open wire version negotiation and serialise an exception. This will take some time that would be better spent dealing with the existing connections.

        Show
        Gary Tully added a comment - It will work for stomp but the issue of returning an exception requires full connection setup, the server has to accept the socket connection, do open wire version negotiation and serialise an exception. This will take some time that would be better spent dealing with the existing connections.
        Jeff Turner made changes -
        Project Import Fri Nov 26 22:32:02 EST 2010 [ 1290828722158 ]
        Rob Davies made changes -
        Assignee Bruce Snyder [ bsnyder ] Rob Davies [ rajdavies ]
        Rob Davies made changes -
        Fix Version/s 5.6.0 [ 12317974 ]
        Fix Version/s NEEDS_REVIEWED [ 12315630 ]
        Hide
        Rob Davies added a comment -

        Fixed by revision 1209700

        Show
        Rob Davies added a comment - Fixed by revision 1209700
        Rob Davies made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        21h 13m 1 Rob Davies 04/Sep/08 15:31
        Resolved Resolved Reopened Reopened
        298d 9h 22m 2 Bruce Snyder 30/Jun/09 02:24
        Reopened Reopened Resolved Resolved
        885d 21h 42m 2 Rob Davies 02/Dec/11 21:37

          People

          • Assignee:
            Rob Davies
            Reporter:
            Rob Davies
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development