[jira] [Commented] (PROTON-1514) [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled
[
https://issues.apache.org/jira/browse/PROTON-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16469646#comment-16469646
]
ASF subversion and git services commented on PROTON-1514:
-
Commit 2dda72c703e1a2bffac1bbcd509205e5645c77d9 in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2dda72c ]
PROTON-1514: check for settled flag on all frames of multi-frame transfer;
enforce sole legal transition is settled to unsettled.
The previous revert at 6e15ddc was a false alarm.
> [proton-c] When last frame of multi-frame transfer has settled=true, Proton
> still considers delivery as unsettled
> -
>
> Key: PROTON-1514
> URL: https://issues.apache.org/jira/browse/PROTON-1514
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.17.0
>Reporter: Ganesh Murthy
>Assignee: Cliff Jansen
>Priority: Major
> Labels: framing
> Fix For: proton-c-0.23.0
>
>
> I have a situation where a receiver (proton python's simple_recv.py) is
> receiving a multi-frame transfer from a Dispatch Router. The settled flag is
> false on all the transfer frames except on the last frame which has
> settled=true as seen here -
> {noformat}
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (16351) "g here33227Long string here33228Long
> string here33229Long string here33230Long string here33231Long string
> here33232Long string here33233Long string here33234Long string here33235Long
> string here33236Long string here33237Long string here33238Long string
> here33239Long string here33240Long string here33241Long string here33242Long
> string here33243Long string here33244Long string here33245Long string
> here33246Long string here33247Long string here33248Long string here33249Long
> string here33250Long string here33251Long string here33252Long string
> here33253Long string here33254Long string here33255Long string here33256Long
> string here33257Long string here33258Long string here33259Long string
> here33260Long string here33261Long string here33262Long string here33263Long
> string here33264Long string here33265Long string here33266Long string
> here33267Long string here33268Long string here33269Long string here33270Long
> string here33271Long string here33272Long string here33273Long string
> here33274Long string here33275Lon"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (49053) "ng string here34006Long string
> here34007Long string here34008Long string here34009Long string here34010Long
> string here34011Long string here34012Long string here34013Long string
> here34014Long string here34015Long string here34016Long string here34017Long
> string here34018Long string here34019Long string here34020Long string
> here34021Long string here34022Long string here34023Long string here34024Long
> string here34025Long string here34026Long string here34027Long string
> here34028Long string here34029Long string here34030Long string here34031Long
> string here34032Long string here34033Long string here34034Long string
> here34035Long string here34036Long string here34037Long string here34038Long
> string here34039Long string here34040Long string here34041Long string
> here34042Long string here34043Long string here34044Long string here34045Long
> string here34046Long string here34047Long string here34048Long string
> here34049Long string here34050Long string here34051Long string here34052Long
> string here34053Long string here"... (truncated)
> [0x55aeecddb670]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=true] (98106) "1Long string here36342Long string
> here36343Long string here36344Long string here36345Long string here36346Long
> string here36347Long string here36348Long string here36349Long string
> here36350Long string here36351Long string here36352Long string here36353Long
> string here36354Long string here36355Long string here36356Long string
> here36357Long string here36358Long string here36359Long string here36360Long
> string here36361Long string here36362Long string here36363Long string
> here36364Long string here36365Long string here36366Long string here36367Long
> string here36368Long string here36369Long string here36370Long string
> here36371Long string here36372Long string here36373Long string here36374Long
> string here36375Long
[jira] [Updated] (DISPATCH-994) segfault in qdr_link_second_attach
[
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated DISPATCH-994:
Description:
Link routing from router A through router B to a 'broker', and closing and
opening two receivers causes a segfault.
{noformat}
==25674== Thread 4:
==25674== Invalid read of size 8
==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
==25674==by 0x4E8BF2B: handle (server.c:940)
==25674==by 0x4E8CBA7: thread_run (server.c:958)
==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==25674==
==25674==
==25674== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==25674== Access not within mapped region at address 0x10
==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
==25674==by 0x4E8BF2B: handle (server.c:940)
==25674==by 0x4E8CBA7: thread_run (server.c:958)
==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
==25674== If you believe this happened as a result of a stack
==25674== overflow in your program's main thread (unlikely but
==25674== possible), you can try to increase the size of the
==25674== main thread stack using the --main-stacksize= flag.
==25674== The main thread stack size used in this run was 8388608
{noformat}
To reproduce, start three routers with the attached config files, then run the
attached python test program.
was:
Link routing from router A through router B to a 'broker', and closing and
opening two receivers causes a segfault.
{noformat}
==25674== Thread 4:
==25674== Invalid read of size 8
==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
==25674==by 0x4E8BF2B: handle (server.c:940)
==25674==by 0x4E8CBA7: thread_run (server.c:958)
==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==25674==
==25674==
==25674== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==25674== Access not within mapped region at address 0x10
==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
==25674==by 0x4E8BF2B: handle (server.c:940)
==25674==by 0x4E8CBA7: thread_run (server.c:958)
==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
==25674== If you believe this happened as a result of a stack
==25674== overflow in your program's main thread (unlikely but
==25674== possible), you can try to increase the size of the
==25674== main thread stack using the --main-stacksize= flag.
==25674== The main thread stack size used in this run was 8388608
{noformat}
> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: router-a.conf, router-b.conf, router-c.conf,
> topic_test.py
>
>
> Link routing from router A through router B to a 'broker', and closing and
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674==
> ==25674==
> ==25674== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==25674== Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in
[jira] [Updated] (DISPATCH-994) segfault in qdr_link_second_attach
[
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated DISPATCH-994:
Attachment: topic_test.py
> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: router-a.conf, router-b.conf, router-c.conf,
> topic_test.py
>
>
> Link routing from router A through router B to a 'broker', and closing and
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674==
> ==25674==
> ==25674== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==25674== Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== If you believe this happened as a result of a stack
> ==25674== overflow in your program's main thread (unlikely but
> ==25674== possible), you can try to increase the size of the
> ==25674== main thread stack using the --main-stacksize= flag.
> ==25674== The main thread stack size used in this run was 8388608
> {noformat}
--
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] (DISPATCH-994) segfault in qdr_link_second_attach
[
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated DISPATCH-994:
Attachment: (was: 5673.conf)
> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: router-a.conf, router-b.conf, router-c.conf,
> topic_test.py
>
>
> Link routing from router A through router B to a 'broker', and closing and
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674==
> ==25674==
> ==25674== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==25674== Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== If you believe this happened as a result of a stack
> ==25674== overflow in your program's main thread (unlikely but
> ==25674== possible), you can try to increase the size of the
> ==25674== main thread stack using the --main-stacksize= flag.
> ==25674== The main thread stack size used in this run was 8388608
> {noformat}
--
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] (DISPATCH-994) segfault in qdr_link_second_attach
[
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated DISPATCH-994:
Attachment: router-c.conf
router-b.conf
router-a.conf
> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: router-a.conf, router-b.conf, router-c.conf,
> topic_test.py
>
>
> Link routing from router A through router B to a 'broker', and closing and
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674==
> ==25674==
> ==25674== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==25674== Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== If you believe this happened as a result of a stack
> ==25674== overflow in your program's main thread (unlikely but
> ==25674== possible), you can try to increase the size of the
> ==25674== main thread stack using the --main-stacksize= flag.
> ==25674== The main thread stack size used in this run was 8388608
> {noformat}
--
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] (DISPATCH-994) segfault in qdr_link_second_attach
[
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated DISPATCH-994:
Attachment: 5673.conf
> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: 5673.conf
>
>
> Link routing from router A through router B to a 'broker', and closing and
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674==
> ==25674==
> ==25674== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==25674== Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674== If you believe this happened as a result of a stack
> ==25674== overflow in your program's main thread (unlikely but
> ==25674== possible), you can try to increase the size of the
> ==25674== main thread stack using the --main-stacksize= flag.
> ==25674== The main thread stack size used in this run was 8388608
> {noformat}
--
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-994) segfault in qdr_link_second_attach
Gordon Sim created DISPATCH-994:
---
Summary: segfault in qdr_link_second_attach
Key: DISPATCH-994
URL: https://issues.apache.org/jira/browse/DISPATCH-994
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Gordon Sim
Attachments: 5673.conf
Link routing from router A through router B to a 'broker', and closing and
opening two receivers causes a segfault.
{noformat}
==25674== Thread 4:
==25674== Invalid read of size 8
==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
==25674==by 0x4E8BF2B: handle (server.c:940)
==25674==by 0x4E8CBA7: thread_run (server.c:958)
==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==25674==
==25674==
==25674== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==25674== Access not within mapped region at address 0x10
==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
==25674==by 0x4E8BF2B: handle (server.c:940)
==25674==by 0x4E8CBA7: thread_run (server.c:958)
==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
==25674== If you believe this happened as a result of a stack
==25674== overflow in your program's main thread (unlikely but
==25674== possible), you can try to increase the size of the
==25674== main thread stack using the --main-stacksize= flag.
==25674== The main thread stack size used in this run was 8388608
{noformat}
--
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-977) Document transaction support
[ https://issues.apache.org/jira/browse/DISPATCH-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16469453#comment-16469453 ] ASF GitHub Bot commented on DISPATCH-977: - Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/293 Looks good to me. I have created a simple scenario to validate the coordinator, as described in the doc, and it worked just fine. The final doc looks good as well. > Document transaction support > > > Key: DISPATCH-977 > URL: https://issues.apache.org/jira/browse/DISPATCH-977 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > Dispatch Router provides transaction support through link routes and > $coordinator. This capability should be documented. -- 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 issue #293: DISPATCH-977: Add transaction coordinator step to ...
Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/293 Looks good to me. I have created a simple scenario to validate the coordinator, as described in the doc, and it worked just fine. The final doc looks good as well. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-989. Resolution: Fixed > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-989: --- Issue Type: Bug (was: Task) > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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] (DISPATCH-981) link routing results in name collisions now that single session is used
[ https://issues.apache.org/jira/browse/DISPATCH-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-981: Description: If two links with the same name (but different container ids) are link routed to the same endpoint, attach attempts are made with the same name for both links on the same session which causes problems. (was: If two links are link routed to the same endpoint, attach attempts are made with the same name for both links on the same session which causes problems.) > link routing results in name collisions now that single session is used > --- > > Key: DISPATCH-981 > URL: https://issues.apache.org/jira/browse/DISPATCH-981 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: 1.1.0 > > > If two links with the same name (but different container ids) are link routed > to the same endpoint, attach attempts are made with the same name for both > links on the same session which causes problems. -- 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] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-989: --- Fix Version/s: 1.2.0 > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-989: --- Fix Version/s: (was: 1.2.0) > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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] (DISPATCH-993) Test system_tests_topology_disposition fails intermittently
[
https://issues.apache.org/jira/browse/DISPATCH-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke updated DISPATCH-993:
-
Summary: Test system_tests_topology_disposition fails intermittently (was:
Test system_tests_topology_distribution fails intermittently)
> Test system_tests_topology_disposition fails intermittently
> ---
>
> Key: DISPATCH-993
> URL: https://issues.apache.org/jira/browse/DISPATCH-993
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.1.0
>Reporter: Chuck Rolke
>Priority: Major
>
> Test: DeleteSpuriousConnector
> This test might run 20 times OK but it fails (for me!) eventually on today's
> master branch.
> For some reason instead of the messages being _received_ they are being
> _released_. This messes up the on_message n_received count so that it never
> reaches the magic 13 and therefore it never sends out the kill connector
> command.
> Here is a debug trace. Not that after 'receiving' 30 messages the n_received
> count only gets to 12.
> {quote}39:
> ==
> 39: FAIL: test_01_delete_spurious_connector
> (system_tests_topology_disposition.TopologyDispositionTests)
> 39: --
> 39: Traceback (most recent call last):
> 39: File
> "/home/chug/git/qpid-dispatch/tests/system_tests_topology_disposition.py",
> line 379, in test_01_delete_spurious_connector
> 39: self.assertEqual ( None, test.error )
> 39: AssertionError: None != 'No confirmed kill on connector.'
> 39:
> 39: --
> 39: Ran 2 tests in 10.250s
> 39:
> 39: FAILED (failures=1, skipped=1)
> 39: 1525876585.928072 on_link_opened
> 39: 1525876585.928256 on_link_opened
> 39: 1525876585.928463 on_link_opened
> 39: 1525876585.928535 on_link_opened
> 39: 1525876587.925026 timeout sender
> 39: 1525876587.925467 sent: 1
> 39: 1525876587.925707 sent: 2
> 39: 1525876587.925920 sent: 3
> 39: 1525876587.930813 on_released 1
> 39: 1525876587.932044 on_released 2
> 39: 1525876587.932671 on_released 3
> 39: 1525876588.424884 timeout sender
> 39: 1525876588.425253 sent: 4
> 39: 1525876588.425495 sent: 5
> 39: 1525876588.425698 sent: 6
> 39: 1525876588.432105 on_released 4
> 39: 1525876588.433035 on_released 5
> 39: 1525876588.433282 on_released 6
> 39: 1525876588.925559 timeout sender
> 39: 1525876588.925939 sent: 7
> 39: 1525876588.926234 sent: 8
> 39: 1525876588.926466 sent: 9
> 39: 1525876588.931285 on_released 7
> 39: 1525876588.931881 on_released 8
> 39: 1525876588.932027 on_released 9
> 39: 1525876589.426222 timeout sender
> 39: 1525876589.426562 sent: 10
> 39: 1525876589.426783 sent: 11
> 39: 1525876589.426976 sent: 12
> 39: 1525876589.432599 on_released 10
> 39: 1525876589.433407 on_released 11
> 39: 1525876589.433601 on_released 12
> 39: 1525876589.927745 timeout sender
> 39: 1525876589.927996 sent: 13
> 39: 1525876589.928149 sent: 14
> 39: 1525876589.928321 sent: 15
> 39: 1525876589.932239 on_released 13
> 39: 1525876589.932775 on_released 14
> 39: 1525876589.932907 on_released 15
> 39: 1525876590.427907 timeout sender
> 39: 1525876590.428106 sent: 16
> 39: 1525876590.428294 sent: 17
> 39: 1525876590.428404 sent: 18
> 39: 1525876590.431869 on_released 16
> 39: 1525876590.432348 on_released 17
> 39: 1525876590.432463 on_released 18
> 39: 1525876590.928454 timeout sender
> 39: 1525876590.928758 sent: 19
> 39: 1525876590.928955 sent: 20
> 39: 1525876590.929130 sent: 21
> 39: 1525876590.935306 received message 18
> 39: 1525876590.935326 n_received == 1
> 39: 1525876590.936363 received message 19
> 39: 1525876590.936381 n_received == 2
> 39: 1525876590.936989 received message 20
> 39: 1525876590.937010 n_received == 3
> 39: 1525876590.938963 on_accepted 1
> 39: 1525876590.940796 on_accepted 2
> 39: 1525876590.941263 on_accepted 3
> 39: 1525876591.429399 timeout sender
> 39: 1525876591.429752 sent: 22
> 39: 1525876591.429980 sent: 23
> 39: 1525876591.430198 sent: 24
> 39: 1525876591.438830 received message 21
> 39: 1525876591.438858 n_received == 4
> 39: 1525876591.439422 received message 22
> 39: 1525876591.439432 n_received == 5
> 39: 1525876591.440099 received message 23
> 39: 1525876591.440111 n_received == 6
> 39: 1525876591.442100 on_accepted 4
> 39: 1525876591.442532 on_accepted 5
> 39: 1525876591.442632 on_accepted 6
> 39: 1525876591.930557 timeout sender
> 39: 1525876591.930793 sent: 25
> 39: 1525876591.930934 sent: 26
> 39: 1525876591.931059 sent: 27
> 39: 1525876591.936629 received message 24
> 39: 1525876591.936649 n_received == 7
> 39: 1525876591.937648 received message 25
> 39: 1525876591.937665 n_received == 8
> 39: 1525876591.938337 received message 26
> 39:
[jira] [Updated] (QPID-8185) [JMS AMQP 0-x][AMQP 0-8..0-91] Make sure that client closes TCP connection on failure with sending connection.close
[
https://issues.apache.org/jira/browse/QPID-8185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8185:
-
Attachment: 0002-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Make-sure-that-.patch
0001-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Stop-handling-i.patch
> [JMS AMQP 0-x][AMQP 0-8..0-91] Make sure that client closes TCP connection on
> failure with sending connection.close
> ---
>
> Key: QPID-8185
> URL: https://issues.apache.org/jira/browse/QPID-8185
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, 0.18, 0.20, 0.22, 0.24, 0.26, 0.28,
> 0.30, 0.32, qpid-java-6.0.8, qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
> Attachments:
> 0001-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Stop-handling-i.patch,
> 0002-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Make-sure-that-.patch
>
>
> Sending connection.close as part of {{Connection#close}} can end-up in
> timeout exception. The underlying TCP connection remains open and Broker can
> continue sending data to the client when session close ends up in timeout as
> well. The incoming frames cannot be associated with the sessions, as the
> client removes session information on connection close. As result, a number
> of confusing exceptions is reported.
> Here are the examples of exception stack-traces reported for the issue
> {noformat}
> INFO Unsuspending channel threw an exception:
> [Thread-227][AMQSession.java:2374]
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely
> fashion
> at
> org.apache.qpid.client.util.BlockingWaiter.block(BlockingWaiter.java:170)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(BlockingMethodFrameListener.java:115)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:715)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:736)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:730)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession_0_8.sendSuspendChannel(AMQSession_0_8.java:728)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession.suspendChannel(AMQSession.java:3156)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession.startDispatcherIfNecessary(AMQSession.java:2370)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession.syncDispatchQueue(AMQSession.java:2223)
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQSession.rollback(AMQSession.java:1881)
> [qpid-client-0.32.jar:0.32]
> ERROR Error closing session: javax.jms.JMSException: Error closing session:
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely
> fashion [error code 408: Request
> Timeout][DefaultMessageListenerContainer-2][AMQConnection.java:1039]
> ERROR Error closing connection
>
> [DefaultMessageListenerContainer-2][AMQConnection.java:971]
> javax.jms.JMSException: Error closing session:
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely
> fashion [error code 408: Request Timeout]
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:764)
> ~[qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:730)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.closeAllSessions(AMQConnection.java:1035)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:962)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:951)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:951)
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:935)
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:916)
> [qpid-client-0.32.jar:0.32]
> at
> org.springframework.jms.connection.ConnectionFactoryUtils.releaseConnection(ConnectionFactoryUtils.java:80)
> [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
> at
>
[jira] [Updated] (QPID-8185) [JMS AMQP 0-x][AMQP 0-8..0-91] Make sure that client closes TCP connection on failure with sending connection.close
[
https://issues.apache.org/jira/browse/QPID-8185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8185:
-
Attachment: (was:
0001-JMS-AMQP-0-x-AMQP-0-8.0-91-Make-sure-that-client-clo.patch)
> [JMS AMQP 0-x][AMQP 0-8..0-91] Make sure that client closes TCP connection on
> failure with sending connection.close
> ---
>
> Key: QPID-8185
> URL: https://issues.apache.org/jira/browse/QPID-8185
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, 0.18, 0.20, 0.22, 0.24, 0.26, 0.28,
> 0.30, 0.32, qpid-java-6.0.8, qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
> Attachments:
> 0001-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Stop-handling-i.patch,
> 0002-QPID-8185-JMS-AMQP-0-x-AMQP-0-8.0-91-Make-sure-that-.patch
>
>
> Sending connection.close as part of {{Connection#close}} can end-up in
> timeout exception. The underlying TCP connection remains open and Broker can
> continue sending data to the client when session close ends up in timeout as
> well. The incoming frames cannot be associated with the sessions, as the
> client removes session information on connection close. As result, a number
> of confusing exceptions is reported.
> Here are the examples of exception stack-traces reported for the issue
> {noformat}
> INFO Unsuspending channel threw an exception:
> [Thread-227][AMQSession.java:2374]
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely
> fashion
> at
> org.apache.qpid.client.util.BlockingWaiter.block(BlockingWaiter.java:170)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.BlockingMethodFrameListener.blockForFrame(BlockingMethodFrameListener.java:115)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:715)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:736)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.protocol.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:730)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession_0_8.sendSuspendChannel(AMQSession_0_8.java:728)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession.suspendChannel(AMQSession.java:3156)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession.startDispatcherIfNecessary(AMQSession.java:2370)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQSession.syncDispatchQueue(AMQSession.java:2223)
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQSession.rollback(AMQSession.java:1881)
> [qpid-client-0.32.jar:0.32]
> ERROR Error closing session: javax.jms.JMSException: Error closing session:
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely
> fashion [error code 408: Request
> Timeout][DefaultMessageListenerContainer-2][AMQConnection.java:1039]
> ERROR Error closing connection
>
> [DefaultMessageListenerContainer-2][AMQConnection.java:971]
> javax.jms.JMSException: Error closing session:
> org.apache.qpid.AMQTimeoutException: Server did not respond in a timely
> fashion [error code 408: Request Timeout]
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:764)
> ~[qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQSession.close(AMQSession.java:730)
> ~[qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.closeAllSessions(AMQConnection.java:1035)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:962)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:951)
> [qpid-client-0.32.jar:0.32]
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:951)
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:935)
> [qpid-client-0.32.jar:0.32]
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:916)
> [qpid-client-0.32.jar:0.32]
> at
> org.springframework.jms.connection.ConnectionFactoryUtils.releaseConnection(ConnectionFactoryUtils.java:80)
> [spring-jms-4.2.3.RELEASE.jar:4.2.3.RELEASE]
> at
>
[jira] [Created] (DISPATCH-993) Test system_tests_topology_distribution fails intermittently
Chuck Rolke created DISPATCH-993:
Summary: Test system_tests_topology_distribution fails
intermittently
Key: DISPATCH-993
URL: https://issues.apache.org/jira/browse/DISPATCH-993
Project: Qpid Dispatch
Issue Type: Bug
Components: Tests
Affects Versions: 1.1.0
Reporter: Chuck Rolke
Test: DeleteSpuriousConnector
This test might run 20 times OK but it fails (for me!) eventually on today's
master branch.
For some reason instead of the messages being _received_ they are being
_released_. This messes up the on_message n_received count so that it never
reaches the magic 13 and therefore it never sends out the kill connector
command.
Here is a debug trace. Not that after 'receiving' 30 messages the n_received
count only gets to 12.
{quote}39:
==
39: FAIL: test_01_delete_spurious_connector
(system_tests_topology_disposition.TopologyDispositionTests)
39: --
39: Traceback (most recent call last):
39: File
"/home/chug/git/qpid-dispatch/tests/system_tests_topology_disposition.py", line
379, in test_01_delete_spurious_connector
39: self.assertEqual ( None, test.error )
39: AssertionError: None != 'No confirmed kill on connector.'
39:
39: --
39: Ran 2 tests in 10.250s
39:
39: FAILED (failures=1, skipped=1)
39: 1525876585.928072 on_link_opened
39: 1525876585.928256 on_link_opened
39: 1525876585.928463 on_link_opened
39: 1525876585.928535 on_link_opened
39: 1525876587.925026 timeout sender
39: 1525876587.925467 sent: 1
39: 1525876587.925707 sent: 2
39: 1525876587.925920 sent: 3
39: 1525876587.930813 on_released 1
39: 1525876587.932044 on_released 2
39: 1525876587.932671 on_released 3
39: 1525876588.424884 timeout sender
39: 1525876588.425253 sent: 4
39: 1525876588.425495 sent: 5
39: 1525876588.425698 sent: 6
39: 1525876588.432105 on_released 4
39: 1525876588.433035 on_released 5
39: 1525876588.433282 on_released 6
39: 1525876588.925559 timeout sender
39: 1525876588.925939 sent: 7
39: 1525876588.926234 sent: 8
39: 1525876588.926466 sent: 9
39: 1525876588.931285 on_released 7
39: 1525876588.931881 on_released 8
39: 1525876588.932027 on_released 9
39: 1525876589.426222 timeout sender
39: 1525876589.426562 sent: 10
39: 1525876589.426783 sent: 11
39: 1525876589.426976 sent: 12
39: 1525876589.432599 on_released 10
39: 1525876589.433407 on_released 11
39: 1525876589.433601 on_released 12
39: 1525876589.927745 timeout sender
39: 1525876589.927996 sent: 13
39: 1525876589.928149 sent: 14
39: 1525876589.928321 sent: 15
39: 1525876589.932239 on_released 13
39: 1525876589.932775 on_released 14
39: 1525876589.932907 on_released 15
39: 1525876590.427907 timeout sender
39: 1525876590.428106 sent: 16
39: 1525876590.428294 sent: 17
39: 1525876590.428404 sent: 18
39: 1525876590.431869 on_released 16
39: 1525876590.432348 on_released 17
39: 1525876590.432463 on_released 18
39: 1525876590.928454 timeout sender
39: 1525876590.928758 sent: 19
39: 1525876590.928955 sent: 20
39: 1525876590.929130 sent: 21
39: 1525876590.935306 received message 18
39: 1525876590.935326 n_received == 1
39: 1525876590.936363 received message 19
39: 1525876590.936381 n_received == 2
39: 1525876590.936989 received message 20
39: 1525876590.937010 n_received == 3
39: 1525876590.938963 on_accepted 1
39: 1525876590.940796 on_accepted 2
39: 1525876590.941263 on_accepted 3
39: 1525876591.429399 timeout sender
39: 1525876591.429752 sent: 22
39: 1525876591.429980 sent: 23
39: 1525876591.430198 sent: 24
39: 1525876591.438830 received message 21
39: 1525876591.438858 n_received == 4
39: 1525876591.439422 received message 22
39: 1525876591.439432 n_received == 5
39: 1525876591.440099 received message 23
39: 1525876591.440111 n_received == 6
39: 1525876591.442100 on_accepted 4
39: 1525876591.442532 on_accepted 5
39: 1525876591.442632 on_accepted 6
39: 1525876591.930557 timeout sender
39: 1525876591.930793 sent: 25
39: 1525876591.930934 sent: 26
39: 1525876591.931059 sent: 27
39: 1525876591.936629 received message 24
39: 1525876591.936649 n_received == 7
39: 1525876591.937648 received message 25
39: 1525876591.937665 n_received == 8
39: 1525876591.938337 received message 26
39: 1525876591.938355 n_received == 9
39: 1525876591.940128 on_accepted 7
39: 1525876591.941903 on_accepted 8
39: 1525876591.942270 on_accepted 9
39: 1525876592.431203 timeout sender
39: 1525876592.431488 sent: 28
39: 1525876592.431667 sent: 29
39: 1525876592.431824 sent: 30
39: 1525876592.438571 received message 27
39: 1525876592.438605 n_received == 10
39: 1525876592.440517 received message 28
39: 1525876592.440549 n_received == 11
39: 1525876592.441283 received message 29
39: 1525876592.441309 n_received == 12
39: 1525876592.443643 on_accepted 10
39:
[jira] [Resolved] (DISPATCH-976) Allow policy for sources and targets to handle multiple wildcards
[
https://issues.apache.org/jira/browse/DISPATCH-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved DISPATCH-976.
--
Resolution: Fixed
Fixed at Commit e919507
> Allow policy for sources and targets to handle multiple wildcards
> -
>
> Key: DISPATCH-976
> URL: https://issues.apache.org/jira/browse/DISPATCH-976
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> As per the [upstream policy
> documentation|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc]
> in the secion on [AMQP Source and Target Wildcard and Name
> Substitution|https://github.com/apache/qpid-dispatch/blob/1.0.0/doc/book/policy.adoc#amqp-source-and-target-wildcard-and-name-substitution]
> utilization of the asterisk wildcard is constrained as per the following
> quote:
> {quote}The asterisk is recognized only if it is the last character in the
> link name.
> {quote}
> It is desirable that the configuration could handle a situation where there
> are multiple asterisks in use such as:
>
> |{color:#00}"tstGroup": {{color}|
> |{color:#00} "users": "tst@amq",{color}|
> |{color:#00} "sources": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "targets": "abc.*,my.*.b2b.tst.*",{color}|
> |{color:#00} "remoteHosts": "*"{color}|
> |{color:#00}} {color}|
>
>
--
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-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468894#comment-16468894 ] ASF subversion and git services commented on DISPATCH-989: -- Commit 6502523b06193e66635bbb7e44801bcfd0aa4798 in qpid-dispatch's branch refs/heads/1.1.x from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6502523 ] DISPATCH-989 Removing this testing tool > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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-991) Master qdstat throws keyError when running against 1.0.1 router
[ https://issues.apache.org/jira/browse/DISPATCH-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468893#comment-16468893 ] ASF subversion and git services commented on DISPATCH-991: -- Commit 55bda75ccbf7043fd98b3412f298d9d3de2f0587 in qpid-dispatch's branch refs/heads/1.1.x from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=55bda75 ] DISPATCH-991 - Added back area attribute and fixed the keyError. Now qdstat will be backward compatible (cherry picked from commit 90b04701f01ea53fb00efc8b5d44c321bb78dc79) > Master qdstat throws keyError when running against 1.0.1 router > --- > > Key: DISPATCH-991 > URL: https://issues.apache.org/jira/browse/DISPATCH-991 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 1.1.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > > When running the master qdstat against a previously released 1.0.1 version of > the router the following error is put out - > KeyError: 'presettledDeliveries -- 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-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468892#comment-16468892 ] ASF subversion and git services commented on DISPATCH-989: -- Commit f0cc5659f968ea842f407cc99cb3cb8ea1582e32 in qpid-dispatch's branch refs/heads/1.1.x from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f0cc565 ] DISPATCH-989 Replace broken symlink with original files. Add npm dependency on rhea. > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468848#comment-16468848 ] ASF subversion and git services commented on DISPATCH-989: -- Commit fe1f711e26d94078dfe2b3a10f80cc8cb5716452 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=fe1f711 ] DISPATCH-989 Removing this testing tool > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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-8182) [Broker-J] [Message Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8182:
-
Summary: [Broker-J] [Message Conversion] Message id fidelity lost when
converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed
UUID (was: [Broker-J] [Conversion] Message id fidelity lost when converting
from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID)
> [Broker-J] [Message Conversion] Message id fidelity lost when converting from
> AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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-8182) [Broker-J] [Message Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8182:
-
Status: Reviewable (was: In Progress)
> [Broker-J] [Message Conversion] Message id fidelity lost when converting from
> AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468791#comment-16468791
]
Keith Wall commented on QPID-8182:
--
On reflection, I decided that my first point in my comment was invalid. Having
the conversion layer add the "ID:" seems arbitrary and would be incorrect for
the non JMS clients and would harm compatibility. The other changes - namely
the subject of the JIRA and the second point were implemented by 2696d7a.
> [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP
> 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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] [Assigned] (QPID-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-8182:
Assignee: Keith Wall
> [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP
> 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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-991) Master qdstat throws keyError when running against 1.0.1 router
[ https://issues.apache.org/jira/browse/DISPATCH-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468718#comment-16468718 ] Robbie Gemmell commented on DISPATCH-991: - For later reference: some of the changes appear to be about resolving a problem with the DISPATCH-933 change+undo commits in 1.1.0, around the 'area' attribute. > Master qdstat throws keyError when running against 1.0.1 router > --- > > Key: DISPATCH-991 > URL: https://issues.apache.org/jira/browse/DISPATCH-991 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 1.1.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > > When running the master qdstat against a previously released 1.0.1 version of > the router the following error is put out - > KeyError: 'presettledDeliveries -- 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-933) Introduce a new RouterStats entity and move all stats from the RouterEntity to the RouterStats entity
[
https://issues.apache.org/jira/browse/DISPATCH-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468717#comment-16468717
]
Robbie Gemmell commented on DISPATCH-933:
-
For later reference: some of the changes on DISPATCH-991 appear to be about
resolving a problem with the above undo commit, around the 'area' attribute.
> Introduce a new RouterStats entity and move all stats from the RouterEntity
> to the RouterStats entity
> -
>
> Key: DISPATCH-933
> URL: https://issues.apache.org/jira/browse/DISPATCH-933
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: Backlog
>
>
> Right now all router statistics attributes like deliveriesIngress,
> rejectedDeliveries, droppedPresettledDeliveries etc. reside in the router
> entity..
>
> Router Config Attributes like saslConfigPath, saslConfigName,
> helloIntervalSeconds, helloMaxAgeSeconds etc. also reside in the router entity
>
> When a qdmanage query is issued, the results do not include the router config
> attributes. This is because the core does not have access to these attributes
>
> {noformat}
> [gmurthy@localhost qpid-dispatch]$ qdmanage QUERY --type=router
> [
> {
> "linkRouteCount": 0,
> "droppedPresettledDeliveries": 0,
> "rejectedDeliveries": 0,
> "autoLinkCount": 0,
> "id": "Router.A",
> "presettledDeliveries": 0,
> "area": "0",
> "deliveriesIngress": 1,
> "deliveriesIngressRouteContainer": 0,
> "acceptedDeliveries": 1,
> "version": "1.0.0",
> "linkCount": 2,
> "connectionCount": 1,
> "addrCount": 4,
> "deliveriesEgressRouteContainer": 0,
> "nodeCount": 0,
> "modifiedDeliveries": 0,
> "identity": "1",
> "deliveriesEgress": 0,
> "releasedDeliveries": 0,
> "name": "Router.A",
> "type": "org.apache.qpid.dispatch.router",
> "deliveriesTransit": 0,
> "mode": "standalone"
> }
> ]
> {noformat}
>
> The solution to this problem is to create a new entity called RouterStats and
> move all the statistics related attributes to RouterStats. This RouterStats
> entity will be handled by the C management agent.
>
> The old Router entity which is currently handled by the C agent will be
> handled by the Python agent instead.
--
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-8182) [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
[
https://issues.apache.org/jira/browse/QPID-8182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468711#comment-16468711
]
ASF subversion and git services commented on QPID-8182:
---
Commit 2696d7a542a8927d48b43ce48a1d8104d7b8dc4c in qpid-broker-j's branch
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2696d7a ]
QPID-8182: Ensure messageId fidelity during conversion where possible
> [Broker-J] [Conversion] Message id fidelity lost when converting from AMQP
> 1.0 to 0-10 when message-id-string carries a ID: prefixed UUID
> -
>
> Key: QPID-8182
> URL: https://issues.apache.org/jira/browse/QPID-8182
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> If I publish a message from Qpid JMS Client in {{PREFIXED_UUID_STRING}} mode
> and receive the message using the Qpid JMS Client 0-x over AMQP 0-10, the
> UUID of the message id received does not match the original value generated
> by the client.
--
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] [Comment Edited] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468675#comment-16468675 ] Robbie Gemmell edited comment on DISPATCH-989 at 5/9/18 11:07 AM: -- This didn't really go the way I thought. So the files are still used (or would have been if present), but whatever tool they are used by should be deprecated and removed? Given that noone noticed it was broken up to and including RC2 (I wasn't actually trying to use whatever tool they are part of when I found the issue), and you think it should be deprecated and removed, now seems to be the time to do it? The broken pieces are part of the current 1.1.0 RC2, and a 1.1.0 RC3 is about to be spun. Either we need to make this fix there and maybe also deprecate (and then could remove them from master immediately if desired), or the tool can just be deleted instead since we'd have otherwise decided it was ok to leave it broken in the current release. CC [~ganeshmurthy] was (Author: gemmellr): This didn't really go the way I thought. So the files are still used (or would have been if present), but whatever tool they are used by should be deprecated and removed? Given that noone noticed it was broken up to and including RC2 (I wasn't actually trying to use whatever tool they are part of when I found the issue), and you think it should be deprecated and removed, now seems to be the time to do it? The broken pieces are part of the current 1.1.0 RC2, and a 1.1.0 RC3 is about to be spun. Either we need to make this fix there and maybe also deprecate (and then could remove them from master immediately if desired), or the tool can just be deleted instead since we'd have otherwise decided it was ok to leave it broken. CC [~ganeshmurthy] > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated DISPATCH-989: Priority: Blocker (was: Minor) > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Blocker > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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] [Reopened] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened DISPATCH-989: - > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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] (DISPATCH-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated DISPATCH-989: Fix Version/s: 1.1.0 > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.1.0, 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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-989) symlinks in tree to non existent files, possibly stale and could be removed?
[ https://issues.apache.org/jira/browse/DISPATCH-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468675#comment-16468675 ] Robbie Gemmell commented on DISPATCH-989: - This didn't really go the way I thought. So the files are still used (or would have been if present), but whatever tool they are used by should be deprecated and removed? Given that noone noticed it was broken up to and including RC2 (I wasn't actually trying to use whatever tool they are part of when I found the issue), and you think it should be deprecated and removed, now seems to be the time to do it? The broken pieces are part of the current 1.1.0 RC2, and a 1.1.0 RC3 is about to be spun. Either we need to make this fix there and maybe also deprecate (and then could remove them from master immediately if desired), or the tool can just be deleted instead since we'd have otherwise decided it was ok to leave it broken. CC [~ganeshmurthy] > symlinks in tree to non existent files, possibly stale and could be removed? > > > Key: DISPATCH-989 > URL: https://issues.apache.org/jira/browse/DISPATCH-989 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 1.1.0 >Reporter: Robbie Gemmell >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.2.0 > > > There are a number of symlinks in the console tree which point to files that > no longer exist. Its not clear these are actually required anymore, and may > be stale and could be removed? The targets were seemingly removed by > DISPATCH-917 > Dir console/test/css/: > brokers.ttf -> ../../stand-alone/plugin/css/brokers.ttf > dispatch.css -> ../../stand-alone/plugin/css/dispatch.css > plugin.css -> ../../stand-alone/plugin/css/plugin.css > site-base.css -> ../../stand-alone/plugin/css/site-base.css > Dir console/test/html/: > qdrConnect.html -> ../../stand-alone/plugin/html/qdrConnect.html > qdrLayout.html -> ../../stand-alone/plugin/html/qdrLayout.html > Dir console/test/js/: > qdrService.js -> ../../stand-alone/plugin/js/qdrService.js > Dir console/test/lib/: > rhea-min.js -> ../../stand-alone/plugin/lib/rhea-min.js -- 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
