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

        Hide
        Rob Davies added a comment -

        Fixed by revision 1209700

        Show
        Rob Davies added a comment - Fixed by revision 1209700
        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.
        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
        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 .
        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.
        Hide
        Bruce Snyder added a comment -

        Committed changes in revision 789520 .

        Show
        Bruce Snyder added a comment - Committed changes in revision 789520 .
        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.
        Hide
        Rob Davies added a comment -

        Fixed by SVN revision 692009

        Show
        Rob Davies added a comment - Fixed by SVN revision 692009

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development