[jira] [Commented] (PROTON-1134) 0.13.0 release tasks

[Justin Ross (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15325366#comment-15325366
 ] 

Justin Ross commented on PROTON-1134:
-

Need to repeat this note from 0.12:

Note: Qpid C++ 0.34 builds will fail against this version of Proton unless you 
set -DCMAKE_CXX_FLAGS=-Wno-error=switch. A new release of Qpid C++ will resolve 
this problem.



> 0.13.0 release tasks
> 
>
> Key: PROTON-1134
> URL: https://issues.apache.org/jira/browse/PROTON-1134
> Project: Qpid Proton
>  Issue Type: Task
>  Components: release
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1209) CLONE - Proton's use of Cyrus SASL is not thread-safe - long term fix

[Andrew Stitcher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Stitcher updated PROTON-1209:

Fix Version/s: (was: 0.13.0)

> CLONE - Proton's use of Cyrus SASL is not thread-safe - long term fix
> -
>
> Key: PROTON-1209
> URL: https://issues.apache.org/jira/browse/PROTON-1209
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.10
>Reporter: michael goulish
>Assignee: Andrew Stitcher
>Priority: Critical
>
> Documentation for the Cyrus SASL library says that the library is believed to 
> be thread-safe only if the code that uses it meets several requirements.
> The requirements are:
> * you supply mutex functions (see sasl_set_mutex())
> * you make no libsasl calls until sasl_client/server_init() completes
> * no libsasl calls are made after sasl_done() is begun
> * when using GSSAPI, you use a thread-safe GSS / Kerberos 5 library.
> It says explicitly that that sasl_set* calls are not thread safe, since they 
> set global state.
> The proton library makes calls to sasl_set* functions in :
>   pni_init_client()
>   pni_init_server(), and
>   pni_process_init()
> Since those are internal functions, there is no way for code that uses Proton 
> to lock around those calls.
> I think proton needs a new API call to let applications call 
> sasl_set_mutex().  Or something.
> We probably also need other protections to meet the other requirements 
> specified in the Cyrus documentation (and quoted above).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-381) qdstat -g causes segfault

[Gordon Sim (JIRA)]

Gordon Sim created DISPATCH-381:
---

 Summary: qdstat -g causes segfault
 Key: DISPATCH-381
 URL: https://issues.apache.org/jira/browse/DISPATCH-381
 Project: Qpid Dispatch
  Issue Type: Bug
Reporter: Gordon Sim


Using latest from master, start a router, connect with qpid-receive or 
qpid-receive, then do qdstat -g:

{noformat}
Core was generated by `./sbin/qdrouterd --conf 
./etc/qpid-dispatch/router1-with-broker.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f79dd616b3a in strlen () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f79cb7fe700 (LWP 7322))]
Missing separate debuginfos, use: dnf debuginfo-install 
cyrus-sasl-gssapi-2.1.26-25.2.fc23.x86_64 
cyrus-sasl-lib-2.1.26-25.2.fc23.x86_64 cyrus-sasl-md5-2.1.26-25.2.fc23.x86_64 
cyrus-sasl-plain-2.1.26-25.2.fc23.x86_64 
cyrus-sasl-scram-2.1.26-25.2.fc23.x86_64 glibc-2.22-11.fc23.x86_64 
keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.14.1-3.fc23.x86_64 
libcom_err-1.42.13-3.fc23.x86_64 libdb-5.3.28-13.fc23.x86_64 
libffi-3.1-8.fc23.x86_64 libselinux-2.4-4.fc23.x86_64 
nss-softokn-freebl-3.23.0-1.0.fc23.x86_64 openssl-libs-1.0.2g-2.fc23.x86_64 
pcre-8.38-7.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64 
sssd-client-1.13.3-5.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
(gdb) thread apply all bt

Thread 5 (Thread 0x7f79de9da180 (LWP 7319)):
#0  0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7f79de5b4faf in sys_cond_wait (cond=, 
held_mutex=0x1cdc3c0) at 
/home/gordon/projects/dispatch/src/posix/threading.c:107
#2  0x7f79de5c8b24 in thread_run (arg=) at 
/home/gordon/projects/dispatch/src/server.c:906
#3  0x7f79de5c9270 in qd_server_run (qd=0x1aff240) at 
/home/gordon/projects/dispatch/src/server.c:1431
#4  0x00401ab7 in main_process 
(config_path=config_path@entry=0x7ffe87716143 
"./etc/qpid-dispatch/router1-with-broker.conf", 
python_pkgdir=python_pkgdir@entry=0x402458 
"/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python", 
fd=fd@entry=2) at /home/gordon/projects/dispatch/router/src/main.c:145
#5  0x004017a7 in main (argc=3, argv=0x7ffe87714838) at 
/home/gordon/projects/dispatch/router/src/main.c:345

Thread 4 (Thread 0x7f79d0c92700 (LWP 7320)):
#0  0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7f79de5b4faf in sys_cond_wait (cond=, 
held_mutex=0x1e1fc60) at 
/home/gordon/projects/dispatch/src/posix/threading.c:107
#2  0x7f79de5c02fd in router_core_thread (arg=0x1e1f930) at 
/home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
#3  0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
#4  0x7f79dd68ea4d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f79caffd700 (LWP 7323)):
#0  0x7f79dd682fdd in poll () from /lib64/libc.so.6
#1  0x7f79de5b4a00 in qdpn_driver_wait_2 (d=0x1d46c70, timeout=, timeout@entry=678) at 
/home/gordon/projects/dispatch/src/posix/driver.c:964
#2  0x7f79de5c8609 in thread_run (arg=) at 
/home/gordon/projects/dispatch/src/server.c:932
#3  0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
#4  0x7f79dd68ea4d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f79cbfff700 (LWP 7321)):
#0  0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7f79de5b4faf in sys_cond_wait (cond=, 
held_mutex=0x1cdc3c0) at 
/home/gordon/projects/dispatch/src/posix/threading.c:107
#2  0x7f79de5c8b24 in thread_run (arg=) at 
/home/gordon/projects/dispatch/src/server.c:906
#3  0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
#4  0x7f79dd68ea4d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f79cb7fe700 (LWP 7322)):
#0  0x7f79dd616b3a in strlen () from /lib64/libc.so.6
#1  0x7f79dd9e5900 in PyString_FromString () from /lib64/libpython2.7.so.1.0
#2  0x7f79de5ab9ba in qd_entity_set_map_key_value 
(entity=entity@entry=0x7f79d0cc67f8, attribute=attribute@entry=0x7f79de5cb885 
"properties", key=, value=0x0)
at /home/gordon/projects/dispatch/src/entity.c:174
#3  0x7f79de5c7af1 in qd_set_connection_properties (conn=0x1e5afc0, 
entity=0x7f79d0cc67f8) at /home/gordon/projects/dispatch/src/server.c:383
#4  qd_entity_refresh_connection (entity=0x7f79d0cc67f8, impl=0x1e5afc0) at 
/home/gordon/projects/dispatch/src/server.c:430
#5  0x7f79d3bafd30 in ffi_call_unix64 () from /lib64/libffi.so.6
#6  0x7f79d3baf79b in ffi_call () from /lib64/libffi.so.6
#7  0x7f79d3dc2daf in _ctypes_callproc () from 
/usr/lib64/python2.7/lib-dynload/_ctypes.so
#8  0x7f79d3dbc9d4 in PyCFuncPtr_call () from 
/usr/lib64/python2.7/lib-dynload/_ctypes.so
#9  0x7f79dd997b03 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#10 0x7f79dda2da68 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#11 0x7f79dda2f666 in 

[jira] [Updated] (DISPATCH-224) Tools fail with no useful error in some SASL configurations

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated DISPATCH-224:
-
Description: 
(Downgraded to a doc issue, but still a serious one. See [#comment-15323200])

A simple test of a default install of dispatch in /usr/local does not work:

{code}
$ make install
$ qdrouterd&
$ qdstat -g
ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
{code}

The exception gives no hint why we were disconnected, and the router log file 
has no entries at all regarding the disconnection. The actual cause is a SASL 
rejection due to invalid configuration. There are several issues that need 
fixing:

- The router log should show an error if SASL cant find/parse its config file.
- The router log should show an error if a connection is rejected for security 
reasons.
- The client exception should indicate that the disconnect was caused by a 
security problem.
- The router should look for SASL configuration under its install prefix since 
that is where it is installed.
- The default router configuration needs to be updated to either be functional 
or clearly NON functional.

Question is is what should the default configuration allow? IMO it should at 
least allow you to use the tools shipped with qdrouterd to verify that it is 
running and working.

The alternative is don't ship a default config at all. In that case the router 
should fail to start at all with a clear message "you must configure me first, 
see $prefix/share/doc/qdrouter/config-examples." We can provide a sample 
"qdrouterd-insecure.conf" to get developers started quickly without forcing 
them to learn SASL first. We can add other example configs for different 
scenarios as we go.

  was:
(

A simple test of a default install of dispatch in /usr/local does not work:

{code}
$ make install
$ qdrouterd&
$ qdstat -g
ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
{code}

The exception gives no hint why we were disconnected, and the router log file 
has no entries at all regarding the disconnection. The actual cause is a SASL 
rejection due to invalid configuration. There are several issues that need 
fixing:

- The router log should show an error if SASL cant find/parse its config file.
- The router log should show an error if a connection is rejected for security 
reasons.
- The client exception should indicate that the disconnect was caused by a 
security problem.
- The router should look for SASL configuration under its install prefix since 
that is where it is installed.
- The default router configuration needs to be updated to either be functional 
or clearly NON functional.

Question is is what should the default configuration allow? IMO it should at 
least allow you to use the tools shipped with qdrouterd to verify that it is 
running and working.

The alternative is don't ship a default config at all. In that case the router 
should fail to start at all with a clear message "you must configure me first, 
see $prefix/share/doc/qdrouter/config-examples." We can provide a sample 
"qdrouterd-insecure.conf" to get developers started quickly without forcing 
them to learn SASL first. We can add other example configs for different 
scenarios as we go.


> Tools fail with no useful error in some SASL configurations
> ---
>
> Key: DISPATCH-224
> URL: https://issues.apache.org/jira/browse/DISPATCH-224
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Ted Ross
>Priority: Critical
> Fix For: 0.7.0
>
>
> (Downgraded to a doc issue, but still a serious one. See [#comment-15323200])
> A simple test of a default install of dispatch in /usr/local does not work:
> {code}
> $ make install
> $ qdrouterd&
> $ qdstat -g
> ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
> {code}
> The exception gives no hint why we were disconnected, and the router log file 
> has no entries at all regarding the disconnection. The actual cause is a SASL 
> rejection due to invalid configuration. There are several issues that need 
> fixing:
> - The router log should show an error if SASL cant find/parse its config file.
> - The router log should show an error if a connection is rejected for 
> security reasons.
> - The client exception should indicate that the disconnect was caused by a 
> security problem.
> - The router should look for SASL configuration under its install prefix 
> since that is where it is installed.
> - The default router configuration needs to be updated to either be 
> functional or clearly NON functional.
> Question is is what should the default configuration allow? IMO it should at 
> least allow you to use the 

[jira] [Updated] (DISPATCH-224) Tools fail with no useful error in some SASL configurations

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated DISPATCH-224:
-
Summary: Tools fail with no useful error in some SASL configurations  (was: 
Default installed configuration fails without error message.)

> Tools fail with no useful error in some SASL configurations
> ---
>
> Key: DISPATCH-224
> URL: https://issues.apache.org/jira/browse/DISPATCH-224
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Ted Ross
>Priority: Critical
> Fix For: 0.7.0
>
>
> A simple test of a default install of dispatch in /usr/local does not work:
> {code}
> $ make install
> $ qdrouterd&
> $ qdstat -g
> ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
> {code}
> The exception gives no hint why we were disconnected, and the router log file 
> has no entries at all regarding the disconnection. The actual cause is a SASL 
> rejection due to invalid configuration. There are several issues that need 
> fixing:
> - The router log should show an error if SASL cant find/parse its config file.
> - The router log should show an error if a connection is rejected for 
> security reasons.
> - The client exception should indicate that the disconnect was caused by a 
> security problem.
> - The router should look for SASL configuration under its install prefix 
> since that is where it is installed.
> - The default router configuration needs to be updated to either be 
> functional or clearly NON functional.
> Question is is what should the default configuration allow? IMO it should at 
> least allow you to use the tools shipped with qdrouterd to verify that it is 
> running and working.
> The alternative is don't ship a default config at all. In that case the 
> router should fail to start at all with a clear message "you must configure 
> me first, see $prefix/share/doc/qdrouter/config-examples." We can provide a 
> sample "qdrouterd-insecure.conf" to get developers started quickly without 
> forcing them to learn SASL first. We can add other example configs for 
> different scenarios as we go.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-224) Tools fail with no useful error in some SASL configurations

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway updated DISPATCH-224:
-
Description: 
(

A simple test of a default install of dispatch in /usr/local does not work:

{code}
$ make install
$ qdrouterd&
$ qdstat -g
ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
{code}

The exception gives no hint why we were disconnected, and the router log file 
has no entries at all regarding the disconnection. The actual cause is a SASL 
rejection due to invalid configuration. There are several issues that need 
fixing:

- The router log should show an error if SASL cant find/parse its config file.
- The router log should show an error if a connection is rejected for security 
reasons.
- The client exception should indicate that the disconnect was caused by a 
security problem.
- The router should look for SASL configuration under its install prefix since 
that is where it is installed.
- The default router configuration needs to be updated to either be functional 
or clearly NON functional.

Question is is what should the default configuration allow? IMO it should at 
least allow you to use the tools shipped with qdrouterd to verify that it is 
running and working.

The alternative is don't ship a default config at all. In that case the router 
should fail to start at all with a clear message "you must configure me first, 
see $prefix/share/doc/qdrouter/config-examples." We can provide a sample 
"qdrouterd-insecure.conf" to get developers started quickly without forcing 
them to learn SASL first. We can add other example configs for different 
scenarios as we go.

  was:
A simple test of a default install of dispatch in /usr/local does not work:

{code}
$ make install
$ qdrouterd&
$ qdstat -g
ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
{code}

The exception gives no hint why we were disconnected, and the router log file 
has no entries at all regarding the disconnection. The actual cause is a SASL 
rejection due to invalid configuration. There are several issues that need 
fixing:

- The router log should show an error if SASL cant find/parse its config file.
- The router log should show an error if a connection is rejected for security 
reasons.
- The client exception should indicate that the disconnect was caused by a 
security problem.
- The router should look for SASL configuration under its install prefix since 
that is where it is installed.
- The default router configuration needs to be updated to either be functional 
or clearly NON functional.

Question is is what should the default configuration allow? IMO it should at 
least allow you to use the tools shipped with qdrouterd to verify that it is 
running and working.

The alternative is don't ship a default config at all. In that case the router 
should fail to start at all with a clear message "you must configure me first, 
see $prefix/share/doc/qdrouter/config-examples." We can provide a sample 
"qdrouterd-insecure.conf" to get developers started quickly without forcing 
them to learn SASL first. We can add other example configs for different 
scenarios as we go.


> Tools fail with no useful error in some SASL configurations
> ---
>
> Key: DISPATCH-224
> URL: https://issues.apache.org/jira/browse/DISPATCH-224
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Ted Ross
>Priority: Critical
> Fix For: 0.7.0
>
>
> (
> A simple test of a default install of dispatch in /usr/local does not work:
> {code}
> $ make install
> $ qdrouterd&
> $ qdstat -g
> ConnectionException: Connection amqp://0.0.0.0:amqp/$management disconnected
> {code}
> The exception gives no hint why we were disconnected, and the router log file 
> has no entries at all regarding the disconnection. The actual cause is a SASL 
> rejection due to invalid configuration. There are several issues that need 
> fixing:
> - The router log should show an error if SASL cant find/parse its config file.
> - The router log should show an error if a connection is rejected for 
> security reasons.
> - The client exception should indicate that the disconnect was caused by a 
> security problem.
> - The router should look for SASL configuration under its install prefix 
> since that is where it is installed.
> - The default router configuration needs to be updated to either be 
> functional or clearly NON functional.
> Question is is what should the default configuration allow? IMO it should at 
> least allow you to use the tools shipped with qdrouterd to verify that it is 
> running and working.
> The alternative is don't ship a default config at all. In that case the 
> router 

[jira] [Commented] (PROTON-1232) Improve implementation of default_container

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15325051#comment-15325051
 ] 

ASF subversion and git services commented on PROTON-1232:
-

Commit 6243919fd47e36afaab16bb9183af244fd8b0338 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6243919 ]

PROTON-1232: [C++ binding] Improve default_container construction


> Improve implementation of default_container
> ---
>
> Key: PROTON-1232
> URL: https://issues.apache.org/jira/browse/PROTON-1232
> Project: Qpid Proton
>  Issue Type: Improvement
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> It would be much better not to expose symbols for internal container classes, 
> but rather expose a factory for the container and use a header only proxy to 
> allow value like use.
> This allow adding new container types by simply exposing a new factory (a 
> single symbol/entry point) rather than exposing a whole new class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-380) Router stops receiving messages from multiple senders publishing to multiple queues in parallel

[Vishal Sharda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishal Sharda updated DISPATCH-380:
---
Attachment: qdstat_wrong_output.png
Senders_4_10_queues.png
Senders_3_10_Queues.png
Senders_2.png
Senders_1.png

Screenshots showing how qdstat shows senders connected but insecure and 
unauthenticated after they hang.

> Router stops receiving messages from multiple senders publishing to multiple 
> queues in parallel
> ---
>
> Key: DISPATCH-380
> URL: https://issues.apache.org/jira/browse/DISPATCH-380
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
> Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate 
> machines
>Reporter: Vishal Sharda
>Priority: Critical
> Fix For: 0.6.0
>
> Attachments: Senders_1.png, Senders_2.png, Senders_3_10_Queues.png, 
> Senders_4_10_queues.png, qdstat_wrong_output.png
>
>
> I am running a Java Client against a cluster of 3 interior routers connected 
> to each other.  2-way SSL is enabled for all the connections.
> There were 20 simultaneous queues with 20 senders on each queue and each 
> sender publishing 1000 messages.  All the senders were connected to Router 1. 
>  20 receivers were connected to Router 2 with 1 receiver receiving from each 
> queue.
> In the first run, router stopped receiving incoming messages after delivering 
> 386,339 out of 400K "Hello World!" messages.
> In the second run, 388,781 messages out of 400K were delivered.
> I reduced the number of queues to 10 (halving total number of messages to 
> 200K) and the issue occurred again.
> I ran the Java client on an 8 CPU machine again with 10 queues and the issue 
> occurred again after delivering just 54K out of 200K messages.
> All the senders were hung (still connected) with no messages flowing at all.
> Connection information from qdstat:
> When the messages are flowing properly and I run "qdstat -c", I see all the 
> senders as secure and authenticated.
> After they hang and I run "qdstat -c", it erroneously shows all the clients 
> as insecure and unauthenticated.
> Shortly after the clients hang, all the queues are deleted from the router 
> network but connections are still shown until I terminate the clients.
> I saw this erroneous situation before also when "qdstat -c" showed some 
> senders as secure and authentic but some as insecure/unauthentic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-380) Router stops receiving messages from multiple senders publishing to multiple queues in parallel

[Vishal Sharda (JIRA)]

Vishal Sharda created DISPATCH-380:
--

 Summary: Router stops receiving messages from multiple senders 
publishing to multiple queues in parallel
 Key: DISPATCH-380
 URL: https://issues.apache.org/jira/browse/DISPATCH-380
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Routing Engine
 Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and 
dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate machines
Reporter: Vishal Sharda
Priority: Critical
 Fix For: 0.6.0


I am running a Java Client against a cluster of 3 interior routers connected to 
each other.  2-way SSL is enabled for all the connections.

There were 20 simultaneous queues with 20 senders on each queue and each sender 
publishing 1000 messages.  All the senders were connected to Router 1.  20 
receivers were connected to Router 2 with 1 receiver receiving from each queue.

In the first run, router stopped receiving incoming messages after delivering 
386,339 out of 400K "Hello World!" messages.
In the second run, 388,781 messages out of 400K were delivered.

I reduced the number of queues to 10 (halving total number of messages to 200K) 
and the issue occurred again.

I ran the Java client on an 8 CPU machine again with 10 queues and the issue 
occurred again after delivering just 54K out of 200K messages.

All the senders were hung (still connected) with no messages flowing at all.

Connection information from qdstat:

When the messages are flowing properly and I run "qdstat -c", I see all the 
senders as secure and authenticated.

After they hang and I run "qdstat -c", it erroneously shows all the clients as 
insecure and unauthenticated.

Shortly after the clients hang, all the queues are deleted from the router 
network but connections are still shown until I terminate the clients.

I saw this erroneous situation before also when "qdstat -c" showed some senders 
as secure and authentic but some as insecure/unauthentic.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7287) Query parser fails silently with expression such as a + b

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7287:
--
Status: Reviewable  (was: In Progress)

> Query parser fails silently with expression such as a + b
> -
>
> Key: QPID-7287
> URL: https://issues.apache.org/jira/browse/QPID-7287
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Rob Godfrey
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> There is a defect in the order-by (and select) parsing when the input is in 
> the form a + b.  It seems the parser fails, but the exception is not reported 
> back  to the client, nor it is reported to the logs.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1224) Proton-J SSL uses deprecated Bouncy Castle functionality

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324921#comment-15324921
 ] 

ASF GitHub Bot commented on PROTON-1224:


GitHub user JemDay opened a pull request:

https://github.com/apache/qpid-proton/pull/75

PROTON-1224: Upgrade BouncyCastle

Support 1.48+ of BouncyCastle
Added unit-test and associated certificate and key test resources.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/JemDay/qpid-proton master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-proton/pull/75.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 #75


commit d97854bc37f6b71f0ba6944c39e59826c6651d12
Author: Jem Day 
Date:   2016-06-10T17:13:36Z

PROTON-1224: Upgrade BouncyCastle to 1.48+

commit f9efcf058cd056ac61ed174b6b31555454740610
Author: Jem Day 
Date:   2016-06-10T17:13:36Z

PROTON-1224: Upgrade BouncyCastle to 1.48+

commit daa2959004e2d090a5e5afcedd4dfc7e3e9a49a7
Author: Jem Day 
Date:   2016-06-10T17:30:38Z

Merge branch 'master' of https://github.com/JemDay/qpid-proton

commit 7aff6361d6942ea069727f118750bb27117aa8cf
Author: Jem Day 
Date:   2016-06-10T17:34:27Z

Merge branch 'master' of https://github.com/apache/qpid-proton




> Proton-J SSL uses deprecated Bouncy Castle functionality
> 
>
> Key: PROTON-1224
> URL: https://issues.apache.org/jira/browse/PROTON-1224
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Affects Versions: 0.12.2
>Reporter: Jem Day
>
> The BouncyCastle project deprecated functionality used by the proton-j driver 
> in version 1.48. This causes run-time issues for us as our application 
> containers are using newer BC versions.
> I've submitted a PR for this change and verified that all tests run using 
> both BC 1.48 and 1.54.
> Note: The CI pipeline for the PR is flagging an error but i am able to 
> build/test locally with no reported errors - build log is attached to the PR 
> comments.
> https://github.com/apache/qpid-proton/pull/74



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7287) Query parser fails silently with expression such as a + b

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324916#comment-15324916
 ] 

ASF subversion and git services commented on QPID-7287:
---

Commit 1747761 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1747761 ]

QPID-7287 : Query grammar should allow for arithmetic expressions in select and 
order by clauses

> Query parser fails silently with expression such as a + b
> -
>
> Key: QPID-7287
> URL: https://issues.apache.org/jira/browse/QPID-7287
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> There is a defect in the order-by (and select) parsing when the input is in 
> the form a + b.  It seems the parser fails, but the exception is not reported 
> back  to the client, nor it is reported to the logs.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-7287) Query parser fails silently with expression such as a + b

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned QPID-7287:
-

Assignee: Rob Godfrey

> Query parser fails silently with expression such as a + b
> -
>
> Key: QPID-7287
> URL: https://issues.apache.org/jira/browse/QPID-7287
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Rob Godfrey
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> There is a defect in the order-by (and select) parsing when the input is in 
> the form a + b.  It seems the parser fails, but the exception is not reported 
> back  to the client, nor it is reported to the logs.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-375) Console instalation instructions do not work

[Ernest Allen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernest Allen resolved DISPATCH-375.
---
   Resolution: Fixed
Fix Version/s: 0.7.0

> Console instalation instructions do not work
> 
>
> Key: DISPATCH-375
> URL: https://issues.apache.org/jira/browse/DISPATCH-375
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.6.0
>Reporter: Jiri Danek
>Assignee: Ernest Allen
>Priority: Trivial
> Fix For: 0.7.0
>
> Attachments: Dockerfile-debian
>
>
> Instructions in {{console/hawtio/README.md}} say that I should do
> {noformat}
> cp target/dispatch-hawtio-console-*.war 
> apache-tomcat-8.0.35/webapps/dispatch-hawtio-console.war
> {noformat}
> but what I had to do in fact was
> {noformat}
> cp target/dispatch-hawtio-console-*.war 
> apache-tomcat-8.0.35/webapps/dispatch-plugin.war
> {noformat}
> that is, the war file should have a different name than the document says.l



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-379) Missing default route indication on topology page

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-379:
-

 Summary: Missing default route indication on topology page
 Key: DISPATCH-379
 URL: https://issues.apache.org/jira/browse/DISPATCH-379
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 0.7.0
Reporter: Ernest Allen
Assignee: Ernest Allen


On the topology page you were able to select a node and then mouse over a 
different node to see the default router between the two nodes. That no longer 
works.

This functionality should be fixed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1235) C Reactor: connection fails if hostname with no port is used for transport address

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324874#comment-15324874
 ] 

ASF subversion and git services commented on PROTON-1235:
-

Commit 7bc06c96d6364238b128559e4f3c23c649d26789 in qpid-proton's branch 
refs/heads/master from [~kgiusti]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7bc06c9 ]

PROTON-1235: set hostname even if port not available


> C Reactor: connection fails if hostname with no port is used for transport 
> address
> --
>
> Key: PROTON-1235
> URL: https://issues.apache.org/jira/browse/PROTON-1235
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.14.0
>
>
> If the application uses the connection's hostname as the transport address 
> _and_ the port number is not present (ie no ":" suffix) the connection 
> attempt will fail with a "no address configured" error.
> The expected behavior is to adopt the default "5672" port if none is 
> specified.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-349) Modify the client icon on the topology page to indicate when there are multiple clients.

[Ernest Allen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernest Allen resolved DISPATCH-349.
---
   Resolution: Fixed
Fix Version/s: 0.7.0

The fix for this was contained in the patch for DISPATCH-318

> Modify the client icon on the topology page to indicate when there are 
> multiple clients.
> 
>
> Key: DISPATCH-349
> URL: https://issues.apache.org/jira/browse/DISPATCH-349
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 0.7.0
>
>
> On the topology page there is an icon that represents a client that is 
> connected to a router. When there are multiple clients, the icon should 
> change to give a visual indication that it represents multiple clients.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-318) Don't allow router nodes to be moved off of the screen on topology page

[Ernest Allen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ernest Allen resolved DISPATCH-318.
---
   Resolution: Fixed
Fix Version/s: 0.7.0

> Don't allow router nodes to be moved off of the screen on topology page
> ---
>
> Key: DISPATCH-318
> URL: https://issues.apache.org/jira/browse/DISPATCH-318
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 0.7.0
>
>
> It is possible to drag and drop a router node off the visible page. Once you 
> do that, it is difficult to get it back on the page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1134) 0.13.0 release tasks

[Ken Giusti (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324866#comment-15324866
 ] 

Ken Giusti commented on PROTON-1134:


Using pn_connection_set_hostname() to set the transport address on Reactor/C 
connections is bad practice and specifically not recommended.  A new reactor 
method has been introduced to deal with this:

pn_reactor_connection_to_host(, , , )

And the pn_reactor_connection(, ) has been deprecated in 
favor of this new interface.

The python Container.connect() method now takes an optional parameter with the 
keyword 'virtual_host'.  This can be used to set the 'hostname' attribute in 
the Open frame sent by the client.

---

0.13.0 has a known issue with the C/Reactor.  If the reactor connection's 
hostname is used to configure the transport address (see above), then C/Reactor 
may fail to connect if the hostname does not include a ":" suffix.

Using the connection's hostname as the transport address is discouraged.  Use 
the new reactor connection factory method pn_reactor_connection_to_host() 
instead.


> 0.13.0 release tasks
> 
>
> Key: PROTON-1134
> URL: https://issues.apache.org/jira/browse/PROTON-1134
> Project: Qpid Proton
>  Issue Type: Task
>  Components: release
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-318) Don't allow router nodes to be moved off of the screen on topology page

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324850#comment-15324850
 ] 

ASF subversion and git services commented on DISPATCH-318:
--

Commit 5240adc14e33533b56fc8a79af7fde036bdb5a26 in qpid-dispatch's branch 
refs/heads/master from [~eallen]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=5240adc ]

DISPATCH-318: Prevent dragging nodes off edge of screen. Also minor visual 
fixes for displaying multiple client.


> Don't allow router nodes to be moved off of the screen on topology page
> ---
>
> Key: DISPATCH-318
> URL: https://issues.apache.org/jira/browse/DISPATCH-318
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
>
> It is possible to drag and drop a router node off the visible page. Once you 
> do that, it is difficult to get it back on the page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request 48558: C reactor does not set transport address properly if connection hostname is used and it does not contain a port

[Justin Ross]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/48558/#review137038
---


Ship it!




Ship It!

- Justin Ross


On June 10, 2016, 4:40 p.m., Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48558/
> ---
> 
> (Updated June 10, 2016, 4:40 p.m.)
> 
> 
> Review request for qpid and Justin Ross.
> 
> 
> Bugs: proton-1235
> https://issues.apache.org/jira/browse/proton-1235
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> see jira
> 
> 
> Diffs
> -
> 
>   proton-c/src/reactor/connection.c a3e7367 
> 
> Diff: https://reviews.apache.org/r/48558/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kenneth Giusti
> 
>

[jira] [Commented] (PROTON-1235) C Reactor: connection fails if hostname with no port is used for transport address

[Ken Giusti (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324765#comment-15324765
 ] 

Ken Giusti commented on PROTON-1235:


reviewboard:

https://reviews.apache.org/r/48558/

> C Reactor: connection fails if hostname with no port is used for transport 
> address
> --
>
> Key: PROTON-1235
> URL: https://issues.apache.org/jira/browse/PROTON-1235
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.14.0
>
>
> If the application uses the connection's hostname as the transport address 
> _and_ the port number is not present (ie no ":" suffix) the connection 
> attempt will fail with a "no address configured" error.
> The expected behavior is to adopt the default "5672" port if none is 
> specified.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Review Request 48558: C reactor does not set transport address properly if connection hostname is used and it does not contain a port

[Kenneth Giusti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/48558/
---

Review request for qpid and Justin Ross.


Bugs: proton-1235
https://issues.apache.org/jira/browse/proton-1235


Repository: qpid-proton-git


Description
---

see jira


Diffs
-

  proton-c/src/reactor/connection.c a3e7367 

Diff: https://reviews.apache.org/r/48558/diff/


Testing
---


Thanks,

Kenneth Giusti

[jira] [Created] (DISPATCH-378) Seg Fault in CORE_link_push

[Gordon Sim (JIRA)]

Gordon Sim created DISPATCH-378:
---

 Summary: Seg Fault in CORE_link_push
 Key: DISPATCH-378
 URL: https://issues.apache.org/jira/browse/DISPATCH-378
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 0.6.1
 Environment: Latest master branch of dispatch, fedora 23
Reporter: Gordon Sim


Doing some perf testing with a very simple two router setup, one router 
connecting to the other. Hit this once only so far (i.e. not readily 
reproducible) wasn't doing anything noticeably different at the time.

{noformat}
Core was generated by `./sbin/qdrouterd --conf 
./etc/qpid-dispatch/router2.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  qd_link_pn (link=0x0) at /home/gordon/projects/dispatch/src/container.c:862
862 return link->pn_link;
[Current thread is 1 (Thread 0x7f07c4f53700 (LWP 27600))]
Missing separate debuginfos, use: dnf debuginfo-install 
cyrus-sasl-gssapi-2.1.26-25.2.fc23.x86_64 
cyrus-sasl-lib-2.1.26-25.2.fc23.x86_64 cyrus-sasl-md5-2.1.26-25.2.fc23.x86_64 
cyrus-sasl-plain-2.1.26-25.2.fc23.x86_64 
cyrus-sasl-scram-2.1.26-25.2.fc23.x86_64 glibc-2.22-11.fc23.x86_64 
keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.14.1-3.fc23.x86_64 
libcom_err-1.42.13-3.fc23.x86_64 libdb-5.3.28-13.fc23.x86_64 
libffi-3.1-8.fc23.x86_64 libselinux-2.4-4.fc23.x86_64 
nss-softokn-freebl-3.23.0-1.0.fc23.x86_64 openssl-libs-1.0.2g-2.fc23.x86_64 
pcre-8.38-7.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64 
sssd-client-1.13.3-5.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
(gdb) bt
#0  qd_link_pn (link=0x0) at /home/gordon/projects/dispatch/src/container.c:862
#1  0x7f07d429b0fc in CORE_link_push (context=0xf11550, 
link=0x7f07bc035a70) at /home/gordon/projects/dispatch/src/router_node.c:808
#2  0x7f07d429159e in qdr_connection_process (conn=0x7f07b80c3070) at 
/home/gordon/projects/dispatch/src/router_core/connections.c:175
#3  0x7f07d427f728 in writable_handler (container=0xe3db70, 
container=0xe3db70, conn=, qd_conn=0x7f07bc02ea10) at 
/home/gordon/projects/dispatch/src/container.c:353
#4  handler (handler_context=0xe3db70, conn_context=, 
event=, qd_conn=0x7f07bc02ea10) at 
/home/gordon/projects/dispatch/src/container.c:590
#5  0x7f07d429ed85 in process_connector (cxtr=0x7f07bc021b40, 
qd_server=0xdd33f0) at /home/gordon/projects/dispatch/src/server.c:804
#6  thread_run (arg=) at 
/home/gordon/projects/dispatch/src/server.c:1024
#7  0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
#8  0x7f07d3364a4d in clone () from /lib64/libc.so.6
(gdb) info threads
  Id   Target Id Frame 
  5Thread 0x7f07d46b0180 (LWP 27596) 0x7f07d3e04b10 in 
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  4Thread 0x7f07c5f55700 (LWP 27598) 0x7f07d3e04b10 in 
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  3Thread 0x7f07c5754700 (LWP 27599) 0x7f07d3358fdd in poll () from 
/lib64/libc.so.6
  2Thread 0x7f07c6968700 (LWP 27597) 0x7f07d3e04b10 in 
pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
* 1Thread 0x7f07c4f53700 (LWP 27600) qd_link_pn (link=0x0) at 
/home/gordon/projects/dispatch/src/container.c:862
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f07c6968700 (LWP 27597))]
#0  0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
(gdb) bt
#0  0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7f07d428afaf in sys_cond_wait (cond=, 
held_mutex=0xf169a0) at /home/gordon/projects/dispatch/src/posix/threading.c:107
#2  0x7f07d42962fd in router_core_thread (arg=0xf16670) at 
/home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
#3  0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
#4  0x7f07d3364a4d in clone () from /lib64/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 0x7f07c5754700 (LWP 27599))]
#0  0x7f07d3358fdd in poll () from /lib64/libc.so.6
(gdb) bt
#0  0x7f07d3358fdd in poll () from /lib64/libc.so.6
#1  0x7f07d428aa00 in qdpn_driver_wait_2 (d=0xe468c0, timeout=, timeout@entry=64) at /home/gordon/projects/dispatch/src/posix/driver.c:964
#2  0x7f07d429e609 in thread_run (arg=) at 
/home/gordon/projects/dispatch/src/server.c:932
#3  0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
#4  0x7f07d3364a4d in clone () from /lib64/libc.so.6
(gdb) thread 4
[Switching to thread 4 (Thread 0x7f07c5f55700 (LWP 27598))]
#0  0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
(gdb) bt
#0  0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7f07d428afaf in sys_cond_wait (cond=, 
held_mutex=0xe30320) at /home/gordon/projects/dispatch/src/posix/threading.c:107
#2  0x7f07d429eb24 in thread_run (arg=) at 
/home/gordon/projects/dispatch/src/server.c:906
#3  

[jira] [Assigned] (PROTON-1235) C Reactor: connection fails if hostname with no port is used for transport address

[Ken Giusti (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti reassigned PROTON-1235:
--

Assignee: Ken Giusti

> C Reactor: connection fails if hostname with no port is used for transport 
> address
> --
>
> Key: PROTON-1235
> URL: https://issues.apache.org/jira/browse/PROTON-1235
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.14.0
>
>
> If the application uses the connection's hostname as the transport address 
> _and_ the port number is not present (ie no ":" suffix) the connection 
> attempt will fail with a "no address configured" error.
> The expected behavior is to adopt the default "5672" port if none is 
> specified.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (PROTON-1235) C Reactor: connection fails if hostname with no port is used for transport address

[Ken Giusti (JIRA)]

Ken Giusti created PROTON-1235:
--

 Summary: C Reactor: connection fails if hostname with no port is 
used for transport address
 Key: PROTON-1235
 URL: https://issues.apache.org/jira/browse/PROTON-1235
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.13.0
Reporter: Ken Giusti
 Fix For: 0.14.0


If the application uses the connection's hostname as the transport address 
_and_ the port number is not present (ie no ":" suffix) the connection 
attempt will fail with a "no address configured" error.

The expected behavior is to adopt the default "5672" port if none is specified.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton pull request #74: proton-j : Upgrade BouncyCastle

[JemDay]

Github user JemDay closed the pull request at:

https://github.com/apache/qpid-proton/pull/74


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton issue #74: proton-j : Upgrade BouncyCastle

[JemDay]

Github user JemDay commented on the issue:

https://github.com/apache/qpid-proton/pull/74
  
Closing PR .. will recreate


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-211) Expose connection properties in management response

[Ganesh Murthy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ganesh Murthy resolved DISPATCH-211.

Resolution: Fixed

> Expose connection properties in management response
> ---
>
> Key: DISPATCH-211
> URL: https://issues.apache.org/jira/browse/DISPATCH-211
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.6.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> The response for a management request for the .connection entity contains a 
> "properties" field, but it is always empty.
> The connections properties should be returned. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-211) Expose connection properties in management response

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324537#comment-15324537
 ] 

ASF subversion and git services commented on DISPATCH-211:
--

Commit 06296ba31b9a69a7748adfda8d453f89fee8c843 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=06296ba ]

DISPATCH-211 - Exposed connection properties in management response


> Expose connection properties in management response
> ---
>
> Key: DISPATCH-211
> URL: https://issues.apache.org/jira/browse/DISPATCH-211
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.6.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> The response for a management request for the .connection entity contains a 
> "properties" field, but it is always empty.
> The connections properties should be returned. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-377) Replace all dashed separated entity/attributeNames in Router book with mixedCase

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-377:
--

 Summary: Replace all dashed separated entity/attributeNames in 
Router book with mixedCase
 Key: DISPATCH-377
 URL: https://issues.apache.org/jira/browse/DISPATCH-377
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Documentation
Affects Versions: 0.7.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7221) [Java Broker] On VirtualHost creation ManagedAttribute queue.deadLetterQueueEnabled should be initialised by context variable instead of referencing it

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7221:
--
Fix Version/s: qpid-java-6.1

> [Java Broker] On VirtualHost creation ManagedAttribute 
> queue.deadLetterQueueEnabled should be initialised by context variable 
> instead of referencing it
> ---
>
> Key: QPID-7221
> URL: https://issues.apache.org/jira/browse/QPID-7221
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> Currently, {{VirtualHost._queue_deadLetterQueueEnabled}} defaults to 
> {{$queue.deadLetterQueueEnabled}}.
> This context variable is not materialised when the VirtualHost is 
> instantiated. This can cause surprising behaviour when either the context var 
> changes or a VH configuration is migrated to a different broker where the 
> context variable might be different.
> In addition the UI does not resolve the context variable leading it to not 
> correctly display the state of the checkbox (QPID-7227).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7221) [Java Broker] On VirtualHost creation ManagedAttribute queue.deadLetterQueueEnabled should be initialised by context variable instead of referencing it

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7221:
--
Assignee: (was: Rob Godfrey)

> [Java Broker] On VirtualHost creation ManagedAttribute 
> queue.deadLetterQueueEnabled should be initialised by context variable 
> instead of referencing it
> ---
>
> Key: QPID-7221
> URL: https://issues.apache.org/jira/browse/QPID-7221
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> Currently, {{VirtualHost._queue_deadLetterQueueEnabled}} defaults to 
> {{$queue.deadLetterQueueEnabled}}.
> This context variable is not materialised when the VirtualHost is 
> instantiated. This can cause surprising behaviour when either the context var 
> changes or a VH configuration is migrated to a different broker where the 
> context variable might be different.
> In addition the UI does not resolve the context variable leading it to not 
> correctly display the state of the checkbox (QPID-7227).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7221) [Java Broker] On VirtualHost creation ManagedAttribute queue.deadLetterQueueEnabled should be initialised by context variable instead of referencing it

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324453#comment-15324453
 ] 

ASF subversion and git services commented on QPID-7221:
---

Commit 1747707 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1747707 ]

QPID-7221 : Allow for attributes to have their defaults copied / materialized 
at creation time.  Apply to virtual host isDeadLetterQueueEnabled

> [Java Broker] On VirtualHost creation ManagedAttribute 
> queue.deadLetterQueueEnabled should be initialised by context variable 
> instead of referencing it
> ---
>
> Key: QPID-7221
> URL: https://issues.apache.org/jira/browse/QPID-7221
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Rob Godfrey
>
> Currently, {{VirtualHost._queue_deadLetterQueueEnabled}} defaults to 
> {{$queue.deadLetterQueueEnabled}}.
> This context variable is not materialised when the VirtualHost is 
> instantiated. This can cause surprising behaviour when either the context var 
> changes or a VH configuration is migrated to a different broker where the 
> context variable might be different.
> In addition the UI does not resolve the context variable leading it to not 
> correctly display the state of the checkbox (QPID-7227).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7221) [Java Broker] On VirtualHost creation ManagedAttribute queue.deadLetterQueueEnabled should be initialised by context variable instead of referencing it

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7221:
--
Status: Reviewable  (was: In Progress)

> [Java Broker] On VirtualHost creation ManagedAttribute 
> queue.deadLetterQueueEnabled should be initialised by context variable 
> instead of referencing it
> ---
>
> Key: QPID-7221
> URL: https://issues.apache.org/jira/browse/QPID-7221
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Rob Godfrey
>
> Currently, {{VirtualHost._queue_deadLetterQueueEnabled}} defaults to 
> {{$queue.deadLetterQueueEnabled}}.
> This context variable is not materialised when the VirtualHost is 
> instantiated. This can cause surprising behaviour when either the context var 
> changes or a VH configuration is migrated to a different broker where the 
> context variable might be different.
> In addition the UI does not resolve the context variable leading it to not 
> correctly display the state of the checkbox (QPID-7227).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-7221) [Java Broker] On VirtualHost creation ManagedAttribute queue.deadLetterQueueEnabled should be initialised by context variable instead of referencing it

[Rob Godfrey (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey reassigned QPID-7221:
-

Assignee: Rob Godfrey

> [Java Broker] On VirtualHost creation ManagedAttribute 
> queue.deadLetterQueueEnabled should be initialised by context variable 
> instead of referencing it
> ---
>
> Key: QPID-7221
> URL: https://issues.apache.org/jira/browse/QPID-7221
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Rob Godfrey
>
> Currently, {{VirtualHost._queue_deadLetterQueueEnabled}} defaults to 
> {{$queue.deadLetterQueueEnabled}}.
> This context variable is not materialised when the VirtualHost is 
> instantiated. This can cause surprising behaviour when either the context var 
> changes or a VH configuration is migrated to a different broker where the 
> context variable might be different.
> In addition the UI does not resolve the context variable leading it to not 
> correctly display the state of the checkbox (QPID-7227).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-367) balanced distribution needs to be more... balanced.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324430#comment-15324430
 ] 

ASF GitHub Bot commented on DISPATCH-367:
-

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/81

DISPATCH-367 - Swap link pointers so that the distribution will be ba…

…lanced for synchronous senders

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-367

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/81.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 #81


commit e90fc60a4de5e2f4fe67e9ef9275a63aea31c62b
Author: Ganesh Murthy 
Date:   2016-06-10T13:13:12Z

DISPATCH-367 - Swap link pointers so that the distribution will be balanced 
for synchronous senders




> balanced distribution needs to be more... balanced.
> ---
>
> Key: DISPATCH-367
> URL: https://issues.apache.org/jira/browse/DISPATCH-367
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ken Giusti
>Assignee: Ganesh Murthy
> Fix For: 0.6.0
>
>
> When blocking sends are done to a balanced address with multiple consumers on 
> the same router all the messages go to one of the consumers.
> I would expect that the messages would be evenly distributed across all 
> _locally_attached_ consumers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #81: DISPATCH-367 - Swap link pointers so that th...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/81

DISPATCH-367 - Swap link pointers so that the distribution will be ba…

…lanced for synchronous senders

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-367

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/81.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 #81


commit e90fc60a4de5e2f4fe67e9ef9275a63aea31c62b
Author: Ganesh Murthy 
Date:   2016-06-10T13:13:12Z

DISPATCH-367 - Swap link pointers so that the distribution will be balanced 
for synchronous senders




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1185) [proton-j] Send operations like SendLink.send() & RecvLink.flow() (aka writing to the transport stack) doesn't flush all bytes to the Network

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1185:
---
Fix Version/s: (was: 0.13.0)

> [proton-j] Send operations like SendLink.send() & RecvLink.flow() (aka 
> writing to the transport stack) doesn't flush all bytes to the Network
> -
>
> Key: PROTON-1185
> URL: https://issues.apache.org/jira/browse/PROTON-1185
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.2
> Environment: All
>Reporter: Sreeram Garlapati
>  Labels: proton-j, send-stuck
>
> We are experiencing this issue intermittently - writing to Proton-j transport 
> stack doesn't flush bytes to the Network. The application remains in "stuck 
> state" - until more bytes are written to that Transport.
> We are experiencing this in both these APIs - SenderImpl.send(...) and 
> ReceiverImpl.flow(...) - which under-the-covers writes bytes to Transport. We 
> can see our Traces where we are invoking these APIs - but at this point - the 
> Proton frames (set PN_TRACE_FRM=1) stops.
> We use SSL transport and our Amqp layer is here: 
> https://github.com/Azure/azure-event-hubs/tree/master/java/azure-eventhubs/src/main/java/com/microsoft/azure/servicebus/amqp
> Please let me know what exact information will be useful to diagnose this 
> issue. 
> This issue currently consistently repro's after Sending on 1 Link (on 1 
> Session - 1 AmqpConnection) **for a long time**. While I am trying hard to 
> break this down to a simplest possible reproducer code - I filed the issue to 
> communicate ahead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1204) NullPointerException in Reactor Stack - IOHandler.onUnHandled method

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1204:
---
Fix Version/s: (was: 0.13.0)

> NullPointerException in Reactor Stack - IOHandler.onUnHandled method
> 
>
> Key: PROTON-1204
> URL: https://issues.apache.org/jira/browse/PROTON-1204
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.2
>Reporter: Sreeram Garlapati
>
> We are hitting NPE in the proton reactor Stack in IOHandler.java ().
> LN 302: ReactorImpl reactor = (ReactorImpl)event.getReactor();
> LN 303: Selector selector = reactor.getSelector();   <--- at this line 
> 'reactor is null' when eventType=NON_CORE_EVENT
> Below is the exception stack trace:
> -
> java.lang.NullPointerException
> org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:112)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:304)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:273)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.run(ReactorImpl.java:340)
> com.microsoft.azure.servicebus.MessagingFactory$RunReactor.run(MessagingFactory.java:366)
> java.lang.Thread.run(Unknown Source)Cause: null
> org.apache.qpid.proton.reactor.impl.IOHandler.onUnhandled(IOHandler.java:303)
> org.apache.qpid.proton.engine.BaseHandler.handle(BaseHandler.java:236)
> org.apache.qpid.proton.engine.impl.EventImpl.dispatch(EventImpl.java:108)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.dispatch(ReactorImpl.java:304)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.process(ReactorImpl.java:273)
> org.apache.qpid.proton.reactor.impl.ReactorImpl.run(ReactorImpl.java:340)
> com.microsoft.azure.servicebus.MessagingFactory$RunReactor.run(MessagingFactory.java:366)
> java.lang.Thread.run(Unknown Source)
> I am trying to debug thru this and am blocked on understanding this: as per 
> the Javadoc available - NON_CORE_EVENT can only be raised by extensions ? Can 
> someone please help understand what are extensions and when this event is 
> raised?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (PROTON-1146) [proton-j] fixes for issues identified by Coverity

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell resolved PROTON-1146.

Resolution: Fixed

Resolving this JIRA. While there are other things to look into, they can get 
their own JIRA later, since 0.13.0 is going out now.

> [proton-j] fixes for issues identified by Coverity
> --
>
> Key: PROTON-1146
> URL: https://issues.apache.org/jira/browse/PROTON-1146
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 0.13.0
>
>
> Holder for small fixes/improvements identified by Coverity



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1177) [proton-j] Source and Target interfaces are incomplete and confusing

[Robbie Gemmell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated PROTON-1177:
---
Fix Version/s: (was: 0.13.0)
   0.14.0

> [proton-j] Source and Target interfaces are incomplete and confusing
> 
>
> Key: PROTON-1177
> URL: https://issues.apache.org/jira/browse/PROTON-1177
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.12.1
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: 0.14.0
>
>
> The org.apache.qpid.proton.amqp.transport.Source and 
> org.apache.qpid.proton.amqp.transport.Target interfaces are used on the Link 
> interface setters/getters, however they container almost none of the methods 
> needed to use the Source and Target. The impls have all the necessary 
> methods, but folks would currently need to cast the values to them in order 
> to use in almost any meaningful way, and they exist in a completely different 
> package which makes them less than obvious. Finally, most of the interfaces 
> for engine objects have a factory in their interface for creating them, the 
> Source and Target ones do not, making their use less obvious again.
> Changing the existing interface/impl names/packages would break most existing 
> uses, so we probably want to avoid that, but we should at least update the 
> interfaces to contain the required methods, and perhaps add the equivalent 
> factories to make their creation more obvious.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (DISPATCH-184) dispatch do not stop when 'amqp' is not defined

[Jiri Danek (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324085#comment-15324085
 ] 

Jiri Danek edited comment on DISPATCH-184 at 6/10/16 8:40 AM:
--

Issue is still present. If I delete my amqp lines from {{/etc/services}}, then 
with the default config this happens:

{noformat}
mv /etc/services /etc/services_
qdrouterd &
Fri Jun 10 07:41:42 2016 SERVER (info) Container Name: Router.A
Fri Jun 10 07:41:42 2016 ROUTER (info) Router started in Standalone mode
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) Router Core thread running. 
0/Router.A
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
M/$management
Fri Jun 10 07:41:42 2016 AGENT (info) Activating management agent on 
$_management_internal
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$management
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$_management_internal
Fri Jun 10 07:41:42 2016 DISPLAYNAME (info) Activating DisplayNameService on 
$displayname
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$displayname
Fri Jun 10 07:41:42 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp 
proto=any role=normal
Fri Jun 10 07:41:42 2016 DRIVER (error) getaddrinfo(0.0.0.0, amqp): Servname 
not supported for ai_socktype
Fri Jun 10 07:41:42 2016 POLICY (info) Policy configured maximumConnections: 0, 
policyFolder: '', access rules enabled: 'false'
Fri Jun 10 07:41:42 2016 POLICY (info) Policy fallback defaultApplication is 
disabled
Fri Jun 10 07:41:42 2016 SERVER (info) Operational, 4 Threads Running

# qdstat -g
Segmentation fault
{noformat}

(core from {{qdstat -g}} on Fedora 23 is attached)

Dispatch is supposed to work even without the amqp line in {{/etc/services}}, 
because 
[qpid-dispatch/python/qpid_dispatch_internal/proton_future/__init__.py|https://github.com/apache/qpid-dispatch/blob/2b1d8f67f3ad5dd25edaf8fc71117988a14e102d/python/qpid_dispatch_internal/proton_future/__init__.py#L3782]
 contains this function, which should be called to take care of the problem.

{code}
@staticmethod
def _port_int(value):
  """Convert service, an integer or a service name, into an integer port 
number."""
  try:
return int(value)
  except ValueError:
try:
  return socket.getservbyname(value)
except socket.error:
  # Not every system has amqp/amqps defined as a service
  if value == Url.AMQPS:  return 5671
  elif value == Url.AMQP: return 5672
  else:
raise ValueError("Not a valid port number or service name: '%s'" % 
value)
{code}


was (Author: jdanek):
Issue is still present. If I delete my amqp lines from {{/etc/services}}, then 
with the default config this happens:

{noformat}
mv /etc/services /etc/services_
qdrouterd &
Fri Jun 10 07:41:42 2016 SERVER (info) Container Name: Router.A
Fri Jun 10 07:41:42 2016 ROUTER (info) Router started in Standalone mode
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) Router Core thread running. 
0/Router.A
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
M/$management
Fri Jun 10 07:41:42 2016 AGENT (info) Activating management agent on 
$_management_internal
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$management
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$_management_internal
Fri Jun 10 07:41:42 2016 DISPLAYNAME (info) Activating DisplayNameService on 
$displayname
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$displayname
Fri Jun 10 07:41:42 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp 
proto=any role=normal
Fri Jun 10 07:41:42 2016 DRIVER (error) getaddrinfo(0.0.0.0, amqp): Servname 
not supported for ai_socktype
Fri Jun 10 07:41:42 2016 POLICY (info) Policy configured maximumConnections: 0, 
policyFolder: '', access rules enabled: 'false'
Fri Jun 10 07:41:42 2016 POLICY (info) Policy fallback defaultApplication is 
disabled
Fri Jun 10 07:41:42 2016 SERVER (info) Operational, 4 Threads Running

# qdstat -g
Segmentation fault
{noformat}

(core from {{qdstat -g}} on Fedora 23 is attached)

Dispatch is supposed to work even without the amqp line in {{/etc/services}}, 
because [qpid-dispatch/python/qpid_dispatch_internal/proton_future/__init__.py
|https://github.com/apache/qpid-dispatch/blob/2b1d8f67f3ad5dd25edaf8fc71117988a14e102d/python/qpid_dispatch_internal/proton_future/__init__.py#L3782]
 contains this function, which should be called to take care of the problem.

{code}
@staticmethod
def _port_int(value):
  """Convert service, an integer or a service name, into an integer port 
number."""
  try:
return int(value)
  except ValueError:
try:
  return socket.getservbyname(value)
except socket.error:
  # Not every system has amqp/amqps defined 

[jira] [Updated] (DISPATCH-184) dispatch do not stop when 'amqp' is not defined

[Jiri Danek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiri Danek updated DISPATCH-184:

Attachment: python_qdstat-g_fc23.stacktrace

Issue is still present. If I delete my amqp lines from {{/etc/services}}, then 
with the default config this happens:

{noformat}
mv /etc/services /etc/services_
qdrouterd &
Fri Jun 10 07:41:42 2016 SERVER (info) Container Name: Router.A
Fri Jun 10 07:41:42 2016 ROUTER (info) Router started in Standalone mode
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) Router Core thread running. 
0/Router.A
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
M/$management
Fri Jun 10 07:41:42 2016 AGENT (info) Activating management agent on 
$_management_internal
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$management
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$_management_internal
Fri Jun 10 07:41:42 2016 DISPLAYNAME (info) Activating DisplayNameService on 
$displayname
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription 
L/$displayname
Fri Jun 10 07:41:42 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp 
proto=any role=normal
Fri Jun 10 07:41:42 2016 DRIVER (error) getaddrinfo(0.0.0.0, amqp): Servname 
not supported for ai_socktype
Fri Jun 10 07:41:42 2016 POLICY (info) Policy configured maximumConnections: 0, 
policyFolder: '', access rules enabled: 'false'
Fri Jun 10 07:41:42 2016 POLICY (info) Policy fallback defaultApplication is 
disabled
Fri Jun 10 07:41:42 2016 SERVER (info) Operational, 4 Threads Running

# qdstat -g
Segmentation fault
{noformat}

(core from {{qdstat -g}} on Fedora 23 is attached)

Dispatch is supposed to work even without the amqp line in {{/etc/services}}, 
because [qpid-dispatch/python/qpid_dispatch_internal/proton_future/__init__.py
|https://github.com/apache/qpid-dispatch/blob/2b1d8f67f3ad5dd25edaf8fc71117988a14e102d/python/qpid_dispatch_internal/proton_future/__init__.py#L3782]
 contains this function, which should be called to take care of the problem.

{code}
@staticmethod
def _port_int(value):
  """Convert service, an integer or a service name, into an integer port 
number."""
  try:
return int(value)
  except ValueError:
try:
  return socket.getservbyname(value)
except socket.error:
  # Not every system has amqp/amqps defined as a service
  if value == Url.AMQPS:  return 5671
  elif value == Url.AMQP: return 5672
  else:
raise ValueError("Not a valid port number or service name: '%s'" % 
value)
{code}

> dispatch do not stop when 'amqp' is not defined
> ---
>
> Key: DISPATCH-184
> URL: https://issues.apache.org/jira/browse/DISPATCH-184
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
> Environment: Gentoo linux, Linux falka 4.2.3-gentoo #1 SMP Thu Oct 8 
> 10:08:43 CEST 2015 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz 
> GenuineIntel GNU/Linux
> proton-c (latest from apache github a16c58a59c2a5504ecd556dd397b7d28cc68dbd4)
> dispatch (latest from apache github 8353ac674a7150a1bbfa63c912ad9689a492e84a)
> sys-devel/gcc-4.9.3
> dev-lang/python-2.7.10
>Reporter: Zdenek Kraus
>Priority: Minor
> Attachments: python_qdstat-g_fc23.stacktrace
>
>
> If there is no existent record of 'amqp' protocol being 5672/tcp in 
> /etc/services, dispatch logs error messages and continue on.
> steps:
> 1. make sure that record 'amqp 5672/tcp' is not present at /etc/services
> 2. run qpid dispatch
> current results:
> Wed Oct 21 16:11:35 2015 DRIVER (error) getaddrinfo(0.0.0.0, amqp): Servname 
> not supported for ai_socktype
> and continue.
> expected:
> error message and should stop with error.
> note: this could be added into documentation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7298) [Java Broker] [0-8..0-91] Broker sends unsolicited ExchangeDeclareOk in response to declares of exchanges with reserved names

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7298.
--
Resolution: Fixed

> [Java Broker] [0-8..0-91] Broker sends unsolicited ExchangeDeclareOk in 
> response to declares of exchanges with reserved names 
> --
>
> Key: QPID-7298
> URL: https://issues.apache.org/jira/browse/QPID-7298
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.3
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1, qpid-java-6.0.4
>
>
> The Java Broker sends an unsolicited {{ExchangeDeclareOk}} response if the 
> client sends an exchange declare for a reserved exchange name with {{nowait}} 
> set true.  This behaviour violates the specification. 
> Problem is the absence of {{nowait}} check at 
> org/apache/qpid/server/protocol/v0_8/AMQChannel.java:2975 (within the 
> ReservedExchangeNameException catch block).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7298) [Java Broker] [0-8..0-91] Broker sends unsolicited ExchangeDeclareOk in response to declares of exchanges with reserved names

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15323981#comment-15323981
 ] 

Keith Wall commented on QPID-7298:
--

Changes look reasonable to me. Merged to 6.0.x.

> [Java Broker] [0-8..0-91] Broker sends unsolicited ExchangeDeclareOk in 
> response to declares of exchanges with reserved names 
> --
>
> Key: QPID-7298
> URL: https://issues.apache.org/jira/browse/QPID-7298
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.3
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1, qpid-java-6.0.4
>
>
> The Java Broker sends an unsolicited {{ExchangeDeclareOk}} response if the 
> client sends an exchange declare for a reserved exchange name with {{nowait}} 
> set true.  This behaviour violates the specification. 
> Problem is the absence of {{nowait}} check at 
> org/apache/qpid/server/protocol/v0_8/AMQChannel.java:2975 (within the 
> ReservedExchangeNameException catch block).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7298) [Java Broker] [0-8..0-91] Broker sends unsolicited ExchangeDeclareOk in response to declares of exchanges with reserved names

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15323979#comment-15323979
 ] 

ASF subversion and git services commented on QPID-7298:
---

Commit 1747643 from [~k-wall] in branch 'java/branches/6.0.x'
[ https://svn.apache.org/r1747643 ]

QPID-7298 : prevent exchange-declare-ok being sent when nowait=true

Merged from trunk with command:

svn merge -c 1747526 ^/qpid/java/trunk

> [Java Broker] [0-8..0-91] Broker sends unsolicited ExchangeDeclareOk in 
> response to declares of exchanges with reserved names 
> --
>
> Key: QPID-7298
> URL: https://issues.apache.org/jira/browse/QPID-7298
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.3
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1, qpid-java-6.0.4
>
>
> The Java Broker sends an unsolicited {{ExchangeDeclareOk}} response if the 
> client sends an exchange declare for a reserved exchange name with {{nowait}} 
> set true.  This behaviour violates the specification. 
> Problem is the absence of {{nowait}} check at 
> org/apache/qpid/server/protocol/v0_8/AMQChannel.java:2975 (within the 
> ReservedExchangeNameException catch block).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org