You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Ted Ross (JIRA)" <qp...@incubator.apache.org> on 2007/11/02 16:35:52 UTC
[jira] Created: (QPID-669) Non-Blocking connection/session
semantics for Python client
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.
[jira] Assigned: (QPID-669) Non-Blocking connection/session
semantics for Python client
Posted by "Rafael H. Schloming (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael H. Schloming reassigned QPID-669:
----------------------------------------
Assignee: Rafael H. Schloming
> 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
> Assignee: Rafael H. Schloming
> 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.
[jira] Updated: (QPID-669) Non-Blocking connection/session
semantics for Python client
Posted by "Rafael H. Schloming (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael H. Schloming updated QPID-669:
-------------------------------------
Fix Version/s: (was: M4)
> 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
> Assignee: Rafael H. Schloming
> 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.
[jira] Commented: (QPID-669) Non-Blocking connection/session
semantics for Python client
Posted by "Ted Ross (JIRA)" <qp...@incubator.apache.org>.
[ 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.