Qpid
  1. Qpid
  2. QPID-3659

Java client mishandles tcp_nodelay when specified as part of the broker URL

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.15
    • Fix Version/s: 0.15
    • Component/s: Java Client
    • Labels:
      None

      Description

      When tcp_nodelay is set as part of the broker's address, the performance of the client drops badly, no matter whether the value is set to 'true' or 'false'. I assume that the parameter is being mishandled and is tuning off the tcp_nodelay property (which is by default on) even when set to 'true'.

      amqp://guest:guest@/test?brokerlist='tcp://20.0.10.43?tcp_nodelay=true'

      returns serialised get-put cycles onto a single queue at the rate of 25/sec, but

      amqp://guest:guest@/test?brokerlist='tcp://20.0.10.43'

      returns 3017/sec under otherwise identical conditions.

      I assume that the lower performance figure is consistent with tcp_nodelay not being active in this test case.

        Activity

        Hide
        Robbie Gemmell added a comment -

        AFAIK you need to single quote the value when specifying stuff in there, eg tcp_nodelay='true'. See if that makes any difference.

        Show
        Robbie Gemmell added a comment - AFAIK you need to single quote the value when specifying stuff in there, eg tcp_nodelay='true'. See if that makes any difference.
        Hide
        Rajith Attapattu added a comment -

        It is indeed due to not being quoted properly.
        However due to the really convoluted syntax there is an increased risk of people screwing up.
        If the default value is false then it's a different matter, but in this case the default value for TCP_NODELAY is true (from the 0.14 release).
        Therefore any mistake by the end user will turn off TCP_NODELAY.

        Show
        Rajith Attapattu added a comment - It is indeed due to not being quoted properly. However due to the really convoluted syntax there is an increased risk of people screwing up. If the default value is false then it's a different matter, but in this case the default value for TCP_NODELAY is true (from the 0.14 release). Therefore any mistake by the end user will turn off TCP_NODELAY.

          People

          • Assignee:
            Rajith Attapattu
            Reporter:
            Kim van der Riet
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development