[jira] [Updated] (PROTON-2141) [cpp] Make unit tests pass on ipv4 machine
[ https://issues.apache.org/jira/browse/PROTON-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2141: - Attachment: (was: disable-iv6.patch) > [cpp] Make unit tests pass on ipv4 machine > -- > > Key: PROTON-2141 > URL: https://issues.apache.org/jira/browse/PROTON-2141 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > > There are test failure when running unit tests on an ipv4 machine. > So we propose the pull request below. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2141) [cpp] Make unit tests pass on ipv4 machine
[ https://issues.apache.org/jira/browse/PROTON-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2141: - Description: There are test failure when running unit tests on an ipv4 machine. So we propose the pull request below. was: There are test failure when running unit tests on an ipv4 machine. So we propose this attached fix. A pull request will be added too. > [cpp] Make unit tests pass on ipv4 machine > -- > > Key: PROTON-2141 > URL: https://issues.apache.org/jira/browse/PROTON-2141 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > > There are test failure when running unit tests on an ipv4 machine. > So we propose the pull request below. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2141) [cpp] Make unit tests pass on ipv4 machine
Rabih Mourad created PROTON-2141: Summary: [cpp] Make unit tests pass on ipv4 machine Key: PROTON-2141 URL: https://issues.apache.org/jira/browse/PROTON-2141 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.29.0 Reporter: Rabih Mourad Attachments: disable-iv6.patch There are test failure when running unit tests on an ipv4 machine. So we propose this attached fix. A pull request will be added too. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2141) [cpp] Make unit tests pass on ipv4 machine
[ https://issues.apache.org/jira/browse/PROTON-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2141: - Attachment: disable-iv6.patch > [cpp] Make unit tests pass on ipv4 machine > -- > > Key: PROTON-2141 > URL: https://issues.apache.org/jira/browse/PROTON-2141 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: disable-iv6.patch > > > There are test failure when running unit tests on an ipv4 machine. > So we propose this attached fix. > A pull request will be added too. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979221#comment-16979221 ] Rabih Mourad commented on PROTON-2137: -- [~astitcher] here is the pull request: [https://github.com/apache/qpid-proton/pull/210] > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from this pull > request [Proton 2075:[C++] Allow TLS to use system default trusted > certificate.|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99] > is calling > [pni_init_ssl_domain|https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475] > which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Description: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from this pull request [Proton 2075:[C++] Allow TLS to use system default trusted certificate.|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99] is calling [pni_init_ssl_domain|https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih was: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from this pull request [Proton 2075:[C++] Allow TLS to use system default trusted certificate.|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from this pull > request [Proton 2075:[C++] Allow TLS to use system default trusted > certificate.|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99] > is calling > [pni_init_ssl_domain|https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475] > which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Description: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from this pull request [Proton 2075:[C++] Allow TLS to use system default trusted certificate.|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih was: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075:[C++] Allow TLS to use system default trusted certificate|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from this pull > request [Proton 2075:[C++] Allow TLS to use system default trusted > certificate.|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Description: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075:[C++] Allow TLS to use system default trusted certificate|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih was: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075|[C++] Allow TLS to use system default trusted certificate] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from [Proton > 2075:[C++] Allow TLS to use system default trusted > certificate|https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27] > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Description: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075|[C++] Allow TLS to use system default trusted certificate.] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih was: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075|: [C++] Allow TLS to use system default trusted certificate.] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from [Proton > 2075|[C++] Allow TLS to use system default trusted certificate.] > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Description: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075|[C++] Allow TLS to use system default trusted certificate] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih was: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075|[C++] Allow TLS to use system default trusted certificate.] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from [Proton > 2075|[C++] Allow TLS to use system default trusted certificate] > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Description: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [Proton 2075|: [C++] Allow TLS to use system default trusted certificate.] In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih was: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from PROTON-2075: [C++] Allow TLS to use system default trusted certificate. In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from [Proton > 2075|: [C++] Allow TLS to use system default trusted certificate.] > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Description: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from PROTON-2075: [C++] Allow TLS to use system default trusted certificate. In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih was: We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [PROTON-2075|[https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27]]: [C++] Allow TLS to use system default trusted certificate. In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |[https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99]|https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99] is calling [pni_init_ssl_domain|[https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475]|https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from PROTON-2075: > [C++] Allow TLS to use system default trusted certificate. > In fact we noticed that the ssl_client_options and the ssl_server_options > are not default constructed the same way and that the [ssl_server_options > |#L99]] is calling [pni_init_ssl_domain|#L475]] which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Attachment: remove-default-ssl.patch > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from > [PROTON-2075|[https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27]]: > [C++] Allow TLS to use system default trusted certificate. > In fact we noticed that the ssl_client_options and the ssl_server_options are > not default constructed the same way and that the [ssl_server_options > |[https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99]|https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99] > is calling > [pni_init_ssl_domain|[https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475]|https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475] > which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2137) [cpp] Performance regression found in 0.29.0
[ https://issues.apache.org/jira/browse/PROTON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rabih Mourad updated PROTON-2137: - Attachment: code.txt > [cpp] Performance regression found in 0.29.0 > > > Key: PROTON-2137 > URL: https://issues.apache.org/jira/browse/PROTON-2137 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.29.0 >Reporter: Rabih Mourad >Priority: Major > Attachments: code.txt, remove-default-ssl.patch > > > We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. > While running our unit tests, we found a considerable performance regression. > We were able to reproduce the regression in a very simple use case. > Please find the code attached. > This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in > 0.29.0 . > > After analysis we discovered that the regression is coming from > [PROTON-2075|[https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27]]: > [C++] Allow TLS to use system default trusted certificate. > In fact we noticed that the ssl_client_options and the ssl_server_options are > not default constructed the same way and that the [ssl_server_options > |[https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99]|https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99] > is calling > [pni_init_ssl_domain|[https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475]|https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475] > which is taking some time. > What we would like is to avoid initializing ssl domain when it’s disabled > from the connection_options. > Does it sound reasonable for you? > > Here is a patch that we propose. All proton unit tests are green on the > master. > Can you please [~astitcher] check if this patch is aligned with what you > meant to do in (PROTON-2075) ? > > Thanks, > Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2137) [cpp] Performance regression found in 0.29.0
Rabih Mourad created PROTON-2137: Summary: [cpp] Performance regression found in 0.29.0 Key: PROTON-2137 URL: https://issues.apache.org/jira/browse/PROTON-2137 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.29.0 Reporter: Rabih Mourad We are upgrading in our Murex code the proton version from 0.27.0 to 0.29.0. While running our unit tests, we found a considerable performance regression. We were able to reproduce the regression in a very simple use case. Please find the code attached. This test takes 1 ms in the version 0.27.0 and 0.28.0 but it takes 103 ms in 0.29.0 . After analysis we discovered that the regression is coming from [PROTON-2075|[https://github.com/apache/qpid-proton/commit/e152190459cd75792002d2aae72d351dc22abe27]]: [C++] Allow TLS to use system default trusted certificate. In fact we noticed that the ssl_client_options and the ssl_server_options are not default constructed the same way and that the [ssl_server_options |[https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99]|https://github.com/apache/qpid-proton/blob/e152190459cd75792002d2aae72d351dc22abe27/cpp/src/ssl_options.cpp#L99] is calling [pni_init_ssl_domain|[https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475]|https://github.com/apache/qpid-proton/blob/9dd013335de0694bc52848897b17190f297450c1/c/src/ssl/openssl.c#L475] which is taking some time. What we would like is to avoid initializing ssl domain when it’s disabled from the connection_options. Does it sound reasonable for you? Here is a patch that we propose. All proton unit tests are green on the master. Can you please [~astitcher] check if this patch is aligned with what you meant to do in (PROTON-2075) ? Thanks, Ali & Rabih -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1862) idle timeout not working on linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806637#comment-16806637 ] Rabih Mourad commented on PROTON-1862: -- Now it is clear for me. Thanks for updating the doc. > idle timeout not working on linux > -- > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > Attachments: proton_1862_tests.txt, test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- 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-1862) idle timeout not working on linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803083#comment-16803083 ] Rabih Mourad edited comment on PROTON-1862 at 3/27/19 5:14 PM: --- We block the receiver container with a sleep to simulate a hanging on the server side after the connection is established. The client (sender) does not sleep therefore after the idle timeout is expired it should fail and on linux it is not. But as Ali said in his last comments. The issue is that the server (receiver) is calling the on_connection_open and the on_session_open callbacks before the real amqp connection is established. Therefore there is no idle timeout yet. Therefore the fix might be to call those call backs after the real connection is established on the wire. The regression was introduced in the version 0.18.1 was (Author: rabih.promail): We block the receiver container with a sleep to simulate a hanging on the server side after the connection is established. The client (sender) does not sleep therefore after the idle timeout is expired it should fail and on linux it is not. But as Ali said in his last comments. The issue is that the server (receiver) is calling the on_connection_open and the on_session_open callbacks before the real amqp connection is established. Therefore there is no idle timeout yet. Therefore the fix might be to call those call backs after the real connection is established on the wire. > idle timeout not working on linux > -- > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > Attachments: proton_1862_tests.txt, test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- 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-1862) idle timeout not working on linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803083#comment-16803083 ] Rabih Mourad commented on PROTON-1862: -- We block the receiver container with a sleep to simulate a hanging on the server side after the connection is established. The client (sender) does not sleep therefore after the idle timeout is expired it should fail and on linux it is not. But as Ali said in his last comments. The issue is that the server (receiver) is calling the on_connection_open and the on_session_open callbacks before the real amqp connection is established. Therefore there is no idle timeout yet. Therefore the fix might be to call those call backs after the real connection is established on the wire. > idle timeout not working on linux > -- > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > Attachments: proton_1862_tests.txt, test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- 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-8070) Qpid java broker is unable to reconnect to database after kill -9 then restart
Rabih Mourad created QPID-8070: -- Summary: Qpid java broker is unable to reconnect to database after kill -9 then restart Key: QPID-8070 URL: https://issues.apache.org/jira/browse/QPID-8070 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-6.1.4 Reporter: Rabih Mourad Hello, We are using Qpid java broker version 6.1.4. Our test case: We have a JMS client sending messages continuously in autoAck mode to a messaging cluster. The cluster is composed of 1 dispatch router and 2 java brokers which are connected to an Oracle Db. At some point, the test kills a broker using kill -9 and then attempts to restart it. Randomly, we have a NullPointerException while the broker is restarting and connecting to the virtual host node (the full error stack is at the end of the email). Do you have any idea why this is happening? is there a chance that a kill -9 on a broker leaves the Db in an unstable state? Best regards, Rabih 2018-01-03 17:16:45,930 INFO [VirtualHostNode-default-Config] (q.m.t.recovery_start) - [Broker] [vh(/default)/ms(GenericJDBCMessageStore)] TXN-1004 : Recovery Start 2018-01-03 17:16:45,938 WARN [VirtualHostNode-default-Config] (o.a.q.s.v.SynchronousMessageStoreRecoverer) - Message id 1 in log references queue with id 0b2a06aa-6d46-49aa-885f-63f3cd73108d which is not in the configuration, entry will be discarded 2018-01-03 17:16:45,946 ERROR [VirtualHostNode-default-Config] (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 'default'. Object will be put into ERROR state. java.lang.NullPointerException: null at org.apache.qpid.server.store.AbstractJDBCMessageStore.commitTranAsync(AbstractJDBCMessageStore.java:826) at org.apache.qpid.server.store.AbstractJDBCMessageStore.access$600(AbstractJDBCMessageStore.java:59) at org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCTransaction.commitTranAsync(AbstractJDBCMessageStore.java:1205) at org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.commitTranAsync(GenericAbstractJDBCMessageStore.java:142) at org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer$MessageInstanceVisitor.handle(SynchronousMessageStoreRecoverer.java:219) at org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessageInstances(AbstractJDBCMessageStore.java:1911) at org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:82) at org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2581) at org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2563) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482) at org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461) at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1035) at org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1029) at org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2609) at org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2605) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:360) at org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2604) at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319) at org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:404) at org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:187) at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156) at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101) at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170) at com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322) at org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2599) at org.apache.qpid.server.mode
[jira] [Created] (PROTON-1464) Idle_timeout on windows can't be less than 1s
Rabih Mourad created PROTON-1464:
Summary: Idle_timeout on windows can't be less than 1s
Key: PROTON-1464
URL: https://issues.apache.org/jira/browse/PROTON-1464
Project: Qpid Proton
Issue Type: Bug
Components: cpp-binding
Affects Versions: 0.17.0, 0.16.0
Reporter: Rabih Mourad
Assignee: Cliff Jansen
I noticed that windows does not take into consideration the configured
connection idle_timeout if it is less than 1 second. Linux does not have this
problem.
I wrote some code to reproduce at the end of the mail:
{noformat}
#include
#include
#include #include
#include
class hello_world : public proton::messaging_handler {
public:
void on_container_start(proton::container& c) {
c.connect("localhost:77",
proton::connection_options().idle_timeout(proton::duration(10))); //takes
~1000ms
// or c.connect("host:77",
proton::connection_options().idle_timeout(proton::duration(10))); //takes ~
2500ms
}
};
int main() {
LARGE_INTEGER frequency;
LARGE_INTEGER t1, t2;
QueryPerformanceFrequency(&frequency);
QueryPerformanceCounter(&t1);
try {
hello_world hw;
proton::default_container(hw).run();
return 0;
}
catch (const std::exception& e) {
std::cerr << e.what() << std::endl;
}
QueryPerformanceCounter(&t2);
double elapsedTime = (t2.QuadPart - t1.QuadPart) * 1000.0 /
frequency.QuadPart;
std::cout << "elapsed: " << elapsedTime << std::endl;
return 1;
}{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-631) Tests should be made conditional to skip tests for SASL features that are not available
Rabih Mourad created DISPATCH-631:
-
Summary: Tests should be made conditional to skip tests for SASL
features that are not available
Key: DISPATCH-631
URL: https://issues.apache.org/jira/browse/DISPATCH-631
Project: Qpid Dispatch
Issue Type: Bug
Components: Tests
Affects Versions: 0.7.0, 0.8.0
Environment: linux, sunos
Reporter: Rabih Mourad
Attachments: failedTests.txt
> I compiled qpid-proton 0.16.0 with "-DSASL_IMPL=none", but i have an
> qpid-dispatch 0.7.0 unit tests that are failing in:
>
> system_tests_qdstat
> system_tests_sasl_plain
> system_tests_deprecated
>
> I attached the tests output.
>
> Do you have any idea, where should i look? Is Cyrus mandatory for the
> qpid-dispatch 0.7.0?
Not mandatory, the tests should probably be made conditional to skip tests for
SASL features that are not available. Raise a JIRA for that.
Failing tests output:
FAIL: test_ssl_cert_to_auth_fail_no_sasl_external
(system_tests_qdstat.QdstatSslNoExternalTest)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_qdstat.py",
line 325, in test_ssl_cert_to_auth_fail_no_sasl_external
self.ssl_test_bad('auth_s', ['client_cert_all'])
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_qdstat.py",
line 322, in ssl_test_bad
self.assertRaises(AssertionError, self.ssl_test, url_name, arg_names)
AssertionError: AssertionError not raised
==
FAIL: test_inter_router_plain_exists
(system_tests_sasl_plain.RouterTestPlainSasl)
The setUpClass sets up two routers with SASL PLAIN enabled.
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 121, in test_inter_router_plain_exists
self.assertIn("inter-router", out)
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_test.py",
line 674, in assertIn
assert item in items, "%s not in %s" % (item, items)
AssertionError: inter-router not in Connections
Id host container roledir
security authentication
=
13 127.0.0.1:43271 09eaefc9-7250-4a3b-a9d0-42c58e48a194 normal in
no-security anonymous-user
==
FAIL: test_qdstat_connect_sasl (system_tests_sasl_plain.RouterTestPlainSasl)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 135, in test_qdstat_connect_sasl
"qdstat exit status %s, output:\n%s" % (p.returncode, out)
AssertionError: qdstat exit status 1, output:
ConnectionException: Connection amqp://0.0.0.0:24677/$management disconnected:
Condition('amqp:unauthorized-access', 'Authentication failed [mech=NULL]')
==
FAIL: test_qdstat_connect_sasl_password_file
(system_tests_sasl_plain.RouterTestPlainSasl)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 163, in test_qdstat_connect_sasl_password_file
"qdstat exit status %s, output:\n%s" % (p.returncode, out)
AssertionError: qdstat exit status 1, output:
ConnectionException: Connection amqp://0.0.0.0:24677/$management disconnected:
Condition('amqp:unauthorized-access', 'Authentication failed [mech=NULL]')
==
FAIL: test_aaa_qdstat_connect_sasl_over_ssl
(system_tests_sasl_plain.RouterTestPlainSaslOverSsl)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 263, in test_aaa_qdstat_connect_sasl_over_ssl
"qdstat exit status %s, output:\n%s" % (p.returncode, out)
AssertionError: qdstat exit status 1, output:
ConnectionException: Connection amqps://0.0.0.0:24681/$management disconnected:
Condition('amqp:unauthorized-access', 'Authentication failed [mech=NULL]')
===
[jira] [Updated] (DISPATCH-631) Tests should be made conditional to skip tests for SASL features that are not available
[
https://issues.apache.org/jira/browse/DISPATCH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rabih Mourad updated DISPATCH-631:
--
Description:
> Hello,
>
> I compiled qpid-proton 0.16.0 with "-DSASL_IMPL=none", but i have an
> 3 of qpid-dispatch 0.7.0 unit tests that are failing:
>
> system_tests_qdstat
> system_tests_sasl_plain
> system_tests_deprecated
>
> I attached the tests output.
>
> Do you have any idea, where should i look? Is Cyrus mandatory for the
> qpid-dispatch 0.7.0?
Not mandatory, the tests should probably be made conditional to skip tests for
SASL features that are not available. Raise a JIRA for that.
> Best regards,
> Rabih
was:
> I compiled qpid-proton 0.16.0 with "-DSASL_IMPL=none", but i have an
> qpid-dispatch 0.7.0 unit tests that are failing in:
>
> system_tests_qdstat
> system_tests_sasl_plain
> system_tests_deprecated
>
> I attached the tests output.
>
> Do you have any idea, where should i look? Is Cyrus mandatory for the
> qpid-dispatch 0.7.0?
Not mandatory, the tests should probably be made conditional to skip tests for
SASL features that are not available. Raise a JIRA for that.
Failing tests output:
FAIL: test_ssl_cert_to_auth_fail_no_sasl_external
(system_tests_qdstat.QdstatSslNoExternalTest)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_qdstat.py",
line 325, in test_ssl_cert_to_auth_fail_no_sasl_external
self.ssl_test_bad('auth_s', ['client_cert_all'])
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_qdstat.py",
line 322, in ssl_test_bad
self.assertRaises(AssertionError, self.ssl_test, url_name, arg_names)
AssertionError: AssertionError not raised
==
FAIL: test_inter_router_plain_exists
(system_tests_sasl_plain.RouterTestPlainSasl)
The setUpClass sets up two routers with SASL PLAIN enabled.
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 121, in test_inter_router_plain_exists
self.assertIn("inter-router", out)
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_test.py",
line 674, in assertIn
assert item in items, "%s not in %s" % (item, items)
AssertionError: inter-router not in Connections
Id host container roledir
security authentication
=
13 127.0.0.1:43271 09eaefc9-7250-4a3b-a9d0-42c58e48a194 normal in
no-security anonymous-user
==
FAIL: test_qdstat_connect_sasl (system_tests_sasl_plain.RouterTestPlainSasl)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 135, in test_qdstat_connect_sasl
"qdstat exit status %s, output:\n%s" % (p.returncode, out)
AssertionError: qdstat exit status 1, output:
ConnectionException: Connection amqp://0.0.0.0:24677/$management disconnected:
Condition('amqp:unauthorized-access', 'Authentication failed [mech=NULL]')
==
FAIL: test_qdstat_connect_sasl_password_file
(system_tests_sasl_plain.RouterTestPlainSasl)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 163, in test_qdstat_connect_sasl_password_file
"qdstat exit status %s, output:\n%s" % (p.returncode, out)
AssertionError: qdstat exit status 1, output:
ConnectionException: Connection amqp://0.0.0.0:24677/$management disconnected:
Condition('amqp:unauthorized-access', 'Authentication failed [mech=NULL]')
==
FAIL: test_aaa_qdstat_connect_sasl_over_ssl
(system_tests_sasl_plain.RouterTestPlainSaslOverSsl)
--
Traceback (most recent call last):
File
"/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
line 263, in test_aaa_qdstat_connect_sasl_over_ssl
"qdstat exit status %s, output:\n%s" % (p.returncode, out)
AssertionErr
[jira] [Updated] (DISPATCH-631) Tests should be made conditional to skip tests for SASL features that are not available
[
https://issues.apache.org/jira/browse/DISPATCH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rabih Mourad updated DISPATCH-631:
--
Attachment: failedTests.txt
> Tests should be made conditional to skip tests for SASL features that are not
> available
> ---
>
> Key: DISPATCH-631
> URL: https://issues.apache.org/jira/browse/DISPATCH-631
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.7.0, 0.8.0
> Environment: linux, sunos
>Reporter: Rabih Mourad
> Attachments: failedTests.txt
>
>
> > I compiled qpid-proton 0.16.0 with "-DSASL_IMPL=none", but i have an
> > qpid-dispatch 0.7.0 unit tests that are failing in:
> >
> > system_tests_qdstat
> > system_tests_sasl_plain
> > system_tests_deprecated
> >
> > I attached the tests output.
> >
> > Do you have any idea, where should i look? Is Cyrus mandatory for the
> > qpid-dispatch 0.7.0?
> Not mandatory, the tests should probably be made conditional to skip tests
> for SASL features that are not available. Raise a JIRA for that.
> Failing tests output:
> FAIL: test_ssl_cert_to_auth_fail_no_sasl_external
> (system_tests_qdstat.QdstatSslNoExternalTest)
> --
> Traceback (most recent call last):
> File
> "/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_qdstat.py",
> line 325, in test_ssl_cert_to_auth_fail_no_sasl_external
> self.ssl_test_bad('auth_s', ['client_cert_all'])
> File
> "/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_qdstat.py",
> line 322, in ssl_test_bad
> self.assertRaises(AssertionError, self.ssl_test, url_name, arg_names)
> AssertionError: AssertionError not raised
> ==
> FAIL: test_inter_router_plain_exists
> (system_tests_sasl_plain.RouterTestPlainSasl)
> The setUpClass sets up two routers with SASL PLAIN enabled.
> --
> Traceback (most recent call last):
> File
> "/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
> line 121, in test_inter_router_plain_exists
> self.assertIn("inter-router", out)
> File
> "/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_test.py",
> line 674, in assertIn
> assert item in items, "%s not in %s" % (item, items)
> AssertionError: inter-router not in Connections
> Id host container roledir
> security authentication
>
> =
> 13 127.0.0.1:43271 09eaefc9-7250-4a3b-a9d0-42c58e48a194 normal in
> no-security anonymous-user
> ==
> FAIL: test_qdstat_connect_sasl (system_tests_sasl_plain.RouterTestPlainSasl)
> --
> Traceback (most recent call last):
> File
> "/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
> line 135, in test_qdstat_connect_sasl
> "qdstat exit status %s, output:\n%s" % (p.returncode, out)
> AssertionError: qdstat exit status 1, output:
> ConnectionException: Connection amqp://0.0.0.0:24677/$management
> disconnected: Condition('amqp:unauthorized-access', 'Authentication failed
> [mech=NULL]')
> ==
> FAIL: test_qdstat_connect_sasl_password_file
> (system_tests_sasl_plain.RouterTestPlainSasl)
> --
> Traceback (most recent call last):
> File
> "/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux/qpid-dispatch-0.7.0/tests/system_tests_sasl_plain.py",
> line 163, in test_qdstat_connect_sasl_password_file
> "qdstat exit status %s, output:\n%s" % (p.returncode, out)
> AssertionError: qdstat exit status 1, output:
> ConnectionException: Connection amqp://0.0.0.0:24677/$management
> disconnected: Condition('amqp:unauthorized-access', 'Authentication failed
> [mech=NULL]')
> ==
> FAIL: test_aaa_qdstat_connect_sasl_over_ssl
> (system_tests_sasl_plain.RouterTestPlainSaslOverSsl)
> --
> Traceback (most recent call last):
> File
> "/data/jenkins-slave/home/workspace/qpid-dispatch-router/label/linux
