[jira] [Comment Edited] (DISPATCH-895) qpid-dispatch crashes with a SEGFAULT in libqpid-proton
[ https://issues.apache.org/jira/browse/DISPATCH-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281302#comment-16281302 ] Saurabh Badhwar edited comment on DISPATCH-895 at 12/7/17 4:02 AM: --- On running qpid-dispatch under gdb with the coredump attached for analysis, it seems like the crash happens in pni_add_tpwork when the following instrcution: pn_connection_t *connection = delivery->link->session->connection; is executed. This probably seems like, either the link has been freed and is then being referred to. gdb -c /root/bz1519140-qdrouterd-segfault-coredump/coredump $(which qdrouterd) .. Program terminated with signal 11, Segmentation fault. #0 pni_add_tpwork (delivery=0x7f0d6c80ef00) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:727 727 pn_connection_t *connection = delivery->link->session->connection; (gdb) bt #0 pni_add_tpwork (delivery=0x7f0d6c80ef00) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:727 #1 0x7f0d8bde1cae in pn_delivery_update (delivery=, state=) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:2026 #2 0x7f0d8c051cc8 in CORE_delivery_update (context=0x234e970, dlv=0x7f0d7005c1d0, disp=39, settled=) at /usr/src/debug/qpid-dispatch-0.8.0/src/router_node.c:1068 #3 0x7f0d8c046c5d in qdr_connection_process (conn=0x7f0d6880f210) at /usr/src/debug/qpid-dispatch-0.8.0/src/router_core/connections.c:306 #4 0x7f0d8c0321d8 in writable_handler (container=0x2087740, container=0x2087740, conn=, qd_conn=0x269c290) at /usr/src/debug/qpid-dispatch-0.8.0/src/container.c:307 #5 handler (handler_context=0x2087740, conn_context=0x2197f40, event=, qd_conn=0x269c290) at /usr/src/debug/qpid-dispatch-0.8.0/src/container.c:614 #6 0x7f0d8c056ccb in process_connector (cxtr=, qd_server=0x230e4f0) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:792 #7 thread_run (arg=) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:1012 #8 0x7f0d8c0574e6 in qd_server_run (qd=0x1d28030) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:1421 #9 0x00401bd7 in main_process (config_path=config_path@entry=0x7ffed8973f2d "/etc/qpid-dispatch/qdrouterd.conf", python_pkgdir=python_pkgdir@entry=0x402321 "/usr/lib/qpid-dispatch/python", fd=fd@entry=2) at /usr/src/debug/qpid-dispatch-0.8.0/router/src/main.c:147 #10 0x00401844 in main (argc=3, argv=0x7ffed8972c68) at /usr/src/debug/qpid-dispatch-0.8.0/router/src/main.c:353 On taking a more indepth look at the variables with the debug symbols provided to gdb, the traces affirm that either the delivery->link is null when it was passed to pni_add_tpwork or it was already freed. (gdb) print delivery $6 = (pn_delivery_t *) 0x7f0b881447c0 (gdb) ptype pn_delivery_t type = struct pn_delivery_t { pn_disposition_t local; pn_disposition_t remote; pn_link_t *link; pn_buffer_t *tag; pn_delivery_t *unsettled_next; pn_delivery_t *unsettled_prev; pn_delivery_t *work_next; pn_delivery_t *work_prev; pn_delivery_t *tpwork_next; pn_delivery_t *tpwork_prev; pn_delivery_state_t state; pn_buffer_t *bytes; pn_record_t *context; _Bool updated; _Bool settled; _Bool work; _Bool tpwork; _Bool done; _Bool referenced; } (gdb) print *delivery $7 = { local = { condition = { name = 0x7f0b881ba660, description = 0x7f0b88213ef0, info = 0x7f0b8820dc50 }, type = 39, data = 0x7f0b881446f0, annotations = 0x7f0b88145480, section_offset = 0, section_number = 0, failed = true, undeliverable = false, settled = true }, remote = { condition = { name = 0x7f0b8820da60, description = 0x7f0b8820dab0, info = 0x7f0b8820db00 }, type = 0, data = 0x7f0b88144600, annotations = 0x7f0b88214010, section_offset = 0, section_number = 0, failed = false, undeliverable = false, settled = false }, link = 0x0, tag = 0x7f0b881ba920, unsettled_next = 0x0, unsettled_prev = 0x0, work_next = 0x7f0b88048cf0, work_prev = 0x0, tpwork_next = 0x7f0b8802c230, tpwork_prev = 0x0, state = { id = 0, sent = false, init = false }, bytes = 0x7f0b881ba770, context = 0x7f0b881badd0, updated = false, settled = true, work = false, tpwork = false, done = true, referenced = true } was (Author: sbadhwar): On running qpid-dispatch under gdb with the coredump attached for analysis, it seems like the crash happens in pni_add_tpwork when the following instrcution: pn_connection_t *connection = delivery->link->session->connection; is executed. This probably seems like, either the link has been freed and is then being referred to. gdb -c /root/bz1519140-qdrouterd-segfault-coredump/coredump $(which qdrouterd) .. Program terminated with signa
[jira] [Commented] (DISPATCH-895) qpid-dispatch crashes with a SEGFAULT in libqpid-proton
[ https://issues.apache.org/jira/browse/DISPATCH-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281303#comment-16281303 ] Saurabh Badhwar commented on DISPATCH-895: -- A more indepth information from debug analysis on per thread basis: [root@c10-h19-r730xd-vm3 ~]# gdb qdrouterd /var/spool/abrt/ccpp-2017-12-05-09\:16\:21-14072/coredump -ex 'info thread' -ex 'thread apply all bt' -batch [New LWP 14075] [New LWP 14072] [New LWP 14073] [New LWP 14076] [New LWP 14074] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/qdrouterd -c /etc/qpid-dispatch/qdrouterd.conf'. Program terminated with signal 11, Segmentation fault. #0 pni_add_tpwork (delivery=0x7f0b881447c0) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:727 727 pn_connection_t *connection = delivery->link->session->connection; Id Target Id Frame 5Thread 0x7f0b9ed34700 (LWP 14074) 0x7f0bac2a0c0b in send () from /lib64/libpthread.so.0 4Thread 0x7f0b9dd32700 (LWP 14076) 0x7f0bac2a042d in __lll_lock_wait () from /lib64/libpthread.so.0 3Thread 0x7f0b9f748700 (LWP 14073) 0x7f0bac29d945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2Thread 0x7f0bacb6b1c0 (LWP 14072) 0x7f0baaed9052 in mul4x_internal () from /lib64/libcrypto.so.10 * 1Thread 0x7f0b9e533700 (LWP 14075) pni_add_tpwork (delivery=0x7f0b881447c0) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:727 Thread 5 (Thread 0x7f0b9ed34700 (LWP 14074)): #0 0x7f0bac2a0c0b in send () from /lib64/libpthread.so.0 #1 0x7f0bac72a5e7 in connector_process (c=0x7f0b94098150) at /usr/src/debug/qpid-dispatch-0.8.0/src/posix/driver.c:776 #2 0x7f0bac742d09 in process_connector (cxtr=, qd_server=0x141a370) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:734 #3 thread_run (arg=) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:1012 #4 0x7f0bac299e25 in start_thread () from /lib64/libpthread.so.0 #5 0x7f0bab5cd34d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f0b9dd32700 (LWP 14076)): #0 0x7f0bac2a042d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x7f0bac2a2c6c in _L_cond_lock_789 () from /lib64/libpthread.so.0 #2 0x7f0bac2a2b01 in __pthread_mutex_cond_lock () from /lib64/libpthread.so.0 #3 0x7f0bac29d9d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #4 0x7f0bac72b319 in sys_cond_wait (cond=, held_mutex=) at /usr/src/debug/qpid-dispatch-0.8.0/src/posix/threading.c:91 #5 0x7f0bac74292c in thread_run (arg=) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:894 #6 0x7f0bac299e25 in start_thread () from /lib64/libpthread.so.0 #7 0x7f0bab5cd34d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f0b9f748700 (LWP 14073)): #0 0x7f0bac29d945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f0bac72b319 in sys_cond_wait (cond=, held_mutex=) at /usr/src/debug/qpid-dispatch-0.8.0/src/posix/threading.c:91 #2 0x7f0bac7392d5 in router_core_thread (arg=0x1448e20) at /usr/src/debug/qpid-dispatch-0.8.0/src/router_core/router_core_thread.c:66 #3 0x7f0bac299e25 in start_thread () from /lib64/libpthread.so.0 #4 0x7f0bab5cd34d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f0bacb6b1c0 (LWP 14072)): #0 0x7f0baaed9052 in mul4x_internal () from /lib64/libcrypto.so.10 #1 0x7f0baaed92c4 in bn_power5 () from /lib64/libcrypto.so.10 #2 0x0175b600 in ?? () #3 0x7ffd21c408f0 in ?? () #4 0x0175b380 in ?? () #5 0x in ?? () Thread 1 (Thread 0x7f0b9e533700 (LWP 14075)): #0 pni_add_tpwork (delivery=0x7f0b881447c0) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:727 #1 0x7f0bac4cdcae in pn_delivery_update (delivery=, state=) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:2026 #2 0x7f0bac73dcc8 in CORE_delivery_update (context=0x144b970, dlv=0x7f0b90074f10, disp=39, settled=) at /usr/src/debug/qpid-dispatch-0.8.0/src/router_node.c:1068 #3 0x7f0bac732c5d in qdr_connection_process (conn=0x7f0b88030bd0) at /usr/src/debug/qpid-dispatch-0.8.0/src/router_core/connections.c:306 #4 0x7f0bac71e1d8 in writable_handler (container=0xe658c0, container=0xe658c0, conn=, qd_conn=0x7f0b9b10) at /usr/src/debug/qpid-dispatch-0.8.0/src/container.c:307 #5 handler (handler_context=0xe658c0, conn_context=0x1294f40, event=, qd_conn=0x7f0b9b10) at /usr/src/debug/qpid-dispatch-0.8.0/src/container.c:614 #6 0x7f0bac742ccb in process_connector (cxtr=, qd_server=0x141a370) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:792 #7 thread_run (arg=) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:1012 #8 0x7f0bac299e25 in start_thread () from /lib64/libpthread.so.0 #9 0x7f0bab5
[jira] [Commented] (DISPATCH-895) qpid-dispatch crashes with a SEGFAULT in libqpid-proton
[ https://issues.apache.org/jira/browse/DISPATCH-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281302#comment-16281302 ] Saurabh Badhwar commented on DISPATCH-895: -- On running qpid-dispatch under gdb with the coredump attached for analysis, it seems like the crash happens in pni_add_tpwork when the following instrcution: pn_connection_t *connection = delivery->link->session->connection; is executed. This probably seems like, either the link has been freed and is then being referred to. gdb -c /root/bz1519140-qdrouterd-segfault-coredump/coredump $(which qdrouterd) .. Program terminated with signal 11, Segmentation fault. #0 pni_add_tpwork (delivery=0x7f0d6c80ef00) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:727 727 pn_connection_t *connection = delivery->link->session->connection; (gdb) bt #0 pni_add_tpwork (delivery=0x7f0d6c80ef00) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:727 #1 0x7f0d8bde1cae in pn_delivery_update (delivery=, state=) at /usr/src/debug/qpid-proton-0.16.0/proton-c/src/core/engine.c:2026 #2 0x7f0d8c051cc8 in CORE_delivery_update (context=0x234e970, dlv=0x7f0d7005c1d0, disp=39, settled=) at /usr/src/debug/qpid-dispatch-0.8.0/src/router_node.c:1068 #3 0x7f0d8c046c5d in qdr_connection_process (conn=0x7f0d6880f210) at /usr/src/debug/qpid-dispatch-0.8.0/src/router_core/connections.c:306 #4 0x7f0d8c0321d8 in writable_handler (container=0x2087740, container=0x2087740, conn=, qd_conn=0x269c290) at /usr/src/debug/qpid-dispatch-0.8.0/src/container.c:307 #5 handler (handler_context=0x2087740, conn_context=0x2197f40, event=, qd_conn=0x269c290) at /usr/src/debug/qpid-dispatch-0.8.0/src/container.c:614 #6 0x7f0d8c056ccb in process_connector (cxtr=, qd_server=0x230e4f0) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:792 #7 thread_run (arg=) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:1012 #8 0x7f0d8c0574e6 in qd_server_run (qd=0x1d28030) at /usr/src/debug/qpid-dispatch-0.8.0/src/server.c:1421 #9 0x00401bd7 in main_process (config_path=config_path@entry=0x7ffed8973f2d "/etc/qpid-dispatch/qdrouterd.conf", python_pkgdir=python_pkgdir@entry=0x402321 "/usr/lib/qpid-dispatch/python", fd=fd@entry=2) at /usr/src/debug/qpid-dispatch-0.8.0/router/src/main.c:147 #10 0x00401844 in main (argc=3, argv=0x7ffed8972c68) at /usr/src/debug/qpid-dispatch-0.8.0/router/src/main.c:353 > qpid-dispatch crashes with a SEGFAULT in libqpid-proton > --- > > Key: DISPATCH-895 > URL: https://issues.apache.org/jira/browse/DISPATCH-895 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.8.0 > Environment: OS: Red Hat Enterprise Linux 7.4 > Arch: x86_64 > Installed Packages > Name: qpid-cpp-client > Arch: x86_64 > Version : 1.36.0 > Release : 9.el7 > Size: 4.4 M > Repo: installed > From repo : rhel-server-7-satellite-6-beta-rpms > Summary : Libraries for Qpid C++ client applications > URL : http://qpid.apache.org > License : ASL 2.0 > Description : Run-time libraries for AMQP client applications developed using > Qpid > : C++. Clients exchange messages with an AMQP message broker using > : the AMQP protocol. > Name: qpid-cpp-server > Arch: x86_64 > Version : 1.36.0 > Release : 9.el7 > Size: 5.2 M > Repo: installed > From repo : rhel-server-7-satellite-6-beta-rpms > Summary : An AMQP message broker daemon > URL : http://qpid.apache.org > License : ASL 2.0 > Description : A message broker daemon that receives stores and routes > messages using > : the open AMQP messaging protocol. > Name: qpid-cpp-server-linearstore > Arch: x86_64 > Version : 1.36.0 > Release : 9.el7 > Size: 797 k > Repo: installed > From repo : rhel-server-7-satellite-6-beta-rpms > Summary : Red Hat persistence extension to the Qpid messaging sytem > URL : http://qpid.apache.org > License : ASL 2.0 > Description : Red Hat persistence extension to the Qpid AMQP broker: > persistent message > : storage using a libaio-based asynchronous journal. > Name: qpid-dispatch-debuginfo > Arch: x86_64 > Version : 0.8.0 > Release : 10.el7 > Size: 2.1 M > Repo: installed > Summary : Debug information for package qpid-dispatch > URL : http://qpid.apache.org/ > License : ASL 2.0 > Description : This package provides debug information for package > qpid-dispatch. > : Debug information is useful when developing applications that > use this > : package or when debugging this package. > Name
[jira] [Created] (DISPATCH-895) qpid-dispatch crashes with a SEGFAULT in libqpid-proton
Saurabh Badhwar created DISPATCH-895: Summary: qpid-dispatch crashes with a SEGFAULT in libqpid-proton Key: DISPATCH-895 URL: https://issues.apache.org/jira/browse/DISPATCH-895 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 0.8.0 Environment: OS: Red Hat Enterprise Linux 7.4 Arch: x86_64 Installed Packages Name: qpid-cpp-client Arch: x86_64 Version : 1.36.0 Release : 9.el7 Size: 4.4 M Repo: installed >From repo : rhel-server-7-satellite-6-beta-rpms Summary : Libraries for Qpid C++ client applications URL : http://qpid.apache.org License : ASL 2.0 Description : Run-time libraries for AMQP client applications developed using Qpid : C++. Clients exchange messages with an AMQP message broker using : the AMQP protocol. Name: qpid-cpp-server Arch: x86_64 Version : 1.36.0 Release : 9.el7 Size: 5.2 M Repo: installed >From repo : rhel-server-7-satellite-6-beta-rpms Summary : An AMQP message broker daemon URL : http://qpid.apache.org License : ASL 2.0 Description : A message broker daemon that receives stores and routes messages using : the open AMQP messaging protocol. Name: qpid-cpp-server-linearstore Arch: x86_64 Version : 1.36.0 Release : 9.el7 Size: 797 k Repo: installed >From repo : rhel-server-7-satellite-6-beta-rpms Summary : Red Hat persistence extension to the Qpid messaging sytem URL : http://qpid.apache.org License : ASL 2.0 Description : Red Hat persistence extension to the Qpid AMQP broker: persistent message : storage using a libaio-based asynchronous journal. Name: qpid-dispatch-debuginfo Arch: x86_64 Version : 0.8.0 Release : 10.el7 Size: 2.1 M Repo: installed Summary : Debug information for package qpid-dispatch URL : http://qpid.apache.org/ License : ASL 2.0 Description : This package provides debug information for package qpid-dispatch. : Debug information is useful when developing applications that use this : package or when debugging this package. Name: qpid-dispatch-router Arch: x86_64 Version : 0.8.0 Release : 10.el7 Size: 1.0 M Repo: installed >From repo : rhel-server-7-satellite-6-beta-rpms Summary : The Qpid Dispatch Router executable URL : http://qpid.apache.org/ License : ASL 2.0 Description : The Qpid Dispatch Router executable. Name: qpid-proton-c Arch: x86_64 Version : 0.16.0 Release : 7.el7 Size: 334 k Repo: installed >From repo : rhel-server-7-satellite-6-beta-rpms Summary : C libraries for Qpid Proton URL : http://qpid.apache.org/proton/ License : ASL 2.0 Description : C libraries for Qpid Proton. Name: qpid-proton-debuginfo Arch: x86_64 Version : 0.16.0 Release : 7.el7 Size: 6.8 M Repo: installed Summary : Debug information for package qpid-proton URL : http://qpid.apache.org/proton/ License : ASL 2.0 Description : This package provides debug information for package qpid-proton. : Debug information is useful when developing applications that use this : package or when debugging this package. Name: qpid-qmf Arch: x86_64 Version : 1.36.0 Release : 9.el7 Size: 476 k Repo: installed >From repo : rhel-server-7-satellite-6-beta-rpms Summary : The QPID Management Framework URL : http://qpid.apache.org License : ASL 2.0 Description : The Qpid Management Framework is a general-purpose management bus built on Qpid : messaging. It takes advantage of the scalability, security, and rich : capabilities of Qpid to provide flexible and easy-to-use manageability to a : large set of applications. Name: qpid-tools Arch: noarch Version : 1.36.0 Release : 9.el7 Size: 384 k Repo: installed >From repo : rhel-server-7-satellite-6-beta-rpms Summary : Management and diagostic tools for Apache Qpid URL : http://qpid.apache.org License : ASL 2.0 Description : Management and diagnostic tools for Apache Qpid brokers and clients. Reporter: Saurabh Badhwar During the work process associated with Red Hat Satellite, we found that Qpid-dispatch router started to crash abruptly without any changes being made to it. On checking the logs, it seems like qpid-dispatch-router experienced a SEGFAULT and crashed. Once this crash starts to happen there is no way we are able to restart qpid-dispatch since it continues to fail. A trace from the /var/log/messages [root@c10-h19-r730xd-
[jira] [Commented] (QPID-8038) [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281051#comment-16281051 ] ASF subversion and git services commented on QPID-8038: --- Commit 93c1e0b8d04783c028d25e59fe69088cd039a263 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=93c1e0b ] QPID-8038: [Broker-J] [AMQP 0-8..0-91] Add more queue protocol tests > [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x > - > > Key: QPID-8038 > URL: https://issues.apache.org/jira/browse/QPID-8038 > Project: Qpid > Issue Type: Improvement > Components: Broker-J, Java Tests >Reporter: Alex Rudyy > > We need a test frameworks which would allow creation of tests which would be > sending the AMQP 0-x performatives over TCP and receiving and asserting > broker responses. > The framework should satisfy the following requirements: > * It should allow running tests against other AMQP brokers > * The framework should encapsulate starting/stopping of broker and queue > creation/deletion under special interface(s) which can be implemented by the > Broker developers in order to run tests against different Broker > implementations > * Tests should be able to start and stop broker if required or configured > * Tests should be able to generate AMQP performatives and assert received > peer's AMQP performatives > * The framework should allow using other transport than TCP if required > * The framework should be based on AMQP 0-x implementations of Broker-J -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1326) Compilation failures against OpenSSL v1.1.0
[ https://issues.apache.org/jira/browse/PROTON-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281012#comment-16281012 ] ASF GitHub Bot commented on PROTON-1326: Github user kgiusti closed the pull request at: https://github.com/apache/qpid-proton/pull/118 > Compilation failures against OpenSSL v1.1.0 > --- > > Key: PROTON-1326 > URL: https://issues.apache.org/jira/browse/PROTON-1326 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.14.0, 0.15.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Critical > Fix For: proton-c-0.18.0 > > > Openssl changes the API in a way that breaks proton's openssl implementation. > Proton/C can not compile against Openssl version 1.1 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #118: PROTON-1326: update python setup.py to avoid ...
Github user kgiusti closed the pull request at: https://github.com/apache/qpid-proton/pull/118 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1326) Compilation failures against OpenSSL v1.1.0
[ https://issues.apache.org/jira/browse/PROTON-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280982#comment-16280982 ] ASF GitHub Bot commented on PROTON-1326: Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/118 @kgiusti I think this PR is now irrelevant - as 0.18 is out and supports openssl 1.0 and 1.1. Could you close it? > Compilation failures against OpenSSL v1.1.0 > --- > > Key: PROTON-1326 > URL: https://issues.apache.org/jira/browse/PROTON-1326 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.14.0, 0.15.0 >Reporter: Ken Giusti >Assignee: Andrew Stitcher >Priority: Critical > Fix For: proton-c-0.18.0 > > > Openssl changes the API in a way that breaks proton's openssl implementation. > Proton/C can not compile against Openssl version 1.1 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #118: PROTON-1326: update python setup.py to avoid using i...
Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/118 @kgiusti I think this PR is now irrelevant - as 0.18 is out and supports openssl 1.0 and 1.1. Could you close it? --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #232: DISPATCH 894 - Made the following changes t...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/232 DISPATCH 894 - Made the following changes to make the system tests wo⦠â¦rk on CentOS 6. 1. Modified system tests to use unittest2 instead of unittest test framework. 2. Modified tests/CMakeLists.txt to use the unit2 test runner. 3. Fixed some tests to use backwards compatible assert functions. 4. Remove unused imports in tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-894-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/232.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #232 commit 6d10fc94131e22872a84489e81fd4f1ec5f1e1b7 Author: Ganesh Murthy Date: 2017-12-06T15:08:24Z DISPATCH 894 - Made the following changes to make the system tests work on CentOS 6. 1. Modified system tests to use unittest2 instead of unittest test framework. 2. Modified tests/CMakeLists.txt to use the unit2 test runner. 3. Fixed some tests to use backwards compatible assert functions. 4. Remove unused imports in tests --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-891) Router incref assert in system_tests_delivery_abort
[ https://issues.apache.org/jira/browse/DISPATCH-891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-891. -- Resolution: Fixed Fix Version/s: 1.1.0 Fixed at commit 16d60e7 > Router incref assert in system_tests_delivery_abort > --- > > Key: DISPATCH-891 > URL: https://issues.apache.org/jira/browse/DISPATCH-891 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.0.0 > Environment: Fedora 27, > Dispatch master#d5f279b, > Proton master#25025e9 >Reporter: Chuck Rolke > Fix For: 1.1.0 > > Attachments: A.log > > > Self tests fail every time. > {noformat} > > ctest -VV -R system_tests_delivery_abort > UpdateCTestConfiguration from > :/home/chug/git/qpid-dispatch/build/DartConfiguration.tcl > Parse Config file:/home/chug/git/qpid-dispatch/build/DartConfiguration.tcl > UpdateCTestConfiguration from > :/home/chug/git/qpid-dispatch/build/DartConfiguration.tcl > Parse Config file:/home/chug/git/qpid-dispatch/build/DartConfiguration.tcl > Test project /home/chug/git/qpid-dispatch/build > Constructing a list of tests > Done constructing a list of tests > Updating test list for fixtures > Added 0 tests to meet fixture requirements > Checking test dependency graph... > Checking test dependency graph end > test 36 > Start 36: system_tests_delivery_abort > 36: Test command: /usr/bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "-m" "unittest" "-v" > "system_tests_delivery_abort" > 36: Test timeout computed to be: 1500 > 36: test_01_message_route_truncated_one_router > (system_tests_delivery_abort.RouterTest) ... ok > 36: test_02_message_route_truncated_two_routers > (system_tests_delivery_abort.RouterTest) ... ok > 36: test_03_link_route_truncated_one_router > (system_tests_delivery_abort.RouterTest) ... ok > 36: test_04_link_route_truncated_two_routers > (system_tests_delivery_abort.RouterTest) ... ok > 36: test_05_message_route_abort_one_router > (system_tests_delivery_abort.RouterTest) ... ok > 36: test_06_message_route_abort_two_routers > (system_tests_delivery_abort.RouterTest) ... ok > 36: test_07_multicast_truncate_one_router > (system_tests_delivery_abort.RouterTest) ... FAIL > 36: ERROR > 36: > 36: == > 36: ERROR: tearDownClass (system_tests_delivery_abort.RouterTest) > 36: -- > 36: Traceback (most recent call last): > 36: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 606, in > tearDownClass > 36: cls.tester.teardown() > 36: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 544, in > teardown > 36: raise RuntimeError("Errors during teardown: \n\n%s" % > "\n\n".join([str(e) for e in errors])) > 36: RuntimeError: Errors during teardown: > 36: > 36: Process 27948 error: exit code -6, expected -1 > 36: qdrouterd -c A.conf -I /home/chug/git/qpid-dispatch/python > 36: > /home/chug/git/qpid-dispatch/build/tests/system_test.dir/system_tests_delivery_abort/RouterTest/setUpClass/A-1.cmd > 36: > 36: qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/transfer.c:337: > qdr_delivery_incref: Assertion `rc > 0 || !delivery->ref_counted' failed. > 36: qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/transfer.c:337: > qdr_delivery_incref: Assertion `rc > 0 || !delivery->ref_counted' failed. > 36: > 36: > 36: == > 36: FAIL: test_07_multicast_truncate_one_router > (system_tests_delivery_abort.RouterTest) > 36: -- > 36: Traceback (most recent call last): > 36: File > "/home/chug/git/qpid-dispatch/tests/system_tests_delivery_abort.py", line > 128, in test_07_multicast_truncate_one_router > 36: self.assertEqual(None, test.error) > 36: AssertionError: None != "Timeout Expired - Unprocessed Ops: > ['Send_Short_3'], Result1: ['Send_Short_1'], Result2: ['Send_Short_1']" > 36: > 36: -- > 36: Ran 7 tests in 17.906s > 36: > 36: FAILED (failures=1, errors=1) > 1/1 Test #36: system_tests_delivery_abort ..***Failed 18.01 sec > 0% tests passed, 1 tests failed out of 1 > Total Test time (real) = 18.01 sec > The following tests FAILED: >36 - system_tests_delivery_abort (Failed) > Errors while running CTest > {noformat} > Will attach failed router log with incref/decref trace -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-
[jira] [Commented] (PROTON-869) [proton-c] should be straightforward to associate handlers with acceptors
[ https://issues.apache.org/jira/browse/PROTON-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280667#comment-16280667 ] Justin Ross commented on PROTON-869: The new proactor code allows use of listen handlers for incoming connections. > [proton-c] should be straightforward to associate handlers with acceptors > - > > Key: PROTON-869 > URL: https://issues.apache.org/jira/browse/PROTON-869 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.9 >Reporter: Adrian Preston >Priority: Minor > Labels: api, patch, reactor > Fix For: proton-c-0.19.0 > > Attachments: proton-869.patch > > > Currently it is only possible to associate a handler with an acceptor by > casting it to pn_selectable_t. This could be broken by a future change to > the implementation of pn_acceptor_t. > Related: the acceptor implementation does not generate a PN_SELECTABLE_ERROR > event if the act of accepting a socket connection fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-869) [proton-c] should be straightforward to associate handlers with acceptors
[ https://issues.apache.org/jira/browse/PROTON-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-869. Resolution: Fixed > [proton-c] should be straightforward to associate handlers with acceptors > - > > Key: PROTON-869 > URL: https://issues.apache.org/jira/browse/PROTON-869 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.9 >Reporter: Adrian Preston >Priority: Minor > Labels: api, patch, reactor > Fix For: proton-c-0.19.0 > > Attachments: proton-869.patch > > > Currently it is only possible to associate a handler with an acceptor by > casting it to pn_selectable_t. This could be broken by a future change to > the implementation of pn_acceptor_t. > Related: the acceptor implementation does not generate a PN_SELECTABLE_ERROR > event if the act of accepting a socket connection fails. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1656) [OSX] c-proactor-tests test_ipv4_ipv6 fails
[ https://issues.apache.org/jira/browse/PROTON-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1656. - Resolution: Fixed > [OSX] c-proactor-tests test_ipv4_ipv6 fails > --- > > Key: PROTON-1656 > URL: https://issues.apache.org/jira/browse/PROTON-1656 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c > Environment: OSX 10.11.6, Xcode 7.3.1 >Reporter: Roddie Kieley >Assignee: Alan Conway > Labels: osx > Fix For: proton-c-0.19.0 > > > This fails almost 100% of the time, usually with the following: > {code} > 10: TEST: test_ipv4_ipv6(&t) > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637: > check failed: No condition, expected :refused [test_ipv4_ipv6(&t)] > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:638: > check failed: No condition, expected :refused [test_ipv4_ipv6(&t)] > 10: FAIL: test_ipv4_ipv6(&t) (2 errors) > {code} > or > {code} > 10: TEST: test_ipv4_ipv6(&t) > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637: > check failed: 'refused' not in 'connection timed out - connecting to > 127.0.0.1:49446' [test_ipv4_ipv6(&t)] > 10: FAIL: test_ipv4_ipv6(&t) (1 errors) > {code} > It passed once during testing yesterday but not sure what that is indicative > of yet. Tested on Fedora 25 and always passes. Note that Fedora 25 is on a > separate box and I do note that the OSX box has two 'inactive' entries in > ifconfig which may or may not interfere with binding to 0.0.0.0 or ::1: > {code} > earth:126 rkieley$ ifconfig > lo0: flags=8049 mtu 16384 > options=3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > nd6 options=1 > gif0: flags=8010 mtu 1280 > stf0: flags=0<> mtu 1280 > en0: flags=8863 mtu 1500 > options=27 > ether d4:9a:20:0d:67:fc > inet6 fe80::d69a:20ff:fe0d:67fc%en0 prefixlen 64 scopeid 0x4 > inet 192.168.2.4 netmask 0xff00 broadcast 192.168.2.255 > nd6 options=1 > media: autoselect (1000baseT ) > status: active > en1: flags=8823 mtu 1500 > ether f8:1e:df:f4:46:8c > nd6 options=1 > media: autoselect () > status: inactive > fw0: flags=8863 mtu 494 > lladdr d4:9a:20:ff:fe:0d:67:fc > nd6 options=1 > media: autoselect > status: inactive > earth:126 rkieley$ > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1656) [OSX] c-proactor-tests test_ipv4_ipv6 fails
[ https://issues.apache.org/jira/browse/PROTON-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1656: --- Assignee: Alan Conway > [OSX] c-proactor-tests test_ipv4_ipv6 fails > --- > > Key: PROTON-1656 > URL: https://issues.apache.org/jira/browse/PROTON-1656 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c > Environment: OSX 10.11.6, Xcode 7.3.1 >Reporter: Roddie Kieley >Assignee: Alan Conway > Labels: osx > Fix For: proton-c-0.19.0 > > > This fails almost 100% of the time, usually with the following: > {code} > 10: TEST: test_ipv4_ipv6(&t) > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637: > check failed: No condition, expected :refused [test_ipv4_ipv6(&t)] > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:638: > check failed: No condition, expected :refused [test_ipv4_ipv6(&t)] > 10: FAIL: test_ipv4_ipv6(&t) (2 errors) > {code} > or > {code} > 10: TEST: test_ipv4_ipv6(&t) > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637: > check failed: 'refused' not in 'connection timed out - connecting to > 127.0.0.1:49446' [test_ipv4_ipv6(&t)] > 10: FAIL: test_ipv4_ipv6(&t) (1 errors) > {code} > It passed once during testing yesterday but not sure what that is indicative > of yet. Tested on Fedora 25 and always passes. Note that Fedora 25 is on a > separate box and I do note that the OSX box has two 'inactive' entries in > ifconfig which may or may not interfere with binding to 0.0.0.0 or ::1: > {code} > earth:126 rkieley$ ifconfig > lo0: flags=8049 mtu 16384 > options=3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > nd6 options=1 > gif0: flags=8010 mtu 1280 > stf0: flags=0<> mtu 1280 > en0: flags=8863 mtu 1500 > options=27 > ether d4:9a:20:0d:67:fc > inet6 fe80::d69a:20ff:fe0d:67fc%en0 prefixlen 64 scopeid 0x4 > inet 192.168.2.4 netmask 0xff00 broadcast 192.168.2.255 > nd6 options=1 > media: autoselect (1000baseT ) > status: active > en1: flags=8823 mtu 1500 > ether f8:1e:df:f4:46:8c > nd6 options=1 > media: autoselect () > status: inactive > fw0: flags=8863 mtu 494 > lladdr d4:9a:20:ff:fe:0d:67:fc > nd6 options=1 > media: autoselect > status: inactive > earth:126 rkieley$ > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1656) [OSX] c-proactor-tests test_ipv4_ipv6 fails
[ https://issues.apache.org/jira/browse/PROTON-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1656: Labels: osx (was: ) > [OSX] c-proactor-tests test_ipv4_ipv6 fails > --- > > Key: PROTON-1656 > URL: https://issues.apache.org/jira/browse/PROTON-1656 > Project: Qpid Proton > Issue Type: Sub-task > Components: proton-c > Environment: OSX 10.11.6, Xcode 7.3.1 >Reporter: Roddie Kieley >Assignee: Alan Conway > Labels: osx > Fix For: proton-c-0.19.0 > > > This fails almost 100% of the time, usually with the following: > {code} > 10: TEST: test_ipv4_ipv6(&t) > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637: > check failed: No condition, expected :refused [test_ipv4_ipv6(&t)] > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:638: > check failed: No condition, expected :refused [test_ipv4_ipv6(&t)] > 10: FAIL: test_ipv4_ipv6(&t) (2 errors) > {code} > or > {code} > 10: TEST: test_ipv4_ipv6(&t) > 10: > /Users/rkieley/LocalProjects/issues/PROTON-522/qpid-proton-roddiekieley/proton-c/src/tests/proactor.c:637: > check failed: 'refused' not in 'connection timed out - connecting to > 127.0.0.1:49446' [test_ipv4_ipv6(&t)] > 10: FAIL: test_ipv4_ipv6(&t) (1 errors) > {code} > It passed once during testing yesterday but not sure what that is indicative > of yet. Tested on Fedora 25 and always passes. Note that Fedora 25 is on a > separate box and I do note that the OSX box has two 'inactive' entries in > ifconfig which may or may not interfere with binding to 0.0.0.0 or ::1: > {code} > earth:126 rkieley$ ifconfig > lo0: flags=8049 mtu 16384 > options=3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff00 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > nd6 options=1 > gif0: flags=8010 mtu 1280 > stf0: flags=0<> mtu 1280 > en0: flags=8863 mtu 1500 > options=27 > ether d4:9a:20:0d:67:fc > inet6 fe80::d69a:20ff:fe0d:67fc%en0 prefixlen 64 scopeid 0x4 > inet 192.168.2.4 netmask 0xff00 broadcast 192.168.2.255 > nd6 options=1 > media: autoselect (1000baseT ) > status: active > en1: flags=8823 mtu 1500 > ether f8:1e:df:f4:46:8c > nd6 options=1 > media: autoselect () > status: inactive > fw0: flags=8863 mtu 494 > lladdr d4:9a:20:ff:fe:0d:67:fc > nd6 options=1 > media: autoselect > status: inactive > earth:126 rkieley$ > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1201) Proton should not issue extra credit on a link that the application has requested be closed
[ https://issues.apache.org/jira/browse/PROTON-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1201: Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > Proton should not issue extra credit on a link that the application has > requested be closed > --- > > Key: PROTON-1201 > URL: https://issues.apache.org/jira/browse/PROTON-1201 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 >Reporter: Adel Boutros >Assignee: Cliff Jansen > Labels: workaround > Fix For: proton-c-0.20.0 > > > Proton-c client receives message after closing the connection and the link > and setting prefetech window to 1 > You can check the full details here: > http://qpid.2158936.n2.nabble.com/Proton-C-question-td7643503.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1550) Epoll proactor performance improvement
[ https://issues.apache.org/jira/browse/PROTON-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280659#comment-16280659 ] Justin Ross commented on PROTON-1550: - The wakeup code does not appear to be a bottleneck after all. > Epoll proactor performance improvement > -- > > Key: PROTON-1550 > URL: https://issues.apache.org/jira/browse/PROTON-1550 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Linux >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: perf > Fix For: proton-c-0.19.0 > > > While stress testing and evaluating performance of the epoll proactor there > have been indications that as the number of connections increase, the > throughput increases more slowly than overall cpu use. > Instrumenting and profiling suggest that, at least for applications like > qpid-dispatch, there can be a large number of simultaneous pending > pn_connection_wake() requests for thread-safe handoff of messages from one > connection context to another. > As the number of connections rise, the use of adaptive spin locks for this > purpose is suspected to be an inefficient strategy, perhaps resulting in a > lock convoy. A trial use of one or more lockless queues could yield > substantial performance gain or at least better understanding of current hot > spots. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1550) Epoll proactor performance improvement
[ https://issues.apache.org/jira/browse/PROTON-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1550. --- Resolution: Not A Problem > Epoll proactor performance improvement > -- > > Key: PROTON-1550 > URL: https://issues.apache.org/jira/browse/PROTON-1550 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Linux >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Labels: perf > Fix For: proton-c-0.19.0 > > > While stress testing and evaluating performance of the epoll proactor there > have been indications that as the number of connections increase, the > throughput increases more slowly than overall cpu use. > Instrumenting and profiling suggest that, at least for applications like > qpid-dispatch, there can be a large number of simultaneous pending > pn_connection_wake() requests for thread-safe handoff of messages from one > connection context to another. > As the number of connections rise, the use of adaptive spin locks for this > purpose is suspected to be an inefficient strategy, perhaps resulting in a > lock convoy. A trial use of one or more lockless queues could yield > substantial performance gain or at least better understanding of current hot > spots. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1170) closed links are never deleted
[ https://issues.apache.org/jira/browse/PROTON-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1170: Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > closed links are never deleted > -- > > Key: PROTON-1170 > URL: https://issues.apache.org/jira/browse/PROTON-1170 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c > Environment: miserable >Reporter: michael goulish >Assignee: Cliff Jansen > Labels: leak, perf > Fix For: proton-c-0.20.0 > > > I wrote a reactor-based application that makes a single connection, and then > repeatedly makes-and-closes links (receivers) on that connection. > It makes and closes the links as fast as possible: as soon as it gets the > on_receiver_close event, it makes a new one. As soon as it gets the > on_receiver_open event -- it closes that receiver. > This application talks to a dispatch router. > Problem: Both the router and my application grow their memory (RSS) rapidly > -- and the router's ability to respond to new link creations slows down > rapidly. Looking at the router with Valgrind/Callgrind, after about 15,000 > links have been created and closed I see that 45% of all CPU time on the > router is being consumed by pn_find_link(). Instrumenting that code, I see > that the list it is looking at never decreases in size. > I tried creating my links with the "lifetime_policy" set to DELETE_ON_CLOSE, > but that had no effect. Grepping for that symbol, I see that it does not > occur in the proton C code except in its definition, and in a printing > convenience function. > Major scalability bug. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable
[ https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1556. - Resolution: Fixed > [proton-cpp] ssl_client_options is not self-assignable > -- > > Key: PROTON-1556 > URL: https://issues.apache.org/jira/browse/PROTON-1556 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 >Reporter: Jiri Daněk >Assignee: Cliff Jansen >Priority: Critical > Fix For: proton-c-0.19.0 > > Attachments: report-7646dc.html > > > {{ssl_client_options}} probably cannot be self-assigned. See the attached > report from clang-analyzer, which looks very plausible. > The problem is that assuming {{x == *this}}, the assignment operator will > decref and then incref the same value. Assuming the reference count was {{1}} > to start with, there will be use-after-free. > This probably does not matter that much in real-world code, but I found some > quotations that making self assignment work is really important in C++... > {noformat} > 58ssl_domain& internal::ssl_domain::operator=(const ssl_domain&x) { > 59if (impl_) impl_->decref(); > 60impl_ = x.impl_; > 61server_type_ = x.server_type_; > 62if (impl_) impl_->incref(); > 63return *this; > 64} > {noformat} > I believe the static analyzer is correct, because when I do not make any > changes to the {{examples/cpp/ssl}} example, Valgrind does not report errors > concerning the class, but if I add a {{ssl_cli = ssl_cli;}}, then I get > {noformat} > $ valgrind ./ssl -c > /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/ > ==4950== Memcheck, a memory error detector > ==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info > ==4950== Command: ./ssl -c > /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/ > ==4950== > ==4950== Invalid read of size 4 > ==4950==at 0x4E715CC: incref (ssl_domain.cpp:37) > ==4950==by 0x4E715CC: > proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) > (ssl_domain.cpp:62) > ==4950==by 0x4032F0: operator= (ssl.hpp:172) > ==4950==by 0x4032F0: main (ssl.cpp:176) > ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd > ==4950==at 0x4C2D2EB: operator delete(void*) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40) > ==4950==by 0x4E715FA: > proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) > (ssl_domain.cpp:59) > ==4950==by 0x4032F0: operator= (ssl.hpp:172) > ==4950==by 0x4032F0: main (ssl.cpp:176) > ==4950== Block was alloc'd at > ==4950==at 0x4C2C22F: operator new(unsigned long) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() > (ssl_domain.cpp:72) > ==4950==by 0x4E7195C: > proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string std::char_traits, std::allocator > const&, > proton::ssl::verify_mode) (ssl_domain.cpp:120) > ==4950==by 0x4032B9: main (ssl.cpp:175) > ==4950== > ==4950== Invalid read of size 4 > ==4950==at 0x4E71619: decref (ssl_domain.cpp:39) > ==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain() > (ssl_domain.cpp:66) > ==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172) > ==4950==by 0x4032F8: main (ssl.cpp:175) > ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd > ==4950==at 0x4C2D2EB: operator delete(void*) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40) > ==4950==by 0x4E715FA: > proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) > (ssl_domain.cpp:59) > ==4950==by 0x4032F0: operator= (ssl.hpp:172) > ==4950==by 0x4032F0: main (ssl.cpp:176) > ==4950== Block was alloc'd at > ==4950==at 0x4C2C22F: operator new(unsigned long) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() > (ssl_domain.cpp:72) > ==4950==by 0x4E7195C: > proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string std::char_traits, std::allocator > const&, > proton::ssl::verify_mode) (ssl_domain.cpp:120) > ==4950==by 0x4032B9: main (ssl.cpp:175) > ==4950== > ==4950== Invalid read of size 8 > ==4950==at 0x4
[jira] [Commented] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable
[ https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280652#comment-16280652 ] Justin Ross commented on PROTON-1556: - We're now happy with the fix we have. > [proton-cpp] ssl_client_options is not self-assignable > -- > > Key: PROTON-1556 > URL: https://issues.apache.org/jira/browse/PROTON-1556 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 >Reporter: Jiri Daněk >Assignee: Cliff Jansen >Priority: Critical > Fix For: proton-c-0.19.0 > > Attachments: report-7646dc.html > > > {{ssl_client_options}} probably cannot be self-assigned. See the attached > report from clang-analyzer, which looks very plausible. > The problem is that assuming {{x == *this}}, the assignment operator will > decref and then incref the same value. Assuming the reference count was {{1}} > to start with, there will be use-after-free. > This probably does not matter that much in real-world code, but I found some > quotations that making self assignment work is really important in C++... > {noformat} > 58ssl_domain& internal::ssl_domain::operator=(const ssl_domain&x) { > 59if (impl_) impl_->decref(); > 60impl_ = x.impl_; > 61server_type_ = x.server_type_; > 62if (impl_) impl_->incref(); > 63return *this; > 64} > {noformat} > I believe the static analyzer is correct, because when I do not make any > changes to the {{examples/cpp/ssl}} example, Valgrind does not report errors > concerning the class, but if I add a {{ssl_cli = ssl_cli;}}, then I get > {noformat} > $ valgrind ./ssl -c > /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/ > ==4950== Memcheck, a memory error detector > ==4950== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==4950== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info > ==4950== Command: ./ssl -c > /home/jdanek/Work/repos/qpid-proton/examples/cpp/ssl_certs/ > ==4950== > ==4950== Invalid read of size 4 > ==4950==at 0x4E715CC: incref (ssl_domain.cpp:37) > ==4950==by 0x4E715CC: > proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) > (ssl_domain.cpp:62) > ==4950==by 0x4032F0: operator= (ssl.hpp:172) > ==4950==by 0x4032F0: main (ssl.cpp:176) > ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd > ==4950==at 0x4C2D2EB: operator delete(void*) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40) > ==4950==by 0x4E715FA: > proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) > (ssl_domain.cpp:59) > ==4950==by 0x4032F0: operator= (ssl.hpp:172) > ==4950==by 0x4032F0: main (ssl.cpp:176) > ==4950== Block was alloc'd at > ==4950==at 0x4C2C22F: operator new(unsigned long) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() > (ssl_domain.cpp:72) > ==4950==by 0x4E7195C: > proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string std::char_traits, std::allocator > const&, > proton::ssl::verify_mode) (ssl_domain.cpp:120) > ==4950==by 0x4032B9: main (ssl.cpp:175) > ==4950== > ==4950== Invalid read of size 4 > ==4950==at 0x4E71619: decref (ssl_domain.cpp:39) > ==4950==by 0x4E71619: proton::internal::ssl_domain::~ssl_domain() > (ssl_domain.cpp:66) > ==4950==by 0x4032F8: ~ssl_client_options (ssl.hpp:172) > ==4950==by 0x4032F8: main (ssl.cpp:175) > ==4950== Address 0x766a3c0 is 0 bytes inside a block of size 16 free'd > ==4950==at 0x4C2D2EB: operator delete(void*) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E715FA: decref (ssl_domain.cpp:40) > ==4950==by 0x4E715FA: > proton::internal::ssl_domain::operator=(proton::internal::ssl_domain const&) > (ssl_domain.cpp:59) > ==4950==by 0x4032F0: operator= (ssl.hpp:172) > ==4950==by 0x4032F0: main (ssl.cpp:176) > ==4950== Block was alloc'd at > ==4950==at 0x4C2C22F: operator new(unsigned long) (in > /nix/store/gv9x2j31hvn0wf37h4jmb9xz6vgc3vvv-valgrind-3.12.0/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4950==by 0x4E7166C: proton::internal::ssl_domain::pn_domain() > (ssl_domain.cpp:72) > ==4950==by 0x4E7195C: > proton::ssl_client_options::ssl_client_options(std::__cxx11::basic_string std::char_traits, std::allocator > const&, > proton::ssl::verify_mode) (ssl_domain.cpp:120) > ==4950==by 0x4032B9: main (ssl.cp
[jira] [Updated] (PROTON-144) Reduce byte overhead for small payloads
[ https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-144: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > Reduce byte overhead for small payloads > --- > > Key: PROTON-144 > URL: https://issues.apache.org/jira/browse/PROTON-144 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2, 0.3 >Reporter: Affan Dar >Assignee: Andrew Stitcher > Labels: codec, perf > Fix For: proton-c-0.20.0 > > > In constrained bandwidth scenarios (e.g. on a cellular data network) any byte > overhead is very costly. > From the traces for a simple app, we are seeing a large overhead (>100 bytes) > in the message payload for sending a two byte message. It seems like there > are some default properties like the to and reply-to addresses that the > proton client stamps onto a message and also there is padding on the actual > two byte payload itself. > To be able to successfully embed the proton lib in such resource constrained > devices the byte overhead needs to be trimmed down as much as the protocol > allows. > --- > Details of test app > --- > The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN > updated usually once a day although commits have slowed since the push for > 0.2 and libopenssl version 1.0.0e-34.17.1. > The debugging output is all from proton, to get the debugging output set the > Env variable "PN_TRACE_FRM=1" > The test is done connecting to localhost and sending a message across as > simply as possible: > client: > pn_messenger_t *messenger = pn_messenger("b"); > pn_messenger_start(messenger); > pn_message_t *message = pn_message(); > pn_message_set_address(message, "amqps://0.0.0.0/a"); > char data[2] = {(unsigned char)0xff, (unsigned char)0xff}; > pn_message_load_data(message, data, 2); > pn_messenger_put(messenger, message); > pn_messenger_send(messenger); > > server code: > pn_messenger_t *messenger = pn_messenger("a"); > pn_messenger_start(messenger); > pn_messenger_subscribe(messenger, "amqps://~0.0.0.0"); > pn_message_t *message = pn_message(); > pn_messenger_recv(messenger, 1); > pn_messenger_get(messenger, message); > size_t size = 2; > char data[2]; > pn_message_save_data(message, data, &size); > > server output: > Accepted from localhost.localdomain:36331 > -> SASL > [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x622180:0] -> SASL-OUTCOME @68 [0] > -> AMQP > [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null] > <- SASL > [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""] > <- AMQP > [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024] > [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024] > [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, > true, false] (133) > "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff" > > client output: > Connected to 0.0.0.0:5671 > -> SASL > [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""] > <- SASL > [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x620020:0] <- SASL-OUTCOME @68 [0] > <- AMQP > [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null] > -> AMQP > [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024] > [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61a840:1] <- BEGIN @17 [1, 0, 1024, 1024] > [0x61a840:1] <- ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61
[jira] [Updated] (PROTON-144) Reduce byte overhead for small payloads
[ https://issues.apache.org/jira/browse/PROTON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-144: --- Labels: codec perf (was: perf) > Reduce byte overhead for small payloads > --- > > Key: PROTON-144 > URL: https://issues.apache.org/jira/browse/PROTON-144 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2, 0.3 >Reporter: Affan Dar >Assignee: Andrew Stitcher > Labels: codec, perf > Fix For: proton-c-0.19.0 > > > In constrained bandwidth scenarios (e.g. on a cellular data network) any byte > overhead is very costly. > From the traces for a simple app, we are seeing a large overhead (>100 bytes) > in the message payload for sending a two byte message. It seems like there > are some default properties like the to and reply-to addresses that the > proton client stamps onto a message and also there is padding on the actual > two byte payload itself. > To be able to successfully embed the proton lib in such resource constrained > devices the byte overhead needs to be trimmed down as much as the protocol > allows. > --- > Details of test app > --- > The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN > updated usually once a day although commits have slowed since the push for > 0.2 and libopenssl version 1.0.0e-34.17.1. > The debugging output is all from proton, to get the debugging output set the > Env variable "PN_TRACE_FRM=1" > The test is done connecting to localhost and sending a message across as > simply as possible: > client: > pn_messenger_t *messenger = pn_messenger("b"); > pn_messenger_start(messenger); > pn_message_t *message = pn_message(); > pn_message_set_address(message, "amqps://0.0.0.0/a"); > char data[2] = {(unsigned char)0xff, (unsigned char)0xff}; > pn_message_load_data(message, data, 2); > pn_messenger_put(messenger, message); > pn_messenger_send(messenger); > > server code: > pn_messenger_t *messenger = pn_messenger("a"); > pn_messenger_start(messenger); > pn_messenger_subscribe(messenger, "amqps://~0.0.0.0"); > pn_message_t *message = pn_message(); > pn_messenger_recv(messenger, 1); > pn_messenger_get(messenger, message); > size_t size = 2; > char data[2]; > pn_message_save_data(message, data, &size); > > server output: > Accepted from localhost.localdomain:36331 > -> SASL > [0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x622180:0] -> SASL-OUTCOME @68 [0] > -> AMQP > [0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null] > <- SASL > [0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""] > <- AMQP > [0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024] > [0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024] > [0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false] > [0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0, > true, false] (133) > "\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff" > > client output: > Connected to 0.0.0.0:5671 > -> SASL > [0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""] > <- SASL > [0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]] > [0x620020:0] <- SASL-OUTCOME @68 [0] > <- AMQP > [0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null] > -> AMQP > [0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null, > null] > [0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024] > [0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61a840:1] <- BEGIN @17 [1, 0, 1024, 1024] > [0x61a840:1] <- ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0, > null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0, > false, null, null], null, null, 0] > [0x61a840:1] <- FLOW @19 [0, 1024, 0, 1024, 1, 0,
[jira] [Resolved] (PROTON-1684) Change build for updated minimum tool versions
[ https://issues.apache.org/jira/browse/PROTON-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1684. - Resolution: Fixed > Change build for updated minimum tool versions > -- > > Key: PROTON-1684 > URL: https://issues.apache.org/jira/browse/PROTON-1684 > Project: Qpid Proton > Issue Type: Improvement > Components: build, proton-c >Affects Versions: proton-c-0.18.1 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: proton-c-0.19.0 > > > As discussed in > http://qpid.2158936.n2.nabble.com/Re-Proposed-update-to-minimum-tool-requirements-for-proton-c-tt7668432.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1696) Go test of anonymous SASL fails if it can't find saslpasswd2
[ https://issues.apache.org/jira/browse/PROTON-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1696: --- Assignee: Alan Conway (was: Andrew Stitcher) > Go test of anonymous SASL fails if it can't find saslpasswd2 > > > Key: PROTON-1696 > URL: https://issues.apache.org/jira/browse/PROTON-1696 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.18.1 >Reporter: Andrew Stitcher >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > Even if extended SASL is not being tested. In this case it shouldn't even be > using saslpasswd2 to create an authentication database. Anonymous by its very > nature doesn't use an authentication db. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1542) hostname should be set on sasl-init
[ https://issues.apache.org/jira/browse/PROTON-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1542: Labels: sasl (was: ) > hostname should be set on sasl-init > --- > > Key: PROTON-1542 > URL: https://issues.apache.org/jira/browse/PROTON-1542 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Gordon Sim >Assignee: Andrew Stitcher > Labels: sasl > Fix For: proton-c-0.21.0 > > > For a multi-tenant service/server, where each tenant has its own user base, > the hostname in the sasl-init frame provides a convenient way of determining > the correct tenant to authenticate for. > At present this is not set for any proton-c based client. It is similar to > the SNI information included in the TLS layer initiation (if such a layer is > in use). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1542) hostname should be set on sasl-init
[ https://issues.apache.org/jira/browse/PROTON-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1542: Fix Version/s: (was: proton-c-0.19.0) proton-c-0.21.0 > hostname should be set on sasl-init > --- > > Key: PROTON-1542 > URL: https://issues.apache.org/jira/browse/PROTON-1542 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Gordon Sim >Assignee: Andrew Stitcher > Labels: sasl > Fix For: proton-c-0.21.0 > > > For a multi-tenant service/server, where each tenant has its own user base, > the hostname in the sasl-init frame provides a convenient way of determining > the correct tenant to authenticate for. > At present this is not set for any proton-c based client. It is similar to > the SNI information included in the TLS layer initiation (if such a layer is > in use). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1614) Add tests for TLS cipher suite configuration
[ https://issues.apache.org/jira/browse/PROTON-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1614: Fix Version/s: (was: proton-c-0.19.0) proton-c-future > Add tests for TLS cipher suite configuration > > > Key: PROTON-1614 > URL: https://issues.apache.org/jira/browse/PROTON-1614 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher > Labels: testing > Fix For: proton-c-future > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1614) Add tests for TLS cipher suite configuration
[ https://issues.apache.org/jira/browse/PROTON-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1614: Labels: testing (was: ) > Add tests for TLS cipher suite configuration > > > Key: PROTON-1614 > URL: https://issues.apache.org/jira/browse/PROTON-1614 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher > Labels: testing > Fix For: proton-c-0.19.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1335) [Proton-c] [C++ Bindings] [Visual Studio 2008] Unable to create a binary message
[ https://issues.apache.org/jira/browse/PROTON-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1335: --- Assignee: Justin Ross (was: Andrew Stitcher) > [Proton-c] [C++ Bindings] [Visual Studio 2008] Unable to create a binary > message > > > Key: PROTON-1335 > URL: https://issues.apache.org/jira/browse/PROTON-1335 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.14.0 >Reporter: Adel Boutros >Assignee: Justin Ross > Labels: windows > Fix For: proton-c-0.19.0 > > > Details can be found here: > http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-C-sending-receiving-bytes-and-map-messages-td7652225.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1615) c++: container leaks if exception thrown by handler.
[ https://issues.apache.org/jira/browse/PROTON-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1615: --- Assignee: Alan Conway (was: Andrew Stitcher) > c++: container leaks if exception thrown by handler. > > > Key: PROTON-1615 > URL: https://issues.apache.org/jira/browse/PROTON-1615 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Alan Conway >Assignee: Alan Conway > Labels: leak > Fix For: proton-c-0.19.0 > > > An exception throw by a handler is re-thrown out of container.run() as > expected, however > the container does not shut down cleanly and many leaks are reported by > valgrind or asan. The container should be exception-safe. > To demonstrate the problem apply this small patch to the helloworld_direct > example. > examples/cpp/helloworld_direct.cpp | 1 + > modified examples/cpp/helloworld_direct.cpp > @@ -53,6 +53,7 @@ class hello_world_direct : public proton::messaging_handler > { > > // Receive one message and stop listener > void on_message(proton::delivery &, proton::message &m) OVERRIDE { > +throw std::runtime_error("thrown from on_message"); > std::cout << m.body() << std::endl; > listener.stop(); > } -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-198) Pkg config file installed in the wrong location on FreeBSD
[ https://issues.apache.org/jira/browse/PROTON-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-198: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-future > Pkg config file installed in the wrong location on FreeBSD > -- > > Key: PROTON-198 > URL: https://issues.apache.org/jira/browse/PROTON-198 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.3 > Environment: FreeBSD >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: freebsd > Fix For: proton-c-future > > > make install puts the libqpid-proton.pc file in the wrong location for the > platform: > In /usr/local//pkgconfig. This platform has a seperate > /usr/local/libdata directory for stuff like this. > This wouldn't be so bad if it could be configured, but currently the > pkgconfig directory is hardcoded to be related to the libdir. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-515: --- Fix Version/s: (was: proton-c-future) proton-c-0.20.0 > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys >Assignee: Andrew Stitcher > Labels: openvms, patch, reactor > Fix For: proton-c-0.20.0 > > Attachments: > 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, > CMakeLists.txt.patch, io.c.patch, pipe.c.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-515: --- Labels: openvms patch reactor (was: openvms patch) > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys >Assignee: Andrew Stitcher > Labels: openvms, patch, reactor > Fix For: proton-c-future > > Attachments: > 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, > CMakeLists.txt.patch, io.c.patch, pipe.c.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-515: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-future > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys >Assignee: Andrew Stitcher > Labels: openvms, patch, reactor > Fix For: proton-c-future > > Attachments: > 0001-PROTON-515-Change-pn_handle_t-to-be-void-to-get-arou.patch, > CMakeLists.txt.patch, io.c.patch, pipe.c.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-546) C++ Windows warnings: conversions and possible loss of data
[ https://issues.apache.org/jira/browse/PROTON-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-546: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-future > C++ Windows warnings: conversions and possible loss of data > --- > > Key: PROTON-546 > URL: https://issues.apache.org/jira/browse/PROTON-546 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.6 >Reporter: Chuck Rolke >Assignee: Andrew Stitcher > Labels: windows > Fix For: proton-c-future > > Attachments: PROTON-546-size-warnings.txt > > > Windows has other warnings similar to PROTON-545, especially during 64-bit > builds. > See attached file for details. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1629) [cpp] proton::container is not move constructible
[ https://issues.apache.org/jira/browse/PROTON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1629: Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > [cpp] proton::container is not move constructible > - > > Key: PROTON-1629 > URL: https://issues.apache.org/jira/browse/PROTON-1629 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: proton-c-0.18.0 > Environment: Linux, gcc (GCC) 7.0.1 20170409 (experimental), git tip > at > commit 72b7ea0508e94aae3e5d9470293bc5c7e8250a45 (upstream/master) > PROTON-1592: [python] restore original tx_recv.py example >Reporter: Jiri Daněk >Assignee: Andrew Stitcher >Priority: Minor > Fix For: proton-c-0.20.0 > > > Following C++11 code does not compile > {code} > auto handler = proton::messaging_handler(); > auto container = proton::container(handler); // container is not move > constructible > {code} > Error from GCC is > {noformat} > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp: > In function ‘int {anonymous}::test_container_schedule_multithreaded()’: > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:591:47: > error: use of deleted function ‘proton::container::container(const > proton::container&)’ > auto container = proton::container(handler); // container is not move > constructible >^ > In file included from > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:28:0: > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27: > note: ‘proton::container::container(const proton::container&)’ is implicitly > deleted because the default definition would be ill-formed: > class PN_CPP_CLASS_EXTERN container { >^ > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27: > error: use of deleted function ‘constexpr > proton::internal::pn_unique_ptr::pn_unique_ptr(const > proton::internal::pn_unique_ptr&)’ > In file included from > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/connection_options.hpp:29:0, > from > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:27: > /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/./internal/pn_unique_ptr.hpp:43:26: > note: ‘constexpr > proton::internal::pn_unique_ptr::pn_unique_ptr(const > proton::internal::pn_unique_ptr&)’ is implicitly > declared as deleted because > ‘proton::internal::pn_unique_ptr’ declares a move > constructor or move assignment operator > template class pn_unique_ptr { > ^ > make[3]: *** > [proton-c/bindings/cpp/CMakeFiles/container_test.dir/build.make:63: > proton-c/bindings/cpp/CMakeFiles/container_test.dir/src/container_test.cpp.o] > Error 1 > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1706) pn_listener_t provide access to actual listening port
[ https://issues.apache.org/jira/browse/PROTON-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1706: Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > pn_listener_t provide access to actual listening port > - > > Key: PROTON-1706 > URL: https://issues.apache.org/jira/browse/PROTON-1706 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.20.0 > > > Allow access to the actual listening port of a pn_listener_t so that the > actual address is available when listening on port 0. > Proposed API: > {code} > /** > * Get the listening addresses of a listener. > * A listener can have more than one address for several reasons: > * - DNS host records may indicate more than one address > * - On a multi-homed host, listening on the default host "" will listen on > all local addresses. > * - Some IPv4/IPV6 configurations may expand a single address into a v4/v6 > pair. > * > * @param l points to the listener > * @param addrs an array of `pn_netaddr_t*` to be filled with pointers the > listening addresses > * Pointers are invalid after the listener closes (PN_LISTENER_CLOSE event > is handled) > * @param len is the length of the array @p addrs > * @return The actual number of addresses used for listening. This may be: > * - 0: addresses are unavailable. > * - <= @p len: all addresses were copied to @p addrs, remaining entries > were set to NULL. > * - > @p len: the first @p len addresses were copied to @p addr. > * `pn_netaddr_listen(l, NULL, 0)` returns the number of listening addresses. > */ > PNP_EXTERN const size_t pn_netaddr_listen(pn_listener_t *l, pn_netaddr_t** > addrs, size_t len); > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1682) SASL auth with GSSAPI fails: hostname is not set
[ https://issues.apache.org/jira/browse/PROTON-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1682: Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > SASL auth with GSSAPI fails: hostname is not set > > > Key: PROTON-1682 > URL: https://issues.apache.org/jira/browse/PROTON-1682 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.18.1 >Reporter: Andrew Stitcher >Assignee: Alan Conway > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor
[ https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1665: Priority: Major (was: Critical) > Review locking - TLS / SSL thread safety with proactor > -- > > Key: PROTON-1665 > URL: https://issues.apache.org/jira/browse/PROTON-1665 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Alan Conway >Assignee: Alan Conway > Labels: tls > Fix For: proton-c-future > > > ssl_domain objects are semi-global. > For example two connections simultaneously creating or releasing their own > private pn_ssl_t objects may mess up the refcount of the shared > pn_ssl_domain_t object leading to memory corruption or leaks. > Windows schannel is further complicated by the OS internal refcounting of its > security context thingies. That may get automatically solved by the above, > or may require a separate JIRA to track. The same may apply to openssl. > The obvious thread-safety issues were addressed by PROTON-1620 and the use > of per-transport SSL objects appears to be correct and safe. However we need > a careful review of the use of shared OpenSSL objects (related to SSL domains > and certificate stores) to ensure they are being used safely and no > additional locks are needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor
[ https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1665: Labels: tls (was: ) > Review locking - TLS / SSL thread safety with proactor > -- > > Key: PROTON-1665 > URL: https://issues.apache.org/jira/browse/PROTON-1665 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Alan Conway >Assignee: Alan Conway > Labels: tls > Fix For: proton-c-future > > > ssl_domain objects are semi-global. > For example two connections simultaneously creating or releasing their own > private pn_ssl_t objects may mess up the refcount of the shared > pn_ssl_domain_t object leading to memory corruption or leaks. > Windows schannel is further complicated by the OS internal refcounting of its > security context thingies. That may get automatically solved by the above, > or may require a separate JIRA to track. The same may apply to openssl. > The obvious thread-safety issues were addressed by PROTON-1620 and the use > of per-transport SSL objects appears to be correct and safe. However we need > a careful review of the use of shared OpenSSL objects (related to SSL domains > and certificate stores) to ensure they are being used safely and no > additional locks are needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1665) Review locking - TLS / SSL thread safety with proactor
[ https://issues.apache.org/jira/browse/PROTON-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1665: Fix Version/s: (was: proton-c-0.19.0) proton-c-future > Review locking - TLS / SSL thread safety with proactor > -- > > Key: PROTON-1665 > URL: https://issues.apache.org/jira/browse/PROTON-1665 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Critical > Fix For: proton-c-future > > > ssl_domain objects are semi-global. > For example two connections simultaneously creating or releasing their own > private pn_ssl_t objects may mess up the refcount of the shared > pn_ssl_domain_t object leading to memory corruption or leaks. > Windows schannel is further complicated by the OS internal refcounting of its > security context thingies. That may get automatically solved by the above, > or may require a separate JIRA to track. The same may apply to openssl. > The obvious thread-safety issues were addressed by PROTON-1620 and the use > of per-transport SSL objects appears to be correct and safe. However we need > a careful review of the use of shared OpenSSL objects (related to SSL domains > and certificate stores) to ensure they are being used safely and no > additional locks are needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1644) [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD
[ https://issues.apache.org/jira/browse/PROTON-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1644: Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > [FreeBSD] Scheme for reusing ports in testing does not work for FreeBSD > --- > > Key: PROTON-1644 > URL: https://issues.apache.org/jira/browse/PROTON-1644 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, ruby-binding >Affects Versions: proton-c-0.18.0 > Environment: FreeBSD 10.3-RELEASE-p20 >Reporter: Andrew Stitcher >Assignee: Alan Conway > Labels: freebsd > Fix For: proton-c-0.20.0 > > > The scheme for picking ports using SO_REUSEPORT does not seem to work on > FreeBSD producing a bunch of errors like > {noformat} > listen error: proton:io: address already in use - listening on localhost:51439 > broker shutdown: proton:io: address already in use - listening on > localhost:51439 > {noformat} > This happens in the tests: > - 12:ruby-test-container > - 31:c-proactor-tests > - 34:cpp-example-container > - 35:cpp-example-container-ssl -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1643) [FreeBSD] ruby-example-test hangs
[ https://issues.apache.org/jira/browse/PROTON-1643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1643: --- Assignee: Andrew Stitcher (was: Alan Conway) > [FreeBSD] ruby-example-test hangs > - > > Key: PROTON-1643 > URL: https://issues.apache.org/jira/browse/PROTON-1643 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.18.0 > Environment: FreeBSD 10.3-RELEASE-p20 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Labels: freebsd > Fix For: proton-c-0.19.0 > > > When running ctest ruby-example-test hangs. > If you examine the process list there is a process {{/usr/local/bin/ruby23 > reactor/broker.rb -a :26780}} that has not exited. If you kill that process > the test fails but the test run carries on. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1688) [go] support encoding/decoding described arrays
[ https://issues.apache.org/jira/browse/PROTON-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1688: Fix Version/s: (was: proton-c-0.19.0) proton-c-future > [go] support encoding/decoding described arrays > --- > > Key: PROTON-1688 > URL: https://issues.apache.org/jira/browse/PROTON-1688 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-future > > > Add support for AMQP described arrays. > Most described types are already covered by amqp.Described, but arrays are a > special case. > An array of described values has the descriptor and type encoded only once, > followed by the undecorated values. Proton-C has a special API for this, it > is not the same as starting an array and then encoding each value with the > description. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-448) Ruby bindings need to have their set calls updated to properly map values to pn_data_t*
[ https://issues.apache.org/jira/browse/PROTON-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-448: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > Ruby bindings need to have their set calls updated to properly map values to > pn_data_t* > --- > > Key: PROTON-448 > URL: https://issues.apache.org/jira/browse/PROTON-448 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.5 >Reporter: Darryl L. Pierce >Assignee: Alan Conway > Fix For: proton-c-0.20.0 > > > When using the APIs in Qpid::Proton::Data I'm seeing: > irb(main):001:0> require 'qpid_proton' > => true > irb(main):002:0> data = Qpid::Proton::Data.new > => # > irb(main):003:0> data.ubyte = 3 > value=3 > TypeError: Expected argument 0 of type pn_data_t *, but got Fixnum 16 > in SWIG method 'pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `pn_data_put_ubyte' > from > /home/mcpierce/Programming/Proton/proton-c/bindings/ruby/lib/qpid_proton/data.rb:437:in > `ubyte=' > from (irb):3 > from /usr/bin/irb:12:in `' -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-447) Ruby types returned from Data should carry their AMQP type
[ https://issues.apache.org/jira/browse/PROTON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-447: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-0.20.0 > Ruby types returned from Data should carry their AMQP type > -- > > Key: PROTON-447 > URL: https://issues.apache.org/jira/browse/PROTON-447 > Project: Qpid Proton > Issue Type: Improvement > Components: ruby-binding >Reporter: Darryl L. Pierce >Assignee: Alan Conway > Fix For: proton-c-0.20.0 > > > When a value is pulled out of a Qpid::Proton::Data type, such as a float or > integer, it should somehow carry with it its AMQP type. So, for example, if > the value returned is a ulong (represented as a Fixnum) then that should be > attached to the Fixnum so that it can potentially be put back into another > Data instance without losing that detail. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1708) [proton-j] Improve performance of proton-j codec
[ https://issues.apache.org/jira/browse/PROTON-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280589#comment-16280589 ] ASF subversion and git services commented on PROTON-1708: - Commit aeb164ba7e0c08fdc47dcf681ef496b68c5d8312 in qpid-proton-j's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=aeb164b ] PROTON-1708: return the type object directly for unregistered described types > [proton-j] Improve performance of proton-j codec > > > Key: PROTON-1708 > URL: https://issues.apache.org/jira/browse/PROTON-1708 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.23.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: proton-j-0.24.0 > > > Several areas in the proton-j codec can be improved to provide overall > improvements in both the encode and decode of AMQP types as well as reduce GC > overhead with reduction in allocations of intermediate and helper objects. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8038) [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280570#comment-16280570 ] ASF subversion and git services commented on QPID-8038: --- Commit 85c9caae60565836487e962626896068385bad99 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=85c9caa ] QPID-8038: [Broker-J] [AMQP 0-8..0-91] Add more exchange protocol tests > [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x > - > > Key: QPID-8038 > URL: https://issues.apache.org/jira/browse/QPID-8038 > Project: Qpid > Issue Type: Improvement > Components: Broker-J, Java Tests >Reporter: Alex Rudyy > > We need a test frameworks which would allow creation of tests which would be > sending the AMQP 0-x performatives over TCP and receiving and asserting > broker responses. > The framework should satisfy the following requirements: > * It should allow running tests against other AMQP brokers > * The framework should encapsulate starting/stopping of broker and queue > creation/deletion under special interface(s) which can be implemented by the > Broker developers in order to run tests against different Broker > implementations > * Tests should be able to start and stop broker if required or configured > * Tests should be able to generate AMQP performatives and assert received > peer's AMQP performatives > * The framework should allow using other transport than TCP if required > * The framework should be based on AMQP 0-x implementations of Broker-J -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1712) add type details to the ApplicationProperties map
[ https://issues.apache.org/jira/browse/PROTON-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-1712. Resolution: Fixed > add type details to the ApplicationProperties map > - > > Key: PROTON-1712 > URL: https://issues.apache.org/jira/browse/PROTON-1712 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: proton-j-0.24.0 > > > The ApplicationProperties object takes/returns a map of the keys+values. The > keys are only allowed to be strings by the protocol spec, however the > signatures are currently using a raw Map type. We should use > Map to reflect the actual scenario and typical existing usage > (with casting). > This change will be binary compatible due to generic type erasure at > compilation, but can introduce some trivial source incompatibility depending > on particular casting etc done by using code. The improvement seems worth > such trivial changes where needed during upgrade, and adapting source to work > with old and new versions is similarly simple enough if required. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #231: DISPATCH 894 - Modified system tests to use...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/231 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8059) Potential Integer Overflow
[ https://issues.apache.org/jira/browse/QPID-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8059: -- Affects Version/s: (was: qpid-python-1.37.0) > Potential Integer Overflow > -- > > Key: QPID-8059 > URL: https://issues.apache.org/jira/browse/QPID-8059 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: songwanging >Priority: Minor > > Our tool DeepTect has detected a potential integer overflow: > Path: > qpid-broker-j/broker-core/src/main/java/org/apache/qpid/server/queue/MessageContentJsonConverter.java > {code:java} > class MessageContentJsonConverter > { > ... > private long _remaining; > ... > private Object copyString(final String source) throws IOException{ > ... > limit=Math.min((int)_remaining,source.length()) > .. > } > ... > } > {code} > In the above code snippet, "_remaining" is a long variable, if it is super > large, directly casting "_remaining" into integer will definitely lead to a > potential integer overflow. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8059) Potential Integer Overflow
songwanging created QPID-8059: - Summary: Potential Integer Overflow Key: QPID-8059 URL: https://issues.apache.org/jira/browse/QPID-8059 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-python-1.37.0 Reporter: songwanging Priority: Minor Our tool DeepTect has detected a potential integer overflow: Path: qpid-broker-j/broker-core/src/main/java/org/apache/qpid/server/queue/MessageContentJsonConverter.java {code:java} class MessageContentJsonConverter { ... private long _remaining; ... private Object copyString(final String source) throws IOException{ ... limit=Math.min((int)_remaining,source.length()) .. } ... } {code} In the above code snippet, "_remaining" is a long variable, if it is super large, directly casting "_remaining" into integer will definitely lead to a potential integer overflow. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #231: DISPATCH 894 - Modified system tests to use...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/231 DISPATCH 894 - Modified system tests to use unittest2 instead of unit⦠â¦test test framework. Modified tests/CMakeLists.txt to use the unit2 test runner You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-894 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/231.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #231 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1712) add type details to the ApplicationProperties map
[ https://issues.apache.org/jira/browse/PROTON-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280387#comment-16280387 ] ASF subversion and git services commented on PROTON-1712: - Commit 5ddb6be24617f81187e85abd0c9709cb7fcf9f11 in qpid-proton-j's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=5ddb6be ] PROTON-1712: add type details to the ApplicationProperties map > add type details to the ApplicationProperties map > - > > Key: PROTON-1712 > URL: https://issues.apache.org/jira/browse/PROTON-1712 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: proton-j-0.24.0 > > > The ApplicationProperties object takes/returns a map of the keys+values. The > keys are only allowed to be strings by the protocol spec, however the > signatures are currently using a raw Map type. We should use > Map to reflect the actual scenario and typical existing usage > (with casting). > This change will be binary compatible due to generic type erasure at > compilation, but can introduce some trivial source incompatibility depending > on particular casting etc done by using code. The improvement seems worth > such trivial changes where needed during upgrade, and adapting source to work > with old and new versions is similarly simple enough if required. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8058) [Broker-J][AMQP 1.0] Broker did not respond to drain request
[ https://issues.apache.org/jira/browse/QPID-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8058: - Attachment: TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testCreateQueueOnBrokerManagement.txt > [Broker-J][AMQP 1.0] Broker did not respond to drain request > > > Key: QPID-8058 > URL: https://issues.apache.org/jira/browse/QPID-8058 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy > Attachments: > TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testCreateQueueOnBrokerManagement.txt > > > Test {{AmqpManagementTest.testCreateQueueOnBrokerManagement}} failed with the > following error: > {noformat} > org.apache.qpid.jms.JmsOperationTimedOutException: Remote did not respond to > a drain request in time > {noformat} > As per exception message, the client sent the Flow with drain=true but Broker > did not reply on it > {noformat} > 2017-12-05 18:20:13,950 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame > RECV[/127.0.0.1:48726|1] : > Flow{nextIncomingId=0,incomingWindow=2047,nextOutgoingId=2,outgoingWindow=2147483647,handle=0,deliveryCount=0,linkCredit=1000,drain=true} > {noformat} > See the test log attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1537) ruby: update API in line with new C++ API changes
[ https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280365#comment-16280365 ] ASF subversion and git services commented on PROTON-1537: - Commit e0445234dfdb78baa8c0d8a82d0c1b4111e4b6a1 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=e044523 ] PROTON-1537: [ruby] Split Delivery API into Tracker and Transfer. Delivery is now used only for incoming messages, Tracker for outgoing messages, and Transfer is the common base class for both. Since most of the previous Deliveyr behavior is common, Delivery is still backwards-compatible with some deprecated methods. The API for release and modify is still compatible but has been re-worked so that Delivery#release(opts) now handles release and modified states with appropriate option settings. Tracker#modified provides to modified state directly. The Disposition class has is deprecated in favour of the new Delivery/Tracker methods. > ruby: update API in line with new C++ API changes > - > > Key: PROTON-1537 > URL: https://issues.apache.org/jira/browse/PROTON-1537 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > Update the ruby Container interface in line with the new C++ container API > Deprecate Reactor (use Container instead) > Deprecate or remove Messenger API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1537) ruby: update API in line with new C++ API changes
[ https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280367#comment-16280367 ] ASF subversion and git services commented on PROTON-1537: - Commit 56902090d59f44abff6c4c15f371244eefa3face in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5690209 ] PROTON-1537: [ruby] Move `deprecated` into Qpid module Minor fixup of doc comments, removed dead code in Qpid module. > ruby: update API in line with new C++ API changes > - > > Key: PROTON-1537 > URL: https://issues.apache.org/jira/browse/PROTON-1537 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > Update the ruby Container interface in line with the new C++ container API > Deprecate Reactor (use Container instead) > Deprecate or remove Messenger API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1537) ruby: update API in line with new C++ API changes
[ https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280368#comment-16280368 ] ASF subversion and git services commented on PROTON-1537: - Commit 7c004d3eb0408bff6548db60e9db228fd1c6880f in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7c004d3 ] PROTON-1537: [ruby] Fix copyright comments and top-level yard doc Removed useless #-- #++ brackets around copyright comments; they were supposed to prevent them being attached as doc comments to the first definition in the file but they don't. What does work is making sure there are 2 empty lines after the copyright comment and before the first definition. Clean up the top level doc comments and references. > ruby: update API in line with new C++ API changes > - > > Key: PROTON-1537 > URL: https://issues.apache.org/jira/browse/PROTON-1537 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > Update the ruby Container interface in line with the new C++ container API > Deprecate Reactor (use Container instead) > Deprecate or remove Messenger API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8058) [Broker-J][AMQP 1.0] Broker did not respond to drain request
Alex Rudyy created QPID-8058: Summary: [Broker-J][AMQP 1.0] Broker did not respond to drain request Key: QPID-8058 URL: https://issues.apache.org/jira/browse/QPID-8058 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.0.0 Reporter: Alex Rudyy Test {{AmqpManagementTest.testCreateQueueOnBrokerManagement}} failed with the following error: {noformat} org.apache.qpid.jms.JmsOperationTimedOutException: Remote did not respond to a drain request in time {noformat} As per exception message, the client sent the Flow with drain=true but Broker did not reply on it {noformat} 2017-12-05 18:20:13,950 DEBUG [IO-/127.0.0.1:48726] o.a.q.s.p.frame RECV[/127.0.0.1:48726|1] : Flow{nextIncomingId=0,incomingWindow=2047,nextOutgoingId=2,outgoingWindow=2147483647,handle=0,deliveryCount=0,linkCredit=1000,drain=true} {noformat} See the test log attached. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1537) ruby: update API in line with new C++ API changes
[ https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280366#comment-16280366 ] ASF subversion and git services commented on PROTON-1537: - Commit 56b0949faa64fc212ef93647155f892849deb681 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=56b0949 ] PROTON-1537: [ruby] Wrapper hash/equality @impl pointer Override hash/equality on ruby wrappers for proton objects to be based on the pn_x pointer rather than the ruby object identity - wrappers are equivalent if they wrap the same pn_x object, including when used as Hash keys. > ruby: update API in line with new C++ API changes > - > > Key: PROTON-1537 > URL: https://issues.apache.org/jira/browse/PROTON-1537 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: proton-c-0.19.0 > > > Update the ruby Container interface in line with the new C++ container API > Deprecate Reactor (use Container instead) > Deprecate or remove Messenger API. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1712) add type details to the ApplicationProperties map
Robbie Gemmell created PROTON-1712: -- Summary: add type details to the ApplicationProperties map Key: PROTON-1712 URL: https://issues.apache.org/jira/browse/PROTON-1712 Project: Qpid Proton Issue Type: Improvement Components: proton-j Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Minor Fix For: proton-j-0.24.0 The ApplicationProperties object takes/returns a map of the keys+values. The keys are only allowed to be strings by the protocol spec, however the signatures are currently using a raw Map type. We should use Map to reflect the actual scenario and typical existing usage (with casting). This change will be binary compatible due to generic type erasure at compilation, but can introduce some trivial source incompatibility depending on particular casting etc done by using code. The improvement seems worth such trivial changes where needed during upgrade, and adapting source to work with old and new versions is similarly simple enough if required. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-894) Unable to run system tests on CentOS 6 (Python 2.6)
Ganesh Murthy created DISPATCH-894: -- Summary: Unable to run system tests on CentOS 6 (Python 2.6) Key: DISPATCH-894 URL: https://issues.apache.org/jira/browse/DISPATCH-894 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.0.0 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Fix For: 1.1.0 On operating systems that have Python 2.6 as the default Python (link CentOS 6), running ctest does not actually run any tests. Here is a snippet of the test output {noformat} 33/37 Test #33: system_tests_failover_list Passed0.51 sec Start 34: system_tests_denied_unsettled_multicast 34: Test command: /usr/bin/python "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" "-v" "system_tests_denied_unsettled_multicast" 34: Test timeout computed to be: 1500 34: -- 34: Ran 0 test in 0.200s 34: 34: OK 34/37 Test #34: system_tests_denied_unsettled_multicast ... Passed0.54 sec test 35 Start 35: system_tests_auth_service_plugin 35: Test command: /usr/bin/python "/home/gmurthy/opensource/qpid-dispatch/build/tests/run.py" "-m" "unittest" "-v" "system_tests_auth_service_plugin" 35: Test timeout computed to be: 1500 35: 35: -- 35: Ran 0 tests in 0.322s {noformat} The problem seems to be that ctest is launching unittest which is older is Py 2.6 and is not feature rich as in Python 2.7 To solve this problem, Python provides a backwards compatible unit test package called unittest2. This unittest2 backports the new features provided by unittest test framework to older versions of Python. unittest2 is available for Python versions 2.3 thru 3.4. It offers a test launcher called unit2 which should be used by ctest. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-893) Compile fails using libwebsockets 7
[ https://issues.apache.org/jira/browse/DISPATCH-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reassigned DISPATCH-893: Assignee: Alan Conway > Compile fails using libwebsockets 7 > --- > > Key: DISPATCH-893 > URL: https://issues.apache.org/jira/browse/DISPATCH-893 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.0.0 > Environment: Ubuntu 16.04 LTS > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 >Reporter: AWETTT >Assignee: Alan Conway >Priority: Minor > > andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >cmake .. > -- The C compiler identification is GNU 5.4.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Found PythonInterp: /usr/bin/python (found version "2.7.12") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version > "2.7.12") > -- Found LIBWEBSOCKETS: /usr/lib/x86_64-linux-gnu/libwebsockets.so > -- Found VALGRIND: /usr/bin/valgrind > -- Performing Test HAS_PEDANTIC_FLAG > -- Performing Test HAS_PEDANTIC_FLAG - Success > -- Configuring done > -- Generating done > -- Build files have been written to: > /home/andreas/brokers/qpid-dispatch-1.0.0/build > - > andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >make all > [ 1%] Generating schema_enum.h, schema_enum.c > Scanning dependencies of target qpid-dispatch > [ 2%] Building C object src/CMakeFiles/qpid-dispatch.dir/amqp.c.o > [ 4%] Building C object src/CMakeFiles/qpid-dispatch.dir/bitmask.c.o > [ 5%] Building C object src/CMakeFiles/qpid-dispatch.dir/buffer.c.o > [ 6%] Building C object src/CMakeFiles/qpid-dispatch.dir/error.c.o > [ 8%] Building C object src/CMakeFiles/qpid-dispatch.dir/compose.c.o > [ 9%] Building C object > src/CMakeFiles/qpid-dispatch.dir/connection_manager.c.o > [ 10%] Building C object src/CMakeFiles/qpid-dispatch.dir/container.c.o > [ 12%] Building C object src/CMakeFiles/qpid-dispatch.dir/dispatch.c.o > [ 13%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity.c.o > [ 14%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity_cache.c.o > [ 16%] Building C object src/CMakeFiles/qpid-dispatch.dir/failoverlist.c.o > [ 17%] Building C object src/CMakeFiles/qpid-dispatch.dir/hash.c.o > [ 18%] Building C object src/CMakeFiles/qpid-dispatch.dir/iovec.c.o > [ 20%] Building C object src/CMakeFiles/qpid-dispatch.dir/iterator.c.o > [ 21%] Building C object src/CMakeFiles/qpid-dispatch.dir/log.c.o > [ 22%] Building C object src/CMakeFiles/qpid-dispatch.dir/message.c.o > [ 24%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse.c.o > [ 25%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse_tree.c.o > [ 27%] Building C object src/CMakeFiles/qpid-dispatch.dir/policy.c.o > [ 28%] Building C object src/CMakeFiles/qpid-dispatch.dir/remote_sasl.c.o > [ 29%] Building C object src/CMakeFiles/qpid-dispatch.dir/posix/threading.c.o > [ 31%] Building C object src/CMakeFiles/qpid-dispatch.dir/python_embedded.c.o > [ 32%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_agent.c.o > [ 33%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_config.c.o > [ 35%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent.c.o > [ 36%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_address.c.o > [ 37%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_address.c.o > [ 39%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_auto_link.c.o > [ 40%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_connection.c.o > [ 41%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_link_route.c.o > [ 43%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_link.c.o > [ 44%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_router.c.o > [ 45%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/connections.c.o > [ 47%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/error.c.o > [ 48%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/forwarder.c.o > [ 50%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/route_control.c.o > [ 51%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core.c.o > [ 52%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core_thread.c.o > [ 54%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/route_tables.c.o > [ 55%] Bu
[jira] [Commented] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown
[ https://issues.apache.org/jira/browse/QPID-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280248#comment-16280248 ] Alex Rudyy commented on QPID-8040: -- commit 1c06450ac1cef869f7e87a168e2de4090773f436 Author: Alex Rudyy [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=1c06450 ] QPID-8040: [Broker-J] Handle CancelledKeyException on processing of selection keys > [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during > Broker shutdown > --- > > Key: QPID-8040 > URL: https://issues.apache.org/jira/browse/QPID-8040 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > Attachments: > TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testInvokeOperationReturningMap > > > The following exception was trapped by the UncaughtExceptionHandler during a > shutdown of the Broker. The would have caused a abnormal termination. I > expect it could also happen during a HA virtualhost mastership change too. > This code hasn't changed, so I think the problem is probably longstanding. > {noformat} > 2017-11-10 20:30:04,540 DEBUG [QpidJMS Connection Executor: > ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown > of ExecutorService: > java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool > size = 0, active threads = 0, queued tasks = 0, completed tasks = 24] is > shutdown: true and terminated: true took: 0.000 seconds. > 2017-11-10 20:30:04,540 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Stopping task executor > virtualhost-test-preferences > 2017-11-10 20:30:04,544 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped > 2017-11-10 20:30:04,543 ERROR [Selector-Port-amqp] > o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread > Selector-Port-amqp > java.nio.channels.CancelledKeyException: null > at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) > at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82) > at > java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown
[ https://issues.apache.org/jira/browse/QPID-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8040: Assignee: Alex Rudyy > [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during > Broker shutdown > --- > > Key: QPID-8040 > URL: https://issues.apache.org/jira/browse/QPID-8040 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > Attachments: > TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testInvokeOperationReturningMap > > > The following exception was trapped by the UncaughtExceptionHandler during a > shutdown of the Broker. The would have caused a abnormal termination. I > expect it could also happen during a HA virtualhost mastership change too. > This code hasn't changed, so I think the problem is probably longstanding. > {noformat} > 2017-11-10 20:30:04,540 DEBUG [QpidJMS Connection Executor: > ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown > of ExecutorService: > java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool > size = 0, active threads = 0, queued tasks = 0, completed tasks = 24] is > shutdown: true and terminated: true took: 0.000 seconds. > 2017-11-10 20:30:04,540 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Stopping task executor > virtualhost-test-preferences > 2017-11-10 20:30:04,544 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped > 2017-11-10 20:30:04,543 ERROR [Selector-Port-amqp] > o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread > Selector-Port-amqp > java.nio.channels.CancelledKeyException: null > at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) > at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82) > at > java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown
[ https://issues.apache.org/jira/browse/QPID-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8040: - Status: Reviewable (was: In Progress) > [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during > Broker shutdown > --- > > Key: QPID-8040 > URL: https://issues.apache.org/jira/browse/QPID-8040 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > Attachments: > TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testInvokeOperationReturningMap > > > The following exception was trapped by the UncaughtExceptionHandler during a > shutdown of the Broker. The would have caused a abnormal termination. I > expect it could also happen during a HA virtualhost mastership change too. > This code hasn't changed, so I think the problem is probably longstanding. > {noformat} > 2017-11-10 20:30:04,540 DEBUG [QpidJMS Connection Executor: > ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown > of ExecutorService: > java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool > size = 0, active threads = 0, queued tasks = 0, completed tasks = 24] is > shutdown: true and terminated: true took: 0.000 seconds. > 2017-11-10 20:30:04,540 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Stopping task executor > virtualhost-test-preferences > 2017-11-10 20:30:04,544 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped > 2017-11-10 20:30:04,543 ERROR [Selector-Port-amqp] > o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread > Selector-Port-amqp > java.nio.channels.CancelledKeyException: null > at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) > at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82) > at > java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown
[ https://issues.apache.org/jira/browse/QPID-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8040: Assignee: Keith Wall (was: Alex Rudyy) > [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during > Broker shutdown > --- > > Key: QPID-8040 > URL: https://issues.apache.org/jira/browse/QPID-8040 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > Attachments: > TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testInvokeOperationReturningMap > > > The following exception was trapped by the UncaughtExceptionHandler during a > shutdown of the Broker. The would have caused a abnormal termination. I > expect it could also happen during a HA virtualhost mastership change too. > This code hasn't changed, so I think the problem is probably longstanding. > {noformat} > 2017-11-10 20:30:04,540 DEBUG [QpidJMS Connection Executor: > ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown > of ExecutorService: > java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool > size = 0, active threads = 0, queued tasks = 0, completed tasks = 24] is > shutdown: true and terminated: true took: 0.000 seconds. > 2017-11-10 20:30:04,540 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Stopping task executor > virtualhost-test-preferences > 2017-11-10 20:30:04,544 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped > 2017-11-10 20:30:04,543 ERROR [Selector-Port-amqp] > o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread > Selector-Port-amqp > java.nio.channels.CancelledKeyException: null > at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) > at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82) > at > java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-892) Support code coverage testing
[ https://issues.apache.org/jira/browse/DISPATCH-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-892. - Resolution: Fixed > Support code coverage testing > - > > Key: DISPATCH-892 > URL: https://issues.apache.org/jira/browse/DISPATCH-892 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Tests >Affects Versions: 1.0.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.1.0 > > > Port the code coverage work done by the Proton developers. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown
[ https://issues.apache.org/jira/browse/QPID-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280243#comment-16280243 ] ASF subversion and git services commented on QPID-8040: --- Commit 34e38ae1ed3a5a519e875657142955f8e42766c7 in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=34e38ae ] QPID-8040: [Broker-J] Handle CancelledKeyException on registering of selector keys > [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during > Broker shutdown > --- > > Key: QPID-8040 > URL: https://issues.apache.org/jira/browse/QPID-8040 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > Attachments: > TEST-org.apache.qpid.systest.management.amqp.AmqpManagementTest.testInvokeOperationReturningMap > > > The following exception was trapped by the UncaughtExceptionHandler during a > shutdown of the Broker. The would have caused a abnormal termination. I > expect it could also happen during a HA virtualhost mastership change too. > This code hasn't changed, so I think the problem is probably longstanding. > {noformat} > 2017-11-10 20:30:04,540 DEBUG [QpidJMS Connection Executor: > ID:51dec5e7-faf9-4b92-89ec-16396a27a101:1] o.a.q.j.u.ThreadPoolUtils Shutdown > of ExecutorService: > java.util.concurrent.ScheduledThreadPoolExecutor@6fbbe33[Terminated, pool > size = 0, active threads = 0, queued tasks = 0, completed tasks = 24] is > shutdown: true and terminated: true took: 0.000 seconds. > 2017-11-10 20:30:04,540 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Stopping task executor > virtualhost-test-preferences > 2017-11-10 20:30:04,544 DEBUG [VirtualHostNode-test-Config] > o.a.q.s.c.u.TaskExecutorImpl Task executor is stopped > 2017-11-10 20:30:04,543 ERROR [Selector-Port-amqp] > o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread > Selector-Port-amqp > java.nio.channels.CancelledKeyException: null > at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73) > at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:82) > at > java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:204) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.processSelectionKeys(SelectorThread.java:240) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:326) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:528) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-893) Compile fails using libwebsockets 7
AWETTT created DISPATCH-893: --- Summary: Compile fails using libwebsockets 7 Key: DISPATCH-893 URL: https://issues.apache.org/jira/browse/DISPATCH-893 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.0.0 Environment: Ubuntu 16.04 LTS gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 Reporter: AWETTT Priority: Minor andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >cmake .. -- The C compiler identification is GNU 5.4.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Found PythonInterp: /usr/bin/python (found version "2.7.12") -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version "2.7.12") -- Found LIBWEBSOCKETS: /usr/lib/x86_64-linux-gnu/libwebsockets.so -- Found VALGRIND: /usr/bin/valgrind -- Performing Test HAS_PEDANTIC_FLAG -- Performing Test HAS_PEDANTIC_FLAG - Success -- Configuring done -- Generating done -- Build files have been written to: /home/andreas/brokers/qpid-dispatch-1.0.0/build - andreas:/home/andreas/brokers/qpid-dispatch-1.0.0/build >make all [ 1%] Generating schema_enum.h, schema_enum.c Scanning dependencies of target qpid-dispatch [ 2%] Building C object src/CMakeFiles/qpid-dispatch.dir/amqp.c.o [ 4%] Building C object src/CMakeFiles/qpid-dispatch.dir/bitmask.c.o [ 5%] Building C object src/CMakeFiles/qpid-dispatch.dir/buffer.c.o [ 6%] Building C object src/CMakeFiles/qpid-dispatch.dir/error.c.o [ 8%] Building C object src/CMakeFiles/qpid-dispatch.dir/compose.c.o [ 9%] Building C object src/CMakeFiles/qpid-dispatch.dir/connection_manager.c.o [ 10%] Building C object src/CMakeFiles/qpid-dispatch.dir/container.c.o [ 12%] Building C object src/CMakeFiles/qpid-dispatch.dir/dispatch.c.o [ 13%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity.c.o [ 14%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity_cache.c.o [ 16%] Building C object src/CMakeFiles/qpid-dispatch.dir/failoverlist.c.o [ 17%] Building C object src/CMakeFiles/qpid-dispatch.dir/hash.c.o [ 18%] Building C object src/CMakeFiles/qpid-dispatch.dir/iovec.c.o [ 20%] Building C object src/CMakeFiles/qpid-dispatch.dir/iterator.c.o [ 21%] Building C object src/CMakeFiles/qpid-dispatch.dir/log.c.o [ 22%] Building C object src/CMakeFiles/qpid-dispatch.dir/message.c.o [ 24%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse.c.o [ 25%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse_tree.c.o [ 27%] Building C object src/CMakeFiles/qpid-dispatch.dir/policy.c.o [ 28%] Building C object src/CMakeFiles/qpid-dispatch.dir/remote_sasl.c.o [ 29%] Building C object src/CMakeFiles/qpid-dispatch.dir/posix/threading.c.o [ 31%] Building C object src/CMakeFiles/qpid-dispatch.dir/python_embedded.c.o [ 32%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_agent.c.o [ 33%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_config.c.o [ 35%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent.c.o [ 36%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent_address.c.o [ 37%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_address.c.o [ 39%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_auto_link.c.o [ 40%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent_connection.c.o [ 41%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_link_route.c.o [ 43%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent_link.c.o [ 44%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/agent_router.c.o [ 45%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/connections.c.o [ 47%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/error.c.o [ 48%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/forwarder.c.o [ 50%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/route_control.c.o [ 51%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/router_core.c.o [ 52%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/router_core_thread.c.o [ 54%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/route_tables.c.o [ 55%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/management_agent.c.o [ 56%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/terminus.c.o [ 58%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_core/transfer.c.o [ 59%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_node.c.o [ 60%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_pynode
[jira] [Commented] (QPID-8057) [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds after sending session close controls and waiting for broker responses
[ https://issues.apache.org/jira/browse/QPID-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280196#comment-16280196 ] ASF subversion and git services commented on QPID-8057: --- Commit 7fe48d96b4aa5e13b1b33abd6db573904f8aab00 in qpid-jms-amqp-0-x's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=7fe48d9 ] QPID-8057: [JMS AMQP 0-x][AMQP 0-10] Fix race on handling of execution exception > [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds > after sending session close controls and waiting for broker responses > - > > Key: QPID-8057 > URL: https://issues.apache.org/jira/browse/QPID-8057 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-6.0.8, qpid-java-client-0-x-6.3.0, > qpid-java-6.1.5 >Reporter: Alex Rudyy > Attachments: > TEST-org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommit.txt > > > IoReceiver thread can "dead lock" itself for 60 seconds after receiving > execution exception from broker and sending session controls to close other > connection sessions. This issue can occur in the following scenario: > * broker sends execution exception > * client receives execution exception and populates field > {{org.apache.qpid.client.AMQSession_0_10#_currentException}} as part of > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. The field is > set using synchronization lock > {{org.apache.qpid.client.AMQSession_0_10#_currentExceptionLock}}. However, > the field is referenced later in > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} without the > synchronization lock. It could be reset (set to null) from the application > main thread as part of call > {{org.apache.qpid.client.AMQSession#checkNotClosed}} whilst the execution of > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} is still in > progress. As result, > {{org.apache.qpid.client.AMQSession_0_10#_currentException}} can have null > value when method {{org.apache.qpid.client.AMQConnection#exceptionReceived}} > is invoked from > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. "{{null}} > cause" is interpreted as "hard error" causing to close other sessions and > connection from IoReceiver thread. Whilst closing session or connection, the > client waits for the broker responses, however, it cannot get them as > IoReceiver thread is blocked. Wen should not wait for any broker responses in > IoReceiver thread. > Thus, we have 2 issues here: > * {{org.apache.qpid.client.AMQSession_0_10#_currentException}} should not be > referenced without a synchronization lock > * the client should not wait for broker responses in IoReceiver thread (i.e. > session or connection close should not be performed in IoReceiver thread) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8030) [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary correlationId
[ https://issues.apache.org/jira/browse/QPID-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8030. -- Resolution: Fixed The implemented change looks good to me. Closing the JIRA after merging into 7.0.x branch > [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary > correlationId > -- > > Key: QPID-8030 > URL: https://issues.apache.org/jira/browse/QPID-8030 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.1 > > > In AMQP 0-8..9 the message correlation Id can be either a String or byte[]. > AMQP 1.0 supports both of those formats so the conversion should preserve > those. > Currently the conversion always converts to String. In case the byte[] are > non-UTF_8 substitution characters are used. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8030) [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary correlationId
[ https://issues.apache.org/jira/browse/QPID-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280137#comment-16280137 ] ASF subversion and git services commented on QPID-8030: --- Commit 6747c7dbcd14bfbe09d3702f59ce49994dc40349 in qpid-broker-j's branch refs/heads/7.0.x from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6747c7d ] QPID-8030: [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary correlationId (cherry picked from commit e08052db31043b9c5ba13981c8778b668eb23448) > [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary > correlationId > -- > > Key: QPID-8030 > URL: https://issues.apache.org/jira/browse/QPID-8030 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.1 > > > In AMQP 0-8..9 the message correlation Id can be either a String or byte[]. > AMQP 1.0 supports both of those formats so the conversion should preserve > those. > Currently the conversion always converts to String. In case the byte[] are > non-UTF_8 substitution characters are used. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8057) [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds after sending session close controls and waiting for broker responses
[ https://issues.apache.org/jira/browse/QPID-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8057: - Attachment: TEST-org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommit.txt Attached logs for the test {{org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommit}} which had failed due to running into the issue > [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds > after sending session close controls and waiting for broker responses > - > > Key: QPID-8057 > URL: https://issues.apache.org/jira/browse/QPID-8057 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-6.0.8, qpid-java-client-0-x-6.3.0, > qpid-java-6.1.5 >Reporter: Alex Rudyy > Attachments: > TEST-org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommit.txt > > > IoReceiver thread can "dead lock" itself for 60 seconds after receiving > execution exception from broker and sending session controls to close other > connection sessions. This issue can occur in the following scenario: > * broker sends execution exception > * client receives execution exception and populates field > {{org.apache.qpid.client.AMQSession_0_10#_currentException}} as part of > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. The field is > set using synchronization lock > {{org.apache.qpid.client.AMQSession_0_10#_currentExceptionLock}}. However, > the field is referenced later in > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} without the > synchronization lock. It could be reset (set to null) from the application > main thread as part of call > {{org.apache.qpid.client.AMQSession#checkNotClosed}} whilst the execution of > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} is still in > progress. As result, > {{org.apache.qpid.client.AMQSession_0_10#_currentException}} can have null > value when method {{org.apache.qpid.client.AMQConnection#exceptionReceived}} > is invoked from > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. "{{null}} > cause" is interpreted as "hard error" causing to close other sessions and > connection from IoReceiver thread. Whilst closing session or connection, the > client waits for the broker responses, however, it cannot get them as > IoReceiver thread is blocked. Wen should not wait for any broker responses in > IoReceiver thread. > Thus, we have 2 issues here: > * {{org.apache.qpid.client.AMQSession_0_10#_currentException}} should not be > referenced without a synchronization lock > * the client should not wait for broker responses in IoReceiver thread (i.e. > session or connection close should not be performed in IoReceiver thread) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8057) [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds after sending session close controls and waiting for broker responses
[ https://issues.apache.org/jira/browse/QPID-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8057: - Description: IoReceiver thread can "dead lock" itself for 60 seconds after receiving execution exception from broker and sending session controls to close other connection sessions. This issue can occur in the following scenario: * broker sends execution exception * client receives execution exception and populates field {{org.apache.qpid.client.AMQSession_0_10#_currentException}} as part of {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. The field is set using synchronization lock {{org.apache.qpid.client.AMQSession_0_10#_currentExceptionLock}}. However, the field is referenced later in {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} without the synchronization lock. It could be reset (set to null) from the application main thread as part of call {{org.apache.qpid.client.AMQSession#checkNotClosed}} whilst the execution of {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} is still in progress. As result, {{org.apache.qpid.client.AMQSession_0_10#_currentException}} can have null value when method {{org.apache.qpid.client.AMQConnection#exceptionReceived}} is invoked from {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. "{{null}} cause" is interpreted as "hard error" causing to close other sessions and connection from IoReceiver thread. Whilst closing session or connection, the client waits for the broker responses, however, it cannot get them as IoReceiver thread is blocked. Wen should not wait for any broker responses in IoReceiver thread. Thus, we have 2 issues here: * {{org.apache.qpid.client.AMQSession_0_10#_currentException}} should not be referenced without a synchronization lock * the client should not wait for broker responses in IoReceiver thread (i.e. session or connection close should not be performed in IoReceiver thread) was: IoReceiver thread can "dead lock" itself for 60 seconds after receiving execution exception from broker and sending session controls to close other connection sessions. This issue can occur in the following scenario: * broker sends execution exception * client receives execution exception and populates field {{org.apache.qpid.client.AMQSession_0_10#_currentException}} as part of {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. The field is set using synchronization lock {{org.apache.qpid.client.AMQSession_0_10#_currentExceptionLock}}. However, the field is referenced later in {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} without the synchronization lock. It could reset (set to null) from the application main thread as part of call {{org.apache.qpid.client.AMQSession#checkNotClosed}} whilst the execution of {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} is still in progress. As result, {{org.apache.qpid.client.AMQSession_0_10#_currentException}} can have null value when metho {{org.apache.qpid.client.AMQConnection#exceptionReceived}} is invoked from {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. {{null}} cause is interpreted as 'hard error' causing to close other sessions and connection from IoReceiver thread. Whilst closing session or connection the client waits for the broker responses, however, it cannot get them as IoReceiver thread is blocked. Wen should not wait for any broker responses in IoReceiver thread. Thus, we have 2 issues here: * {{org.apache.qpid.client.AMQSession_0_10#_currentException}} should not be referenced without a synchronization lock * the client should not wait for broker responses in IoReceiver thread (i.e. session or connection close should not be performed in IoReceiver thread) > [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds > after sending session close controls and waiting for broker responses > - > > Key: QPID-8057 > URL: https://issues.apache.org/jira/browse/QPID-8057 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-6.0.8, qpid-java-client-0-x-6.3.0, > qpid-java-6.1.5 >Reporter: Alex Rudyy > > IoReceiver thread can "dead lock" itself for 60 seconds after receiving > execution exception from broker and sending session controls to close other > connection sessions. This issue can occur in the following scenario: > * broker sends execution exception > * client receives execution exception and populates field > {{org.apache.qpid.client.AMQSession_0_10#_currentException}} as part of > {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. The field is > set using synchronizati
[jira] [Created] (QPID-8057) [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds after sending session close controls and waiting for broker responses
Alex Rudyy created QPID-8057: Summary: [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds after sending session close controls and waiting for broker responses Key: QPID-8057 URL: https://issues.apache.org/jira/browse/QPID-8057 Project: Qpid Issue Type: Bug Components: JMS AMQP 0-x Affects Versions: qpid-java-6.1.5, qpid-java-client-0-x-6.3.0, qpid-java-6.0.8 Reporter: Alex Rudyy IoReceiver thread can "dead lock" itself for 60 seconds after receiving execution exception from broker and sending session controls to close other connection sessions. This issue can occur in the following scenario: * broker sends execution exception * client receives execution exception and populates field {{org.apache.qpid.client.AMQSession_0_10#_currentException}} as part of {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. The field is set using synchronization lock {{org.apache.qpid.client.AMQSession_0_10#_currentExceptionLock}}. However, the field is referenced later in {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} without the synchronization lock. It could reset (set to null) from the application main thread as part of call {{org.apache.qpid.client.AMQSession#checkNotClosed}} whilst the execution of {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}} is still in progress. As result, {{org.apache.qpid.client.AMQSession_0_10#_currentException}} can have null value when metho {{org.apache.qpid.client.AMQConnection#exceptionReceived}} is invoked from {{org.apache.qpid.client.AMQSession_0_10#setCurrentException}}. {{null}} cause is interpreted as 'hard error' causing to close other sessions and connection from IoReceiver thread. Whilst closing session or connection the client waits for the broker responses, however, it cannot get them as IoReceiver thread is blocked. Wen should not wait for any broker responses in IoReceiver thread. Thus, we have 2 issues here: * {{org.apache.qpid.client.AMQSession_0_10#_currentException}} should not be referenced without a synchronization lock * the client should not wait for broker responses in IoReceiver thread (i.e. session or connection close should not be performed in IoReceiver thread) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8031) [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0
[ https://issues.apache.org/jira/browse/QPID-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279902#comment-16279902 ] ASF subversion and git services commented on QPID-8031: --- Commit cd534214affe087847792de95cca3b524202c7ab in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=cd53421 ] QPID-8031: [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0 > [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0 > - > > Key: QPID-8031 > URL: https://issues.apache.org/jira/browse/QPID-8031 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Lorenz Quack >Priority: Minor > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8031-Broker-J-System-Tests-Bump-version-of-AMQP.patch > > > When the 6.3.0 client is released we should bump the version in the broker. > Eventually the broker system tests should become independent of the specific > client version. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org