[jira] [Commented] (DISPATCH-1181) handling MAU when local address is not yet defined can result in wrong treatment
[ https://issues.apache.org/jira/browse/DISPATCH-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682054#comment-16682054 ] ASF GitHub Bot commented on DISPATCH-1181: -- GitHub user grs opened a pull request: https://github.com/apache/qpid-dispatch/pull/418 DISPATCH-1181: add hint about treatment to MAU ...and use that on receipt if there is no locally defined treatment You can merge this pull request into a Git repository by running: $ git pull https://github.com/grs/qpid-dispatch mau-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/418.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 #418 commit 29abeccc911f7d06e3937203e9a605093a1e146f Author: Gordon Sim Date: 2018-11-09T22:43:10Z DISPATCH-1181: add hint about treatment to MAU and use that on receipt if there is no locally defined treatment > handling MAU when local address is not yet defined can result in wrong > treatment > > > Key: DISPATCH-1181 > URL: https://issues.apache.org/jira/browse/DISPATCH-1181 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > When dynamically configuring routers in a network, it is possible for an MAU > from one route rto reach another router for an address that the second router > has not yet had defined. At present this may cause the wrong treatment to be > applied to that address, which does not then get updated when the address > *is* defined. If the default distribution is unavailable then the MAU > handling exits without mapping the destination. > > E.g. > > start router 1 > define a multicast address on it > create receiver on that address & router > start router 2 > wait a bit before creating the same multicast address > create receiver on this router using the same address > send to the address on router 2 > > The address is treated as anycast (the default distribution). Using qdstat -a > the incorrect (or undesired) distribution can also be seen. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #418: DISPATCH-1181: add hint about treatment to ...
GitHub user grs opened a pull request: https://github.com/apache/qpid-dispatch/pull/418 DISPATCH-1181: add hint about treatment to MAU ...and use that on receipt if there is no locally defined treatment You can merge this pull request into a Git repository by running: $ git pull https://github.com/grs/qpid-dispatch mau-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/418.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 #418 commit 29abeccc911f7d06e3937203e9a605093a1e146f Author: Gordon Sim Date: 2018-11-09T22:43:10Z DISPATCH-1181: add hint about treatment to MAU and use that on receipt if there is no locally defined treatment --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1181) handling MAU when local address is not yet defined can result in wrong treatment
Gordon Sim created DISPATCH-1181: Summary: handling MAU when local address is not yet defined can result in wrong treatment Key: DISPATCH-1181 URL: https://issues.apache.org/jira/browse/DISPATCH-1181 Project: Qpid Dispatch Issue Type: Bug Reporter: Gordon Sim Assignee: Gordon Sim When dynamically configuring routers in a network, it is possible for an MAU from one route rto reach another router for an address that the second router has not yet had defined. At present this may cause the wrong treatment to be applied to that address, which does not then get updated when the address *is* defined. If the default distribution is unavailable then the MAU handling exits without mapping the destination. E.g. start router 1 define a multicast address on it create receiver on that address & router start router 2 wait a bit before creating the same multicast address create receiver on this router using the same address send to the address on router 2 The address is treated as anycast (the default distribution). Using qdstat -a the incorrect (or undesired) distribution can also be seen. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1179) Can't remote query edge router
[
https://issues.apache.org/jira/browse/DISPATCH-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681913#comment-16681913
]
Ernest Allen commented on DISPATCH-1179:
I can query the edge router from an internal router through rhea.js if I
construct the to address like /_edge//$management
I just can't do it through qdstat
> Can't remote query edge router
> --
>
> Key: DISPATCH-1179
> URL: https://issues.apache.org/jira/browse/DISPATCH-1179
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 1.5.0
>Reporter: Ernest Allen
>Priority: Major
>
> Unable to query an edge router from the interior router.
> qdstat's -r queries a router by id
> Running an interior router with 1 edge router, I'm unable to use qdstat on
> the interior router with -r to get any info from the edge
> router.
> The request times out with the message:
> Timeout: Connection amqp://0.0.0.0:22007/_topo/0/EDGE.1/$management timed
> out: Sending on sender
> 4944bd67-de97-437f-b31f-8f813cb1aa2e-_topo/0/EDGE.1/$management
> When I execute the qdstat request, the output for the edge router shows that
> a connection from the interior router was made, but there is no response.
> here is the command I tried:
> qdstat -b 0.0.0.0:22007 -g -r EDGE.1
> where the interior router has a listener on 22007 and the edge router has an
> ID of EDGE.1
> here are the conf files:
> Interior router ---
> router {
> mode: interior
> id: INT.B
> }
> listener {
> port: 22007
> stripAnnotations: no
> }
> listener {
> role: edge
> port: 22006 # edge_port_B
> }
> -
>
> edge router -
> router {
> mode: edge
> id: EDGE.1
> }
> listener {
> stripAnnotations: no
> port: 5674
> }
> connector {
> role: edge
> name: uplink
> port: 22006
> }
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1178) Allow unspecified router-id in configuration - select a random ID
[ https://issues.apache.org/jira/browse/DISPATCH-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681899#comment-16681899 ] ASF subversion and git services commented on DISPATCH-1178: --- Commit 2caa83f17e029c0bdc2d210d36d24bb2f344a569 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=2caa83f ] DISPATCH-1178 - If router-id is not specified, the router provides a randomly generated id. > Allow unspecified router-id in configuration - select a random ID > - > > Key: DISPATCH-1178 > URL: https://issues.apache.org/jira/browse/DISPATCH-1178 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.5.0 > > > With the introduction of edge router capability, it will be nice to remove > the requirement that every router must have an explicitly assigned unique ID. > With this improvement, a router that has no configured router-id shall > generate a random router-ID for use during its run. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1178) Allow unspecified router-id in configuration - select a random ID
[ https://issues.apache.org/jira/browse/DISPATCH-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1178. Resolution: Fixed > Allow unspecified router-id in configuration - select a random ID > - > > Key: DISPATCH-1178 > URL: https://issues.apache.org/jira/browse/DISPATCH-1178 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.5.0 > > > With the introduction of edge router capability, it will be nice to remove > the requirement that every router must have an explicitly assigned unique ID. > With this improvement, a router that has no configured router-id shall > generate a random router-ID for use during its run. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #417: NO-JIRA: Add a tool for post-processing val...
GitHub user kgiusti opened a pull request: https://github.com/apache/qpid-dispatch/pull/417 NO-JIRA: Add a tool for post-processing valgrind test results You can merge this pull request into a Git repository by running: $ git pull https://github.com/kgiusti/dispatch grinder Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/417.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 #417 commit 35b0fc9acabf473bdfd8fee03007c67d650b68db Author: Kenneth Giusti Date: 2018-11-09T15:59:45Z NO-JIRA: Add a tool for post-processing valgrind test results --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1959) [c,cpp] API additions to simplify reconnect
[ https://issues.apache.org/jira/browse/PROTON-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1959: --- Affects Version/s: (was: proton-c-0.25.0) proton-c-0.26.0 Fix Version/s: (was: proton-c-0.26.0) proton-c-0.27.0 Updating fix/affects versions. > [c,cpp] API additions to simplify reconnect > --- > > Key: PROTON-1959 > URL: https://issues.apache.org/jira/browse/PROTON-1959 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: proton-c-0.26.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.27.0 > > > Add some minor API extensions to make it easier to tell if a connection is > reconnecting, and to set up one-time events that only happen on the initial > connect. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8258) [Broker-J] Upgrade dojotoolkit to version 1.14
[ https://issues.apache.org/jira/browse/QPID-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8258: - Fix Version/s: qpid-java-broker-7.1.0 > [Broker-J] Upgrade dojotoolkit to version 1.14 > -- > > Key: QPID-8258 > URL: https://issues.apache.org/jira/browse/QPID-8258 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > A number of security vulnerabilities have been fixed in dojotoolkit 1.14: > * > [CVE-2018-6561|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6561] > dijit.Editor in Dojo Toolkit 1.13 allows XSS via the onload attribute > of an SVG element. > * > [CVE-2018-15494|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15494] > In Dojo Toolkit before 1.14, there is unescaped string injection in > dojox/Grid/DataGrid. > * > [CVE-2018-1000665|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000665]; > Dojo Dojo Objective Harness (DOH) version prior to version 1.14 contains a > Cross Site Scripting (XSS) vulnerability in unit.html and > testsDOH/_base/loader/i18n-exhaustive/i18n-test/unit.html and > testsDOH/_base/i18nExhaustive.js in the DOH that can result in Victim > attacked through their browser - deliver malware, steal HTTP cookies, bypass > CORS trust. This attack appear to be exploitable via Victims are typically > lured to a web site under the attacker's control; the XSS vulnerability on > the target domain is silently exploited without the victim's knowledge. This > vulnerability appears to have been fixed in 1.14. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1176) Router crash when connected to network that has > 400 edge routers
[ https://issues.apache.org/jira/browse/DISPATCH-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1176. - Resolution: Fixed Fix Version/s: 1.5.0 > Router crash when connected to network that has > 400 edge routers > -- > > Key: DISPATCH-1176 > URL: https://issues.apache.org/jira/browse/DISPATCH-1176 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.5.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.5.0 > > > Router that is connected to console crashes after refreshing page. > Steps: > * 2 router network: A and B > * connect console to router A > * connect several hundred edge routers to router B (> 400) > * refresh the console > I'm getting the following backtrace: > 2018-11-07 11:21:12.726892 -0500 SERVER (info) [35]: Connection from > 127.0.0.1 (to :5673) failed: amqp:connection:framing-error connection aborted > qdrouterd: > /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255: > qdr_deliver_continue_CT: Assertion `in_dlv->where == QDR_DELIVERY_IN_SETTLED' > failed. > Thread 2 "qdrouterd" received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffe3c9d700 (LWP 28359)] > 0x766b2f2b in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > compat-openssl10-1.0.2o-1.fc28.x86_64 > cyrus-sasl-gssapi-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-lib-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-md5-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-plain-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-scram-2.1.27-0.2rc7.fc28.x86_64 keyutils-libs-1.5.10-6.fc28.x86_64 > krb5-libs-1.16.1-2.fc28.x86_64 libcom_err-1.43.8-2.fc28.x86_64 > libdb-5.3.28-30.fc28.x86_64 libffi-3.1-16.fc28.x86_64 > libselinux-2.7-13.fc28.x86_64 libwebsockets-2.4.2-1.fc28.x86_64 > libxcrypt-4.0.1-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 > pcre2-10.31-4.fc28.x86_64 python2-libs-2.7.15-2.fc28.x86_64 > zlib-1.2.11-8.fc28.x86_64 > (gdb) bt > #0 0x766b2f2b in raise () from /lib64/libc.so.6 > #1 0x7669d561 in abort () from /lib64/libc.so.6 > #2 0x7669d431 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 > #3 0x766ab692 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b98e96 in qdr_deliver_continue_CT (core=0x9cc620, > action=0x7fffcc02b260, discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255 > #5 0x77b91341 in router_core_thread (arg=0x9cc620) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:116 > #6 0x774cc594 in start_thread () from /lib64/libpthread.so.0 > #7 0x7677600f in clone () from /lib64/libc.so.6 > > This doesn't happen every time you refresh the console with F5. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1176) Router crash when connected to network that has > 400 edge routers
[ https://issues.apache.org/jira/browse/DISPATCH-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681655#comment-16681655 ] ASF subversion and git services commented on DISPATCH-1176: --- Commit 6160a35dcb134bbcec9b15a1fdbf04458441d946 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6160a35 ] DISPATCH-1176 - Do not continue processing settled streaming deliveries when they have nowhere to go. If the settled delivery is not in any of the lists, dont process it This closes #416 This closes #415 > Router crash when connected to network that has > 400 edge routers > -- > > Key: DISPATCH-1176 > URL: https://issues.apache.org/jira/browse/DISPATCH-1176 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.5.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy >Priority: Major > > Router that is connected to console crashes after refreshing page. > Steps: > * 2 router network: A and B > * connect console to router A > * connect several hundred edge routers to router B (> 400) > * refresh the console > I'm getting the following backtrace: > 2018-11-07 11:21:12.726892 -0500 SERVER (info) [35]: Connection from > 127.0.0.1 (to :5673) failed: amqp:connection:framing-error connection aborted > qdrouterd: > /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255: > qdr_deliver_continue_CT: Assertion `in_dlv->where == QDR_DELIVERY_IN_SETTLED' > failed. > Thread 2 "qdrouterd" received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffe3c9d700 (LWP 28359)] > 0x766b2f2b in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > compat-openssl10-1.0.2o-1.fc28.x86_64 > cyrus-sasl-gssapi-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-lib-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-md5-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-plain-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-scram-2.1.27-0.2rc7.fc28.x86_64 keyutils-libs-1.5.10-6.fc28.x86_64 > krb5-libs-1.16.1-2.fc28.x86_64 libcom_err-1.43.8-2.fc28.x86_64 > libdb-5.3.28-30.fc28.x86_64 libffi-3.1-16.fc28.x86_64 > libselinux-2.7-13.fc28.x86_64 libwebsockets-2.4.2-1.fc28.x86_64 > libxcrypt-4.0.1-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 > pcre2-10.31-4.fc28.x86_64 python2-libs-2.7.15-2.fc28.x86_64 > zlib-1.2.11-8.fc28.x86_64 > (gdb) bt > #0 0x766b2f2b in raise () from /lib64/libc.so.6 > #1 0x7669d561 in abort () from /lib64/libc.so.6 > #2 0x7669d431 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 > #3 0x766ab692 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b98e96 in qdr_deliver_continue_CT (core=0x9cc620, > action=0x7fffcc02b260, discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255 > #5 0x77b91341 in router_core_thread (arg=0x9cc620) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:116 > #6 0x774cc594 in start_thread () from /lib64/libpthread.so.0 > #7 0x7677600f in clone () from /lib64/libc.so.6 > > This doesn't happen every time you refresh the console with F5. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1176) Router crash when connected to network that has > 400 edge routers
[ https://issues.apache.org/jira/browse/DISPATCH-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681638#comment-16681638 ] ASF GitHub Bot commented on DISPATCH-1176: -- GitHub user ganeshmurthy reopened a pull request: https://github.com/apache/qpid-dispatch/pull/416 DISPATCH-1176 - Do not continue processing settled streaming deliveri… …es when they have nowhere to go. If the settled delivery is not in any of the lists, dont process it You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1176 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/416.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 #416 commit f3d2de1b747b4d60210f72ee7b9da93db3c151e3 Author: Ganesh Murthy Date: 2018-11-08T18:34:38Z DISPATCH-1176 - Do not continue processing settled streaming deliveries when they have nowhere to go. If the settled delivery is not in any of the lists, dont process it > Router crash when connected to network that has > 400 edge routers > -- > > Key: DISPATCH-1176 > URL: https://issues.apache.org/jira/browse/DISPATCH-1176 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.5.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy >Priority: Major > > Router that is connected to console crashes after refreshing page. > Steps: > * 2 router network: A and B > * connect console to router A > * connect several hundred edge routers to router B (> 400) > * refresh the console > I'm getting the following backtrace: > 2018-11-07 11:21:12.726892 -0500 SERVER (info) [35]: Connection from > 127.0.0.1 (to :5673) failed: amqp:connection:framing-error connection aborted > qdrouterd: > /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255: > qdr_deliver_continue_CT: Assertion `in_dlv->where == QDR_DELIVERY_IN_SETTLED' > failed. > Thread 2 "qdrouterd" received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffe3c9d700 (LWP 28359)] > 0x766b2f2b in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > compat-openssl10-1.0.2o-1.fc28.x86_64 > cyrus-sasl-gssapi-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-lib-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-md5-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-plain-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-scram-2.1.27-0.2rc7.fc28.x86_64 keyutils-libs-1.5.10-6.fc28.x86_64 > krb5-libs-1.16.1-2.fc28.x86_64 libcom_err-1.43.8-2.fc28.x86_64 > libdb-5.3.28-30.fc28.x86_64 libffi-3.1-16.fc28.x86_64 > libselinux-2.7-13.fc28.x86_64 libwebsockets-2.4.2-1.fc28.x86_64 > libxcrypt-4.0.1-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 > pcre2-10.31-4.fc28.x86_64 python2-libs-2.7.15-2.fc28.x86_64 > zlib-1.2.11-8.fc28.x86_64 > (gdb) bt > #0 0x766b2f2b in raise () from /lib64/libc.so.6 > #1 0x7669d561 in abort () from /lib64/libc.so.6 > #2 0x7669d431 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 > #3 0x766ab692 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b98e96 in qdr_deliver_continue_CT (core=0x9cc620, > action=0x7fffcc02b260, discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255 > #5 0x77b91341 in router_core_thread (arg=0x9cc620) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:116 > #6 0x774cc594 in start_thread () from /lib64/libpthread.so.0 > #7 0x7677600f in clone () from /lib64/libc.so.6 > > This doesn't happen every time you refresh the console with F5. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1176) Router crash when connected to network that has > 400 edge routers
[ https://issues.apache.org/jira/browse/DISPATCH-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681657#comment-16681657 ] ASF GitHub Bot commented on DISPATCH-1176: -- Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/415 > Router crash when connected to network that has > 400 edge routers > -- > > Key: DISPATCH-1176 > URL: https://issues.apache.org/jira/browse/DISPATCH-1176 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.5.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy >Priority: Major > > Router that is connected to console crashes after refreshing page. > Steps: > * 2 router network: A and B > * connect console to router A > * connect several hundred edge routers to router B (> 400) > * refresh the console > I'm getting the following backtrace: > 2018-11-07 11:21:12.726892 -0500 SERVER (info) [35]: Connection from > 127.0.0.1 (to :5673) failed: amqp:connection:framing-error connection aborted > qdrouterd: > /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255: > qdr_deliver_continue_CT: Assertion `in_dlv->where == QDR_DELIVERY_IN_SETTLED' > failed. > Thread 2 "qdrouterd" received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffe3c9d700 (LWP 28359)] > 0x766b2f2b in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > compat-openssl10-1.0.2o-1.fc28.x86_64 > cyrus-sasl-gssapi-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-lib-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-md5-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-plain-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-scram-2.1.27-0.2rc7.fc28.x86_64 keyutils-libs-1.5.10-6.fc28.x86_64 > krb5-libs-1.16.1-2.fc28.x86_64 libcom_err-1.43.8-2.fc28.x86_64 > libdb-5.3.28-30.fc28.x86_64 libffi-3.1-16.fc28.x86_64 > libselinux-2.7-13.fc28.x86_64 libwebsockets-2.4.2-1.fc28.x86_64 > libxcrypt-4.0.1-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 > pcre2-10.31-4.fc28.x86_64 python2-libs-2.7.15-2.fc28.x86_64 > zlib-1.2.11-8.fc28.x86_64 > (gdb) bt > #0 0x766b2f2b in raise () from /lib64/libc.so.6 > #1 0x7669d561 in abort () from /lib64/libc.so.6 > #2 0x7669d431 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 > #3 0x766ab692 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b98e96 in qdr_deliver_continue_CT (core=0x9cc620, > action=0x7fffcc02b260, discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255 > #5 0x77b91341 in router_core_thread (arg=0x9cc620) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:116 > #6 0x774cc594 in start_thread () from /lib64/libpthread.so.0 > #7 0x7677600f in clone () from /lib64/libc.so.6 > > This doesn't happen every time you refresh the console with F5. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1176) Router crash when connected to network that has > 400 edge routers
[ https://issues.apache.org/jira/browse/DISPATCH-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681656#comment-16681656 ] ASF GitHub Bot commented on DISPATCH-1176: -- Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/416 > Router crash when connected to network that has > 400 edge routers > -- > > Key: DISPATCH-1176 > URL: https://issues.apache.org/jira/browse/DISPATCH-1176 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.5.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy >Priority: Major > > Router that is connected to console crashes after refreshing page. > Steps: > * 2 router network: A and B > * connect console to router A > * connect several hundred edge routers to router B (> 400) > * refresh the console > I'm getting the following backtrace: > 2018-11-07 11:21:12.726892 -0500 SERVER (info) [35]: Connection from > 127.0.0.1 (to :5673) failed: amqp:connection:framing-error connection aborted > qdrouterd: > /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255: > qdr_deliver_continue_CT: Assertion `in_dlv->where == QDR_DELIVERY_IN_SETTLED' > failed. > Thread 2 "qdrouterd" received signal SIGABRT, Aborted. > [Switching to Thread 0x7fffe3c9d700 (LWP 28359)] > 0x766b2f2b in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > compat-openssl10-1.0.2o-1.fc28.x86_64 > cyrus-sasl-gssapi-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-lib-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-md5-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-plain-2.1.27-0.2rc7.fc28.x86_64 > cyrus-sasl-scram-2.1.27-0.2rc7.fc28.x86_64 keyutils-libs-1.5.10-6.fc28.x86_64 > krb5-libs-1.16.1-2.fc28.x86_64 libcom_err-1.43.8-2.fc28.x86_64 > libdb-5.3.28-30.fc28.x86_64 libffi-3.1-16.fc28.x86_64 > libselinux-2.7-13.fc28.x86_64 libwebsockets-2.4.2-1.fc28.x86_64 > libxcrypt-4.0.1-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64 > pcre2-10.31-4.fc28.x86_64 python2-libs-2.7.15-2.fc28.x86_64 > zlib-1.2.11-8.fc28.x86_64 > (gdb) bt > #0 0x766b2f2b in raise () from /lib64/libc.so.6 > #1 0x7669d561 in abort () from /lib64/libc.so.6 > #2 0x7669d431 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 > #3 0x766ab692 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b98e96 in qdr_deliver_continue_CT (core=0x9cc620, > action=0x7fffcc02b260, discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255 > #5 0x77b91341 in router_core_thread (arg=0x9cc620) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:116 > #6 0x774cc594 in start_thread () from /lib64/libpthread.so.0 > #7 0x7677600f in clone () from /lib64/libc.so.6 > > This doesn't happen every time you refresh the console with F5. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #415: DISPATCH-1176 Prevent uninitialized deliver...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/415 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #416: DISPATCH-1176 - Do not continue processing ...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/416 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #416: DISPATCH-1176 - Do not continue processing ...
GitHub user ganeshmurthy reopened a pull request: https://github.com/apache/qpid-dispatch/pull/416 DISPATCH-1176 - Do not continue processing settled streaming deliveri⦠â¦es when they have nowhere to go. If the settled delivery is not in any of the lists, dont process it You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1176 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/416.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 #416 commit f3d2de1b747b4d60210f72ee7b9da93db3c151e3 Author: Ganesh Murthy Date: 2018-11-08T18:34:38Z DISPATCH-1176 - Do not continue processing settled streaming deliveries when they have nowhere to go. If the settled delivery is not in any of the lists, dont process it --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1180) Console's traffic animation incorrectly shows traffic from an edge router
Ernest Allen created DISPATCH-1180: -- Summary: Console's traffic animation incorrectly shows traffic from an edge router Key: DISPATCH-1180 URL: https://issues.apache.org/jira/browse/DISPATCH-1180 Project: Qpid Dispatch Issue Type: Bug Components: Console Reporter: Ernest Allen Assignee: Ernest Allen When an edge router is connected, message traffic coming from a normal sender appears to come from the edge router on the topology page's 'show traffic' animation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1179) Can't remote query edge router
Ernest Allen created DISPATCH-1179:
--
Summary: Can't remote query edge router
Key: DISPATCH-1179
URL: https://issues.apache.org/jira/browse/DISPATCH-1179
Project: Qpid Dispatch
Issue Type: Bug
Components: Management Agent
Affects Versions: 1.5.0
Reporter: Ernest Allen
Unable to query an edge router from the interior router.
qdstat's -r queries a router by id
Running an interior router with 1 edge router, I'm unable to use qdstat on the
interior router with -r to get any info from the edge router.
The request times out with the message:
Timeout: Connection amqp://0.0.0.0:22007/_topo/0/EDGE.1/$management timed out:
Sending on sender
4944bd67-de97-437f-b31f-8f813cb1aa2e-_topo/0/EDGE.1/$management
When I execute the qdstat request, the output for the edge router shows that a
connection from the interior router was made, but there is no response.
here is the command I tried:
qdstat -b 0.0.0.0:22007 -g -r EDGE.1
where the interior router has a listener on 22007 and the edge router has an ID
of EDGE.1
here are the conf files:
Interior router ---
router {
mode: interior
id: INT.B
}
listener {
port: 22007
stripAnnotations: no
}
listener {
role: edge
port: 22006 # edge_port_B
}
-
edge router -
router {
mode: edge
id: EDGE.1
}
listener {
stripAnnotations: no
port: 5674
}
connector {
role: edge
name: uplink
port: 22006
}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8256) [Broker-J] Update Guava to version 27.0
[
https://issues.apache.org/jira/browse/QPID-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681489#comment-16681489
]
ASF subversion and git services commented on QPID-8256:
---
Commit bed50962f658c2894de3d7f1a2885c1ce8580cac in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=bed5096 ]
QPID-8256: [Broker-J] Update dependency references
> [Broker-J] Update Guava to version 27.0
> ---
>
> Key: QPID-8256
> URL: https://issues.apache.org/jira/browse/QPID-8256
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7,
> qpid-java-6.1.8
>
>
> The Qpid Broker depends on an older guava version 0.22 which is affected by
> vulnerability
> [CVE-2018-10237|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10237].
> It does not look like vulnerability
> [CVE-2018-10237|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10237]
> can be exploited with Qpid Broker, as impacted guava classes
> {{AtomicDoubleArray}} and {{CompoundOrdering}} are not used directly or
> indirectly within Qpid Broker code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1176) Router crash when connected to network that has > 400 edge routers
[
https://issues.apache.org/jira/browse/DISPATCH-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681301#comment-16681301
]
ASF GitHub Bot commented on DISPATCH-1176:
--
Github user ErnieAllen commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/415#discussion_r232223312
--- Diff: src/router_core/router_core_private.h ---
@@ -321,7 +321,8 @@ ALLOC_DECLARE(qdr_router_ref_t);
DEQ_DECLARE(qdr_router_ref_t, qdr_router_ref_list_t);
typedef enum {
-QDR_DELIVERY_NOWHERE = 0,
+QDR_DELIVERY_UNINITIALIZED = 0,
+QDR_DELIVERY_NOWHERE,
--- End diff --
New commit just uses QDR_DELIVERY_NOWHERE as the test in
transfer.c::qdr_deliver_continue_CT to reject the delivery.
> Router crash when connected to network that has > 400 edge routers
> --
>
> Key: DISPATCH-1176
> URL: https://issues.apache.org/jira/browse/DISPATCH-1176
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.5.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
>Priority: Major
>
> Router that is connected to console crashes after refreshing page.
> Steps:
> * 2 router network: A and B
> * connect console to router A
> * connect several hundred edge routers to router B (> 400)
> * refresh the console
> I'm getting the following backtrace:
> 2018-11-07 11:21:12.726892 -0500 SERVER (info) [35]: Connection from
> 127.0.0.1 (to :5673) failed: amqp:connection:framing-error connection aborted
> qdrouterd:
> /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255:
> qdr_deliver_continue_CT: Assertion `in_dlv->where == QDR_DELIVERY_IN_SETTLED'
> failed.
> Thread 2 "qdrouterd" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffe3c9d700 (LWP 28359)]
> 0x766b2f2b in raise () from /lib64/libc.so.6
> Missing separate debuginfos, use: dnf debuginfo-install
> compat-openssl10-1.0.2o-1.fc28.x86_64
> cyrus-sasl-gssapi-2.1.27-0.2rc7.fc28.x86_64
> cyrus-sasl-lib-2.1.27-0.2rc7.fc28.x86_64
> cyrus-sasl-md5-2.1.27-0.2rc7.fc28.x86_64
> cyrus-sasl-plain-2.1.27-0.2rc7.fc28.x86_64
> cyrus-sasl-scram-2.1.27-0.2rc7.fc28.x86_64 keyutils-libs-1.5.10-6.fc28.x86_64
> krb5-libs-1.16.1-2.fc28.x86_64 libcom_err-1.43.8-2.fc28.x86_64
> libdb-5.3.28-30.fc28.x86_64 libffi-3.1-16.fc28.x86_64
> libselinux-2.7-13.fc28.x86_64 libwebsockets-2.4.2-1.fc28.x86_64
> libxcrypt-4.0.1-1.fc28.x86_64 openssl-libs-1.1.0h-3.fc28.x86_64
> pcre2-10.31-4.fc28.x86_64 python2-libs-2.7.15-2.fc28.x86_64
> zlib-1.2.11-8.fc28.x86_64
> (gdb) bt
> #0 0x766b2f2b in raise () from /lib64/libc.so.6
> #1 0x7669d561 in abort () from /lib64/libc.so.6
> #2 0x7669d431 in __assert_fail_base.cold.0 () from /lib64/libc.so.6
> #3 0x766ab692 in __assert_fail () from /lib64/libc.so.6
> #4 0x77b98e96 in qdr_deliver_continue_CT (core=0x9cc620,
> action=0x7fffcc02b260, discard=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:1255
> #5 0x77b91341 in router_core_thread (arg=0x9cc620)
> at
> /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:116
> #6 0x774cc594 in start_thread () from /lib64/libpthread.so.0
> #7 0x7677600f in clone () from /lib64/libc.so.6
>
> This doesn't happen every time you refresh the console with F5.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #415: DISPATCH-1176 Prevent uninitialized deliver...
Github user ErnieAllen commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/415#discussion_r232223312
--- Diff: src/router_core/router_core_private.h ---
@@ -321,7 +321,8 @@ ALLOC_DECLARE(qdr_router_ref_t);
DEQ_DECLARE(qdr_router_ref_t, qdr_router_ref_list_t);
typedef enum {
-QDR_DELIVERY_NOWHERE = 0,
+QDR_DELIVERY_UNINITIALIZED = 0,
+QDR_DELIVERY_NOWHERE,
--- End diff --
New commit just uses QDR_DELIVERY_NOWHERE as the test in
transfer.c::qdr_deliver_continue_CT to reject the delivery.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-425) First heartbeat can be sent at greater interval than subsequent ones
[ https://issues.apache.org/jira/browse/QPIDJMS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681233#comment-16681233 ] Robbie Gemmell commented on QPIDJMS-425: Yes, ServiceBus seems to have its own specific higher-level interpretations of 'idle', beyond the connection itself and its heartbeats. > First heartbeat can be sent at greater interval than subsequent ones > > > Key: QPIDJMS-425 > URL: https://issues.apache.org/jira/browse/QPIDJMS-425 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: David De Franco >Priority: Minor > Attachments: heartbeat-12.log, heartbeat-15.log, > heartbeat-30.log, heartbeat-4.log, heartbeat-6.log > > > We use Qpid JMS for commucation with the Azure Service Bus. > In the Open frame from Azure the idleTimeout field has value 24. > Based on this we expect heartbeat frames are send by Qpid JMS every 2 minutes. > This is correct for the second heartbeat frame and the following frames. But > not for the first heartbeat frame. Which is sent later than after 2 minutes. > And it depends on the client idle timeout setting. The time after which the > first heartbeat frame is sent is for the following client idle timeout > settings: > 4 -> 2 minutes 40 seconds > 6 -> 3 minutes > 12 -> 4 minutes > 15 -> 4 minutes > 30 -> 4 minutes > Also see the attached log files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-425) First heartbeat can be sent at greater interval than subsequent ones
[ https://issues.apache.org/jira/browse/QPIDJMS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681220#comment-16681220 ] David De Franco commented on QPIDJMS-425: - ServiceBus has no issue with this. The heartbeat frames are in time. But ServiceBus doen not respond to the heartbeat frames. It closes the connection anyway after 5 minutes. I raised a service request for that at Microsoft. I reported this issue form my own expectations while analyzing the ServiceBus problem. > First heartbeat can be sent at greater interval than subsequent ones > > > Key: QPIDJMS-425 > URL: https://issues.apache.org/jira/browse/QPIDJMS-425 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: David De Franco >Priority: Minor > Attachments: heartbeat-12.log, heartbeat-15.log, > heartbeat-30.log, heartbeat-4.log, heartbeat-6.log > > > We use Qpid JMS for commucation with the Azure Service Bus. > In the Open frame from Azure the idleTimeout field has value 24. > Based on this we expect heartbeat frames are send by Qpid JMS every 2 minutes. > This is correct for the second heartbeat frame and the following frames. But > not for the first heartbeat frame. Which is sent later than after 2 minutes. > And it depends on the client idle timeout setting. The time after which the > first heartbeat frame is sent is for the following client idle timeout > settings: > 4 -> 2 minutes 40 seconds > 6 -> 3 minutes > 12 -> 4 minutes > 15 -> 4 minutes > 30 -> 4 minutes > Also see the attached log files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8259) [Broker-J] Upgrade Jetty to version 9.4.12.v20180830
Alex Rudyy created QPID-8259: Summary: [Broker-J] Upgrade Jetty to version 9.4.12.v20180830 Key: QPID-8259 URL: https://issues.apache.org/jira/browse/QPID-8259 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Alex Rudyy Fix For: qpid-java-broker-7.1.0 A number of security vulnerabilities have been reported against version in use. See [https://www.eclipse.org/jetty/documentation/9.4.x/security-reports.html] ||/mm/dd|| ID ||Exploitable|| Severity|| Affects|| Fixed Version|| Comment|| |2018/06/25|CVE-2018-12538|High|High|>= 9.4.0, < = 9.4.8|9.4.9|HttpSessions present specifically in the FileSystem’s storage could be hijacked/accessed by an unauthorized user.| |2018/06/25|CVE-2018-12536|High|See CWE-202|< = 9.4.10|9.2.25, 9.3.24, 9.4.11|InvalidPathException Message reveals webapp system path.| |2018/06/25|CVE-2017-7658|See CWE-444|See CWE-444|< = 9.4.10|9.2.25, 9.3.24, 9.4.11|Too Tolerant Parser, Double Content-Length + Transfer-Encoding + Whitespace.| |2018/06/25|CVE-2017-7657|See CWE-444|See CWE-444|< = 9.4.10|9.2.25, 9.3.24, 9.4.11|HTTP/1.1 Request smuggling with carefully crafted body content (Does not apply to HTTP/1.0 or HTTP/2).| |2018/06/25|CVE-2017-7656|See CWE-444|See CWE-444|< = 9.4.10|9.2.25, 9.3.24, 9.4.11|HTTP Request Smuggling when used with invalid request headers (for HTTP/0.9).| -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-425) First heartbeat can be sent at greater interval than subsequent ones
[ https://issues.apache.org/jira/browse/QPIDJMS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-425: --- Summary: First heartbeat can be sent at greater interval than subsequent ones (was: First heartbeat (Empty) frame is sent too late) > First heartbeat can be sent at greater interval than subsequent ones > > > Key: QPIDJMS-425 > URL: https://issues.apache.org/jira/browse/QPIDJMS-425 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: David De Franco >Priority: Minor > Attachments: heartbeat-12.log, heartbeat-15.log, > heartbeat-30.log, heartbeat-4.log, heartbeat-6.log > > > We use Qpid JMS for commucation with the Azure Service Bus. > In the Open frame from Azure the idleTimeout field has value 24. > Based on this we expect heartbeat frames are send by Qpid JMS every 2 minutes. > This is correct for the second heartbeat frame and the following frames. But > not for the first heartbeat frame. Which is sent later than after 2 minutes. > And it depends on the client idle timeout setting. The time after which the > first heartbeat frame is sent is for the following client idle timeout > settings: > 4 -> 2 minutes 40 seconds > 6 -> 3 minutes > 12 -> 4 minutes > 15 -> 4 minutes > 30 -> 4 minutes > Also see the attached log files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-425) First heartbeat (Empty) frame is sent too late
[ https://issues.apache.org/jira/browse/QPIDJMS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-425: --- Priority: Minor (was: Major) > First heartbeat (Empty) frame is sent too late > -- > > Key: QPIDJMS-425 > URL: https://issues.apache.org/jira/browse/QPIDJMS-425 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: David De Franco >Priority: Minor > Attachments: heartbeat-12.log, heartbeat-15.log, > heartbeat-30.log, heartbeat-4.log, heartbeat-6.log > > > We use Qpid JMS for commucation with the Azure Service Bus. > In the Open frame from Azure the idleTimeout field has value 24. > Based on this we expect heartbeat frames are send by Qpid JMS every 2 minutes. > This is correct for the second heartbeat frame and the following frames. But > not for the first heartbeat frame. Which is sent later than after 2 minutes. > And it depends on the client idle timeout setting. The time after which the > first heartbeat frame is sent is for the following client idle timeout > settings: > 4 -> 2 minutes 40 seconds > 6 -> 3 minutes > 12 -> 4 minutes > 15 -> 4 minutes > 30 -> 4 minutes > Also see the attached log files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-425) First heartbeat (Empty) frame is sent too late
[ https://issues.apache.org/jira/browse/QPIDJMS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681202#comment-16681202 ] Robbie Gemmell commented on QPIDJMS-425: ServiceBus advertising a 240sec idle-timeout in its Open frame actually means the client must send something in 240sec, not 120sec. The AMQP spec says peers SHOULD advertise half their actual timeout, so as to avoid spurious timeouts. The client (or rather, proton-j) typically pessimistically assumes they have not and so typically sends at half the advertised period, which is where the 120sec intervals come from. However, given its calculations, the way it works generally, and the way we use it, it seems that isnt happening on the first heartbeat and the actual point of it being sent is being influenced by both the actual time we need to send one (240sec here) as well as the point it is checking to see if one was received from the peer if needed. For consistency I think we should see if we can change this behaviour but it is not actually wrong as-is, just inconsistent with the later heartbeats. Does ServiceBus have an issue with this or are you just reporting from your own observations/expectations? If it did have an issue then I would actually say it should be changed, to advertise things like the AMQP spec recommends. > First heartbeat (Empty) frame is sent too late > -- > > Key: QPIDJMS-425 > URL: https://issues.apache.org/jira/browse/QPIDJMS-425 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.37.0 >Reporter: David De Franco >Priority: Major > Attachments: heartbeat-12.log, heartbeat-15.log, > heartbeat-30.log, heartbeat-4.log, heartbeat-6.log > > > We use Qpid JMS for commucation with the Azure Service Bus. > In the Open frame from Azure the idleTimeout field has value 24. > Based on this we expect heartbeat frames are send by Qpid JMS every 2 minutes. > This is correct for the second heartbeat frame and the following frames. But > not for the first heartbeat frame. Which is sent later than after 2 minutes. > And it depends on the client idle timeout setting. The time after which the > first heartbeat frame is sent is for the following client idle timeout > settings: > 4 -> 2 minutes 40 seconds > 6 -> 3 minutes > 12 -> 4 minutes > 15 -> 4 minutes > 30 -> 4 minutes > Also see the attached log files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
