Qpid
  1. Qpid
  2. QPID-669

Non-Blocking connection/session semantics for Python client

    Details

    • Type: Wish Wish
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Python Client
    • Labels:
      None

      Description

      This is a request for non-blocking connection/session semantics in the Python client API to support the management client.

        Activity

        Ted Ross created issue -
        Hide
        Ted Ross added a comment -

        Earlier correspondence on this topic:

        Rafi,

        As you get ready to make changes to the python API, I've got some features I'd like to see implemented to support the management console.

        The main issue is the need to maintain connectivity to multiple (possibly many) brokers simultaneously. There's no assurance that all or any of the brokers will be reachable at any given time, even when first trying to contact them. A broker may become disconnected and need to be re-connected.

        I propose that the management console be responsible for maintaining the connections to the brokers. To do this, it will need a non-blocking API for connection/session setup.

        In the current API, the connection is established in Client.start. Channel establishment and session-open follow. There needs to be an option for this sequence of events to be non-blocking. For example, if a callback is supplied in the "start" method, this could be an indication that asynchronous operation is requested. The callback would then be invoked when either the connection was successfully established or failed (with the failure reason supplied).

        Loss of connection could also be indicated with a callback, but this is less important since I could bounce a heartbeat off the broker periodically to see if it's still connected.

        Session resume complicates matters in that it is desirable to reconnect to the same session after loss of connectivity to pick up management data that was generated during the outage. Perhaps this is addressed simply by exposing the session_resume method in the API and allowing the client to attempt to resume after an outage (again in a non-blocking way).

        Show
        Ted Ross added a comment - Earlier correspondence on this topic: Rafi, As you get ready to make changes to the python API, I've got some features I'd like to see implemented to support the management console. The main issue is the need to maintain connectivity to multiple (possibly many) brokers simultaneously. There's no assurance that all or any of the brokers will be reachable at any given time, even when first trying to contact them. A broker may become disconnected and need to be re-connected. I propose that the management console be responsible for maintaining the connections to the brokers. To do this, it will need a non-blocking API for connection/session setup. In the current API, the connection is established in Client.start. Channel establishment and session-open follow. There needs to be an option for this sequence of events to be non-blocking. For example, if a callback is supplied in the "start" method, this could be an indication that asynchronous operation is requested. The callback would then be invoked when either the connection was successfully established or failed (with the failure reason supplied). Loss of connection could also be indicated with a callback, but this is less important since I could bounce a heartbeat off the broker periodically to see if it's still connected. Session resume complicates matters in that it is desirable to reconnect to the same session after loss of connectivity to pick up management data that was generated during the outage. Perhaps this is addressed simply by exposing the session_resume method in the API and allowing the client to attempt to resume after an outage (again in a non-blocking way).
        Rafael H. Schloming made changes -
        Field Original Value New Value
        Assignee Rafael H. Schloming [ rhs ]
        Gavin made changes -
        Workflow jira [ 12416346 ] QPid [ 12438422 ]
        Gavin made changes -
        Workflow QPid [ 12438422 ] QPid Workflow [ 12439722 ]
        Aidan Skinner made changes -
        Fix Version/s M4 [ 12313279 ]
        Rafael H. Schloming made changes -
        Fix Version/s M4 [ 12313279 ]

          People

          • Assignee:
            Rafael H. Schloming
            Reporter:
            Ted Ross
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development