You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by GitBox <gi...@apache.org> on 2020/07/10 19:36:38 UTC
[GitHub] [qpid-proton] astitcher opened a new pull request #265: Raw connection API for proactor (epoll implementation)
astitcher opened a new pull request #265:
URL: https://github.com/apache/qpid-proton/pull/265
See [PROTON-2247](https://issues.apache.org/jira/projects/PROTON/issues/PROTON-2247)
This is my proposed new API for the Proton proactor including an implementation on the epoll proactor.
The purpose of this API is to allow applications to use raw (non-AMQP) TCP connections alongside AMQP connections in the same proactor. This has applications for bridging other protocols to AMQP and whereever other protocols needs ot be used in a messaging application.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[GitHub] [qpid-proton] asfgit merged pull request #265: PROTON-2247 Raw connection API for proactor (epoll implementation)
Posted by GitBox <gi...@apache.org>.
asfgit merged pull request #265:
URL: https://github.com/apache/qpid-proton/pull/265
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[GitHub] [qpid-proton] cliffjansen commented on pull request #265: PROTON-2247 Raw connection API for proactor (epoll implementation)
Posted by GitBox <gi...@apache.org>.
cliffjansen commented on pull request #265:
URL: https://github.com/apache/qpid-proton/pull/265#issuecomment-659671286
Very nice. +1 on the API.
pn_raw_connection_free is not yet implemented in the pull request and the documentation about ownership of the raw connection is perhaps out of date, but I presume you are already aware.
As an implementation detail, I wonder how you distinguish between an internal wake and an external pn_raw_connection_wake(), given that you have dispensed with the wake_count indicator (used for that purpose in the pconnection).
For example, if an internal wake is generated in unassign_thread() within pni_raw_connection_done(), it seems to me you will get a spurious PN_RAW_CONNECTION_WAKE.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[GitHub] [qpid-proton] cliffjansen commented on pull request #265: PROTON-2247 Raw connection API for proactor (epoll implementation)
Posted by GitBox <gi...@apache.org>.
cliffjansen commented on pull request #265:
URL: https://github.com/apache/qpid-proton/pull/265#issuecomment-659897035
The scenario I can envision is
Thread A calls pni_raw_connection_done(), resulting in a call to rearm_polling().
Thread B is the poller and finds IO on the raw connection, sets sched_io_events and ctx->sched_pending for the raw connection, then releases the sched_mutex.
Thread A, still in pni_raw_connection_done(), now acquires the sched_mutex and in unassign_thread() realizes there is remaining work to do so it places itself on the proactor wake list to return eventually to process the io event.
Thread C becomes the raw connection's next runner via pni_raw_connection_process(c, sched_wake), with sched_wake as true and generates the PN_RAW_CONNECTION_WAKE. There may have been zero calls to pn_raw_connection_wake() for the life of this raw connection.
You can also get an internal wake if certain errors are encountered in pn_proactor_raw_connect(), but as I read the code, sched_wake is ignored in pni_raw_connection_process() due to disconnect logic prior to the call to
if (sched_wake) pni_raw_wake(&rc->raw_connection);
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
[GitHub] [qpid-proton] astitcher commented on pull request #265: PROTON-2247 Raw connection API for proactor (epoll implementation)
Posted by GitBox <gi...@apache.org>.
astitcher commented on pull request #265:
URL: https://github.com/apache/qpid-proton/pull/265#issuecomment-659773351
> pn_raw_connection_free is not yet implemented in the pull request and the documentation about ownership of the raw connection is perhaps out of date, but I presume you are already aware.
Actually it's the other way round - The current documentation is correct, and lack of ``pn_raw_connection_free()`` is my intention - the proactor takes ownership of the ``pn_raw_connection_t`` provided in ``pn_proactor_raw_connect()`` or ``pn_listener_raw_accept()`` and free it after the ``PN_RAW_CONNECTION_DISCONNECT`` event.
> For example, if an internal wake is generated in unassign_thread() within pni_raw_connection_done(), it seems to me you will get a spurious PN_RAW_CONNECTION_WAKE.
This might be something I missed in that case - can you expand on the situations when you might get an internal wake?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org