qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Ross (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-669) Non-Blocking connection/session semantics for Python client
Date Fri, 02 Nov 2007 15:37:50 GMT

    [ https://issues.apache.org/jira/browse/QPID-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539616
] 

Ted Ross commented on QPID-669:
-------------------------------

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). 

> Non-Blocking connection/session semantics for Python client
> -----------------------------------------------------------
>
>                 Key: QPID-669
>                 URL: https://issues.apache.org/jira/browse/QPID-669
>             Project: Qpid
>          Issue Type: Wish
>          Components: Python Client
>            Reporter: Ted Ross
>            Priority: Minor
>
> This is a request for non-blocking connection/session semantics in the Python client
API to support the management client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message