[jira] [Commented] (PROTON-2006) Qpid Proton cannot connect to Azure Service Bus 'amqp:connection:framing-error'
[
https://issues.apache.org/jira/browse/PROTON-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801185#comment-16801185
]
Andrew Stitcher commented on PROTON-2006:
-
>From the error message I'd guess that the example is failing to set up SSL to
>connect to servicebus.
A trace I generated:
{{$ PN_TRACE_FRM=1 PN_TRACE_EVT=1 ./cpp/examples/service_bus -n
xxx.servicebus.windows.net -p yyy -k 'zzz' -e blah}}
{{[0x18bbaa0]:(PN_CONNECTION_INIT, pn_connection<0x18b6790>)}}
{{[0x18bbaa0]:(PN_SESSION_INIT, pn_session<0x18b7ed0>)}}
{{[0x18bbaa0]:(PN_LINK_INIT, pn_link<0x18b9000>)}}
{{[0x18bbaa0]:(PN_CONNECTION_BOUND, pn_connection<0x18b6790>)}}
{{[0x18bbaa0]: -> SASL}}
{{[0x18bbaa0]: <- EOS}}
{{[0x18bbaa0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x18bbaa0>)}}
{{[0x18bbaa0]:(PN_TRANSPORT_ERROR, pn_transport<0x18bbaa0>)}}
{{[0x18bbaa0]: -> EOS}}
{{[0x18bbaa0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x18bbaa0>)}}
{{[0x18bbaa0]:(PN_TRANSPORT_CLOSED, pn_transport<0x18bbaa0>)}}
{{amqp:connection:framing-error: SASL header mismatch: Insufficient data to
determine protocol [''] (connection aborted)}}
It looks like the client sent the SASL header but received the TLS header from
the server.
> Qpid Proton cannot connect to Azure Service Bus
> 'amqp:connection:framing-error'
> ---
>
> Key: PROTON-2006
> URL: https://issues.apache.org/jira/browse/PROTON-2006
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, examples
>Affects Versions: proton-c-0.28.0
>Reporter: Oskar Christensson
>Priority: Major
>
>
> {code:java}
> amqp:connection:framing-error: SASL header mismatch: Insufficient data to
> determine protocol [''] (connection aborted){code}
> We're trying to get a C++ connection to Azure Service Bus using AMQP with
> QPID proton, and trying out the examples under qpid-proton/cpp/examples it
> fails.
> Steps to reproduce:
> # Clone qpid-proton
> # Follow installation and make README
> # Create new Service Bus Namespace in azure
> # Create new Service Bus Queue in Azure with Sessions enabled
> # Create a policy with all permissions
> # `./service_bus -n .servicebus.windows.net -p -k
> -e
> Expected results:
> It should work according to the docs in the cpp/examples/service_bus.cpp docs
> Actual results:
> {code:java}
> amqp:connection:framing-error: SASL header mismatch: Insufficient data to
> determine protocol [''] (connection aborted){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2006) Qpid Proton cannot connect to Azure Service Bus 'amqp:connection:framing-error'
[
https://issues.apache.org/jira/browse/PROTON-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801180#comment-16801180
]
Andrew Stitcher commented on PROTON-2006:
-
I can reproduce this trivially against a servicebus instance myself.
> Qpid Proton cannot connect to Azure Service Bus
> 'amqp:connection:framing-error'
> ---
>
> Key: PROTON-2006
> URL: https://issues.apache.org/jira/browse/PROTON-2006
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, examples
>Affects Versions: proton-c-0.28.0
>Reporter: Oskar Christensson
>Priority: Major
>
>
> {code:java}
> amqp:connection:framing-error: SASL header mismatch: Insufficient data to
> determine protocol [''] (connection aborted){code}
> We're trying to get a C++ connection to Azure Service Bus using AMQP with
> QPID proton, and trying out the examples under qpid-proton/cpp/examples it
> fails.
> Steps to reproduce:
> # Clone qpid-proton
> # Follow installation and make README
> # Create new Service Bus Namespace in azure
> # Create new Service Bus Queue in Azure with Sessions enabled
> # Create a policy with all permissions
> # `./service_bus -n .servicebus.windows.net -p -k
> -e
> Expected results:
> It should work according to the docs in the cpp/examples/service_bus.cpp docs
> Actual results:
> {code:java}
> amqp:connection:framing-error: SASL header mismatch: Insufficient data to
> determine protocol [''] (connection aborted){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-2021. - Resolution: Fixed Fix Version/s: proton-c-0.28.0 > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.28.0 > > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8287) deadlock between queue cleaner and link io thread on ha backup
[ https://issues.apache.org/jira/browse/QPID-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-8287. -- Resolution: Fixed > deadlock between queue cleaner and link io thread on ha backup > -- > > Key: QPID-8287 > URL: https://issues.apache.org/jira/browse/QPID-8287 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.38.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: qpid-cpp-1.39.0 > > > The queue cleaner and link io processing threads take the queue lock and > queue replicator lock in different order, which can cause deadlocks. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8288) timeout on connection that is not writable does not cleanup on primary
[ https://issues.apache.org/jira/browse/QPID-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-8288. -- Resolution: Fixed > timeout on connection that is not writable does not cleanup on primary > -- > > Key: QPID-8288 > URL: https://issues.apache.org/jira/browse/QPID-8288 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.38.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: qpid-cpp-1.39.0 > > > If an incoming socket from a backup is not writable at the point it times > out, then the sessions get cleaned up but the connection observers are not > notified of the closed connection (as the code used by the io layer is not > yet deleted; it is only deleted when the socket is writable). > For the primary in an ha cluster this means it does not fully handle the lost > connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8288) timeout on connection that is not writable does not cleanup on primary
[ https://issues.apache.org/jira/browse/QPID-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801069#comment-16801069 ] ASF subversion and git services commented on QPID-8288: --- Commit 8ed016c6bba566e257d72ae3938b4cab34e8778f in qpid-cpp's branch refs/heads/master from Gordon Sim [ https://gitbox.apache.org/repos/asf?p=qpid-cpp.git;h=8ed016c ] QPID-8288: ensure closed is notified without waiting for deletion of connection > timeout on connection that is not writable does not cleanup on primary > -- > > Key: QPID-8288 > URL: https://issues.apache.org/jira/browse/QPID-8288 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.38.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: qpid-cpp-1.39.0 > > > If an incoming socket from a backup is not writable at the point it times > out, then the sessions get cleaned up but the connection observers are not > notified of the closed connection (as the code used by the io layer is not > yet deleted; it is only deleted when the socket is writable). > For the primary in an ha cluster this means it does not fully handle the lost > connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8287) deadlock between queue cleaner and link io thread on ha backup
[ https://issues.apache.org/jira/browse/QPID-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801068#comment-16801068 ] ASF subversion and git services commented on QPID-8287: --- Commit b1f7154e183d90083a79dbe6ba9b58d2e3134def in qpid-cpp's branch refs/heads/master from Gordon Sim [ https://gitbox.apache.org/repos/asf?p=qpid-cpp.git;h=b1f7154 ] QPID-8287: avoid call holding lock > deadlock between queue cleaner and link io thread on ha backup > -- > > Key: QPID-8287 > URL: https://issues.apache.org/jira/browse/QPID-8287 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.38.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: qpid-cpp-1.39.0 > > > The queue cleaner and link io processing threads take the queue lock and > queue replicator lock in different order, which can cause deadlocks. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801018#comment-16801018 ] Andrew Stitcher edited comment on PROTON-2021 at 3/25/19 8:58 PM: -- In order to maintain backward behaviour compatibility we will maintain the ANONYMOUS peer verification of a client pn_ssl_domain_t created directly with pn_ssl_domain(PN_SSL_MODE_CLIENT) for now. Even though this is insecure. However We will set up the ca certificate store by default for both client and server domains to be the system default trusted ca certificate store as this changes a previous error case into a secure case: Before setting the verify mode for an ssl domain to verify the certificate or the peer name without setting a trusted ca certificate store would cause an error. Setting a store by default allows this error case to safely use the system default. was (Author: astitcher): In order to maintain backward behaviour compatibility we will maintain the ANONYMOUS peer verification of a client pn_ssl_domain_t created directly with pn_ssl_domain(PN_SSL_MODE_CLIENT) for now. Even though this is secure. However We will set up the ca certificate store by default for both client and server domains to be the system default trusted ca certificate store as this changes a previous error case into a secure case: Before setting the verify mode for an ssl domain to verify the certificate or the peer name without setting a trusted ca certificate store would cause an error. Setting a store by default allows this error case to safely use the system default. > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801055#comment-16801055 ] ASF subversion and git services commented on PROTON-2021: - Commit 63025898d33bebc7677518c2c103e2f87dc0ea9e in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=6302589 ] PROTON-2021: [c] Improve TLS default security - Default ssl to use system certificates unless overridden with pn_ssl_domain_set_trusted_ca_db() - Change pn_ssl_init() so that NULL domain gives a sensible default > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801057#comment-16801057 ] ASF subversion and git services commented on PROTON-2021: - Commit a58c282dfae85789747b3777d5c20be615d8e70d in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=a58c282 ] PROTON-2021: [c] Update ssl-send example to use simpler pn_ssl_init() - Also fixed message-id to ulong as required by AMQP 1.0 std - For back compatibility with previous use of send-ssl: -- With no user/passwd allow insecure anonymous connections -- Otherwise use secure default with SASL PLAIN > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801056#comment-16801056 ] ASF subversion and git services commented on PROTON-2021: - Commit a735a512d3064a330d6f2623e4770da9db5aae2e in qpid-proton's branch refs/heads/master from Andrew Stitcher [ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=a735a51 ] PROTON-2021: [c] Round out the ssl certificate verification tests > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801021#comment-16801021 ] Andrew Stitcher commented on PROTON-2021: - Another change that changes an error case into a sensible default case is to allow pn_ssl_init() to take a NULL domain to indicate a domain set up with a defualt. In the case a client domain this default sets up peer name verification with the system default certificates. In the case of a server domain it currently sets up whatever is the default server domain - this will tend to not be very useful except for testing purposes as it won't set up any identifying certificates. > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801018#comment-16801018 ] Andrew Stitcher commented on PROTON-2021: - In order to maintain backward behaviour compatibility we will maintain the ANONYMOUS peer verification of a client pn_ssl_domain_t created directly with pn_ssl_domain(PN_SSL_MODE_CLIENT) for now. Even though this is secure. However We will set up the ca certificate store by default for both client and server domains to be the system default trusted ca certificate store as this changes a previous error case into a secure case: Before setting the verify mode for an ssl domain to verify the certificate or the peer name without setting a trusted ca certificate store would cause an error. Setting a store by default allows this error case to safely use the system default. > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
[ https://issues.apache.org/jira/browse/PROTON-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-2021: Description: There are some aspects of using TLS with proton-c that are awkward and by default less secure than they could be. A good example of this is that it is tricky to set up to verify peer names against the system default ca certificate list. Even though this is carefully set up under many (most?) modern OS distributions. Another example is that for a client on the internet verifying peer names is the only safe way to use TLS, but this is not the default. was: There are some aspects of using TLS with proton-c that are awkward and by default less secure than thye could be. A good example of this is that it is tricky to set up to verify peer names against the system default ca certificate list. Even though this is carefully set up under many (most?) modern OS distributions. Another example is that for a client on the internet verifying peer names is the only safe way to use TLS, but this is not the default. > [c] Make SSL/TLS usage more secure by default > - > > Key: PROTON-2021 > URL: https://issues.apache.org/jira/browse/PROTON-2021 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > There are some aspects of using TLS with proton-c that are awkward and by > default less secure than they could be. > A good example of this is that it is tricky to set up to verify peer names > against the system default ca certificate list. Even though this is carefully > set up under many (most?) modern OS distributions. > Another example is that for a client on the internet verifying peer names is > the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2021) [c] Make SSL/TLS usage more secure by default
Andrew Stitcher created PROTON-2021: --- Summary: [c] Make SSL/TLS usage more secure by default Key: PROTON-2021 URL: https://issues.apache.org/jira/browse/PROTON-2021 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher There are some aspects of using TLS with proton-c that are awkward and by default less secure than thye could be. A good example of this is that it is tricky to set up to verify peer names against the system default ca certificate list. Even though this is carefully set up under many (most?) modern OS distributions. Another example is that for a client on the internet verifying peer names is the only safe way to use TLS, but this is not the default. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2019) [Python] SSL Tests fail on Windows 10
[
https://issues.apache.org/jira/browse/PROTON-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-2019.
-
Resolution: Fixed
Fix Version/s: proton-c-0.28.0
> [Python] SSL Tests fail on Windows 10
> -
>
> Key: PROTON-2019
> URL: https://issues.apache.org/jira/browse/PROTON-2019
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Environment: Windows 10
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.28.0
>
>
> The Python tests fail causing events like this in the event log:
> {quote}Log Name: System
> Source: Schannel
> Date: 3/14/2019 12:48:17 AM
> Event ID: 36874
> Task Category: None
> Level: Error
> Keywords:
> User: SYSTEM
> Computer: WIN10
> Description:
> An TLS 1.2 connection request was received from a remote client application,
> but none of the cipher suites supported by the client application are
> supported by the server. The TLS connection request has failed.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800983#comment-16800983 ] Alan Conway commented on DISPATCH-1274: --- The issue this patch was aiming at is a set of often-called code points that *always* pass a literal 0 to schedule() just to put work on other threads. Those uses don't need a timed delay, just a thread-safe work queue. The overhead of clock_time() and a sorted schedule is always wasted for those calls. For code that actually is trying to set up a timed delay, I think the existing timers are fine - even if the delay sometimes happens to be 0. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8287) deadlock between queue cleaner and link io thread on ha backup
Gordon Sim created QPID-8287: Summary: deadlock between queue cleaner and link io thread on ha backup Key: QPID-8287 URL: https://issues.apache.org/jira/browse/QPID-8287 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: qpid-cpp-1.38.0 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: qpid-cpp-1.39.0 The queue cleaner and link io processing threads take the queue lock and queue replicator lock in different order, which can cause deadlocks. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8288) timeout on connection that is not writable does not cleanup on primary
Gordon Sim created QPID-8288: Summary: timeout on connection that is not writable does not cleanup on primary Key: QPID-8288 URL: https://issues.apache.org/jira/browse/QPID-8288 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: qpid-cpp-1.38.0 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: qpid-cpp-1.39.0 If an incoming socket from a backup is not writable at the point it times out, then the sessions get cleaned up but the connection observers are not notified of the closed connection (as the code used by the io layer is not yet deleted; it is only deleted when the socket is writable). For the primary in an ha cluster this means it does not fully handle the lost connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800889#comment-16800889 ] Gordon Sim commented on DISPATCH-1274: -- I would think checking for 0 and calling some immediate scheduling if needed, and scheduling a non-zero timeout otherwise would be more obvious in its intention. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800883#comment-16800883 ] Cliff Jansen commented on DISPATCH-1274: The connector timer is sometimes zero and sometimes non-zero. Perhaps its use is infrequent enough that it doesn't need to have special code to prevent collisions between a regular and immediate timers, and can just use the former. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1303) Open Artemis broker console when Artemis icon is clicked
Ernest Allen created DISPATCH-1303: -- Summary: Open Artemis broker console when Artemis icon is clicked Key: DISPATCH-1303 URL: https://issues.apache.org/jira/browse/DISPATCH-1303 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.5.0 Reporter: Ernest Allen Assignee: Ernest Allen When the router is connected to an Artemis broker, the topology page will display an Artemis icon. When the user clicks on the Artemis icon, the console should attempt to open the Artemis broker's console in a new browser window. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-1274: Fix Version/s: (was: 1.6.0) > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1301) Management messages lost
[ https://issues.apache.org/jira/browse/DISPATCH-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1301. - Resolution: Fixed Fix Version/s: 1.6.0 > Management messages lost > > > Key: DISPATCH-1301 > URL: https://issues.apache.org/jira/browse/DISPATCH-1301 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.5.0 > Environment: Fedora 29 > Python 2.7.15 > Proton recent master @159fa > >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.6.0 > > Attachments: DISPATCH-1301-router-log.txt > > > Master @d84d7 fails self tests when management requests go into the router > and never get logged as 'Agent request Message'. This doesn't happen every > time but the problem happens in multiple self tests: system_tests_one_router > and system_tests_two_routers. > Externally the tests fail with > AssertionError: None != u'No response received for management request' > Excepts from the log attached as a file -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1301) Management messages lost
[ https://issues.apache.org/jira/browse/DISPATCH-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800838#comment-16800838 ] ASF GitHub Bot commented on DISPATCH-1301: -- asfgit commented on pull request #478: DISPATCH-1301 - Got the reply_to address from inside of on_link_opene… URL: https://github.com/apache/qpid-dispatch/pull/478 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: us...@infra.apache.org > Management messages lost > > > Key: DISPATCH-1301 > URL: https://issues.apache.org/jira/browse/DISPATCH-1301 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.5.0 > Environment: Fedora 29 > Python 2.7.15 > Proton recent master @159fa > >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Attachments: DISPATCH-1301-router-log.txt > > > Master @d84d7 fails self tests when management requests go into the router > and never get logged as 'Agent request Message'. This doesn't happen every > time but the problem happens in multiple self tests: system_tests_one_router > and system_tests_two_routers. > Externally the tests fail with > AssertionError: None != u'No response received for management request' > Excepts from the log attached as a file -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1301) Management messages lost
[ https://issues.apache.org/jira/browse/DISPATCH-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800837#comment-16800837 ] ASF subversion and git services commented on DISPATCH-1301: --- Commit 817ecb9b6bd91965a255c941cdafa750ee0fb97f in qpid-dispatch's branch refs/heads/master from Ganesh Murthy [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=817ecb9 ] DISPATCH-1301 - Got the reply_to address from inside of on_link_opened. This prevents test failures due to prematurely getting the rely address. This closes #478. > Management messages lost > > > Key: DISPATCH-1301 > URL: https://issues.apache.org/jira/browse/DISPATCH-1301 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.5.0 > Environment: Fedora 29 > Python 2.7.15 > Proton recent master @159fa > >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Attachments: DISPATCH-1301-router-log.txt > > > Master @d84d7 fails self tests when management requests go into the router > and never get logged as 'Agent request Message'. This doesn't happen every > time but the problem happens in multiple self tests: system_tests_one_router > and system_tests_two_routers. > Externally the tests fail with > AssertionError: None != u'No response received for management request' > Excepts from the log attached as a file -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit closed pull request #478: DISPATCH-1301 - Got the reply_to address from inside of on_link_opene…
asfgit closed pull request #478: DISPATCH-1301 - Got the reply_to address from inside of on_link_opene… URL: https://github.com/apache/qpid-dispatch/pull/478 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: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800828#comment-16800828 ] Gordon Sim commented on DISPATCH-1274: -- Yes, I think that would actually be cleaner. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800824#comment-16800824 ] Alan Conway commented on DISPATCH-1274: --- Another way to fix this would be to introduce an explicit "immediate" API rather than making it an optimization of timer_schedule(0). There are only a couple of places that make immediate calls an they are easy to separate from normal timer use. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800814#comment-16800814 ] ASF subversion and git services commented on DISPATCH-1274: --- Commit d1ae9134dfd9918088d0afbbbc344a1eef2cb2d0 in qpid-dispatch's branch refs/heads/master from Ganesh Murthy [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=d1ae913 ] DISPATCH-1274 - Missed out removing immediate.c from the previous commit. Removed it now > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800803#comment-16800803 ] ASF subversion and git services commented on DISPATCH-1274: --- Commit 35a2cff60a515b080eba6fcf4e43672557cca1f1 in qpid-dispatch's branch refs/heads/master from Ganesh Murthy [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=35a2cff ] DISPATCH-1274 - This commit reverts 48e62a11e67cf3a37b5e1f9862d07a939101cdb4 and 077710c72a20f854e9fe0cbcd983ba68c4d72d10. This code caused a deadlock in the timer. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[
https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800802#comment-16800802
]
Gordon Sim commented on DISPATCH-1274:
--
Another option might be the following, which I think would keep the
optimisation for the first 256 timers (I suspect it is only one or two of the
fixed ones that actually use 0 timeoutes anyway, the per connection ones
certainly don't).
{noformat}
diff --git a/src/immediate.c b/src/immediate.c
index 5b1cab9e..87402b3f 100644
--- a/src/immediate.c
+++ b/src/immediate.c
@@ -47,7 +47,7 @@ void qd_immediate_finalize(void) {
qd_immediate_t *qd_immediate(qd_dispatch_t *qd, void (*handler)(void*), void*
context) {
sys_mutex_lock(lock);
if (count >= sizeof(immediates)/sizeof(immediates[0])) {
-assert("exceeded max number of qd_immediate_t objects" == 0);
+sys_mutex_unlock(lock);
return 0;
}
qd_immediate_t *i = [count++];
diff --git a/src/timer.c b/src/timer.c
index c76f77dd..06d898c1 100644
--- a/src/timer.c
+++ b/src/timer.c
@@ -55,7 +55,7 @@ static void timer_cancel_LH(qd_timer_t *timer)
DEQ_INSERT_TAIL(idle_timers, timer);
timer->scheduled = false;
}
-qd_immediate_disarm(timer->immediate);
+if (timer->immediate) qd_immediate_disarm(timer->immediate);
}
/* Adjust timer's time_base and delays for the current time. */
@@ -112,7 +112,7 @@ void qd_timer_free(qd_timer_t *timer)
sys_mutex_lock(lock);
timer_cancel_LH(timer);
DEQ_REMOVE(idle_timers, timer);
-qd_immediate_free(timer->immediate);
+if (timer->immediate) qd_immediate_free(timer->immediate);
sys_mutex_unlock(lock);
free_qd_timer_t(timer);
}
@@ -128,7 +128,7 @@ qd_timestamp_t qd_timer_now() {
void qd_timer_schedule(qd_timer_t *timer, qd_duration_t duration)
{
sys_mutex_lock(lock);
-if (duration == 0) {
+if (duration == 0 && timer->immediate) {
qd_immediate_arm(timer->immediate);
sys_mutex_unlock(lock);
return;
@@ -208,7 +208,7 @@ void qd_timer_visit()
qd_timer_t *timer = DEQ_HEAD(scheduled_timers);
while (timer && timer->delta_time == 0) {
timer_cancel_LH(timer); /* Removes timer from scheduled_timers */
-qd_immediate_disarm(timer->immediate);
+if (timer->immediate) qd_immediate_disarm(timer->immediate);
sys_mutex_unlock(lock);
timer->handler(timer->context); /* Call the handler outside the lock,
may re-schedule */
sys_mutex_lock(lock);
{noformat}
> Optimize qd_timer_schedule(0)
> --
>
> Key: DISPATCH-1274
> URL: https://issues.apache.org/jira/browse/DISPATCH-1274
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Container
>Affects Versions: 1.5.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: 1.6.0
>
>
> qd_timer_schedule() uses the general timeout mechanisms which includes
> checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and
> adding/removing work items from sorted list. Optimize the schedule(0) case as
> a simple work_list using pn_proactor_interrupt() for wakeups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800794#comment-16800794 ] Alan Conway commented on DISPATCH-1274: --- That part of the change (using an array instead of a linked list for timer lookup) can be backed out separately if desired. Otherwise the whole thing can be backed out for now since there isn't strong evidence that it provides a big speed up. > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1302) Large messages sent pre-settled may arrive unsettled and never get settled by the sender
[ https://issues.apache.org/jira/browse/DISPATCH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-1302: - Affects Version/s: 1.5.0 > Large messages sent pre-settled may arrive unsettled and never get settled by > the sender > - > > Key: DISPATCH-1302 > URL: https://issues.apache.org/jira/browse/DISPATCH-1302 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.5.0, 1.6.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.7.0 > > Attachments: 0001-DISPATCH-1302-debug-reproducer.patch > > > While testing very large presettled messages across a multi router path some > of the messages are received unsettled and are never settled via a > disposition from the sender. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1295) reduce cpu and locking in timer/immediate code.
[ https://issues.apache.org/jira/browse/DISPATCH-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800776#comment-16800776 ] ASF GitHub Bot commented on DISPATCH-1295: -- cliffjansen commented on pull request #476: DISPATCH-1295 - Reduce lock contention and make fewer system calls. URL: https://github.com/apache/qpid-dispatch/pull/476 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: us...@infra.apache.org > reduce cpu and locking in timer/immediate code. > --- > > Key: DISPATCH-1295 > URL: https://issues.apache.org/jira/browse/DISPATCH-1295 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.6.0 >Reporter: Cliff Jansen >Priority: Major > > Follow on to DISPATCH-1274. > Locks held for longer time than necessary (through system calls). > Spurious calls to timer_visit() that should be restricted to > immediate_visit(). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1295) reduce cpu and locking in timer/immediate code.
[ https://issues.apache.org/jira/browse/DISPATCH-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800775#comment-16800775 ] ASF GitHub Bot commented on DISPATCH-1295: -- cliffjansen commented on issue #476: DISPATCH-1295 - Reduce lock contention and make fewer system calls. URL: https://github.com/apache/qpid-dispatch/pull/476#issuecomment-476237398 Since this pull request builds on top of DISPATCH-1274, and that has been removed for the next release, I am closing this for now. Next steps TBD. 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: us...@infra.apache.org > reduce cpu and locking in timer/immediate code. > --- > > Key: DISPATCH-1295 > URL: https://issues.apache.org/jira/browse/DISPATCH-1295 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.6.0 >Reporter: Cliff Jansen >Priority: Major > > Follow on to DISPATCH-1274. > Locks held for longer time than necessary (through system calls). > Spurious calls to timer_visit() that should be restricted to > immediate_visit(). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] cliffjansen commented on issue #476: DISPATCH-1295 - Reduce lock contention and make fewer system calls.
cliffjansen commented on issue #476: DISPATCH-1295 - Reduce lock contention and make fewer system calls. URL: https://github.com/apache/qpid-dispatch/pull/476#issuecomment-476237398 Since this pull request builds on top of DISPATCH-1274, and that has been removed for the next release, I am closing this for now. Next steps TBD. 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: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] cliffjansen closed pull request #476: DISPATCH-1295 - Reduce lock contention and make fewer system calls.
cliffjansen closed pull request #476: DISPATCH-1295 - Reduce lock contention and make fewer system calls. URL: https://github.com/apache/qpid-dispatch/pull/476 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: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy opened a new pull request #478: DISPATCH-1301 - Got the reply_to address from inside of on_link_opene…
ganeshmurthy opened a new pull request #478: DISPATCH-1301 - Got the reply_to address from inside of on_link_opene… URL: https://github.com/apache/qpid-dispatch/pull/478 …d. This prevents test failures due to prematurely getting the rely address 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: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800716#comment-16800716 ] Ganesh Murthy commented on DISPATCH-1274: - The following is a comment from [~gsim] "This is a deadlock in the timer systems caused by DISPATCH-1274. That optimisation assumes there will never be more than 256 timers. However if initialHandshakeTimeoutSeconds is set on a listener, there will be a timer created for every connection. I'd suggest perhaps we consider backing out DISPATCH-1274 for now as it an optimisation rather than a crucial feature or fix." > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-1274) Optimize qd_timer_schedule(0)
[ https://issues.apache.org/jira/browse/DISPATCH-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reopened DISPATCH-1274: - > Optimize qd_timer_schedule(0) > -- > > Key: DISPATCH-1274 > URL: https://issues.apache.org/jira/browse/DISPATCH-1274 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 1.5.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: 1.6.0 > > > qd_timer_schedule() uses the general timeout mechanisms which includes > checking system time (on schedule and on PN_PROACTOR_TIMEOUT wakeup) and > adding/removing work items from sorted list. Optimize the schedule(0) case as > a simple work_list using pn_proactor_interrupt() for wakeups. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1302) Large messages sent pre-settled may arrive unsettled and never get settled by the sender
[ https://issues.apache.org/jira/browse/DISPATCH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800698#comment-16800698 ] Ken Giusti commented on DISPATCH-1302: -- The above debug patch reproduces the problem. Note that it clobbers the system_tests_one_router.py file just because it's convenient to run this as "ctest -VV -R system_tests_one_router" The test prints out the count of messages received both settled and unsettled for a client on router EB1. Messages are sent settled from client on EA1. See the logs for whether or not the 'settled=true' flag is set on the transfers. > Large messages sent pre-settled may arrive unsettled and never get settled by > the sender > - > > Key: DISPATCH-1302 > URL: https://issues.apache.org/jira/browse/DISPATCH-1302 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.6.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.7.0 > > Attachments: 0001-DISPATCH-1302-debug-reproducer.patch > > > While testing very large presettled messages across a multi router path some > of the messages are received unsettled and are never settled via a > disposition from the sender. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1302) Large messages sent pre-settled may arrive unsettled and never get settled by the sender
[ https://issues.apache.org/jira/browse/DISPATCH-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated DISPATCH-1302: - Attachment: 0001-DISPATCH-1302-debug-reproducer.patch > Large messages sent pre-settled may arrive unsettled and never get settled by > the sender > - > > Key: DISPATCH-1302 > URL: https://issues.apache.org/jira/browse/DISPATCH-1302 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.6.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > Fix For: 1.7.0 > > Attachments: 0001-DISPATCH-1302-debug-reproducer.patch > > > While testing very large presettled messages across a multi router path some > of the messages are received unsettled and are never settled via a > disposition from the sender. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1302) Large messages sent pre-settled may arrive unsettled and never get settled by the sender
Ken Giusti created DISPATCH-1302: Summary: Large messages sent pre-settled may arrive unsettled and never get settled by the sender Key: DISPATCH-1302 URL: https://issues.apache.org/jira/browse/DISPATCH-1302 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.6.0 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 1.7.0 While testing very large presettled messages across a multi router path some of the messages are received unsettled and are never settled via a disposition from the sender. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy closed pull request #477: DISPATCH-1301 - Updated test test_18_management_not_implemented to wa…
ganeshmurthy closed pull request #477: DISPATCH-1301 - Updated test test_18_management_not_implemented to wa… URL: https://github.com/apache/qpid-dispatch/pull/477 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: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1301) Management messages lost
[ https://issues.apache.org/jira/browse/DISPATCH-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800658#comment-16800658 ] ASF GitHub Bot commented on DISPATCH-1301: -- ganeshmurthy commented on pull request #477: DISPATCH-1301 - Updated test test_18_management_not_implemented to wa… URL: https://github.com/apache/qpid-dispatch/pull/477 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: us...@infra.apache.org > Management messages lost > > > Key: DISPATCH-1301 > URL: https://issues.apache.org/jira/browse/DISPATCH-1301 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.5.0 > Environment: Fedora 29 > Python 2.7.15 > Proton recent master @159fa > >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Attachments: DISPATCH-1301-router-log.txt > > > Master @d84d7 fails self tests when management requests go into the router > and never get logged as 'Agent request Message'. This doesn't happen every > time but the problem happens in multiple self tests: system_tests_one_router > and system_tests_two_routers. > Externally the tests fail with > AssertionError: None != u'No response received for management request' > Excepts from the log attached as a file -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] ganeshmurthy commented on issue #477: DISPATCH-1301 - Updated test test_18_management_not_implemented to wa…
ganeshmurthy commented on issue #477: DISPATCH-1301 - Updated test test_18_management_not_implemented to wa… URL: https://github.com/apache/qpid-dispatch/pull/477#issuecomment-476186200 Closing this PR. Will be using on_link_opened as @ted-ross suggested. Will open a new PR with the changes. 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: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1301) Management messages lost
[ https://issues.apache.org/jira/browse/DISPATCH-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800657#comment-16800657 ] ASF GitHub Bot commented on DISPATCH-1301: -- ganeshmurthy commented on issue #477: DISPATCH-1301 - Updated test test_18_management_not_implemented to wa… URL: https://github.com/apache/qpid-dispatch/pull/477#issuecomment-476186200 Closing this PR. Will be using on_link_opened as @ted-ross suggested. Will open a new PR with the changes. 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: us...@infra.apache.org > Management messages lost > > > Key: DISPATCH-1301 > URL: https://issues.apache.org/jira/browse/DISPATCH-1301 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.5.0 > Environment: Fedora 29 > Python 2.7.15 > Proton recent master @159fa > >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Attachments: DISPATCH-1301-router-log.txt > > > Master @d84d7 fails self tests when management requests go into the router > and never get logged as 'Agent request Message'. This doesn't happen every > time but the problem happens in multiple self tests: system_tests_one_router > and system_tests_two_routers. > Externally the tests fail with > AssertionError: None != u'No response received for management request' > Excepts from the log attached as a file -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
