[jira] [Commented] (DISPATCH-386) Router crashes in qd_link_pn
[ https://issues.apache.org/jira/browse/DISPATCH-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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] [Updated] (DISPATCH-386) Router crashes in qd_link_pn
[ https://issues.apache.org/jira/browse/DISPATCH-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Leu updated DISPATCH-386: -- Attachment: trace > 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: 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
[ https://issues.apache.org/jira/browse/DISPATCH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ 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] [Resolved] (DISPATCH-389) Removing CONFIG and DISPATCH as modules for logging
[ https://issues.apache.org/jira/browse/DISPATCH-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-389. Resolution: Fixed Fix Version/s: 0.7.0 > 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
[ https://issues.apache.org/jira/browse/PROTON-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ https://issues.apache.org/jira/browse/PROTON-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ https://issues.apache.org/jira/browse/PROTON-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ 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
[ https://issues.apache.org/jira/browse/QPID-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/QPIDJMS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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.
[ 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 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
[ https://issues.apache.org/jira/browse/PROTON-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Created] (DISPATCH-388) Add deprecated flag to schema entities and attributes
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
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 /
[jira] [Commented] (DISPATCH-364) Inter-router listeners should not permit normal endpoint traffic
[ https://issues.apache.org/jira/browse/DISPATCH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 () f
[jira] [Resolved] (DISPATCH-387) Router core dumps with misbehaving client
[ 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 /lib64/lib
[jira] [Commented] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 > /home/lulf/git/qpid-dispatch/src/server.c:872
[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/QPID-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 /home/lulf/git/qpid
[jira] [Commented] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 0
[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client
[ 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 writable_
[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client
[ 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 /home/lulf/git
[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client
[ 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 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 /