Qpid Proton
  1. Qpid Proton
  2. PROTON-278

Messenger - allow the application to control the use of the message reply-to field.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.4
    • Fix Version/s: 0.6
    • Component/s: proton-c
    • Labels:

      Description

      Currently, messenger always sets the reply-to field in a sent message.

      This should be changed to allow the application to set the reply-to field only when a reply is desired. Messenger should be changed to not unconditionally set this field.

      In order to set this field in the case of a client that has not established a subscription, the client needs to be able to query messenger for the proper value of the reply-to address. A new api would need to be created for this. Proposal:

      int pn_messenger_set_reply( pn_messenger_t *msgr, pn_message_t *msg )

      Set the proper reply-to address in msg. msg would need to have its "to" address configured in order for this method to succeed.

      At least, I think the value for the reply-to may depend on the 'to' address... I may be wrong about that....

      Opinions?

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        207d 46m 1 Rafael H. Schloming 21/Oct/13 16:35
        Rafael H. Schloming made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        ASF subversion and git services added a comment -

        Commit 1534224 from rhs@apache.org in branch 'proton/trunk'
        [ https://svn.apache.org/r1534224 ]

        PROTON-278: fixed reply-to expansion to not expand unset reply-to addresses

        Show
        ASF subversion and git services added a comment - Commit 1534224 from rhs@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1534224 ] PROTON-278 : fixed reply-to expansion to not expand unset reply-to addresses
        Rafael H. Schloming made changes -
        Issue Type Improvement [ 4 ] Bug [ 1 ]
        Rafael H. Schloming made changes -
        Priority Blocker [ 1 ] Critical [ 2 ]
        Rafael H. Schloming made changes -
        Assignee Rafael H. Schloming [ rhs ]
        Rafael H. Schloming made changes -
        Fix Version/s 0.6 [ 12324883 ]
        Rafael H. Schloming made changes -
        Labels reply-to
        Rafael H. Schloming made changes -
        Field Original Value New Value
        Fix Version/s 0.5 [ 12324004 ]
        Hide
        Ted Ross added a comment -

        A second alternative is to provide a special "put" call that sets the reply-to and prepares any needed incoming links:

        pn_messenger_put_request(pn_messenger_t *messenger, pn_message_t *msg);

        Show
        Ted Ross added a comment - A second alternative is to provide a special "put" call that sets the reply-to and prepares any needed incoming links: pn_messenger_put_request(pn_messenger_t *messenger, pn_message_t *msg);
        Hide
        Ted Ross added a comment - - edited

        An alternative API is to add a method on the pn_message_t:

        pn_message_expect_reply(pn_message_t *msg);

        This removes the need to sequence the operation after setting the "to" address. It simply annotates the message as needing a functional reply-to. When the message is subsequently sent, messenger can create or re-use the necessary subscriptions and set the message's reply-to field.

        Show
        Ted Ross added a comment - - edited An alternative API is to add a method on the pn_message_t: pn_message_expect_reply(pn_message_t *msg); This removes the need to sequence the operation after setting the "to" address. It simply annotates the message as needing a functional reply-to. When the message is subsequently sent, messenger can create or re-use the necessary subscriptions and set the message's reply-to field.
        Ken Giusti created issue -

          People

          • Assignee:
            Rafael H. Schloming
            Reporter:
            Ken Giusti
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development