[jira] [Comment Edited] (DISPATCH-895) qpid-dispatch crashes with a SEGFAULT in libqpid-proton

[Saurabh Badhwar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 signal 11, 

[jira] [Commented] (DISPATCH-895) qpid-dispatch crashes with a SEGFAULT in libqpid-proton

[Saurabh Badhwar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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  0x7f0bab5cd34d in clone 

[jira] [Commented] (DISPATCH-895) qpid-dispatch crashes with a SEGFAULT in libqpid-proton

[Saurabh Badhwar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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

[jira] [Commented] (QPID-8038) [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 ...

[kgiusti]

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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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...

[astitcher]

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...

[ganeshmurthy]

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

[Chuck Rolke (JIRA)]

 [ 
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: 

[jira] [Commented] (PROTON-869) [proton-c] should be straightforward to associate handlers with acceptors

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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()
> 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()]
> 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()]
> 10: FAIL: test_ipv4_ipv6() (2 errors)
> {code}
> or 
> {code}
> 10: TEST: test_ipv4_ipv6()
> 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()]
> 10: FAIL: test_ipv4_ipv6() (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

[Justin Ross (JIRA)]

 [ 
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()
> 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()]
> 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()]
> 10: FAIL: test_ipv4_ipv6() (2 errors)
> {code}
> or 
> {code}
> 10: TEST: test_ipv4_ipv6()
> 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()]
> 10: FAIL: test_ipv4_ipv6() (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

[Justin Ross (JIRA)]

 [ 
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()
> 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()]
> 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()]
> 10: FAIL: test_ipv4_ipv6() (2 errors)
> {code}
> or 
> {code}
> 10: TEST: test_ipv4_ipv6()
> 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()]
> 10: FAIL: test_ipv4_ipv6() (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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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) {
> 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
> 

[jira] [Commented] (PROTON-1556) [proton-cpp] ssl_client_options is not self-assignable

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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) {
> 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 

[jira] [Updated] (PROTON-144) Reduce byte overhead for small payloads

[Justin Ross (JIRA)]

 [ 
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, );
>  
> 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]
> 

[jira] [Updated] (PROTON-144) Reduce byte overhead for small payloads

[Justin Ross (JIRA)]

 [ 
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, );
>  
> 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, 1, 

[jira] [Resolved] (PROTON-1684) Change build for updated minimum tool versions

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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.

[Justin Ross (JIRA)]

 [ 
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 ) 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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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*

[Justin Ross (JIRA)]

 [ 
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

[Justin Ross (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Robbie Gemmell (JIRA)]

 [ 
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...

[ganeshmurthy]

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

[Rob Godfrey (JIRA)]

 [ 
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 (JIRA)]

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...

[ganeshmurthy]

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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Alex Rudyy (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (PROTON-1537) ruby: update API in line with new C++ API changes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] (QPID-8058) [Broker-J][AMQP 1.0] Broker did not respond to drain request

[Alex Rudyy (JIRA)]

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] [Created] (PROTON-1712) add type details to the ApplicationProperties map

[Robbie Gemmell (JIRA)]

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 (JIRA)]

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

[Alan Conway (JIRA)]

 [ 
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%] 

[jira] [Commented] (QPID-8040) [Broker-J] Uncaught java.nio.channels.CancelledKeyException seen during Broker shutdown

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Alex Rudyy (JIRA)]

 [ 
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

[Alex Rudyy (JIRA)]

 [ 
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

[Alex Rudyy (JIRA)]

 [ 
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

[Ken Giusti (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (JIRA)]

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 

[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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Alex Rudyy (JIRA)]

 [ 
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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Alex Rudyy (JIRA)]

 [ 
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

[Alex Rudyy (JIRA)]

 [ 
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 

[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 (JIRA)]

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

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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