[jira] [Commented] (DISPATCH-386) Router crashes in qd_link_pn

[Eric Leu (JIRA)]

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

Eric Leu commented on DISPATCH-386:
---

I was using ssl.While  running a different test, got another Segmentation 
fault in qd_link_pn.  Trace and core files are attached.   Please do $ cat 
core.gz-1 core.core.gz-2 core.gz-3 > core.gz

Then  unzip core.gz

We have 3 inter-connected routers: R1, R2, R3.  Senders and receivers connect 
to routers as follows:

A sender is defined as sender = Messenger().   
A receiver is defined as receiver = Messenger() in python.

addr
===
30 senders   -> R1 amqps://...R1/q1  (send to addr)
40 receivers -> R2 amqps://...R2/q1  (subscribe addr)

30 senders   -> R2 amqps://...R2/q2
40 receivers -> R3 amqps://...R3/q2

30 senders   -> R3amqps://...R3/q3
40 receivers -> R1amqps://...R1/q3

30 senders   -> R1 amqps://...R1/q4
40 receivers -> R2 amqps://...R2/q4

30 senders   -> R2 amqps://...R2/q5
40 receivers -> R3 amqps://...R3/q5

30 senders   -> R3amqps://...R3/q6
40 receivers -> R1amqps://...R1/q6

Each sender sends 100 messages.  For each message received, the receivers sends 
a reply back.


> Router crashes in qd_link_pn
> 
>
> Key: DISPATCH-386
> URL: https://issues.apache.org/jira/browse/DISPATCH-386
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> 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: Eric Leu
> Attachments: core.gz-1, core.gz-2, core.gz-3, trace
>
>
> Network: A network of 3 interior routers built using the latest trunk and 
> connected to each other using 2-way SSL, same as in DISPATCH-383.
> Run 3 pairs of senders and receivers on three different destination 
> addresses.  Each sender has 60 threads.  Each receiver has 60 threads.
> Seg fault happened with either of of the two traces:
> (1)
> Program received signal SIGSEGV, Segmentation fault.
> 0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> (gdb) bt
> #0  0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #1  0x77ad70cc in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #2  0x77acc906 in qdr_connection_process () from 
> /usr/local/lib/qpid-dispatch/libqpid-
> dispatch.so
> #3  0x77ab3b28 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #4  0x77adad55 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #5  0x77adb272 in qd_server_run () from 
> /usr/local/lib/qpid-dispatch/libqpid-
> dispatch.so
> #6  0x00401a47 in _start ()
> (2)
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x70d1f700 (LWP 27862)]
> 0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> (gdb) bt
> #0  0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #1  0x77ad71b3 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #2  0x77acc988 in qdr_connection_process () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #3  0x77ab3b28 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #4  0x77adad55 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #5  0x775d10a4 in start_thread (arg=0x70d1f700) at 
> pthread_create.c:309
> #6  0x7697587d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



--
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-386) Router crashes in qd_link_pn

[Eric Leu (JIRA)]

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

Eric Leu updated DISPATCH-386:
--
Attachment: core.gz-3
core.gz-2
core.gz-1

> Router crashes in qd_link_pn
> 
>
> Key: DISPATCH-386
> URL: https://issues.apache.org/jira/browse/DISPATCH-386
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> 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: Eric Leu
> Attachments: core.gz-1, core.gz-2, core.gz-3, trace
>
>
> Network: A network of 3 interior routers built using the latest trunk and 
> connected to each other using 2-way SSL, same as in DISPATCH-383.
> Run 3 pairs of senders and receivers on three different destination 
> addresses.  Each sender has 60 threads.  Each receiver has 60 threads.
> Seg fault happened with either of of the two traces:
> (1)
> Program received signal SIGSEGV, Segmentation fault.
> 0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> (gdb) bt
> #0  0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #1  0x77ad70cc in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #2  0x77acc906 in qdr_connection_process () from 
> /usr/local/lib/qpid-dispatch/libqpid-
> dispatch.so
> #3  0x77ab3b28 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #4  0x77adad55 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #5  0x77adb272 in qd_server_run () from 
> /usr/local/lib/qpid-dispatch/libqpid-
> dispatch.so
> #6  0x00401a47 in _start ()
> (2)
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x70d1f700 (LWP 27862)]
> 0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> (gdb) bt
> #0  0x77ab4ee0 in qd_link_pn () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #1  0x77ad71b3 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #2  0x77acc988 in qdr_connection_process () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #3  0x77ab3b28 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #4  0x77adad55 in ?? () from 
> /usr/local/lib/qpid-dispatch/libqpid-dispatch.so
> #5  0x775d10a4 in start_thread (arg=0x70d1f700) at 
> pthread_create.c:309
> #6  0x7697587d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



--
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-184) dispatch do not stop when 'amqp' is not defined

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-184:
-

GitHub user jdanekrh opened a pull request:

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

DISPATCH-184 - Resolve port name to int when applying configuration

Error in router is caused by a call to getaddrinfo() that uses the 'amqp' 
string for port In function qdpn_listener_t *qdpn_listener(qdpn_driver_t 
*driver, ...). Same call to getaddrinfo() also appears in qdpn_connector().

There ia a Python class Url.Port() that converts a string port to int and 
can handle missing /etc/services. Class used to be in dispatch in proton_future 
package, it was recently removed and now it is only in Proton.

As a solution, I had the following ideas:

1. Add a Port type to python/qpid_dispatch_internal/management/schema.py, 
do the conversion to int as part of validation.
2. Convert port to int in python/qpid_dispatch_internal/management/agent.py 
in ListenerEntity and ConnectorEntity, either in validate, create,  or init 
method.
3. Catch the error code in qdpn_listener and qdpn_connector and do a if 
strcmp(port, "amqp") ... there, Or call into Url.Port() in Python to avoid code 
duplication.

I decided to do a PR with the 2nd one.

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

$ git pull https://github.com/jdanekrh/qpid-dispatch DISPATCH-184

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

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


commit 1915320451d2dfc7ec410887585a09de41685a5c
Author: Jiri Danek 
Date:   2016-06-14T20:46:38Z

DISPATCH-184 - Resolve port name to int when applying configuration

Port can be specified either as a string, e.g. 'amqp', or a number. Some
systems do not have 'amqp' in /etc/services. On such systems, port has
to be resolved by dispatch itself.




> 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

[GitHub] qpid-dispatch pull request #82: DISPATCH-184 - Resolve port name to int when...

[jdanekrh]

GitHub user jdanekrh opened a pull request:

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

DISPATCH-184 - Resolve port name to int when applying configuration

Error in router is caused by a call to getaddrinfo() that uses the 'amqp' 
string for port In function qdpn_listener_t *qdpn_listener(qdpn_driver_t 
*driver, ...). Same call to getaddrinfo() also appears in qdpn_connector().

There ia a Python class Url.Port() that converts a string port to int and 
can handle missing /etc/services. Class used to be in dispatch in proton_future 
package, it was recently removed and now it is only in Proton.

As a solution, I had the following ideas:

1. Add a Port type to python/qpid_dispatch_internal/management/schema.py, 
do the conversion to int as part of validation.
2. Convert port to int in python/qpid_dispatch_internal/management/agent.py 
in ListenerEntity and ConnectorEntity, either in validate, create,  or init 
method.
3. Catch the error code in qdpn_listener and qdpn_connector and do a if 
strcmp(port, "amqp") ... there, Or call into Url.Port() in Python to avoid code 
duplication.

I decided to do a PR with the 2nd one.

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

$ git pull https://github.com/jdanekrh/qpid-dispatch DISPATCH-184

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

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


commit 1915320451d2dfc7ec410887585a09de41685a5c
Author: Jiri Danek 
Date:   2016-06-14T20:46:38Z

DISPATCH-184 - Resolve port name to int when applying configuration

Port can be specified either as a string, e.g. 'amqp', or a number. Some
systems do not have 'amqp' in /etc/services. On such systems, port has
to be resolved by dispatch itself.




---
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] [Assigned] (DISPATCH-389) Removing CONFIG and DISPATCH as modules for logging

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-389:
--

Assignee: Ganesh Murthy

> Removing CONFIG and DISPATCH as modules for logging
> ---
>
> Key: DISPATCH-389
> URL: https://issues.apache.org/jira/browse/DISPATCH-389
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 0.7.0
>
>
> The CONFIG and DISPATCH modules seem to be not used for logging so they 
> should be removed from schema and 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] [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=15330050#comment-15330050
 ] 

ASF GitHub Bot commented on PROTON-1224:


Github user gemmellr commented on the issue:

https://github.com/apache/qpid-proton/pull/75
  
I still need to have a final look, but if you could address the couple 
niggles I commented on that would be good. As I mentioned before, if you could 
also please remove merge commits from PRs that would be good, you have added a 
second in this version. Feel free to rebase the PR and squash all the commits, 
you don't need to open a new PR.


> 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

[GitHub] qpid-proton issue #75: PROTON-1224: Upgrade BouncyCastle

[gemmellr]

Github user gemmellr commented on the issue:

https://github.com/apache/qpid-proton/pull/75
  
I still need to have a final look, but if you could address the couple 
niggles I commented on that would be good. As I mentioned before, if you could 
also please remove merge commits from PRs that would be good, you have added a 
second in this version. Feel free to rebase the PR and squash all the commits, 
you don't need to open a new PR.


---
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] [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=15330041#comment-15330041
 ] 

ASF GitHub Bot commented on PROTON-1224:


Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/75#discussion_r67023365
  
--- Diff: 
proton-j/src/test/resources/org/apache/qpid/proton/engine/impl/ssl/cert.pem.txt 
---
@@ -0,0 +1,27 @@
+-BEGIN CERTIFICATE-
--- End diff --

Please provide instructions on exactly how to (re)create the SSL resources 
used for the tests, so they can be easily updated later as needed.

E.g like the existing proton SSL test resource details: 
https://github.com/apache/qpid-proton/blob/master/tests/python/proton_tests/ssl_db/README.txt
Or the qpid-jms SSL test resource details (which can be sourced and execute 
directly): 
https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/test/resources/README.txt


> 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

[GitHub] qpid-proton pull request #75: PROTON-1224: Upgrade BouncyCastle

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/75#discussion_r67023365
  
--- Diff: 
proton-j/src/test/resources/org/apache/qpid/proton/engine/impl/ssl/cert.pem.txt 
---
@@ -0,0 +1,27 @@
+-BEGIN CERTIFICATE-
--- End diff --

Please provide instructions on exactly how to (re)create the SSL resources 
used for the tests, so they can be easily updated later as needed.

E.g like the existing proton SSL test resource details: 
https://github.com/apache/qpid-proton/blob/master/tests/python/proton_tests/ssl_db/README.txt
Or the qpid-jms SSL test resource details (which can be sourced and execute 
directly): 
https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/test/resources/README.txt


---
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] [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=15330037#comment-15330037
 ] 

ASF GitHub Bot commented on PROTON-1224:


Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/75#discussion_r67023070
  
--- Diff: tests/pom.xml ---
@@ -99,7 +99,7 @@ mvn test \
 
   org.bouncycastle
   bcpkix-jdk15on
-  1.47
+  1.48
--- End diff --

Given the idea is to update it probably makes sense to go for the latest 
version rather than this 3+ year old version (same goes for the other instance).


> 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

[GitHub] qpid-proton pull request #75: PROTON-1224: Upgrade BouncyCastle

[gemmellr]

Github user gemmellr commented on a diff in the pull request:

https://github.com/apache/qpid-proton/pull/75#discussion_r67023070
  
--- Diff: tests/pom.xml ---
@@ -99,7 +99,7 @@ mvn test \
 
   org.bouncycastle
   bcpkix-jdk15on
-  1.47
+  1.48
--- End diff --

Given the idea is to update it probably makes sense to go for the latest 
version rather than this 3+ year old version (same goes for the other instance).


---
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-388) Add deprecated flag to schema entities and attributes

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-388.

   Resolution: Fixed
Fix Version/s: 0.7.0

> Add deprecated flag to schema entities and attributes
> -
>
> Key: DISPATCH-388
> URL: https://issues.apache.org/jira/browse/DISPATCH-388
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Management Agent
>Affects Versions: 0.6.1
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> Currently, when an attribute is deprecated, the only indication is the text 
> (DEPRECATED) prepended to the description. While the console can search for 
> that string, it would be better (less error prone) to have an actual 
> deprecated: true flag.
> The deprecated flag would only appear on attributes and entities that are 
> deprecated. That is, we don't need to put deprecated: false; the deprecated 
> flag only appears when it's value is true.
>  



--
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-6982) [Java Broker] Refactor VirtualHost to remove unnecessary methods

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-6982:
--

Minor comment: ACO should not refer to constant 
{{VirtualHost.DEFAULT_AWAIT_ATTAINMENT_TIMEOUT}}.  It should probably be 
looking up the context value from the object itself.  

> [Java Broker] Refactor VirtualHost to remove unnecessary methods
> 
>
> Key: QPID-6982
> URL: https://issues.apache.org/jira/browse/QPID-6982
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> There are a number of methods on VirtualHost that are unused or would be 
> better moved to other interfaces (e.g. removeQueue should removed and callers 
> should call a method on the queue object instead)



--
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-244) SASL library generates un-necessary DNS and LDAP requests

[Alan Conway (JIRA)]

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

Alan Conway commented on DISPATCH-244:
--

The unexpected DNS/LDAP traffic may be related to the SASL failures in 
PROTON-223. In both cases the problems are observed on a system with Kerberos 
authentication via VPN. Running an old qpid 0.34 client gives the following 
client-side error:

{code}
qpid-send: internal-error: Sasl error: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Server 
krbtgt/localdom...@redhat.com not found in Kerberos database) 
(/home/aconway/rh-qpid-0.34mc/qpid/cpp/src/qpid/SaslFactory.cpp:318)
{code}


> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.7.0
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when 
> connected to a VPN.
> -  about 10x slower on VPN configured to use TCP connection
> -  about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface. 
> `wallace` below is the local host name, but is not mentioned in any tests so 
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1   LDAP242 
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree 
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72  
> Standard query 0xd03f  A wallace.lab.bos.redhat.com
> {code}



--
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-244) SASL library generates un-necessary DNS and LDAP requests

[Alan Conway (JIRA)]

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

Alan Conway edited comment on DISPATCH-244 at 6/14/16 3:49 PM:
---

The unexpected DNS/LDAP traffic may be related to the SASL failures in 
DISPATCH-224. In both cases the problems are observed on a system with Kerberos 
authentication via VPN. Running an old qpid 0.34 client gives the following 
client-side error:

{code}
qpid-send: internal-error: Sasl error: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Server 
krbtgt/localdom...@redhat.com not found in Kerberos database) 
(/home/aconway/rh-qpid-0.34mc/qpid/cpp/src/qpid/SaslFactory.cpp:318)
{code}



was (Author: aconway):
The unexpected DNS/LDAP traffic may be related to the SASL failures in 
PROTON-224. In both cases the problems are observed on a system with Kerberos 
authentication via VPN. Running an old qpid 0.34 client gives the following 
client-side error:

{code}
qpid-send: internal-error: Sasl error: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Server 
krbtgt/localdom...@redhat.com not found in Kerberos database) 
(/home/aconway/rh-qpid-0.34mc/qpid/cpp/src/qpid/SaslFactory.cpp:318)
{code}


> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.7.0
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when 
> connected to a VPN.
> -  about 10x slower on VPN configured to use TCP connection
> -  about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface. 
> `wallace` below is the local host name, but is not mentioned in any tests so 
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1   LDAP242 
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree 
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72  
> Standard query 0xd03f  A wallace.lab.bos.redhat.com
> {code}



--
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-244) SASL library generates un-necessary DNS and LDAP requests

[Alan Conway (JIRA)]

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

Alan Conway edited comment on DISPATCH-244 at 6/14/16 3:46 PM:
---

The unexpected DNS/LDAP traffic may be related to the SASL failures in 
PROTON-224. In both cases the problems are observed on a system with Kerberos 
authentication via VPN. Running an old qpid 0.34 client gives the following 
client-side error:

{code}
qpid-send: internal-error: Sasl error: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Server 
krbtgt/localdom...@redhat.com not found in Kerberos database) 
(/home/aconway/rh-qpid-0.34mc/qpid/cpp/src/qpid/SaslFactory.cpp:318)
{code}



was (Author: aconway):
The unexpected DNS/LDAP traffic may be related to the SASL failures in 
PROTON-223. In both cases the problems are observed on a system with Kerberos 
authentication via VPN. Running an old qpid 0.34 client gives the following 
client-side error:

{code}
qpid-send: internal-error: Sasl error: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (Server 
krbtgt/localdom...@redhat.com not found in Kerberos database) 
(/home/aconway/rh-qpid-0.34mc/qpid/cpp/src/qpid/SaslFactory.cpp:318)
{code}


> SASL library generates un-necessary DNS and LDAP requests
> -
>
> Key: DISPATCH-244
> URL: https://issues.apache.org/jira/browse/DISPATCH-244
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 0.5
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.7.0
>
>
> The dispatch system tests (e.g. system_tests_management) run very slowly when 
> connected to a VPN.
> -  about 10x slower on VPN configured to use TCP connection
> -  about 5x slower on VPN configured for UDP connection
> Wireshark shows unexpected LDAP and DNS queries on the VPN interface. 
> `wallace` below is the local host name, but is not mentioned in any tests so 
> must be picked up by proton or dispatch at runtime:
> {code}
> 1 0.0 10.3.113.10810.11.6.1   LDAP242 
> searchRequest(11) "dc=redhat,dc=com" wholeSubtree 
> 2 0.035161000 10.3.113.10810.5.30.160 DNS 72  
> Standard query 0xd03f  A wallace.lab.bos.redhat.com
> {code}



--
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] (QPIDJMS-184) JMS Selector parsing will not fail if a valid selector is followed by invalid text

[Timothy Bish (JIRA)]

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

Timothy Bish commented on QPIDJMS-184:
--

Fixed in: 21baa2277ec55bcf37b67d0d2891bdb7e5481ce9

> JMS Selector parsing will not fail if a valid selector is followed by invalid 
> text
> --
>
> Key: QPIDJMS-184
> URL: https://issues.apache.org/jira/browse/QPIDJMS-184
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.9.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.10.0
>
>
> A JMS Selector which has a valid stem followed by invalid data will not cause 
> a failure, and the selector will be parsed an executed as if only the valid 
> stem were present.
> For example the selector
> {code}
> a = 1 AMD  b = 2
> {code}
> will be treated as if the selector was
> {code}
> a = 1
> {code}



--
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] (QPIDJMS-184) JMS Selector parsing will not fail if a valid selector is followed by invalid text

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-184.
--
Resolution: Fixed

> JMS Selector parsing will not fail if a valid selector is followed by invalid 
> text
> --
>
> Key: QPIDJMS-184
> URL: https://issues.apache.org/jira/browse/QPIDJMS-184
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 0.9.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.10.0
>
>
> A JMS Selector which has a valid stem followed by invalid data will not cause 
> a failure, and the selector will be parsed an executed as if only the valid 
> stem were present.
> For example the selector
> {code}
> a = 1 AMD  b = 2
> {code}
> will be treated as if the selector was
> {code}
> a = 1
> {code}



--
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] (QPIDJMS-184) JMS Selector parsing will not fail if a valid selector is followed by invalid text

[Timothy Bish (JIRA)]

Timothy Bish created QPIDJMS-184:


 Summary: JMS Selector parsing will not fail if a valid selector is 
followed by invalid text
 Key: QPIDJMS-184
 URL: https://issues.apache.org/jira/browse/QPIDJMS-184
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.9.0
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 0.10.0




A JMS Selector which has a valid stem followed by invalid data will not cause a 
failure, and the selector will be parsed an executed as if only the valid stem 
were present.

For example the selector

{code}
a = 1 AMD  b = 2
{code}

will be treated as if the selector was

{code}
a = 1
{code}



--
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-1216) c++: proton::coerce() should allow conversion from binary.

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1216.
-
Resolution: Fixed

> c++: proton::coerce() should allow conversion from binary.
> ---
>
> Key: PROTON-1216
> URL: https://issues.apache.org/jira/browse/PROTON-1216
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.12.2
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.13.0
>
>
> proton::coerce should convert a binary value to a std::string. 
> The documentation also needs clarification: coerce should allow exactly those 
> conversions that are allowed as implicit C++ conversions.
> Issue raised in excellent bug report on the user list 
> http://qpid.2158936.n2.nabble.com/Proton-C-0-13-x-decode-binary-type-tp7644510p7644747.html
>  text follows:
> proton::coerce (both forms) currently throws the same
> exception as proton::get, as does value.as_string(), although that doesn't
> appear to be in the public API. Not sure what 'd' was in the d>>b  example,
> but got a version working using value.get() and an implicit
> cast to std::string.
> To reproduce...
> #include 
> #include 
> #include 
> #include 
> template
> void expect_exception ( Lambda f )
> {
>   try
>   {
> f();
> std::cout << "*** FAIL (expected conversion error) ***" << std::endl;
>   }
>   catch ( const proton::conversion_error& e )
>   {
> std::cout << "PASS" << std::endl;
>   }
> }
> template
> void expect_value ( const std::string& expected, Lambda f )
> {
>   try
>   {
> std::cout << (f() == expected ? "PASS" : "*** FAIL (wrong value) ***")
> << std::endl;
>   }
>   catch ( const proton::conversion_error& e )
>   {
> std::cout << "*** FAIL (conversion error) ***" << std::endl;
>   }
> }
> int main()
> {
>   std::string expected = "Hello World!";
>   proton::value value = proton::binary(expected);
>   expect_exception(  [=] { return value.get();   
>  
> });
>   expect_exception(  [=] { return proton::get(value);
>  
> });
>   expect_exception(  [=] { std::string result;
> proton::get(value); return result; });
>   expect_value(expected, [=] () -> std::string { return
> value.get(); } );
>   // The following currently fail under 0.13.x
>   expect_value(expected, [=] { return value.as_string();  
>  
> });
>   expect_value(expected, [=] { return proton::coerce(value); 
>  
> });
>   expect_value(expected, [=] { std::string result;
> proton::coerce(value, result); return result; });
>   
> }



--
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-389) Removing CONFIG and DISPATCH as modules for logging

[Paolo Patierno (JIRA)]

Paolo Patierno created DISPATCH-389:
---

 Summary: Removing CONFIG and DISPATCH as modules for logging
 Key: DISPATCH-389
 URL: https://issues.apache.org/jira/browse/DISPATCH-389
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 0.6.0
Reporter: Paolo Patierno
Priority: Minor


The CONFIG and DISPATCH modules seem to be not used for logging so they should 
be removed from schema and 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] [Commented] (PROTON-1221) c++: new container interface lacks scheduled timer events

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1221:
-

API complete but the implementation does not yet support for multi-threaded 
containers and examples.

https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=ab54cb70601f96ed2b70fd17f6dd5ce1f273c207


PROTON-1221: c++ container::schedule() support.

container::schedule() with simple example of sending messages at a fixed 
interval.
Examples for C++03 and C++11.
Modified inject() to use the same proton::void_function0 as schedule for C++03.

Note: the example chains schedule() calls at a fixed interval. A precise
fixed-frequency sender should take account of the actual time to correct for
variations.


> c++: new container interface lacks scheduled timer events
> -
>
> Key: PROTON-1221
> URL: https://issues.apache.org/jira/browse/PROTON-1221
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> Scheduled timer events fell out of the new proton::container API and need to 
> be restored. Rather than adding timer functions to the messaging_handler 
> interface, container::schedule() will take a std::function (or C++03 functor 
> class) similar to event_loop::inject.



--
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-1221) c++: new container interface lacks scheduled timer events

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1221:

Description: Scheduled timer events fell out of the new proton::container 
API and need to be restored. Rather than adding timer functions to the 
messaging_handler interface, container::schedule() will take a std::function 
(or C++03 functor class) similar to event_loop::inject.  (was: Scheduled timer 
events fell out of the new proton::container API and need to be restored. 
Rather than adding timer functions to the messaging_handler interface, 
container::schedule() will take a std::function (or C++03 functor class) 
similar to event_loop::inject. Otherwise the API would be similar: returning a 
task object that can be ignored or used to cancel() the task.)

> c++: new container interface lacks scheduled timer events
> -
>
> Key: PROTON-1221
> URL: https://issues.apache.org/jira/browse/PROTON-1221
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> Scheduled timer events fell out of the new proton::container API and need to 
> be restored. Rather than adding timer functions to the messaging_handler 
> interface, container::schedule() will take a std::function (or C++03 functor 
> class) similar to event_loop::inject.



--
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-385) Router crashes when on-demand host is no longer reachable

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-385:


After starting the router I ran a qdmanage command to create the connector
{noformat}
qdmanage -b 127.0.0.1:20005 CREATE type=connector name=broker 
host=mrg30.lab.bos.redhat.com role=on-demand port=11000  
saslMechanisms=ANONYMOUS
{noformat}
I see the following 

{noformat}
Tue Jun 14 09:06:49 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
11000): No address associated with hostname
Tue Jun 14 09:06:59 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
11000): No address associated with hostname
Tue Jun 14 09:07:09 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
11000): No address associated with hostname


Tue Jun 14 09:16:19 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
11000): No address associated with hostname
Tue Jun 14 09:16:29 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
11000): No address associated with hostname
Tue Jun 14 09:16:39 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
11000): No address associated with hostname
{noformat}
After 10 minutes no crash yet.

Ernie, since you used your console to add the connector, I might have to do the 
same

> Router crashes when on-demand host is no longer reachable
> -
>
> Key: DISPATCH-385
> URL: https://issues.apache.org/jira/browse/DISPATCH-385
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf
>
>
> Router will crash if the host for an on-demand connector is unreachable.
> To reproduce:
> start the 6 router configs in qpid-dispatch/tests/config-6
> start a broker on a different box (I used a qpidd on port 11000  on mrg30)
> create an on-demand connector to the broker on one of the routers (I use Y)
> verify a connection to the broker has been automatically created and is open
> kill/block the communications to the broker (I stop my vpn, but there may be 
> better ways)
> after a few minutes, the router that the broker was connected to will crash
> here is the bt:
> #0  0x76b9ea28 in raise () from /lib64/libc.so.6
> #1  0x76ba062a in abort () from /lib64/libc.so.6
> #2  0x76b97227 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x76b972d2 in __assert_fail () from /lib64/libc.so.6
> #4  0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00)
> at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71
> #5  0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, 
> link=0x7fffe403a4c0, dlv=0x7fffe4072ec0)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132
> #6  0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, 
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, 
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405
> #7  0x77badd3a in qdr_forward_message_CT (core=0x9264d0, 
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, 
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707
> #8  0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, 
> discard=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581
> #9  0x77bb18ea in router_core_thread (arg=0x9264d0)
> at 
> /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71
> #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0
> #11 0x76c6c59d in clone () from /lib64/libc.so.6
> I'm using master qpid-proton 0.14.0-SNAPSHOT
> master qpid-dispatch 0.7.0
> Here is the routers debug output after the vpn was killed and just before the 
> crash
> Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed
> Mon Jun 13 11:35:10 2016 ROUTER 

[jira] [Created] (DISPATCH-388) Add deprecated flag to schema entities and attributes

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-388:
-

 Summary: Add deprecated flag to schema entities and attributes
 Key: DISPATCH-388
 URL: https://issues.apache.org/jira/browse/DISPATCH-388
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Management Agent
Affects Versions: 0.6.1
Reporter: Ernest Allen
Assignee: Ganesh Murthy


Currently, when an attribute is deprecated, the only indication is the text 
(DEPRECATED) prepended to the description. While the console can search for 
that string, it would be better (less error prone) to have an actual 
deprecated: true flag.

The deprecated flag would only appear on attributes and entities that are 
deprecated. That is, we don't need to put deprecated: false; the deprecated 
flag only appears when it's value is true.
 



--
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-387) Router core dumps with misbehaving client

[ASF subversion and git services (JIRA)]

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

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

Commit db4a04cfe48a2ef75c843c9f8ef094bc2213d637 in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=db4a04c ]

DISPATCH-387 - Remove the assumption that core links are always paired with 
qd-links in CORE_* calls.


> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
>Assignee: Ted Ross
> Fix For: 0.6.1
>
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> Using router built from master.
> Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address 
> amqp-test --ack-frequency 1 --messages 1  --report-total -f 
> --print-content false
> Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
> -d 1 -s 128
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway. The core dump can be found here: 
> http://lulf.no/stuff/qdrouterd_dispatch_387.core
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

[jira] [Commented] (DISPATCH-364) Inter-router listeners should not permit normal endpoint traffic

[ASF subversion and git services (JIRA)]

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

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

Commit d42d3ec20297ea3297d9d68b5fcf60fb1e3db531 in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=d42d3ec ]

DISPATCH-364 - Forbid normal link attaches from endpoints on inter-router 
listeners.


> Inter-router listeners should not permit normal endpoint traffic
> 
>
> Key: DISPATCH-364
> URL: https://issues.apache.org/jira/browse/DISPATCH-364
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6.1
>
>
> A router network can be configured such that normal clients connect to the 
> network using listeners designated with the inter-router role.  Since there 
> can be only a limited number of routers in a network (128 in 0.6.0), it 
> doesn't take many connected clients to clog up the inter-router connection 
> space.
> The router node should be modified such that normal links attaching over 
> inter-router connections are forbidden.



--
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-364) Inter-router listeners should not permit normal endpoint traffic

[ASF subversion and git services (JIRA)]

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

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

Commit 922bae16bbb2b0a7c83eeb1c7451998ff6218448 in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=922bae1 ]

DISPATCH-364 - Added a test to verify attach-failure on the inter-router 
listener.


> Inter-router listeners should not permit normal endpoint traffic
> 
>
> Key: DISPATCH-364
> URL: https://issues.apache.org/jira/browse/DISPATCH-364
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6.1
>
>
> A router network can be configured such that normal clients connect to the 
> network using listeners designated with the inter-router role.  Since there 
> can be only a limited number of routers in a network (128 in 0.6.0), it 
> doesn't take many connected clients to clog up the inter-router connection 
> space.
> The router node should be modified such that normal links attaching over 
> inter-router connections are forbidden.



--
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-366) When delivery fails the router sends the RELEASED disposition, not MODIFIED

[ASF subversion and git services (JIRA)]

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

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

Commit 6fc193c87d9575c55a8c27f602b18f11dfd194ed in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6fc193c ]

DISPATCH-366 - Use modified+delivery-failed for released messages whose 
deliveries are in doubt.


> When delivery fails the router sends the RELEASED disposition, not MODIFIED
> ---
>
> Key: DISPATCH-366
> URL: https://issues.apache.org/jira/browse/DISPATCH-366
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ken Giusti
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 0.6.1, 0.7.0
>
>
> The router does not properly distinguish between a delivery failure and 
> undeliverable.
> In the case of a delivery failure - where the router cannot ensure that the 
> message wasn't consumed - the router must send back the MODIFIED terminal 
> disposition with the delivery-failed flag set. This is necessary as the 
> sender must increment the message's delivery-count if it retransmits.
> In the case of an undeliverable message - where the router cannot forward a 
> message to the destination - the router must send back the RELEASED terminal 
> disposition.  RELEASED informs the sender that the message was not acted 
> upon.  The sender must not increment the message's delivery-count if it 
> retransmits.
> Currently the router uses RELEASED in both these cases.



--
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-341) router did not respond to request to drain a message-routed consumers link credit

[ASF subversion and git services (JIRA)]

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

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

Commit 789b73e2fdf72911182f194c60a8a89b05dd94ea in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=789b73e ]

DISPATCH-341 - Added two tests for message-routed drain.  Added timeouts for 
tests.


> router did not respond to request to drain a message-routed consumers link 
> credit
> -
>
> Key: DISPATCH-341
> URL: https://issues.apache.org/jira/browse/DISPATCH-341
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Qpid Dispatch 0.6.0 RC3
> Qpid JMS 0.10.0-SNAPSHOT
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 0.6.1
>
>
> With a router using the provided default config (updated only to set 
> saslMechanisms to ANONYMOUS), and attaching a sender and receiver (using the 
> JMS client Sender and Receiver examples) to the address "queue" (so 
> presumably using messge routing), it could be seen that Dispatch didn't 
> respond to requests to drain the receivers link.
> In one case, after receiving some messages, a 'drain requst' flow is issued, 
> but neither enough messages to use the credit (expected since no more were 
> sent) or a 'drain reponse' flow are received, just heartbeating back and 
> forth.
> {noformat}
> [1925974223:1] -> Disposition{role=RECEIVER, first=8, last=8, settled=true, 
> state=Accepted{}, batchable=false}
> [1925974223:1] -> Flow{nextIncomingId=9, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=9, 
> linkCredit=991, available=null, drain=true, echo=false, properties=null}
> [1925974223:0] -> Empty Frame
> [1925974223:0] -> Empty Frame
> [1925974223:0] <- Empty Frame
> {noformat}
> In another case, after flowing some credit but not receiving any messages, a 
> 'drain request' is issued, but neither enough messages to use the credit 
> (expected since none were sent) or a 'drain reponse' flow are received, just 
> heartbeating back and forth.
> {noformat}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0, 
> linkCredit=1000, available=null, drain=false, echo=false, properties=null}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0, 
> linkCredit=1000, available=null, drain=true, echo=false, properties=null}
> [2111953084:0] -> Empty Frame
> [2111953084:0] -> Empty Frame
> [2111953084:0] <- Empty Frame
> {noformat}



--
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-341) router did not respond to request to drain a message-routed consumers link credit

[ASF subversion and git services (JIRA)]

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

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

Commit 7a8aa51de4bf6da2a1a49f1d37774975869f8d54 in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7a8aa51 ]

DISPATCH-341 - Drain now propagates across link routes and behaves correctly 
for router-terminated links.


> router did not respond to request to drain a message-routed consumers link 
> credit
> -
>
> Key: DISPATCH-341
> URL: https://issues.apache.org/jira/browse/DISPATCH-341
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Qpid Dispatch 0.6.0 RC3
> Qpid JMS 0.10.0-SNAPSHOT
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 0.6.1
>
>
> With a router using the provided default config (updated only to set 
> saslMechanisms to ANONYMOUS), and attaching a sender and receiver (using the 
> JMS client Sender and Receiver examples) to the address "queue" (so 
> presumably using messge routing), it could be seen that Dispatch didn't 
> respond to requests to drain the receivers link.
> In one case, after receiving some messages, a 'drain requst' flow is issued, 
> but neither enough messages to use the credit (expected since no more were 
> sent) or a 'drain reponse' flow are received, just heartbeating back and 
> forth.
> {noformat}
> [1925974223:1] -> Disposition{role=RECEIVER, first=8, last=8, settled=true, 
> state=Accepted{}, batchable=false}
> [1925974223:1] -> Flow{nextIncomingId=9, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=9, 
> linkCredit=991, available=null, drain=true, echo=false, properties=null}
> [1925974223:0] -> Empty Frame
> [1925974223:0] -> Empty Frame
> [1925974223:0] <- Empty Frame
> {noformat}
> In another case, after flowing some credit but not receiving any messages, a 
> 'drain request' is issued, but neither enough messages to use the credit 
> (expected since none were sent) or a 'drain reponse' flow are received, just 
> heartbeating back and forth.
> {noformat}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0, 
> linkCredit=1000, available=null, drain=false, echo=false, properties=null}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0, 
> linkCredit=1000, available=null, drain=true, echo=false, properties=null}
> [2111953084:0] -> Empty Frame
> [2111953084:0] -> Empty Frame
> [2111953084:0] <- Empty Frame
> {noformat}



--
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-365) Standalone router crashes if an interior router attempts to connect to it

[ASF subversion and git services (JIRA)]

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

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

Commit a7ef32971f591fabf01ee81ef15125711bf24334 in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a7ef329 ]

DISPATCH-365 - Don't handle inter-router link detaches on non inter-router 
connections.


> Standalone router crashes if an interior router attempts to connect to it
> -
>
> Key: DISPATCH-365
> URL: https://issues.apache.org/jira/browse/DISPATCH-365
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Assignee: Ted Ross
>Priority: Critical
> Fix For: 0.6.1
>
> Attachments: config1_standalone.conf, config2_nossl.conf
>
>
> I accidentally pointed my interior router to a standalone router.  The 
> standalone router did not ignore the connection request and crashed.  The 
> attached config files reproduce the crash.



--
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-341) router did not respond to request to drain a message-routed consumers link credit

[ASF subversion and git services (JIRA)]

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

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

Commit 28a40255c7c10fec71d8742d410b8eff67168b99 in qpid-dispatch's branch 
refs/heads/0.6.x from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=28a4025 ]

DISPATCH-341 - From Ganesh Murthy - Added some drain tests


> router did not respond to request to drain a message-routed consumers link 
> credit
> -
>
> Key: DISPATCH-341
> URL: https://issues.apache.org/jira/browse/DISPATCH-341
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Qpid Dispatch 0.6.0 RC3
> Qpid JMS 0.10.0-SNAPSHOT
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 0.6.1
>
>
> With a router using the provided default config (updated only to set 
> saslMechanisms to ANONYMOUS), and attaching a sender and receiver (using the 
> JMS client Sender and Receiver examples) to the address "queue" (so 
> presumably using messge routing), it could be seen that Dispatch didn't 
> respond to requests to drain the receivers link.
> In one case, after receiving some messages, a 'drain requst' flow is issued, 
> but neither enough messages to use the credit (expected since no more were 
> sent) or a 'drain reponse' flow are received, just heartbeating back and 
> forth.
> {noformat}
> [1925974223:1] -> Disposition{role=RECEIVER, first=8, last=8, settled=true, 
> state=Accepted{}, batchable=false}
> [1925974223:1] -> Flow{nextIncomingId=9, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=9, 
> linkCredit=991, available=null, drain=true, echo=false, properties=null}
> [1925974223:0] -> Empty Frame
> [1925974223:0] -> Empty Frame
> [1925974223:0] <- Empty Frame
> {noformat}
> In another case, after flowing some credit but not receiving any messages, a 
> 'drain request' is issued, but neither enough messages to use the credit 
> (expected since none were sent) or a 'drain reponse' flow are received, just 
> heartbeating back and forth.
> {noformat}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0, 
> linkCredit=1000, available=null, drain=false, echo=false, properties=null}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047, 
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0, 
> linkCredit=1000, available=null, drain=true, echo=false, properties=null}
> [2111953084:0] -> Empty Frame
> [2111953084:0] -> Empty Frame
> [2111953084:0] <- Empty Frame
> {noformat}



--
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] [Closed] (DISPATCH-378) Seg Fault in CORE_link_push

[Ted Ross (JIRA)]

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

Ted Ross closed DISPATCH-378.
-
Resolution: Fixed

> 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
>Assignee: Ted Ross
>
> 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= out>, 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 () 

[jira] [Resolved] (DISPATCH-387) Router core dumps with misbehaving client

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-387.
---
Resolution: Fixed

The code in router_node.c made an incorrect assumption that core links are 
always paired with qd-links during calls from the core.  This is usually true 
but there's a case with lost links (when a session with active links is closed) 
where this is not true.

> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
>Assignee: Ted Ross
> Fix For: 0.6.1
>
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> Using router built from master.
> Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address 
> amqp-test --ack-frequency 1 --messages 1  --report-total -f 
> --print-content false
> Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
> -d 1 -s 128
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway. The core dump can be found here: 
> http://lulf.no/stuff/qdrouterd_dispatch_387.core
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
> #0  0x7fbf4ececb1d in poll () from 

[jira] [Commented] (DISPATCH-387) Router core dumps with misbehaving client

[ASF subversion and git services (JIRA)]

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

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

Commit ebee479ece7fdcf27625dffac9f9ab963f7cc195 in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ebee479 ]

DISPATCH-387 - Remove the assumption that core links are always paired with 
qd-links in CORE_* calls.


> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
>Assignee: Ted Ross
> Fix For: 0.6.1
>
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> Using router built from master.
> Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address 
> amqp-test --ack-frequency 1 --messages 1  --report-total -f 
> --print-content false
> Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
> -d 1 -s 128
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway. The core dump can be found here: 
> http://lulf.no/stuff/qdrouterd_dispatch_387.core
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable

[Ernest Allen (JIRA)]

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

Ernest Allen commented on DISPATCH-385:
---

Rather than create the connector in the config file at router start, can you 
try starting the router normally and then create the connector using qdmanage? 
I'm creating the connector after the router starts using the console.

> Router crashes when on-demand host is no longer reachable
> -
>
> Key: DISPATCH-385
> URL: https://issues.apache.org/jira/browse/DISPATCH-385
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf
>
>
> Router will crash if the host for an on-demand connector is unreachable.
> To reproduce:
> start the 6 router configs in qpid-dispatch/tests/config-6
> start a broker on a different box (I used a qpidd on port 11000  on mrg30)
> create an on-demand connector to the broker on one of the routers (I use Y)
> verify a connection to the broker has been automatically created and is open
> kill/block the communications to the broker (I stop my vpn, but there may be 
> better ways)
> after a few minutes, the router that the broker was connected to will crash
> here is the bt:
> #0  0x76b9ea28 in raise () from /lib64/libc.so.6
> #1  0x76ba062a in abort () from /lib64/libc.so.6
> #2  0x76b97227 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x76b972d2 in __assert_fail () from /lib64/libc.so.6
> #4  0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00)
> at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71
> #5  0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, 
> link=0x7fffe403a4c0, dlv=0x7fffe4072ec0)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132
> #6  0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, 
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, 
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405
> #7  0x77badd3a in qdr_forward_message_CT (core=0x9264d0, 
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, 
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707
> #8  0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, 
> discard=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581
> #9  0x77bb18ea in router_core_thread (arg=0x9264d0)
> at 
> /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71
> #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0
> #11 0x76c6c59d in clone () from /lib64/libc.so.6
> I'm using master qpid-proton 0.14.0-SNAPSHOT
> master qpid-dispatch 0.7.0
> Here is the routers debug output after the vpn was killed and just before the 
> crash
> Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode
> Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1
> qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: 
> sys_mutex_lock: Assertion `result == 0' failed.
> Program received signal SIGABRT, Aborted.



--
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-387) Router core dumps with misbehaving client

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-387:
--
Fix Version/s: 0.6.1

> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
>Assignee: Ted Ross
> Fix For: 0.6.1
>
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> Using router built from master.
> Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address 
> amqp-test --ack-frequency 1 --messages 1  --report-total -f 
> --print-content false
> Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
> -d 1 -s 128
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway. The core dump can be found here: 
> http://lulf.no/stuff/qdrouterd_dispatch_387.core
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
> #0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
> #1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397)
> at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964
> #2  0x7fbf4fc38249 in thread_run (arg=) at 
> 

[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable

[Ernest Allen (JIRA)]

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

Ernest Allen commented on DISPATCH-385:
---

No messages were being sent to the broker.

> Router crashes when on-demand host is no longer reachable
> -
>
> Key: DISPATCH-385
> URL: https://issues.apache.org/jira/browse/DISPATCH-385
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf
>
>
> Router will crash if the host for an on-demand connector is unreachable.
> To reproduce:
> start the 6 router configs in qpid-dispatch/tests/config-6
> start a broker on a different box (I used a qpidd on port 11000  on mrg30)
> create an on-demand connector to the broker on one of the routers (I use Y)
> verify a connection to the broker has been automatically created and is open
> kill/block the communications to the broker (I stop my vpn, but there may be 
> better ways)
> after a few minutes, the router that the broker was connected to will crash
> here is the bt:
> #0  0x76b9ea28 in raise () from /lib64/libc.so.6
> #1  0x76ba062a in abort () from /lib64/libc.so.6
> #2  0x76b97227 in __assert_fail_base () from /lib64/libc.so.6
> #3  0x76b972d2 in __assert_fail () from /lib64/libc.so.6
> #4  0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00)
> at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71
> #5  0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, 
> link=0x7fffe403a4c0, dlv=0x7fffe4072ec0)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132
> #6  0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, 
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, 
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405
> #7  0x77badd3a in qdr_forward_message_CT (core=0x9264d0, 
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, 
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707
> #8  0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, 
> discard=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581
> #9  0x77bb18ea in router_core_thread (arg=0x9264d0)
> at 
> /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71
> #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0
> #11 0x76c6c59d in clone () from /lib64/libc.so.6
> I'm using master qpid-proton 0.14.0-SNAPSHOT
> master qpid-dispatch 0.7.0
> Here is the routers debug output after the vpn was killed and just before the 
> crash
> Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode
> Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, 
> 11000): No address associated with hostname
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0
> Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1
> qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: 
> sys_mutex_lock: Assertion `result == 0' failed.
> Program received signal SIGABRT, Aborted.



--
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] (DISPATCH-387) Router core dumps with misbehaving client

[Ted Ross (JIRA)]

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

Ted Ross reassigned DISPATCH-387:
-

Assignee: Ted Ross

> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
>Assignee: Ted Ross
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> Using router built from master.
> Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address 
> amqp-test --ack-frequency 1 --messages 1  --report-total -f 
> --print-content false
> Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
> -d 1 -s 128
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway. The core dump can be found here: 
> http://lulf.no/stuff/qdrouterd_dispatch_387.core
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
> #0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
> #1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397)
> at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964
> #2  0x7fbf4fc38249 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:872
> #3  0x7fbf4f79961a 

[jira] [Resolved] (QPID-7124) [Java Broker] IndexOutOfBoundsException when attempting to create an object through the REST API with no path

[Keith Wall (JIRA)]

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

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

Lorenz and I paired on this task.

> [Java Broker] IndexOutOfBoundsException when attempting to create an object 
> through the REST API with no path
> -
>
> Key: QPID-7124
> URL: https://issues.apache.org/jira/browse/QPID-7124
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> * PUT: http://localhost:8080/api/latest/queue with body content \{ "name": 
> "newQueue" \} will result in an error (HTTP status 500 and a 
> java.lang.IndexOutOfBoundsException in the broker's logs).
> * PUT: http://localhost:8080/api/latest/queue/newQueue with body content \{\} 
> will result in an error, too (HTTP status 422 and errorMessage "Either parent 
> path or full object path must be specified on object creation. Full object 
> path must be specified on object update. Found [] of size 0 expecting 3")
> (See e-mail: 
> http://qpid.2158936.n2.nabble.com/potential-java-broker-REST-API-bug-tp7639681.html
>  )



--
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-7124) [Java Broker] IndexOutOfBoundsException when attempting to create an object through the REST API with no path

[Keith Wall (JIRA)]

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

Keith Wall reassigned QPID-7124:


Assignee: Keith Wall

> [Java Broker] IndexOutOfBoundsException when attempting to create an object 
> through the REST API with no path
> -
>
> Key: QPID-7124
> URL: https://issues.apache.org/jira/browse/QPID-7124
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> * PUT: http://localhost:8080/api/latest/queue with body content \{ "name": 
> "newQueue" \} will result in an error (HTTP status 500 and a 
> java.lang.IndexOutOfBoundsException in the broker's logs).
> * PUT: http://localhost:8080/api/latest/queue/newQueue with body content \{\} 
> will result in an error, too (HTTP status 422 and errorMessage "Either parent 
> path or full object path must be specified on object creation. Full object 
> path must be specified on object update. Found [] of size 0 expecting 3")
> (See e-mail: 
> http://qpid.2158936.n2.nabble.com/potential-java-broker-REST-API-bug-tp7639681.html
>  )



--
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-7124) [Java Broker] IndexOutOfBoundsException when attempting to create an object through the REST API with no path

[ASF subversion and git services (JIRA)]

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

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

Commit 1748386 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1748386 ]

QPID-7124: [Java Broker] Improve parsing of REST URLs

> [Java Broker] IndexOutOfBoundsException when attempting to create an object 
> through the REST API with no path
> -
>
> Key: QPID-7124
> URL: https://issues.apache.org/jira/browse/QPID-7124
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> * PUT: http://localhost:8080/api/latest/queue with body content \{ "name": 
> "newQueue" \} will result in an error (HTTP status 500 and a 
> java.lang.IndexOutOfBoundsException in the broker's logs).
> * PUT: http://localhost:8080/api/latest/queue/newQueue with body content \{\} 
> will result in an error, too (HTTP status 422 and errorMessage "Either parent 
> path or full object path must be specified on object creation. Full object 
> path must be specified on object update. Found [] of size 0 expecting 3")
> (See e-mail: 
> http://qpid.2158936.n2.nabble.com/potential-java-broker-REST-API-bug-tp7639681.html
>  )



--
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-387) Router core dumps with misbehaving client

[Ulf Lilleengen (JIRA)]

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

Ulf Lilleengen commented on DISPATCH-387:
-

Yes, it is reproducible, but only if I restrict the receiver with --messages 
1000 or some other number. It seems to crash when the receiver exits.

> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> Using router built from master.
> Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address 
> amqp-test --ack-frequency 1 --messages 1  --report-total -f 
> --print-content false
> Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
> -d 1 -s 128
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway. The core dump can be found here: 
> http://lulf.no/stuff/qdrouterd_dispatch_387.core
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
> #0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
> #1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397)
> at 

[jira] [Commented] (DISPATCH-387) Router core dumps with misbehaving client

[Gordon Sim (JIRA)]

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

Gordon Sim commented on DISPATCH-387:
-

Looks to be the same trace as 
https://issues.apache.org/jira/browse/DISPATCH-378. Are you able to reproduce 
this?

> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> Using router built from master.
> Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address 
> amqp-test --ack-frequency 1 --messages 1  --report-total -f 
> --print-content false
> Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
> -d 1 -s 128
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway. The core dump can be found here: 
> http://lulf.no/stuff/qdrouterd_dispatch_387.core
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
> #0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
> #1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397)
> at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964
> #2  

[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client

[Ulf Lilleengen (JIRA)]

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

Ulf Lilleengen updated DISPATCH-387:

Description: 
I have a simple setup with a router, a sender and a receiver. 

The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
my modifications that made the router crash here: 
https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender

Using router built from master.

Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address amqp-test 
--ack-frequency 1 --messages 1  --report-total -f --print-content false
Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 
-d 1 -s 128

The client might not behaving appropriately, so its entirely possible that I 
don't know what I'm doing! But I was thinking that the router should probably 
not crash due to misbehaving clients anyway. The core dump can be found here: 
http://lulf.no/stuff/qdrouterd_dispatch_387.core

(gdb) where
#0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
#1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
at /home/lulf/git/qpid-dispatch/src/router_node.c:808
#2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
#3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
container=0x1b7b510, conn=, 
qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353
#4  handler (handler_context=0x1b7b510, conn_context=, 
event=, qd_conn=0x7fbf3800e4f0)
at /home/lulf/git/qpid-dispatch/src/container.c:590
#5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
qd_server=0x1c17ef0)
at /home/lulf/git/qpid-dispatch/src/server.c:744
#6  thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:964
#7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

(gdb) thread apply all bt

Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1b939c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc38764 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:846
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1b939c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc38764 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:846
#3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
/home/lulf/git/qpid-dispatch/src/server.c:1371
#4  0x00401aa7 in main_process (
config_path=config_path@entry=0x7fffe5d8fdf0 
"../../qpid-examples/simple_direct.conf", 
python_pkgdir=python_pkgdir@entry=0x402420 
"../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
at /home/lulf/git/qpid-dispatch/router/src/main.c:145
#5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
/home/lulf/git/qpid-dispatch/router/src/main.c:345

Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1c637c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
#0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
#1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout=, timeout@entry=397)
at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964
#2  0x7fbf4fc38249 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:872
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)):
#0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
#1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
at /home/lulf/git/qpid-dispatch/src/router_node.c:808
#2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
#3  0x7fbf4fc19528 in 

[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client

[Ulf Lilleengen (JIRA)]

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

Ulf Lilleengen updated DISPATCH-387:

Description: 
I have a simple setup with a router, a sender and a receiver. 

The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
my modifications that made the router crash here: 
https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender

Using router built from master.

The client might not behaving appropriately, so its entirely possible that I 
don't know what I'm doing! But I was thinking that the router should probably 
not crash due to misbehaving clients anyway. The core dump can be found here: 
http://lulf.no/stuff/qdrouterd_dispatch_387.core

(gdb) where
#0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
#1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
at /home/lulf/git/qpid-dispatch/src/router_node.c:808
#2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
#3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
container=0x1b7b510, conn=, 
qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353
#4  handler (handler_context=0x1b7b510, conn_context=, 
event=, qd_conn=0x7fbf3800e4f0)
at /home/lulf/git/qpid-dispatch/src/container.c:590
#5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
qd_server=0x1c17ef0)
at /home/lulf/git/qpid-dispatch/src/server.c:744
#6  thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:964
#7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

(gdb) thread apply all bt

Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1b939c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc38764 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:846
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1b939c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc38764 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:846
#3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
/home/lulf/git/qpid-dispatch/src/server.c:1371
#4  0x00401aa7 in main_process (
config_path=config_path@entry=0x7fffe5d8fdf0 
"../../qpid-examples/simple_direct.conf", 
python_pkgdir=python_pkgdir@entry=0x402420 
"../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
at /home/lulf/git/qpid-dispatch/router/src/main.c:145
#5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
/home/lulf/git/qpid-dispatch/router/src/main.c:345

Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1c637c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
#0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
#1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout=, timeout@entry=397)
at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964
#2  0x7fbf4fc38249 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:872
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)):
#0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
#1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
at /home/lulf/git/qpid-dispatch/src/router_node.c:808
#2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
#3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
container=0x1b7b510, conn=, 
qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353
#4  handler (handler_context=0x1b7b510, conn_context=, 
event=, qd_conn=0x7fbf3800e4f0)
at 

[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client

[Ulf Lilleengen (JIRA)]

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

Ulf Lilleengen updated DISPATCH-387:

Attachment: simple_direct.conf

Router config

> Router core dumps with misbehaving client
> -
>
> Key: DISPATCH-387
> URL: https://issues.apache.org/jira/browse/DISPATCH-387
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Ulf Lilleengen
> Attachments: simple_direct.conf
>
>
> I have a simple setup with a router, a sender and a receiver. 
> The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
> modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
> my modifications that made the router crash here: 
> https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender
> The client might not behaving appropriately, so its entirely possible that I 
> don't know what I'm doing! But I was thinking that the router should probably 
> not crash due to misbehaving clients anyway.
> (gdb) where
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
> at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
> #3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
> container=0x1b7b510, conn=, 
> qd_conn=0x7fbf3800e4f0) at 
> /home/lulf/git/qpid-dispatch/src/container.c:353
> #4  handler (handler_context=0x1b7b510, conn_context=, 
> event=, qd_conn=0x7fbf3800e4f0)
> at /home/lulf/git/qpid-dispatch/src/container.c:590
> #5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
> qd_server=0x1c17ef0)
> at /home/lulf/git/qpid-dispatch/src/server.c:744
> #6  thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:964
> #7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1b939c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc38764 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:846
> #3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
> /home/lulf/git/qpid-dispatch/src/server.c:1371
> #4  0x00401aa7 in main_process (
> config_path=config_path@entry=0x7fffe5d8fdf0 
> "../../qpid-examples/simple_direct.conf", 
> python_pkgdir=python_pkgdir@entry=0x402420 
> "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
> at /home/lulf/git/qpid-dispatch/router/src/main.c:145
> #5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
> /home/lulf/git/qpid-dispatch/router/src/main.c:345
> Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
> #0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /lib64/libpthread.so.0
> #1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
> held_mutex=0x1c637c0)
> at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
> #2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
> at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
> #0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
> #1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397)
> at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964
> #2  0x7fbf4fc38249 in thread_run (arg=) at 
> /home/lulf/git/qpid-dispatch/src/server.c:872
> #3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
> #4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6
> Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)):
> #0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
> #1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
> at /home/lulf/git/qpid-dispatch/src/router_node.c:808
> #2 

[jira] [Created] (DISPATCH-387) Router core dumps with misbehaving client

[Ulf Lilleengen (JIRA)]

Ulf Lilleengen created DISPATCH-387:
---

 Summary: Router core dumps with misbehaving client
 Key: DISPATCH-387
 URL: https://issues.apache.org/jira/browse/DISPATCH-387
 Project: Qpid Dispatch
  Issue Type: Bug
Reporter: Ulf Lilleengen


I have a simple setup with a router, a sender and a receiver. 

The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a 
modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed 
my modifications that made the router crash here: 
https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender

The client might not behaving appropriately, so its entirely possible that I 
don't know what I'm doing! But I was thinking that the router should probably 
not crash due to misbehaving clients anyway.

(gdb) where
#0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
#1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
at /home/lulf/git/qpid-dispatch/src/router_node.c:808
#2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
#3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
container=0x1b7b510, conn=, 
qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353
#4  handler (handler_context=0x1b7b510, conn_context=, 
event=, qd_conn=0x7fbf3800e4f0)
at /home/lulf/git/qpid-dispatch/src/container.c:590
#5  0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, 
qd_server=0x1c17ef0)
at /home/lulf/git/qpid-dispatch/src/server.c:744
#6  thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:964
#7  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#8  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

(gdb) thread apply all bt

Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1b939c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc38764 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:846
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7fbf50041180 (LWP 13314)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1b939c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc38764 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:846
#3  0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at 
/home/lulf/git/qpid-dispatch/src/server.c:1371
#4  0x00401aa7 in main_process (
config_path=config_path@entry=0x7fffe5d8fdf0 
"../../qpid-examples/simple_direct.conf", 
python_pkgdir=python_pkgdir@entry=0x402420 
"../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2)
at /home/lulf/git/qpid-dispatch/router/src/main.c:145
#5  0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at 
/home/lulf/git/qpid-dispatch/router/src/main.c:345

Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)):
#0  0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
#1  0x7fbf4fc24c8f in sys_cond_wait (cond=, 
held_mutex=0x1c637c0)
at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107
#2  0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490)
at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)):
#0  0x7fbf4ececb1d in poll () from /lib64/libc.so.6
#1  0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout=, timeout@entry=397)
at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964
#2  0x7fbf4fc38249 in thread_run (arg=) at 
/home/lulf/git/qpid-dispatch/src/server.c:872
#3  0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0
#4  0x7fbf4ecf859d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fbf40fbf700 (LWP 13318)):
#0  qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862
#1  0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80)
at /home/lulf/git/qpid-dispatch/src/router_node.c:808
#2  0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0)
at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175
#3  0x7fbf4fc19528 in writable_handler (container=0x1b7b510, 
container=0x1b7b510, conn=, 
qd_conn=0x7fbf3800e4f0) at /home/lulf/git/qpid-dispatch/src/container.c:353
#4  handler (handler_context=0x1b7b510, conn_context=, 
event=, qd_conn=0x7fbf3800e4f0)
at