[jira] [Commented] (PROTON-2668) Change versions of Python used/supported
[ https://issues.apache.org/jira/browse/PROTON-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677486#comment-17677486 ] Ted Ross commented on PROTON-2668: -- Clarification on the above comment: Default EL8 uses Python 3.6. There is an option to install later versions of Python on EL8. This means that dependencies listed in container-files and similar must specify the python version to be installed. > Change versions of Python used/supported > > > Key: PROTON-2668 > URL: https://issues.apache.org/jira/browse/PROTON-2668 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.39.0 > > > We currently support Python 3.6 upwards; this is an old and unsupported > version of python pretty much everywhere. > In particular some of the CI systems no longer even have this version which > is causing some build failures. > Let's change the supported versions to be 3.8 and up which covers pretty much > all supported LTS versions of Ubuntu (20.04, 22.04) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2668) Change versions of Python used/supported
[ https://issues.apache.org/jira/browse/PROTON-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17677462#comment-17677462 ] Ted Ross commented on PROTON-2668: -- This change makes Proton incompatible with Red Hat Enterprise Linux 8 and Centos8. > Change versions of Python used/supported > > > Key: PROTON-2668 > URL: https://issues.apache.org/jira/browse/PROTON-2668 > Project: Qpid Proton > Issue Type: Improvement >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > We currently support Python 3.6 upwards; this is an old and unsupported > version of python pretty much everywhere. > In particular some of the CI systems no longer even have this version which > is causing some build failures. > Let's change the supported versions to be 3.8 and up which covers pretty much > all supported LTS versions of Ubuntu (20.04, 22.04) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2301) Protocol adaptors do not annotate AMQP messages
[ https://issues.apache.org/jira/browse/DISPATCH-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-2301. Resolution: Fixed > Protocol adaptors do not annotate AMQP messages > --- > > Key: DISPATCH-2301 > URL: https://issues.apache.org/jira/browse/DISPATCH-2301 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors >Affects Versions: 1.18.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.19.0 > > > Messages generated by the protocol adaptors (I tested TCP and HTTP, not > HTTP2) do not include message annotations for trace and origin. Without > these annotations, loop prevention and multicast forwarding will not function > properly. This is likely to cause problems during topology changes and maybe > also in different circumstances. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2301) Protocol adaptors do not annotate AMQP messages
Ted Ross created DISPATCH-2301: -- Summary: Protocol adaptors do not annotate AMQP messages Key: DISPATCH-2301 URL: https://issues.apache.org/jira/browse/DISPATCH-2301 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Affects Versions: 1.18.0 Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.19.0 Messages generated by the protocol adaptors (I tested TCP and HTTP, not HTTP2) do not include message annotations for trace and origin. Without these annotations, loop prevention and multicast forwarding will not function properly. This is likely to cause problems during topology changes and maybe also in different circumstances. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2288) Network-centric logging facility for protocol adaptors
Ted Ross created DISPATCH-2288: -- Summary: Network-centric logging facility for protocol adaptors Key: DISPATCH-2288 URL: https://issues.apache.org/jira/browse/DISPATCH-2288 Project: Qpid Dispatch Issue Type: New Feature Components: Protocol Adaptors Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.19.0 A separate logging/tracing facility is needed for the protocol adaptors to serve users that are more accustomed to network/firewall/router logs and are not concerned with AMQP/messaging/link-protocol details. This feature will make the use of the protocol adaptors more observable and debuggable to network-familiar developers and operators. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1903) Remote upload of certificate files for new TLS configurations
[ https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443901#comment-17443901 ] Ted Ross commented on DISPATCH-1903: I moved this issue to the backlog. It is likely that the project will take a different approach to no-restart-TLS-config-changes that will not involve code changes to the router. If this occurs, this issue will be closed. > Remote upload of certificate files for new TLS configurations > - > > Key: DISPATCH-1903 > URL: https://issues.apache.org/jira/browse/DISPATCH-1903 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: Backlog > > > Currently, when using the management protocol to create new SSL-profiles, > those profiles must access certificate files that are already placed in the > file system. In other words, in order to create an SSL-profile on a running > router, files must first be placed on the file system in a location > accessible by the router. This may be problematic in cases where the router > is remote from the managing agent, or when containerization limits access to > the router's underlying file system. > This new feature allows a managing agent to remotely inject files into a > running router to be stored in temporary file storage. These files are > usable in sslProfile management entities (by specifying the files without an > absolute path). The temporary files are removed from the file system on > router shutdown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1903) Remote upload of certificate files for new TLS configurations
[ https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1903: --- Fix Version/s: Backlog (was: 1.19.0) > Remote upload of certificate files for new TLS configurations > - > > Key: DISPATCH-1903 > URL: https://issues.apache.org/jira/browse/DISPATCH-1903 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: Backlog > > > Currently, when using the management protocol to create new SSL-profiles, > those profiles must access certificate files that are already placed in the > file system. In other words, in order to create an SSL-profile on a running > router, files must first be placed on the file system in a location > accessible by the router. This may be problematic in cases where the router > is remote from the managing agent, or when containerization limits access to > the router's underlying file system. > This new feature allows a managing agent to remotely inject files into a > running router to be stored in temporary file storage. These files are > usable in sslProfile management entities (by specifying the files without an > absolute path). The temporary files are removed from the file system on > router shutdown. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2262) Edge/Interior connections can half-fail in real multi-cloud environments
[ https://issues.apache.org/jira/browse/DISPATCH-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-2262. Resolution: Fixed > Edge/Interior connections can half-fail in real multi-cloud environments > > > Key: DISPATCH-2262 > URL: https://issues.apache.org/jira/browse/DISPATCH-2262 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.17.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.18.0 > > > See PROTON-2440 for context. > The configured keepalive on edge-to-interior connections can fail to provide > protection from connection loss. This results in half-failed connections > where the edge sees connection failure and re-connects and the interior sees > nothing and accumulates multiple connections from the same edge. > This is a serious problem because the interior will attempt to forward > deliveries across these dead-but-seemingly-alive connections resulting in > lack of message delivery. > The solution proposed in this issue is to work around the problem by > introducing an application-level keepalive for edge-to-interior connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2267) Add a core-thread facility to allow IO modules to subscribe to address-reachability data
Ted Ross created DISPATCH-2267: -- Summary: Add a core-thread facility to allow IO modules to subscribe to address-reachability data Key: DISPATCH-2267 URL: https://issues.apache.org/jira/browse/DISPATCH-2267 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.19.0 Add a facility to the Core Thread that allows an IO-thread module to register for updates about a particular address. Callbacks into the IO-thread (on an IO thread) shall inform the module about changes to the reachability of an address. This can be used by a protocol listener to open or close the listening socket for a protocol listener based on the availability of remote connectors. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2237) Add latency metric to tcpListener
[ https://issues.apache.org/jira/browse/DISPATCH-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-2237: --- Fix Version/s: (was: 1.18.0) 1.19.0 > Add latency metric to tcpListener > - > > Key: DISPATCH-2237 > URL: https://issues.apache.org/jira/browse/DISPATCH-2237 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.19.0 > > > Add metrics to tcpListener for connection latency. This measures the time > between sending the first frame of the client stream and receiving the first > frame of the server stream. > This is more a measure of network latency than it is of server latency. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-2262) Edge/Interior connections can half-fail in real multi-cloud environments
[ https://issues.apache.org/jira/browse/DISPATCH-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-2262. Resolution: Fixed > Edge/Interior connections can half-fail in real multi-cloud environments > > > Key: DISPATCH-2262 > URL: https://issues.apache.org/jira/browse/DISPATCH-2262 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.17.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.18.0 > > > See PROTON-2440 for context. > The configured keepalive on edge-to-interior connections can fail to provide > protection from connection loss. This results in half-failed connections > where the edge sees connection failure and re-connects and the interior sees > nothing and accumulates multiple connections from the same edge. > This is a serious problem because the interior will attempt to forward > deliveries across these dead-but-seemingly-alive connections resulting in > lack of message delivery. > The solution proposed in this issue is to work around the problem by > introducing an application-level keepalive for edge-to-interior connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2262) Edge/Interior connections can half-fail in real multi-cloud environments
[ https://issues.apache.org/jira/browse/DISPATCH-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17434954#comment-17434954 ] Ted Ross commented on DISPATCH-2262: [~gsim] - I think this one's a little different: - It's intermittent, sometimes occurring and sometimes not with the same (default) configuration. - When it happens (no empty frames), the timer does not expire and the connection does not close. > Edge/Interior connections can half-fail in real multi-cloud environments > > > Key: DISPATCH-2262 > URL: https://issues.apache.org/jira/browse/DISPATCH-2262 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.17.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.18.0 > > > See PROTON-2440 for context. > The configured keepalive on edge-to-interior connections can fail to provide > protection from connection loss. This results in half-failed connections > where the edge sees connection failure and re-connects and the interior sees > nothing and accumulates multiple connections from the same edge. > This is a serious problem because the interior will attempt to forward > deliveries across these dead-but-seemingly-alive connections resulting in > lack of message delivery. > The solution proposed in this issue is to work around the problem by > introducing an application-level keepalive for edge-to-interior connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2262) Edge/Interior connections can half-fail in real multi-cloud environments
Ted Ross created DISPATCH-2262: -- Summary: Edge/Interior connections can half-fail in real multi-cloud environments Key: DISPATCH-2262 URL: https://issues.apache.org/jira/browse/DISPATCH-2262 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 1.17.0 Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.18.0 See PROTON-2440 for context. The configured keepalive on edge-to-interior connections can fail to provide protection from connection loss. This results in half-failed connections where the edge sees connection failure and re-connects and the interior sees nothing and accumulates multiple connections from the same edge. This is a serious problem because the interior will attempt to forward deliveries across these dead-but-seemingly-alive connections resulting in lack of message delivery. The solution proposed in this issue is to work around the problem by introducing an application-level keepalive for edge-to-interior connections. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2440) Configured heartbeats sometimes don't function in inter-cloud environments
Ted Ross created PROTON-2440: Summary: Configured heartbeats sometimes don't function in inter-cloud environments Key: PROTON-2440 URL: https://issues.apache.org/jira/browse/PROTON-2440 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.35.0 Reporter: Ted Ross The context is Qpid Dispatch Routers connected together with one router in Edge mode and the other in Interior mode. The router modes are probably not important for this issue. The connecting (client) router is running on a bare-metal Fedora Linux system in a container under Minikube. The listening router is running in a container in Microsoft Azure Kubernetes Service. There are unknown layers of networks and load balancers between the routers. The problem is that configured heartbeats sometimes don't occur. In other words, a trace on the connection shows no heartbeat (empty) frames flowing. Furthermore, when this happens, the connection is never closed due to lack of heartbeats. This lack of heartbeat protection often results in half-disconnected connections. When this happens, the client-side sees a connection error (usually related to TLS), closes the connection and reconnects with a new connection. The server-side sees no error and winds up with two live connections from the client, only one of which can actually carry messages to/from the client. Qpid Dispatch can work around this problem by establishing an application-level keepalive using message delivery. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2237) Add latency metric to tcpListener
Ted Ross created DISPATCH-2237: -- Summary: Add latency metric to tcpListener Key: DISPATCH-2237 URL: https://issues.apache.org/jira/browse/DISPATCH-2237 Project: Qpid Dispatch Issue Type: Improvement Components: Protocol Adaptors Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.18.0 Add metrics to tcpListener for connection latency. This measures the time between sending the first frame of the client stream and receiving the first frame of the server stream. This is more a measure of network latency than it is of server latency. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2229) Aggregated statistics in TcpListener
[ https://issues.apache.org/jira/browse/DISPATCH-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross closed DISPATCH-2229. -- Resolution: Duplicate > Aggregated statistics in TcpListener > > > Key: DISPATCH-2229 > URL: https://issues.apache.org/jira/browse/DISPATCH-2229 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Protocol Adaptors > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.18.0 > > > Aggregate statistics for the connections associated with a single TcpListener > in the listener entity itself. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2229) Aggregated statistics in TcpListener
Ted Ross created DISPATCH-2229: -- Summary: Aggregated statistics in TcpListener Key: DISPATCH-2229 URL: https://issues.apache.org/jira/browse/DISPATCH-2229 Project: Qpid Dispatch Issue Type: New Feature Components: Protocol Adaptors Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.18.0 Aggregate statistics for the connections associated with a single TcpListener in the listener entity itself. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1735) system_tests_management failing on Fedora 32
[
https://issues.apache.org/jira/browse/DISPATCH-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17281322#comment-17281322
]
Ted Ross commented on DISPATCH-1735:
I also saw this failure on Fedora 32. After completely removing the build and
install directories and re-building from nothing, the failure went away. It
appears that this is caused by some build artifacts left over from an earlier
version. Consider closing this as not-a-bug.
> system_tests_management failing on Fedora 32
>
>
> Key: DISPATCH-1735
> URL: https://issues.apache.org/jira/browse/DISPATCH-1735
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> {noformat}
> 19: ==
> 19: FAIL: test_dummy (system_tests_management.ManagementTest)
> 19: Test all operations on the dummy test entity
> 19: --
> 19: Traceback (most recent call last):
> 19: File
> "/home/gmurthy/opensource/qpid-dispatch/tests/system_tests_management.py",
> line 347, in test_dummy
> 19: self.assertEqual(
> 19: AssertionError: {'operation': 'callme', 'type': 'org.apache[58
> chars]tes'} != {'type': 'org.apache.qpid.dispatch.dummy', [57 chars]y/0'}
> 19: - {'data': b'bytes',
> 19: ? -
> 19:
> 19: + {'data': 'bytes',
> 19:'identity': 'dummy/0',
> 19:'operation': 'callme',
> 19:'type': 'org.apache.qpid.dispatch.dummy'}
> 19:
> 19: --
> 19: Ran 21 tests in 9.483s
> 19:
> 19: FAILED (failures=1)
> 1/1 Test #19: system_tests_management ..***Failed9.69 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1927) TCP adaptor Assertion `(link->undelivered).head' failed.
[
https://issues.apache.org/jira/browse/DISPATCH-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-1927.
Fix Version/s: 1.15.0
Resolution: Fixed
> TCP adaptor Assertion `(link->undelivered).head' failed.
>
>
> Key: DISPATCH-1927
> URL: https://issues.apache.org/jira/browse/DISPATCH-1927
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors, Router Node
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.15.0
>
> Attachments: DISPATCH-1927-use-after-free-log.txt
>
>
> Test setup:
> * Proton git: branch master @ 5e7d7af8f
> * Dispatch git: branch master @ ec39e5e
> * Debug build
> * Running the configuration described in DISPATCH-1777
> Seven clients run TCP_echo_client continuously against the server:
> * Four run --size 0
> * One runs --size 100
> * One runs --size 10
> * One runs --size 100
> Eventually the router running the tcpConnector fails with the assertion.
> Tail of the router log:
> {code:java}
> Two router setup with a TCP listener on one router and a TCP connector on the
> other router.
> This is the log from the second tcpConnector router
> Here comes a message from core to TCP needing a new connection to egress
> server
> 2021-01-22 09:37:57.979054 -0500 TCP_ADAPTOR (debug) [C1] on_activate
> 2021-01-22 09:37:57.979594 -0500 TCP_ADAPTOR (debug) [C1][L1] qdr_tcp_push
> 2021-01-22 09:37:57.979619 -0500 TCP_ADAPTOR (debug) [C1][L1][D46793]
> qdr_tcp_deliver Delivery event
> 2021-01-22 09:37:57.979641 -0500 TCP_ADAPTOR (debug) [C1][L1][D46793]
> tcp_adaptor initiating egress connection
> 2021-01-22 09:37:57.979671 -0500 TCP_ADAPTOR (info) [C11768] Connecting to:
> 127.0.0.1:9090
> 2021-01-22 09:37:57.979789 -0500 TCP_ADAPTOR (debug) [C11767]
> qdr_tcp_activate: waking raw connection
> 2021-01-22 09:37:57.979974 -0500 TCP_ADAPTOR (info) [C11768]
> PN_RAW_CONNECTION_CONNECTED Egress connected to 127.0.0.1:9090
> 2021-01-22 09:37:57.980003 -0500 TCP_ADAPTOR (info) [C11768] Opening
> server-side core connection 127.0.0.1:9090
> 2021-01-22 09:37:57.980057 -0500 ROUTER_CORE (info) [C11768] Connection
> Opened: dir=out host=127.0.0.1:9090 vhost= encrypted=no auth=no user=
> container_id=TcpAdaptor props=
> Delivery is handed off to new connection/link
> 2021-01-22 09:37:57.980153 -0500 TCP_ADAPTOR (debug) [C1][L1][D46793]
> initial_delivery ownership passed to [C11768][L23564][D46793]
> 2021-01-22 09:37:57.980191 -0500 TCP_ADAPTOR (debug) [C11768]
> PN_RAW_CONNECTION_NEED_WRITE_BUFFERS
> 2021-01-22 09:37:57.980215 -0500 TCP_ADAPTOR (debug) [C11768]
> PN_RAW_CONNECTION_NEED_READ_BUFFERS
> 2021-01-22 09:37:57.980243 -0500 TCP_ADAPTOR (debug) [C11768][L23564] Waiting
> for credit to initiate message
> POOF! link_process_delivery has no deliveries yet.
> This is happening too soon. Probably.
> qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/transfer.c:231:
> qdr_link_process_deliveries: Assertion `(link->undelivered).head' failed.
> from gdb: delivery_id = 46793, link_id = 23564, conn_id = 11768 or:
> [C11768][L23564][D46793] for failed process
> Moments later the rest of the connection/link setup happens
> 2021-01-22 09:37:57.980312 -0500 ROUTER_CORE (info) [C11768][L23564] Link
> attached: dir=out source={foo expire:link} target={ expire:link}
> 2021-01-22 09:37:57.980332 -0500 TCP_ADAPTOR (debug) [C11768]
> qdr_tcp_activate: waking raw connection
> 2021-01-22 09:37:57.980356 -0500 TCP_ADAPTOR (debug) [C11767]
> qdr_tcp_activate: waking raw connection
> 2021-01-22 09:37:57.980386 -0500 TCP_ADAPTOR (debug) [C11768]
> PN_RAW_CONNECTION_WAKE
> 2021-01-22 09:37:57.980404 -0500 TCP_ADAPTOR (debug) [C11768][L23564]
> qdr_tcp_second_attach
> 2021-01-22 09:37:57.980430 -0500 TCP_ADAPTOR (debug) [C11768][L23564]
> qdr_tcp_get_credit: NOOP
> 2021-01-22 09:37:57.980453 -0500 TCP_ADAPTOR (debug) [C11768][L23564]
> qdr_tcp_push
> 2021-01-22 09:37:57.980471 -0500 TCP_ADAPTOR (debug) [C11768][L23564][D46793]
> qdr_tcp_deliver Delivery event
> 2021-01-22 09:37:57.980563 -0500 TCP_ADAPTOR (debug) [C11768][L23565] Create
> Link to amqp:/_topo/0/router-b/temp.tsMXbvjL9M01_l8
> 2021-01-22 09:37:57.980591 -0500 TCP_ADAPTOR (debug) [C11768][L23564] Waiting
> for credit to initiate message
> 2021-01-22 09:37:57.980621 -0500 TCP_ADAPTOR (debug) [C11768] Writing 2040
> bytes
> 2021-01-22 09:37:57.980640 -0500 TCP_AD
[jira] [Assigned] (DISPATCH-1927) TCP adaptor Assertion `(link->undelivered).head' failed.
[
https://issues.apache.org/jira/browse/DISPATCH-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned DISPATCH-1927:
--
Assignee: Ted Ross
> TCP adaptor Assertion `(link->undelivered).head' failed.
>
>
> Key: DISPATCH-1927
> URL: https://issues.apache.org/jira/browse/DISPATCH-1927
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors, Router Node
> Environment: Fedora 31
>Reporter: Charles E. Rolke
>Assignee: Ted Ross
>Priority: Major
>
> Test setup:
> * Proton git: branch master @ 5e7d7af8f
> * Dispatch git: branch master @ ec39e5e
> * Debug build
> * Running the configuration described in DISPATCH-1777
> Seven clients run TCP_echo_client continuously against the server:
> * Four run --size 0
> * One runs --size 100
> * One runs --size 10
> * One runs --size 100
> Eventually the router running the tcpConnector fails with the assertion.
> Tail of the router log:
> {code:java}
> Two router setup with a TCP listener on one router and a TCP connector on the
> other router.
> This is the log from the second tcpConnector router
> Here comes a message from core to TCP needing a new connection to egress
> server
> 2021-01-22 09:37:57.979054 -0500 TCP_ADAPTOR (debug) [C1] on_activate
> 2021-01-22 09:37:57.979594 -0500 TCP_ADAPTOR (debug) [C1][L1] qdr_tcp_push
> 2021-01-22 09:37:57.979619 -0500 TCP_ADAPTOR (debug) [C1][L1][D46793]
> qdr_tcp_deliver Delivery event
> 2021-01-22 09:37:57.979641 -0500 TCP_ADAPTOR (debug) [C1][L1][D46793]
> tcp_adaptor initiating egress connection
> 2021-01-22 09:37:57.979671 -0500 TCP_ADAPTOR (info) [C11768] Connecting to:
> 127.0.0.1:9090
> 2021-01-22 09:37:57.979789 -0500 TCP_ADAPTOR (debug) [C11767]
> qdr_tcp_activate: waking raw connection
> 2021-01-22 09:37:57.979974 -0500 TCP_ADAPTOR (info) [C11768]
> PN_RAW_CONNECTION_CONNECTED Egress connected to 127.0.0.1:9090
> 2021-01-22 09:37:57.980003 -0500 TCP_ADAPTOR (info) [C11768] Opening
> server-side core connection 127.0.0.1:9090
> 2021-01-22 09:37:57.980057 -0500 ROUTER_CORE (info) [C11768] Connection
> Opened: dir=out host=127.0.0.1:9090 vhost= encrypted=no auth=no user=
> container_id=TcpAdaptor props=
> Delivery is handed off to new connection/link
> 2021-01-22 09:37:57.980153 -0500 TCP_ADAPTOR (debug) [C1][L1][D46793]
> initial_delivery ownership passed to [C11768][L23564][D46793]
> 2021-01-22 09:37:57.980191 -0500 TCP_ADAPTOR (debug) [C11768]
> PN_RAW_CONNECTION_NEED_WRITE_BUFFERS
> 2021-01-22 09:37:57.980215 -0500 TCP_ADAPTOR (debug) [C11768]
> PN_RAW_CONNECTION_NEED_READ_BUFFERS
> 2021-01-22 09:37:57.980243 -0500 TCP_ADAPTOR (debug) [C11768][L23564] Waiting
> for credit to initiate message
> POOF! link_process_delivery has no deliveries yet.
> This is happening too soon. Probably.
> qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/transfer.c:231:
> qdr_link_process_deliveries: Assertion `(link->undelivered).head' failed.
> from gdb: delivery_id = 46793, link_id = 23564, conn_id = 11768 or:
> [C11768][L23564][D46793] for failed process
> Moments later the rest of the connection/link setup happens
> 2021-01-22 09:37:57.980312 -0500 ROUTER_CORE (info) [C11768][L23564] Link
> attached: dir=out source={foo expire:link} target={ expire:link}
> 2021-01-22 09:37:57.980332 -0500 TCP_ADAPTOR (debug) [C11768]
> qdr_tcp_activate: waking raw connection
> 2021-01-22 09:37:57.980356 -0500 TCP_ADAPTOR (debug) [C11767]
> qdr_tcp_activate: waking raw connection
> 2021-01-22 09:37:57.980386 -0500 TCP_ADAPTOR (debug) [C11768]
> PN_RAW_CONNECTION_WAKE
> 2021-01-22 09:37:57.980404 -0500 TCP_ADAPTOR (debug) [C11768][L23564]
> qdr_tcp_second_attach
> 2021-01-22 09:37:57.980430 -0500 TCP_ADAPTOR (debug) [C11768][L23564]
> qdr_tcp_get_credit: NOOP
> 2021-01-22 09:37:57.980453 -0500 TCP_ADAPTOR (debug) [C11768][L23564]
> qdr_tcp_push
> 2021-01-22 09:37:57.980471 -0500 TCP_ADAPTOR (debug) [C11768][L23564][D46793]
> qdr_tcp_deliver Delivery event
> 2021-01-22 09:37:57.980563 -0500 TCP_ADAPTOR (debug) [C11768][L23565] Create
> Link to amqp:/_topo/0/router-b/temp.tsMXbvjL9M01_l8
> 2021-01-22 09:37:57.980591 -0500 TCP_ADAPTOR (debug) [C11768][L23564] Waiting
> for credit to initiate message
> 2021-01-22 09:37:57.980621 -0500 TCP_ADAPTOR (debug) [C11768] Writing 2040
> bytes
> 2021-01-22 09:37:57.980640 -0500 TCP_ADAPTOR (debug) [C11768] Writing 2048
> bytes
> 2021-01-22 09:37:57.980657 -0500 TCP_ADAPTOR (debug) [C11768] Writing 2048
[jira] [Updated] (DISPATCH-1903) Remote upload of certificate files for new TLS configurations
[ https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1903: --- Fix Version/s: (was: 1.15.0) 1.16.0 > Remote upload of certificate files for new TLS configurations > - > > Key: DISPATCH-1903 > URL: https://issues.apache.org/jira/browse/DISPATCH-1903 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.16.0 > > > Currently, when using the management protocol to create new SSL-profiles, > those profiles must access certificate files that are already placed in the > file system. In other words, in order to create an SSL-profile on a running > router, files must first be placed on the file system in a location > accessible by the router. This may be problematic in cases where the router > is remote from the managing agent, or when containerization limits access to > the router's underlying file system. > This new feature allows a managing agent to remotely inject files into a > running router to be stored in temporary file storage. These files are > usable in sslProfile management entities (by specifying the files without an > absolute path). The temporary files are removed from the file system on > router shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1912) Fix TSAN failures in the test suite
[ https://issues.apache.org/jira/browse/DISPATCH-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1912. Resolution: Fixed > Fix TSAN failures in the test suite > --- > > Key: DISPATCH-1912 > URL: https://issues.apache.org/jira/browse/DISPATCH-1912 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Running the test with the TSAN thread sanitizer on has revealed some issues. > This Jira will be used for fixes. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1912) Fix TSAN failures in the test suite
Ted Ross created DISPATCH-1912: -- Summary: Fix TSAN failures in the test suite Key: DISPATCH-1912 URL: https://issues.apache.org/jira/browse/DISPATCH-1912 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.15.0 Running the test with the TSAN thread sanitizer on has revealed some issues. This Jira will be used for fixes. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1903) Remote upload of certificate files for new TLS configurations
[ https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264157#comment-17264157 ] Ted Ross commented on DISPATCH-1903: [~robbie] [~gsim] I don't believe that the Proton API allows for directly supplying certificate data. It expects file paths. > Remote upload of certificate files for new TLS configurations > - > > Key: DISPATCH-1903 > URL: https://issues.apache.org/jira/browse/DISPATCH-1903 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Currently, when using the management protocol to create new SSL-profiles, > those profiles must access certificate files that are already placed in the > file system. In other words, in order to create an SSL-profile on a running > router, files must first be placed on the file system in a location > accessible by the router. This may be problematic in cases where the router > is remote from the managing agent, or when containerization limits access to > the router's underlying file system. > This new feature allows a managing agent to remotely inject files into a > running router to be stored in temporary file storage. These files are > usable in sslProfile management entities (by specifying the files without an > absolute path). The temporary files are removed from the file system on > router shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1903) Remote upload of certificate files for new TLS configurations
[ https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264145#comment-17264145 ] Ted Ross commented on DISPATCH-1903: [~gsim] The documentation currently says that the ssl-profile certificate fields are absolute paths. I assume that a relative path would work from the current working directory. Perhaps a symbolic designator of some sort could be used to eliminate this risk. > Remote upload of certificate files for new TLS configurations > - > > Key: DISPATCH-1903 > URL: https://issues.apache.org/jira/browse/DISPATCH-1903 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Currently, when using the management protocol to create new SSL-profiles, > those profiles must access certificate files that are already placed in the > file system. In other words, in order to create an SSL-profile on a running > router, files must first be placed on the file system in a location > accessible by the router. This may be problematic in cases where the router > is remote from the managing agent, or when containerization limits access to > the router's underlying file system. > This new feature allows a managing agent to remotely inject files into a > running router to be stored in temporary file storage. These files are > usable in sslProfile management entities (by specifying the files without an > absolute path). The temporary files are removed from the file system on > router shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1911) Allow internal message endpoints using core-subscribe to set terminal disposition of received deliveries
[ https://issues.apache.org/jira/browse/DISPATCH-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1911. Resolution: Fixed > Allow internal message endpoints using core-subscribe to set terminal > disposition of received deliveries > > > Key: DISPATCH-1911 > URL: https://issues.apache.org/jira/browse/DISPATCH-1911 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Currently, messages delivered to internal components in the router via the > core/subscribe mechanism have no control over the disposition of received > deliveries. The deliveries are automatically accepted and settled before > they are dispatched to the out-of-core handlers, or after an in-core handler > completes. > This improvement allows handlers to provide the disposition and an error so > that messages can be rejected. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1907) Make policy enforceable in internal message receivers
[ https://issues.apache.org/jira/browse/DISPATCH-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1907. Resolution: Fixed > Make policy enforceable in internal message receivers > - > > Key: DISPATCH-1907 > URL: https://issues.apache.org/jira/browse/DISPATCH-1907 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Currently, policy is enforced in the AMQP router-node with a couple of > cherry-picked policy values being passed into the router-core for enforcement > there. > This improvement puts a "policy-spec" structure into the general include path > which can be accessed anywhere in the router code. Rather than > cherry-picking values from the policy, a pointer to the policy-spec is passed > into the core with each opened connection. This structure is available in the > core and through the core-subscription on_message callback so that handlers > of internally targeted messages can enforce policy for the endpoint's > connection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1911) Allow internal message endpoints using core-subscribe to set terminal disposition of received deliveries
Ted Ross created DISPATCH-1911: -- Summary: Allow internal message endpoints using core-subscribe to set terminal disposition of received deliveries Key: DISPATCH-1911 URL: https://issues.apache.org/jira/browse/DISPATCH-1911 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.15.0 Currently, messages delivered to internal components in the router via the core/subscribe mechanism have no control over the disposition of received deliveries. The deliveries are automatically accepted and settled before they are dispatched to the out-of-core handlers, or after an in-core handler completes. This improvement allows handlers to provide the disposition and an error so that messages can be rejected. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1907) Make policy enforceable in internal message receivers
Ted Ross created DISPATCH-1907: -- Summary: Make policy enforceable in internal message receivers Key: DISPATCH-1907 URL: https://issues.apache.org/jira/browse/DISPATCH-1907 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.15.0 Currently, policy is enforced in the AMQP router-node with a couple of cherry-picked policy values being passed into the router-core for enforcement there. This improvement puts a "policy-spec" structure into the general include path which can be accessed anywhere in the router code. Rather than cherry-picking values from the policy, a pointer to the policy-spec is passed into the core with each opened connection. This structure is available in the core and through the core-subscription on_message callback so that handlers of internally targeted messages can enforce policy for the endpoint's connection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2317) Proton Python - Container ID is blank from direct server
Ted Ross created PROTON-2317:
Summary: Proton Python - Container ID is blank from direct server
Key: PROTON-2317
URL: https://issues.apache.org/jira/browse/PROTON-2317
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: proton-c-0.33.0
Reporter: Ted Ross
When using a direct server (Python app is the AMQP listener), the container-id
is sent as an empty string, even if it's explicitly set on the container.
{{[0x5573a1d0ce00]: AMQP:FRAME:0 -> @open(16) [container-id="",
channel-max=32767]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1903) Remote upload of certificate files for new TLS configurations
[ https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17258920#comment-17258920 ] Ted Ross commented on DISPATCH-1903: +1 [~chug] I would add one more policy value that simply enables the feature, probably defaulted to "disabled". These policy attributes should be held per-vhost. I think the common use case will use a default vhost for a "localhost" listener that enables this feature. That will allow a same-system or same-pod controller to make runtime updates to ssl-profiles while preventing any remote access to the feature. This is planned as a write-only feature (as [~chug] mentioned). There will be no read-back access to the temporary files. It should also be noted that this feature cannot be used to overwrite pre-configured ssl-profile certificate files. > Remote upload of certificate files for new TLS configurations > - > > Key: DISPATCH-1903 > URL: https://issues.apache.org/jira/browse/DISPATCH-1903 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Currently, when using the management protocol to create new SSL-profiles, > those profiles must access certificate files that are already placed in the > file system. In other words, in order to create an SSL-profile on a running > router, files must first be placed on the file system in a location > accessible by the router. This may be problematic in cases where the router > is remote from the managing agent, or when containerization limits access to > the router's underlying file system. > This new feature allows a managing agent to remotely inject files into a > running router to be stored in temporary file storage. These files are > usable in sslProfile management entities (by specifying the files without an > absolute path). The temporary files are removed from the file system on > router shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1903) Remote upload of certificate files for new TLS configurations
Ted Ross created DISPATCH-1903: -- Summary: Remote upload of certificate files for new TLS configurations Key: DISPATCH-1903 URL: https://issues.apache.org/jira/browse/DISPATCH-1903 Project: Qpid Dispatch Issue Type: New Feature Components: Container Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.15.0 Currently, when using the management protocol to create new SSL-profiles, those profiles must access certificate files that are already placed in the file system. In other words, in order to create an SSL-profile on a running router, files must first be placed on the file system in a location accessible by the router. This may be problematic in cases where the router is remote from the managing agent, or when containerization limits access to the router's underlying file system. This new feature allows a managing agent to remotely inject files into a running router to be stored in temporary file storage. These files are usable in sslProfile management entities (by specifying the files without an absolute path). The temporary files are removed from the file system on router shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1886) Review and fix races between connection activation and closure
Ted Ross created DISPATCH-1886: -- Summary: Review and fix races between connection activation and closure Key: DISPATCH-1886 URL: https://issues.apache.org/jira/browse/DISPATCH-1886 Project: Qpid Dispatch Issue Type: Bug Components: Container Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.15.0 [~cliffjansen] reviewed the usage of connection-wake (activation) in the router code and identified some potential issues with the multi-threading that occurs between activation and IO processing. This Jira will be used to track updates to the code that result from this analysis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1884) TCP Adaptor fails asan leak tests
[ https://issues.apache.org/jira/browse/DISPATCH-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1884. Resolution: Fixed > TCP Adaptor fails asan leak tests > - > > Key: DISPATCH-1884 > URL: https://issues.apache.org/jira/browse/DISPATCH-1884 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.15.0 > > > There are a number of shutdown leaks reported by asan during the TCP adaptor > tests. Some of these leaks are real in that connectors and listeners that > are dynamically created and destroyed will leak parts of their configuration > and state. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1884) TCP Adaptor fails asan leak tests
Ted Ross created DISPATCH-1884: -- Summary: TCP Adaptor fails asan leak tests Key: DISPATCH-1884 URL: https://issues.apache.org/jira/browse/DISPATCH-1884 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.15.0 There are a number of shutdown leaks reported by asan during the TCP adaptor tests. Some of these leaks are real in that connectors and listeners that are dynamically created and destroyed will leak parts of their configuration and state. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1872) TCP Adaptor mishandles dropped server connections.
[ https://issues.apache.org/jira/browse/DISPATCH-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1872. Fix Version/s: 1.15.0 Resolution: Fixed > TCP Adaptor mishandles dropped server connections. > -- > > Key: DISPATCH-1872 > URL: https://issues.apache.org/jira/browse/DISPATCH-1872 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > If a server connection drops before the payload is processed, the tcp adaptor > can crash or it can fail to release the delivery, causing the client to hang > indefinitely. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1876) TCP adaptor crash handling fast socket open/close
[
https://issues.apache.org/jira/browse/DISPATCH-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-1876.
Fix Version/s: 1.15.0
Resolution: Fixed
> TCP adaptor crash handling fast socket open/close
> -
>
> Key: DISPATCH-1876
> URL: https://issues.apache.org/jira/browse/DISPATCH-1876
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: Charles E. Rolke
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.15.0
>
>
> Single interior router serving a TCP listener and connector. Client program
> opens socket to TCP listener and then closes it immediately.
> Router log:
> {code:java}
> 2020-12-08 11:50:43.397341 -0500 ROUTER_CORE (info) [C2] Connection Opened:
> dir=in host=:::127.0.0.1 vhost= encrypted=no auth=no user=anonymous
> container_id=3ee9b2f3-e322-4244-a75f-4a80635d86bd
> props={:"console_identifier"="Dispatch console"}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:136)
> 2020-12-08 11:50:43.399576 -0500 ROUTER_CORE (info) [C2][L2] Link attached:
> dir=out source={(dyn) expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:50:43.400824 -0500 ROUTER_CORE (info) [C2][L3] Link attached:
> dir=in source={ expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:50:44.123816 -0500 ROUTER_CORE (info) [C3] Connection Opened:
> dir=in host=:::127.0.0.1 vhost= encrypted=no auth=no user=anonymous
> container_id=8f6f9427-2d89-2441-88ad-ace4dc0924d8
> props={:"console_identifier"="Dispatch console"}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:136)
> 2020-12-08 11:50:44.127284 -0500 ROUTER_CORE (info) [C3][L4] Link attached:
> dir=out source={(dyn) expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:50:44.129013 -0500 ROUTER_CORE (info) [C3][L5] Link attached:
> dir=in source={ expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:51:28.731328 -0500 TCP_ADAPTOR (info) PN_LISTENER_ACCEPT
> Accepting TCP connection on 0.0.0.0:29341
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:757)
> 2020-12-08 11:51:28.731531 -0500 ROUTER_CORE (info) [C4] Connection Opened:
> dir=in host=127.0.0.1:44454 vhost= encrypted=no auth=no user=
> container_id=TcpAdaptor props=
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:136)
> 2020-12-08 11:51:28.731832 -0500 ROUTER_CORE (info) [C4][L6] Link attached:
> dir=out source={(dyn) expire:link} target={ expire:link}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:51:28.731869 -0500 TCP_ADAPTOR (info) [C4]
> PN_RAW_CONNECTION_CONNECTED Ingress accepted to 0.0.0.0:29341 from
> 127.0.0.1:44454 (global_id=127.0.0.1:44454@mySite)
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:506)
> 2020-12-08 11:51:28.731898 -0500 ROUTER_CORE (info) [C4][L7] Link attached:
> dir=in source={ expire:link} target={ES_INTA expire:link}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:51:28.732042 -0500 TCP_ADAPTOR (info) [C5] Connecting to:
> 127.0.0.1:29340 (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:688)
> 2020-12-08 11:51:28.732062 -0500 TCP_ADAPTOR (info) [C4]
> PN_RAW_CONNECTION_DISCONNECTED
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:532)
> 2020-12-08 11:51:28.732126 -0500 ROUTER_CORE (info) [C4][L7] Link lost: del=1
> presett=1 psdrop=0 acc=0 rej=0 rel=0 mod=0 delay1=0 delay10=0 blocked=no
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1047)
> 2020-12-08 11:51:28.732150 -0500 ROUTER_CORE (info) [C4][L6] Link lost: del=0
> presett=0 psdrop=0 acc=0 rej=0 rel=0 mod=0 delay1=0 delay10=0 blocked=no
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1047)
> 2020-12-08 11:51:28.732166 -0500 ROUTER_CORE (info) [C4] Connection Closed
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1528)
> 2020-12-08 11:51:28.732296 -0500 TCP_ADAPTOR (info) [C5]
> PN_RAW_CONNECTION_CONNECTED Egress connected to 127.0.0.1:29340
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:511)
> 2020-12-08 11:51:28.732321 -0500 TCP_ADAPTOR (info) [C5] Opening server-side
> core connection 127.0.0.1:29340
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:608)
> 2
[jira] [Assigned] (DISPATCH-1876) TCP adaptor crash handling fast socket open/close
[
https://issues.apache.org/jira/browse/DISPATCH-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned DISPATCH-1876:
--
Assignee: Ted Ross
> TCP adaptor crash handling fast socket open/close
> -
>
> Key: DISPATCH-1876
> URL: https://issues.apache.org/jira/browse/DISPATCH-1876
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: Charles E. Rolke
>Assignee: Ted Ross
>Priority: Major
>
> Single interior router serving a TCP listener and connector. Client program
> opens socket to TCP listener and then closes it immediately.
> Router log:
> {code:java}
> 2020-12-08 11:50:43.397341 -0500 ROUTER_CORE (info) [C2] Connection Opened:
> dir=in host=:::127.0.0.1 vhost= encrypted=no auth=no user=anonymous
> container_id=3ee9b2f3-e322-4244-a75f-4a80635d86bd
> props={:"console_identifier"="Dispatch console"}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:136)
> 2020-12-08 11:50:43.399576 -0500 ROUTER_CORE (info) [C2][L2] Link attached:
> dir=out source={(dyn) expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:50:43.400824 -0500 ROUTER_CORE (info) [C2][L3] Link attached:
> dir=in source={ expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:50:44.123816 -0500 ROUTER_CORE (info) [C3] Connection Opened:
> dir=in host=:::127.0.0.1 vhost= encrypted=no auth=no user=anonymous
> container_id=8f6f9427-2d89-2441-88ad-ace4dc0924d8
> props={:"console_identifier"="Dispatch console"}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:136)
> 2020-12-08 11:50:44.127284 -0500 ROUTER_CORE (info) [C3][L4] Link attached:
> dir=out source={(dyn) expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:50:44.129013 -0500 ROUTER_CORE (info) [C3][L5] Link attached:
> dir=in source={ expire:sess} target={ expire:sess}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:51:28.731328 -0500 TCP_ADAPTOR (info) PN_LISTENER_ACCEPT
> Accepting TCP connection on 0.0.0.0:29341
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:757)
> 2020-12-08 11:51:28.731531 -0500 ROUTER_CORE (info) [C4] Connection Opened:
> dir=in host=127.0.0.1:44454 vhost= encrypted=no auth=no user=
> container_id=TcpAdaptor props=
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:136)
> 2020-12-08 11:51:28.731832 -0500 ROUTER_CORE (info) [C4][L6] Link attached:
> dir=out source={(dyn) expire:link} target={ expire:link}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:51:28.731869 -0500 TCP_ADAPTOR (info) [C4]
> PN_RAW_CONNECTION_CONNECTED Ingress accepted to 0.0.0.0:29341 from
> 127.0.0.1:44454 (global_id=127.0.0.1:44454@mySite)
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:506)
> 2020-12-08 11:51:28.731898 -0500 ROUTER_CORE (info) [C4][L7] Link attached:
> dir=in source={ expire:link} target={ES_INTA expire:link}
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1803)
> 2020-12-08 11:51:28.732042 -0500 TCP_ADAPTOR (info) [C5] Connecting to:
> 127.0.0.1:29340 (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:688)
> 2020-12-08 11:51:28.732062 -0500 TCP_ADAPTOR (info) [C4]
> PN_RAW_CONNECTION_DISCONNECTED
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:532)
> 2020-12-08 11:51:28.732126 -0500 ROUTER_CORE (info) [C4][L7] Link lost: del=1
> presett=1 psdrop=0 acc=0 rej=0 rel=0 mod=0 delay1=0 delay10=0 blocked=no
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1047)
> 2020-12-08 11:51:28.732150 -0500 ROUTER_CORE (info) [C4][L6] Link lost: del=0
> presett=0 psdrop=0 acc=0 rej=0 rel=0 mod=0 delay1=0 delay10=0 blocked=no
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1047)
> 2020-12-08 11:51:28.732166 -0500 ROUTER_CORE (info) [C4] Connection Closed
> (/home/chug/git/qpid-dispatch/src/router_core/connections.c:1528)
> 2020-12-08 11:51:28.732296 -0500 TCP_ADAPTOR (info) [C5]
> PN_RAW_CONNECTION_CONNECTED Egress connected to 127.0.0.1:29340
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:511)
> 2020-12-08 11:51:28.732321 -0500 TCP_ADAPTOR (info) [C5] Opening server-side
> core connection 127.0.0.1:29340
> (/home/chug/git/qpid-dispatch/src/adaptors/tcp_adaptor.c:608)
> 2020-12-08 11:51:28.732451 -0500 ROUTER_CORE (info) [C5] Connec
[jira] [Created] (DISPATCH-1872) TCP Adaptor mishandles dropped server connections.
Ted Ross created DISPATCH-1872: -- Summary: TCP Adaptor mishandles dropped server connections. Key: DISPATCH-1872 URL: https://issues.apache.org/jira/browse/DISPATCH-1872 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Ted Ross Assignee: Ted Ross If a server connection drops before the payload is processed, the tcp adaptor can crash or it can fail to release the delivery, causing the client to hang indefinitely. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1826) Various instabilities in the tcp protocol adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1826. Resolution: Fixed > Various instabilities in the tcp protocol adaptor > - > > Key: DISPATCH-1826 > URL: https://issues.apache.org/jira/browse/DISPATCH-1826 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Several instabilities and leaks have been discovered in the TCP protocol > adaptor: > * Temporary addresses accumulate in the core address table > * Race: and ingress message can be composed and sent before the reply-to > address is established > * Deliveries, messages, and buffers are held and leaked by the adaptor -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1826) Various instabilities in the tcp protocol adaptor
Ted Ross created DISPATCH-1826: -- Summary: Various instabilities in the tcp protocol adaptor Key: DISPATCH-1826 URL: https://issues.apache.org/jira/browse/DISPATCH-1826 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.15.0 Several instabilities and leaks have been discovered in the TCP protocol adaptor: * Temporary addresses accumulate in the core address table * Race: and ingress message can be composed and sent before the reply-to address is established * Deliveries, messages, and buffers are held and leaked by the adaptor -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1804) Add AMQ Footer support to Body Data API
[ https://issues.apache.org/jira/browse/DISPATCH-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1804: --- Fix Version/s: 1.15.0 > Add AMQ Footer support to Body Data API > > > Key: DISPATCH-1804 > URL: https://issues.apache.org/jira/browse/DISPATCH-1804 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors >Reporter: Ganesh Murthy >Assignee: Ted Ross >Priority: Major > Fix For: 1.15.0 > > > Process footers as part of the message Body Data API -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1804) Add AMQ Footer support to Body Data API
[ https://issues.apache.org/jira/browse/DISPATCH-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1804. Resolution: Fixed > Add AMQ Footer support to Body Data API > > > Key: DISPATCH-1804 > URL: https://issues.apache.org/jira/browse/DISPATCH-1804 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors >Reporter: Ganesh Murthy >Assignee: Ted Ross >Priority: Major > > Process footers as part of the message Body Data API -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1776) HTTP/2 - grpc call causes segfault
[
https://issues.apache.org/jira/browse/DISPATCH-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1776:
---
Fix Version/s: 1.15.0
> HTTP/2 - grpc call causes segfault
> --
>
> Key: DISPATCH-1776
> URL: https://issues.apache.org/jira/browse/DISPATCH-1776
> Project: Qpid Dispatch
> Issue Type: Sub-task
> Components: Protocol Adaptors
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.15.0
>
>
> Running a simple grpc echo (over http2) through the router causes a segfault.
> To reproduce run router with (you can change the ports if desired, just be
> consistent with the server and client):
> {noformat}
> router {
> mode: interior
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> httpListener {
> host: 0.0.0.0
> port: 9090
> address: foo
> protocolVersion: HTTP2
> }
> httpConnector {
> host: 127.0.0.1
> port: 8080
> address: foo
> protocolVersion: HTTP2
> }
> log {
> module: HTTP_ADAPTOR
> enable: trace+
> }
> {noformat}
> Then run grpc server with podman (or docker):
> {noformat}
> podman run -it -p8080:9000 quay.io/mhausenblas/yages:0.1.0
> {noformat}
> Then run grpc client, again with podman (or docker):
> {noformat}
> podman run -it --network=host quay.io/mhausenblas/gump:0.1 grpcurl
> --plaintext 127.0.0.1:9090 yages.Echo.Ping
> {noformat}
> I see segfault with following backtrace:
> {noformat}
> Thread 4 "qdrouterd" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffeedb5700 (LWP 3841832)]
> 0x77f4a417 in qd_compose_end_map () at
> /home/gordon/projects/dispatch/src/compose.c:179
> 179 DEQ_INSERT_HEAD(field->fieldStack, comp);
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-lib-2.1.27-2.fc31.x86_64 keyutils-libs-1.6-3.fc31.x86_64
> krb5-libs-1.17-46.fc31.x86_64 libcom_err-1.45.5-1.fc31.x86_64
> libev-4.27-1.fc31.x86_64 libffi-3.1-23.fc31.x86_64
> libnghttp2-1.41.0-1.fc31.x86_64 libselinux-2.9-5.fc31.x86_64
> libuv-1.34.2-1.fc31.x86_64 libwebsockets-3.2.1-1.fc31.x86_64
> libxcrypt-4.4.15-1.fc31.x86_64 openssl-libs-1.1.1d-2.fc31.x86_64
> pcre2-10.34-8.fc31.x86_64 python3-libs-3.7.6-2.fc31.x86_64
> zlib-1.2.11-20.fc31.x86_64
> (gdb) bt
> #0 0x77f4a417 in qd_compose_end_map () at
> /home/gordon/projects/dispatch/src/compose.c:179
> #1 0x77f4008a in on_frame_recv_callback (session=,
> frame=0x64ea70, user_data=0x64a308) at
> /home/gordon/projects/dispatch/src/adaptors/http2/http2_adaptor.c:702
> #2 0x77a8c32e in nghttp2_session_mem_recv () from
> /lib64/libnghttp2.so.14
> #3 0x77f41bdd in handle_incoming_http (conn=0x64a308) at
> /home/gordon/projects/dispatch/src/adaptors/http2/http2_adaptor.h:149
> #4 handle_connection_event (e=, qd_server=,
> context=0x64a308) at
> /home/gordon/projects/dispatch/src/adaptors/http2/http2_adaptor.c:1456
> #5 0x77f933f1 in handle_event_with_context (context=,
> qd_server=, e=) at
> /home/gordon/projects/dispatch/src/server.c:781
> #6 do_handle_raw_connection_event (qd_server=, e= out>) at /home/gordon/projects/dispatch/src/server.c:787
> #7 handle (qd_server=qd_server@entry=0x4371d0, e=e@entry=0x7fffe4000c20,
> pn_conn=pn_conn@entry=0x0, ctx=ctx@entry=0x0) at
> /home/gordon/projects/dispatch/src/server.c:1067
> #8 0x77f942c8 in thread_run (arg=0x4371d0) at
> /home/gordon/projects/dispatch/src/server.c:1099
> #9 0x77e7f4e2 in start_thread () from /lib64/libpthread.so.0
> #10 0x779b46d3 in clone () from /lib64/libc.so.6
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1724) Fallback destination fails when primary consumer is on an auto-link
[
https://issues.apache.org/jira/browse/DISPATCH-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned DISPATCH-1724:
--
Assignee: Charles E. Rolke
> Fallback destination fails when primary consumer is on an auto-link
> ---
>
> Key: DISPATCH-1724
> URL: https://issues.apache.org/jira/browse/DISPATCH-1724
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.12.0
>Reporter: Ted Ross
>Assignee: Charles E. Rolke
>Priority: Major
> Fix For: 1.13.0
>
> Attachments: DISPATCH-1724-problem.svg
>
>
> Fallback destination is failing for a scenario where it should be working.
> In the use case of interest, two message brokers are connected to a single
> router. One broker is designated primary and the other secondary. Both
> brokers have an instance of the same queue.
> The auto-link for enqueue to the primary broker is normal (on phase 0), the
> auto-link for enqueue to the secondary broker is designated as the fallback.
> In this case, if the primary broker is never connected but the secondary
> broker is, a sender for the address in question is never given credit to send.
> Test configuration:
> {code:java}
> address {
> pattern: FOO
> enableFallback: yes
> }
> connector {
> host: 127.0.0.1
> port: 1
> role: route-container
> name: primary
> }
> connector {
> host: 127.0.0.1
> port: 10001
> role: route-container
> name: secondary
> }
> autoLink {
> connection: primary
> dir: out
> addr: FOO
> }
> autoLink {
> connection: secondary
> dir: out
> addr: FOO
> fallback: yes
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1742) Plugin-API for protocol adaptors
[ https://issues.apache.org/jira/browse/DISPATCH-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1742: --- Component/s: Protocol Adaptors > Plugin-API for protocol adaptors > > > Key: DISPATCH-1742 > URL: https://issues.apache.org/jira/browse/DISPATCH-1742 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Protocol Adaptors > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: Backlog > > > This Jira tracks the creation of a protocol-adaptor API to be used in Qpid > Dispatch Router to implement protocol access from non-AMQP protocols. These > adaptors run in the I/O thread pool and use the services of the router-core > via the router-core API. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1502) large scale link disconnects can push memory up
[ https://issues.apache.org/jira/browse/DISPATCH-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross closed DISPATCH-1502. -- > large scale link disconnects can push memory up > --- > > Key: DISPATCH-1502 > URL: https://issues.apache.org/jira/browse/DISPATCH-1502 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim > Assignee: Ted Ross >Priority: Minor > Fix For: 1.11.0 > > > If a router has some connections with large numbers of links on them, and > these connections get suddenly disconnected, the memory for the router can > grow quite a bit in processing the link disconnects (>30% in some cases). > The cause is that there are a large number of qdr_action_t and > qdr_general_work_t instances used as the work is passed from worker thread to > core and back to a worker thread again. As this happens very rapidly > instances are not returned to the pool before more are needed so the pool > grows (in my experiments it was growing by close to the number of links > involved). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1502) large scale link disconnects can push memory up
[ https://issues.apache.org/jira/browse/DISPATCH-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1502. Resolution: Won't Fix Closing. This is likely fixed by https://issues.apache.org/jira/browse/DISPATCH-1532. > large scale link disconnects can push memory up > --- > > Key: DISPATCH-1502 > URL: https://issues.apache.org/jira/browse/DISPATCH-1502 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim > Assignee: Ted Ross >Priority: Minor > Fix For: 1.13.0 > > > If a router has some connections with large numbers of links on them, and > these connections get suddenly disconnected, the memory for the router can > grow quite a bit in processing the link disconnects (>30% in some cases). > The cause is that there are a large number of qdr_action_t and > qdr_general_work_t instances used as the work is passed from worker thread to > core and back to a worker thread again. As this happens very rapidly > instances are not returned to the pool before more are needed so the pool > grows (in my experiments it was growing by close to the number of links > involved). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1502) large scale link disconnects can push memory up
[ https://issues.apache.org/jira/browse/DISPATCH-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1502: --- Fix Version/s: (was: 1.13.0) 1.11.0 > large scale link disconnects can push memory up > --- > > Key: DISPATCH-1502 > URL: https://issues.apache.org/jira/browse/DISPATCH-1502 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim > Assignee: Ted Ross >Priority: Minor > Fix For: 1.11.0 > > > If a router has some connections with large numbers of links on them, and > these connections get suddenly disconnected, the memory for the router can > grow quite a bit in processing the link disconnects (>30% in some cases). > The cause is that there are a large number of qdr_action_t and > qdr_general_work_t instances used as the work is passed from worker thread to > core and back to a worker thread again. As this happens very rapidly > instances are not returned to the pool before more are needed so the pool > grows (in my experiments it was growing by close to the number of links > involved). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1742) Plugin-API for protocol adaptors
Ted Ross created DISPATCH-1742: -- Summary: Plugin-API for protocol adaptors Key: DISPATCH-1742 URL: https://issues.apache.org/jira/browse/DISPATCH-1742 Project: Qpid Dispatch Issue Type: New Feature Reporter: Ted Ross Assignee: Ted Ross Fix For: Backlog This Jira tracks the creation of a protocol-adaptor API to be used in Qpid Dispatch Router to implement protocol access from non-AMQP protocols. These adaptors run in the I/O thread pool and use the services of the router-core via the router-core API. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1724) Fallback destination fails when primary consumer is on an auto-link
[
https://issues.apache.org/jira/browse/DISPATCH-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1724:
---
Description:
Fallback destination is failing for a scenario where it should be working. In
the use case of interest, two message brokers are connected to a single router.
One broker is designated primary and the other secondary. Both brokers have
an instance of the same queue.
The auto-link for enqueue to the primary broker is normal (on phase 0), the
auto-link for enqueue to the secondary broker is designated as the fallback.
In this case, if the primary broker is never connected but the secondary broker
is, a sender for the address in question is never given credit to send.
Test configuration:
{code:java}
address {
pattern: FOO
enableFallback: yes
}
connector {
host: 127.0.0.1
port: 1
role: route-container
name: primary
}
connector {
host: 127.0.0.1
port: 10001
role: route-container
name: secondary
}
autoLink {
connection: primary
dir: out
addr: FOO
}
autoLink {
connection: secondary
dir: out
addr: FOO
fallback: yes
}
{code}
was:
Fallback destination is failing for a scenario where it should be working. In
the use case of interest, two message brokers are connected to a single router.
One broker is designated primary and the other secondary. Both brokers have
an instance of the same queue.
The auto-link for enqueue to the primary broker is normal (on phase 0), the
auto-link for enqueue to the secondary broker is designated at the fallback.
In this case, if the primary broker is never connected but the secondary broker
is, a sender for the address in question is never given credit to send.
Test configuration:
{code}
address {
pattern: FOO
enableFallback: yes
}
connector {
host: 127.0.0.1
port: 1
role: route-container
name: primary
}
connector {
host: 127.0.0.1
port: 10001
role: route-container
name: secondary
}
autoLink {
connection: primary
dir: out
addr: FOO
}
autoLink {
connection: secondary
dir: out
addr: FOO
fallback: yes
}
{code}
> Fallback destination fails when primary consumer is on an auto-link
> ---
>
> Key: DISPATCH-1724
> URL: https://issues.apache.org/jira/browse/DISPATCH-1724
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.12.0
>Reporter: Ted Ross
>Priority: Major
> Fix For: 1.13.0
>
>
> Fallback destination is failing for a scenario where it should be working.
> In the use case of interest, two message brokers are connected to a single
> router. One broker is designated primary and the other secondary. Both
> brokers have an instance of the same queue.
> The auto-link for enqueue to the primary broker is normal (on phase 0), the
> auto-link for enqueue to the secondary broker is designated as the fallback.
> In this case, if the primary broker is never connected but the secondary
> broker is, a sender for the address in question is never given credit to send.
> Test configuration:
> {code:java}
> address {
> pattern: FOO
> enableFallback: yes
> }
> connector {
> host: 127.0.0.1
> port: 1
> role: route-container
> name: primary
> }
> connector {
> host: 127.0.0.1
> port: 10001
> role: route-container
> name: secondary
> }
> autoLink {
> connection: primary
> dir: out
> addr: FOO
> }
> autoLink {
> connection: secondary
> dir: out
> addr: FOO
> fallback: yes
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1724) Fallback destination fails when primary consumer is on an auto-link
Ted Ross created DISPATCH-1724:
--
Summary: Fallback destination fails when primary consumer is on an
auto-link
Key: DISPATCH-1724
URL: https://issues.apache.org/jira/browse/DISPATCH-1724
Project: Qpid Dispatch
Issue Type: Bug
Components: Router Node
Affects Versions: 1.12.0
Reporter: Ted Ross
Fix For: 1.13.0
Fallback destination is failing for a scenario where it should be working. In
the use case of interest, two message brokers are connected to a single router.
One broker is designated primary and the other secondary. Both brokers have
an instance of the same queue.
The auto-link for enqueue to the primary broker is normal (on phase 0), the
auto-link for enqueue to the secondary broker is designated at the fallback.
In this case, if the primary broker is never connected but the secondary broker
is, a sender for the address in question is never given credit to send.
Test configuration:
{code}
address {
pattern: FOO
enableFallback: yes
}
connector {
host: 127.0.0.1
port: 1
role: route-container
name: primary
}
connector {
host: 127.0.0.1
port: 10001
role: route-container
name: secondary
}
autoLink {
connection: primary
dir: out
addr: FOO
}
autoLink {
connection: secondary
dir: out
addr: FOO
fallback: yes
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-383) Intermittent router crashes when restarting one router in the network with different number of threads
[ https://issues.apache.org/jira/browse/DISPATCH-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-383: -- Priority: Major (was: Critical) > Intermittent router crashes when restarting one router in the network with > different number of threads > -- > > Key: DISPATCH-383 > URL: https://issues.apache.org/jira/browse/DISPATCH-383 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Vishal Sharda >Assignee: Ganesh Murthy >Priority: Major > Fix For: Backlog > > Attachments: Crash_route_tables_1.png, Crash_route_tables_2.png, > Crash_route_tables_3.png > > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL. > Stopping one router in the network, changing its number of threads in the > configuration file and starting it again to join the network causes > intermittent crash in other routers in the network. > I was able to reproduce the crash three times and collect the backtraces > inside gdb (screenshots attached). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-358) Intermittent crashes in qdrouterd under load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-358: -- Priority: Major (was: Critical) > Intermittent crashes in qdrouterd under load from parallel senders > -- > > Key: DISPATCH-358 > URL: https://issues.apache.org/jira/browse/DISPATCH-358 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Major > Fix For: Backlog > > Attachments: Crash_EXTERNAL.png, Crash_Java_Router_3.png, > Crash_Java_Send.png, Crash_Java_free_qd_connection.png, > Crash_Java_same_router.png, Crash_Java_same_router_another.png, > Crash_Java_same_router_another_bt.png, Crash_SASL.png, Crash_SASL_2.png, > Crash_SR_1.png, Crash_SR_2.png, Crash_bt_double_free_Java_RES_266MB.png, > Crash_double_free_Java_RES_266MB.png, Crash_free.png, > Crash_sasl_server_done.png, Crash_watch_qdstat.png, Overflow_Error.png > > > In my setup of two inter-connected routers, several senders connecting to one > router while few receivers connecting to the other router, I see several > crashes in the router to which senders connect. These crashes are > intermittent and happen once in every 10 runs or so. I have collected the > backtraces of all the crashes but do not yet have a test case that can > reliably reproduce any of them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-337) Huge memory leaks in Qpid Dispatch router
[ https://issues.apache.org/jira/browse/DISPATCH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-337: -- Priority: Major (was: Critical) > Huge memory leaks in Qpid Dispatch router > - > > Key: DISPATCH-337 > URL: https://issues.apache.org/jira/browse/DISPATCH-337 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Major > Labels: memory-bug > Fix For: Backlog > > Attachments: LNP-1_Huge_memory.png, LNP-1_Leak_starts.png, > LNP-1_not_accepting_connections.png, Memory_usage_first_run_no_SSL.png, > Memory_usage_subsequent_run_no_SSL.png, Rapid_perm_memory_increase.png, > Subsequent_memory_increase.png, Tim-Router-3-huge-memory-usage.png, > Tim_Router_3.png, Tim_Routers_3_and_6_further_leaks.png, config1.conf, > config2.conf, val2_receiver.txt, val2_sender.txt > > > Valgrind shows huge memory leaks while running 2 interconnected routers with > 2 parallel senders connected to the one router and 2 parallel receivers > connected to the other router. > The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here: > https://issues.apache.org/jira/browse/PROTON-1115 > However, the rest of the leaks are from qdrouterd. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-382) Intermittent router crash when starting 50 receivers/0 senders and doing qdstat
[ https://issues.apache.org/jira/browse/DISPATCH-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross closed DISPATCH-382. - Fix Version/s: (was: Backlog) Resolution: Cannot Reproduce > Intermittent router crash when starting 50 receivers/0 senders and doing > qdstat > --- > > Key: DISPATCH-382 > URL: https://issues.apache.org/jira/browse/DISPATCH-382 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Crash_in_Valgrind_1.png, Crash_in_Valgrind_2.png, > Crash_in_Valgrind_3.png, Crash_in_Valgrind_3.txt, val_crash_1.txt, > val_crash_2.txt > > > Network: A network of 3 interior routers built from trunk and connected to > each other using 2-way SSL. > We ran a Proton-J Reactor API based client to start 50 receivers and 0 > senders on one of the above 3 routers. After that we ran "qdstat -c". This > leads to intermittent crash in the router. This crash could not be > reproduced while running the routers independently or inside gdb. When we > run the routers inside Valgrind, this crash is frequent. I was able to > reproduce the crash 3 times using Valgrind (Screenshots and Valgrind output > files are attached). > This intermittent crash becomes permanent in our instrumented build. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1659) Deprecate bespoke config file format for proper JSON
[ https://issues.apache.org/jira/browse/DISPATCH-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112186#comment-17112186 ] Ted Ross commented on DISPATCH-1659: One problem with "proper" JSON is that comments cannot be included in the text. I'm not sure how much of a problem this is but it was a major consideration in the selection of the current format. If we're considering making an incompatible change to the config format, we should probably also consider using YAML for the new format. > Deprecate bespoke config file format for proper JSON > > > Key: DISPATCH-1659 > URL: https://issues.apache.org/jira/browse/DISPATCH-1659 > Project: Qpid Dispatch > Issue Type: Wish > Components: Management Agent >Affects Versions: 1.12.0 >Reporter: Ken Giusti >Priority: Minor > Fix For: 2.0.0, Backlog > > > The format of the qdrouterd.config file is not JSON compliant. Instead it is > some bespoke quasi subset of JSON with custom comment syntax and whitespace > formatting restrictions. > This bespoke format has (at least) two disadvantages: > 1) users cannot leverage the plethora of JSON tooling available for config > generation > 2) increased development/maintenance effort to support the bespoke format. > This is a proposal to deprecate support for the non-JSON configuration file > format in favor of a JSON compliant file format. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1519) add way to have router reload config file
[ https://issues.apache.org/jira/browse/DISPATCH-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1519: -- Assignee: Charles E. Rolke > add way to have router reload config file > - > > Key: DISPATCH-1519 > URL: https://issues.apache.org/jira/browse/DISPATCH-1519 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Charles E. Rolke >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1651) Update management schema to include protocol bridges
[ https://issues.apache.org/jira/browse/DISPATCH-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1651: -- Assignee: Gordon Sim > Update management schema to include protocol bridges > > > Key: DISPATCH-1651 > URL: https://issues.apache.org/jira/browse/DISPATCH-1651 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: Backlog > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1646) Unable to delete listener with http enabled
[ https://issues.apache.org/jira/browse/DISPATCH-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1646: -- Assignee: Ganesh Murthy > Unable to delete listener with http enabled > --- > > Key: DISPATCH-1646 > URL: https://issues.apache.org/jira/browse/DISPATCH-1646 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ulf Lilleengen >Assignee: Ganesh Murthy >Priority: Major > > I'm running into an issue when trying to delete a listener which has 'http: > true' set. The router returns the error message "HTTP listeners cannot be > deleted". I can see that there is a test for this in the router code as well. > However, in order for EnMasse to be able to create and delete listeners that > are used to handle websocket connections for different tenants, we need a way > to delete listeners with http: true set through AMQP management without > restarting the router. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1651) Update management schema to include protocol bridges
[ https://issues.apache.org/jira/browse/DISPATCH-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1651: --- Fix Version/s: Backlog > Update management schema to include protocol bridges > > > Key: DISPATCH-1651 > URL: https://issues.apache.org/jira/browse/DISPATCH-1651 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Priority: Major > Fix For: Backlog > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1652) Define internal interfaces for protocol plugins
[ https://issues.apache.org/jira/browse/DISPATCH-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1652: -- Assignee: Ted Ross > Define internal interfaces for protocol plugins > --- > > Key: DISPATCH-1652 > URL: https://issues.apache.org/jira/browse/DISPATCH-1652 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim > Assignee: Ted Ross >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-781) Tie end-to-end flow control of message-routed deliveries to outgoing capacity
[ https://issues.apache.org/jira/browse/DISPATCH-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-781: -- Fix Version/s: (was: Backlog) 1.13.0 > Tie end-to-end flow control of message-routed deliveries to outgoing capacity > - > > Key: DISPATCH-781 > URL: https://issues.apache.org/jira/browse/DISPATCH-781 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node, Routing Engine > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.13.0 > > > This feature reverses the management of incoming credit for message-routed > deliveries. > The current mechanism is based on the the capacity of the incoming > (sender-client) links. Each attached sender is given credit equal to the > configured link capacity regardless of the capacity of outgoing > (receiver-client) links for the same address. This means that even under > congestion, a newly attached sender will get full capacity credit to send. > The proposed mechanism is based not on incoming capacity but on outgoing > capacity. In this case, the senders are provided a share of the total > outgoing capacity for an address. As the number of incoming links (senders) > for an address changes and the total capacity for outgoing links changes, the > credit window of the senders shall be adjusted. > The proposal is a heuristic approach. It does not revoke credit from senders > (but will limit the number of credits that are replenished). It will also > not deny credit if there are more incoming links than outgoing capacity. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1611) In debug mode, provide time and backtrace of leaked pool allocations
[ https://issues.apache.org/jira/browse/DISPATCH-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1611. Resolution: Fixed > In debug mode, provide time and backtrace of leaked pool allocations > > > Key: DISPATCH-1611 > URL: https://issues.apache.org/jira/browse/DISPATCH-1611 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.12.0 > > > Leaked allocations from pooled objects are not accurately reported by tools > like the ASAN address sanitizer. This feature adds a backtrace and timestamp > for the actual allocation of the leaked object as an aid to debugging. It is > only enabled in debug builds. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1611) In debug mode, provide time and backtrace of leaked pool allocations
Ted Ross created DISPATCH-1611: -- Summary: In debug mode, provide time and backtrace of leaked pool allocations Key: DISPATCH-1611 URL: https://issues.apache.org/jira/browse/DISPATCH-1611 Project: Qpid Dispatch Issue Type: Improvement Components: Container Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.12.0 Leaked allocations from pooled objects are not accurately reported by tools like the ASAN address sanitizer. This feature adds a backtrace and timestamp for the actual allocation of the leaked object as an aid to debugging. It is only enabled in debug builds. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1585) Allow specifying address/source/target to be used for a multitenant listener
[ https://issues.apache.org/jira/browse/DISPATCH-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068927#comment-17068927 ] Ted Ross commented on DISPATCH-1585: Could you provide a concrete example of how this proposed feature would be used? Re-using addresses seems like it would defeat the purpose of multi-tenancy. > Allow specifying address/source/target to be used for a multitenant listener > > > Key: DISPATCH-1585 > URL: https://issues.apache.org/jira/browse/DISPATCH-1585 > Project: Qpid Dispatch > Issue Type: Wish >Reporter: Ulf Lilleengen >Priority: Major > > At present, a multitenant router listener will prefix addresses with the > hostname in the AMQP Open. However, given a configuration where it is > desirable to expose a router address space for multiple DNS names, any > address, linkRoute and autoLink configuration will need to be duplicated for > each DNS name. This complicates router configuration significantly. > > Instead, having a way to specify which prefix to apply for a multitenant > listener would allow reusing the same address, autoLink and linkRoute > configuration for multiple listeners. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1571) Ability to retreive only certain type of link and connection
[ https://issues.apache.org/jira/browse/DISPATCH-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066004#comment-17066004 ] Ted Ross commented on DISPATCH-1571: What are the specific subsets of specific tables that are desired? > Ability to retreive only certain type of link and connection > > > Key: DISPATCH-1571 > URL: https://issues.apache.org/jira/browse/DISPATCH-1571 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Priority: Major > > E.g. just inter-router links/connections or router-control links. In cases > with large numbers of links or connections this would make simple checks more > efficient. > Could be a generic filtering capability or even just some specific calls for > the different subtypes -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1582) Prepare Routing Protocol for Backward Compatibility
[ https://issues.apache.org/jira/browse/DISPATCH-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1582. Resolution: Fixed > Prepare Routing Protocol for Backward Compatibility > --- > > Key: DISPATCH-1582 > URL: https://issues.apache.org/jira/browse/DISPATCH-1582 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.11.0 > > > In anticipation of moving to routing protocol version 2 (we're currently on > 1), there are a few changes needed to make it easy for version 2 to be > backward compatible to version 1. This Jira will track those changes. > The proposed change is to ensure that a version 1 router ignores version >1 > messages, issuing a low-volume warning log when one is received. This way, a > version 2 router can send both versions or send targeted versions based on > its knowledge of peer routers protocol versions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1582) Prepare Routing Protocol for Backward Compatibility
Ted Ross created DISPATCH-1582: -- Summary: Prepare Routing Protocol for Backward Compatibility Key: DISPATCH-1582 URL: https://issues.apache.org/jira/browse/DISPATCH-1582 Project: Qpid Dispatch Issue Type: Improvement Components: Routing Engine Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.11.0 In anticipation of moving to routing protocol version 2 (we're currently on 1), there are a few changes needed to make it easy for version 2 to be backward compatible to version 1. This Jira will track those changes. The proposed change is to ensure that a version 1 router ignores version >1 messages, issuing a low-volume warning log when one is received. This way, a version 2 router can send both versions or send targeted versions based on its knowledge of peer routers protocol versions. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1551) Mobile addresses can get out of sync (DISPATCH-1532 regression)
[ https://issues.apache.org/jira/browse/DISPATCH-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1551. Resolution: Fixed > Mobile addresses can get out of sync (DISPATCH-1532 regression) > --- > > Key: DISPATCH-1551 > URL: https://issues.apache.org/jira/browse/DISPATCH-1551 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.11.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.11.0 > > > There's a defect in the new implementation of mobile-address-sync > (DISPATCH-1532) that can cause a router to accept a differential update (MAU) > when that update is not one sequence value ahead of the current state. In > this case, the updated deltas are not applied to a known base state and can > result in incorrect final state. > This defect does not exist in version 1.10.0 nor any other released version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1551) Mobile addresses can get out of sync (DISPATCH-1532 regression)
Ted Ross created DISPATCH-1551: -- Summary: Mobile addresses can get out of sync (DISPATCH-1532 regression) Key: DISPATCH-1551 URL: https://issues.apache.org/jira/browse/DISPATCH-1551 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.11.0 Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.11.0 There's a defect in the new implementation of mobile-address-sync (DISPATCH-1532) that can cause a router to accept a differential update (MAU) when that update is not one sequence value ahead of the current state. In this case, the updated deltas are not applied to a known base state and can result in incorrect final state. This defect does not exist in version 1.10.0 nor any other released version. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1545) Streaming deliveries can be delayed by head-of-line blocking on inter-router links
[ https://issues.apache.org/jira/browse/DISPATCH-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1545: -- Assignee: Ken Giusti (was: Ted Ross) > Streaming deliveries can be delayed by head-of-line blocking on inter-router > links > -- > > Key: DISPATCH-1545 > URL: https://issues.apache.org/jira/browse/DISPATCH-1545 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.10.0 >Reporter: Ted Ross >Assignee: Ken Giusti >Priority: Major > Fix For: 1.11.0 > > > Message-routed deliveries (for the same priority) are forwarded over the same > inter-router link when moving from router to router. If a streaming delivery > is flowing over such a link, subsequent deliveries on that link will be > delayed until the streaming delivery is complete. A solution is needed that > allows an arbitrary number of streaming deliveries to concurrently flow from > router to router. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1532) Reimplement mobile-sync as a core module
[ https://issues.apache.org/jira/browse/DISPATCH-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1532. Resolution: Fixed > Reimplement mobile-sync as a core module > > > Key: DISPATCH-1532 > URL: https://issues.apache.org/jira/browse/DISPATCH-1532 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.11.0 > > > The code in Qpid Dispatch Router currently does mobile address > synchronization between routers in the Python router module. This has a > couple of drawbacks in cases where there are large numbers of addresses: > * The address strings are stored twice: once in the main address lookup > hash table and again in the Python mobile address module. > * Address lookup on the Python side is inefficient and has been a bottleneck > (improved recently by a patch from Gordon Sim). > * Python processing is single threaded. A large mobile address update can > cause delays in processing management requests and link-state topology > maintenance. > The python router module was intended to be an on-the-side control-plane > module that was not in the critical path for any performance-related > activities. With large numbers of addresses in a network, synchronizing > address locations becomes performance-related. > To address these issues, mobile address synchronization can be moved into a > core module where it can use and share the same address table that is used by > the router core for making high speed routing decisions. In the process, it > will leave the python modules alone to process management requests and > topology maintenance uninterrupted. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1532) Reimplement mobile-sync as a core module
[ https://issues.apache.org/jira/browse/DISPATCH-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1532: --- Description: The code in Qpid Dispatch Router currently does mobile address synchronization between routers in the Python router module. This has a couple of drawbacks in cases where there are large numbers of addresses: * The address strings are stored twice: once in the main address lookup hash table and again in the Python mobile address module. * Address lookup on the Python side is inefficient and has been a bottleneck (improved recently by a patch from Gordon Sim). * Python processing is single threaded. A large mobile address update can cause delays in processing management requests and link-state topology maintenance. The python router module was intended to be an on-the-side control-plane module that was not in the critical path for any performance-related activities. With large numbers of addresses in a network, synchronizing address locations becomes performance-related. To address these issues, mobile address synchronization can be moved into a core module where it can use and share the same address table that is used by the router core for making high speed routing decisions. In the process, it will leave the python modules alone to process management requests and topology maintenance uninterrupted. was: The code in Qpid Dispatch Router currently does mobile address synchronization between routers in the Python router module. This has a couple of drawbacks in cases where there are large numbers of addresses: * The address strings are stored twice: once in the main address lookup hash table and again in the Python mobile address module. * Address lookup on the Python side is inefficient and has been a bottleneck (improved recently by a patch from Gordon Sim). * Python processing is single threaded. A large mobile address update can cause delays in processing management requests and link-state topology maintenance. The python router module was intended to be an on-the-side control-plane moduel that was not in the critical path for any performance-related activities. With large numbers of addresses in a network, synchronizing address locations becomes performance-related. To address these issues, mobile address synchronization can be moved into a core module where it can use and share the same address table that is used by the router core for make high speed routing decisions. In the process, it will leave the python modules alone to process management requests and topology maintenance uninterrupted. > Reimplement mobile-sync as a core module > > > Key: DISPATCH-1532 > URL: https://issues.apache.org/jira/browse/DISPATCH-1532 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.11.0 > > > The code in Qpid Dispatch Router currently does mobile address > synchronization between routers in the Python router module. This has a > couple of drawbacks in cases where there are large numbers of addresses: > * The address strings are stored twice: once in the main address lookup > hash table and again in the Python mobile address module. > * Address lookup on the Python side is inefficient and has been a bottleneck > (improved recently by a patch from Gordon Sim). > * Python processing is single threaded. A large mobile address update can > cause delays in processing management requests and link-state topology > maintenance. > The python router module was intended to be an on-the-side control-plane > module that was not in the critical path for any performance-related > activities. With large numbers of addresses in a network, synchronizing > address locations becomes performance-related. > To address these issues, mobile address synchronization can be moved into a > core module where it can use and share the same address table that is used by > the router core for making high speed routing decisions. In the process, it > will leave the python modules alone to process management requests and > topology maintenance uninterrupted. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1545) Streaming deliveries can be delayed by head-of-line blocking on inter-router links
Ted Ross created DISPATCH-1545: -- Summary: Streaming deliveries can be delayed by head-of-line blocking on inter-router links Key: DISPATCH-1545 URL: https://issues.apache.org/jira/browse/DISPATCH-1545 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.10.0 Reporter: Ted Ross Assignee: Ted Ross Message-routed deliveries (for the same priority) are forwarded over the same inter-router link when moving from router to router. If a streaming delivery is flowing over such a link, subsequent deliveries on that link will be delayed until the streaming delivery is complete. A solution is needed that allows an arbitrary number of streaming deliveries to concurrently flow from router to router. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1545) Streaming deliveries can be delayed by head-of-line blocking on inter-router links
[ https://issues.apache.org/jira/browse/DISPATCH-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1545: --- Fix Version/s: 1.11.0 > Streaming deliveries can be delayed by head-of-line blocking on inter-router > links > -- > > Key: DISPATCH-1545 > URL: https://issues.apache.org/jira/browse/DISPATCH-1545 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.10.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.11.0 > > > Message-routed deliveries (for the same priority) are forwarded over the same > inter-router link when moving from router to router. If a streaming delivery > is flowing over such a link, subsequent deliveries on that link will be > delayed until the streaming delivery is complete. A solution is needed that > allows an arbitrary number of streaming deliveries to concurrently flow from > router to router. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1532) Reimplement mobile-sync as a core module
Ted Ross created DISPATCH-1532: -- Summary: Reimplement mobile-sync as a core module Key: DISPATCH-1532 URL: https://issues.apache.org/jira/browse/DISPATCH-1532 Project: Qpid Dispatch Issue Type: Improvement Components: Routing Engine Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.11.0 The code in Qpid Dispatch Router currently does mobile address synchronization between routers in the Python router module. This has a couple of drawbacks in cases where there are large numbers of addresses: * The address strings are stored twice: once in the main address lookup hash table and again in the Python mobile address module. * Address lookup on the Python side is inefficient and has been a bottleneck (improved recently by a patch from Gordon Sim). * Python processing is single threaded. A large mobile address update can cause delays in processing management requests and link-state topology maintenance. The python router module was intended to be an on-the-side control-plane moduel that was not in the critical path for any performance-related activities. With large numbers of addresses in a network, synchronizing address locations becomes performance-related. To address these issues, mobile address synchronization can be moved into a core module where it can use and share the same address table that is used by the router core for make high speed routing decisions. In the process, it will leave the python modules alone to process management requests and topology maintenance uninterrupted. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1509) Leak of core agent timer
[ https://issues.apache.org/jira/browse/DISPATCH-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1509: -- Assignee: Ken Giusti (was: Ted Ross) > Leak of core agent timer > > > Key: DISPATCH-1509 > URL: https://issues.apache.org/jira/browse/DISPATCH-1509 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.9.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Trivial > Fix For: 1.11.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1509) Leak of core agent timer
[ https://issues.apache.org/jira/browse/DISPATCH-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1509: -- Assignee: Ted Ross (was: Ken Giusti) > Leak of core agent timer > > > Key: DISPATCH-1509 > URL: https://issues.apache.org/jira/browse/DISPATCH-1509 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.9.0 >Reporter: Ken Giusti >Assignee: Ted Ross >Priority: Trivial > Fix For: 1.11.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1483) Link counters for dispositions are not incremented for outgoing links
Ted Ross created DISPATCH-1483: -- Summary: Link counters for dispositions are not incremented for outgoing links Key: DISPATCH-1483 URL: https://issues.apache.org/jira/browse/DISPATCH-1483 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.9.0 Reporter: Ted Ross Fix For: 1.10.0 When transferring messages across a router with the deliveries being accepted by the receiver, the deliveries-accepted counter for the _outgoing_ link are not incremented. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1409) Update qdstat -l output to include the current credit
[ https://issues.apache.org/jira/browse/DISPATCH-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1409. Fix Version/s: 1.10.0 Resolution: Fixed > Update qdstat -l output to include the current credit > - > > Key: DISPATCH-1409 > URL: https://issues.apache.org/jira/browse/DISPATCH-1409 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node, Tools >Affects Versions: 1.8.0 >Reporter: Ken Giusti >Assignee: Ted Ross >Priority: Major > Labels: troubleshooting > Fix For: 1.10.0 > > > The (cap) field in the output of qdstat -l shows the configured capacity for > the link, not the current credit available/outstanding. > In order to easily detect credit stalls it would be useful to provide the > current credit for the link. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1463) Detect deliveries that are stuck in the router for a long time
[ https://issues.apache.org/jira/browse/DISPATCH-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1463. Resolution: Fixed > Detect deliveries that are stuck in the router for a long time > -- > > Key: DISPATCH-1463 > URL: https://issues.apache.org/jira/browse/DISPATCH-1463 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.10.0 > > > The delayed-delivery counts are limited in that they only count deliveries > that have been settled. These counters do not count deliveries that are > currently "stuck" and have not been settled. > This feature provides visibility into the number of stuck deliveries per link > and per router. > A new counter "deliveriesStuck" shall be added to the link and router > entities for per-link and aggregated-per-router respectively. > A delivery is considered "stuck" when it has been in the undelivered or > unsettled lists for more than ten seconds and is still not settled. Once a > stuck delivery is settled or otherwise removed, it is no longer considered > stuck. > When a link transitions from zero to one stuck delivery, an INFO log message > shall be emitted indicating that at least one delivery is stuck on that link. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1439) Expose create time/last transfer time through the Connection management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961035#comment-16961035 ] Ted Ross edited comment on DISPATCH-1439 at 10/29/19 1:52 PM: -- [~kwall] What kind of timestamps are desired/acceptable for this feature? Do you want to correlate the time to log entries? Is it acceptable to have "seconds since connection creation" and "seconds since last transfer"? The latter is more efficient to implement. was (Author: tedross): What kind of timestamps are desired/acceptable for this feature? Do you want to correlate the time to log entries? Is it acceptable to have "seconds since connection creation" and "seconds since last transfer"? The latter is more efficient to implement. > Expose create time/last transfer time through the Connection management entity > -- > > Key: DISPATCH-1439 > URL: https://issues.apache.org/jira/browse/DISPATCH-1439 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > Having these two additional attributes: > * connection create time > * connection last transfer time > would aid fault finding activities. > It would also serve as useful input to external tooling wishing to say, > balance connections to a router network. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1409) Update qdstat -l output to include the current credit
[ https://issues.apache.org/jira/browse/DISPATCH-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-1409: -- Assignee: Ted Ross > Update qdstat -l output to include the current credit > - > > Key: DISPATCH-1409 > URL: https://issues.apache.org/jira/browse/DISPATCH-1409 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node, Tools >Affects Versions: 1.8.0 >Reporter: Ken Giusti >Assignee: Ted Ross >Priority: Major > Labels: troubleshooting > > The (cap) field in the output of qdstat -l shows the configured capacity for > the link, not the current credit available/outstanding. > In order to easily detect credit stalls it would be useful to provide the > current credit for the link. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1439) Expose create time/last transfer time through the Connection management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961035#comment-16961035 ] Ted Ross commented on DISPATCH-1439: What kind of timestamps are desired/acceptable for this feature? Do you want to correlate the time to log entries? Is it acceptable to have "seconds since connection creation" and "seconds since last transfer"? The latter is more efficient to implement. > Expose create time/last transfer time through the Connection management entity > -- > > Key: DISPATCH-1439 > URL: https://issues.apache.org/jira/browse/DISPATCH-1439 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > Having these two additional attributes: > * connection create time > * connection last transfer time > would aid fault finding activities. > It would also serve as useful input to external tooling wishing to say, > balance connections to a router network. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1463) Detect deliveries that are stuck in the router for a long time
Ted Ross created DISPATCH-1463: -- Summary: Detect deliveries that are stuck in the router for a long time Key: DISPATCH-1463 URL: https://issues.apache.org/jira/browse/DISPATCH-1463 Project: Qpid Dispatch Issue Type: New Feature Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.10.0 The delayed-delivery counts are limited in that they only count deliveries that have been settled. These counters do not count deliveries that are currently "stuck" and have not been settled. This feature provides visibility into the number of stuck deliveries per link and per router. A new counter "deliveriesStuck" shall be added to the link and router entities for per-link and aggregated-per-router respectively. A delivery is considered "stuck" when it has been in the undelivered or unsettled lists for more than ten seconds and is still not settled. Once a stuck delivery is settled or otherwise removed, it is no longer considered stuck. When a link transitions from zero to one stuck delivery, an INFO log message shall be emitted indicating that at least one delivery is stuck on that link. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1442) Add a metadata field to the router management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1442. Resolution: Fixed > Add a metadata field to the router management entity > > > Key: DISPATCH-1442 > URL: https://issues.apache.org/jira/browse/DISPATCH-1442 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Management Agent > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.10.0 > > > This improvement adds a new attribute to the router entity called "metadata". > This field is an opaque string that is set during configuration and can be > queried or read at any time via the management protocol. > This field can be used by the user, the console, or controlling orchestration > layers to store identifying information about the router instance. > Examples of the kind of data that can be store in the metadata include but > are not limited to: public cloud availability zone, geographic map > coordinates, a user-friendly label, administrative owner, display color, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1442) Add a metadata field to the router management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1442: --- Description: This improvement adds a new attribute to the router entity called "metadata". This field is an opaque string that is set during configuration and can be queried or read at any time via the management protocol. This field can be used by the user, the console, or controlling orchestration layers to store identifying information about the router instance. Examples of the kind of data that can be store in the metadata include but are not limited to: public cloud availability zone, geographic map coordinates, a user-friendly label, administrative owner, display color, etc. was: This improvement adds a new attribute to the router entity called "annotation". This field is an opaque string that is set during configuration and can be queried or read at any time via the management protocol. This field can be used by the user, the console, or controlling orchestration layers to store identifying information about the router instance. Examples of the kind of data that can be store in the annotation include but are not limited to: public cloud availability zone, geographic map coordinates, a user-friendly label, administrative owner, display color, etc. > Add a metadata field to the router management entity > > > Key: DISPATCH-1442 > URL: https://issues.apache.org/jira/browse/DISPATCH-1442 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Management Agent > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.10.0 > > > This improvement adds a new attribute to the router entity called "metadata". > This field is an opaque string that is set during configuration and can be > queried or read at any time via the management protocol. > This field can be used by the user, the console, or controlling orchestration > layers to store identifying information about the router instance. > Examples of the kind of data that can be store in the metadata include but > are not limited to: public cloud availability zone, geographic map > coordinates, a user-friendly label, administrative owner, display color, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1442) Add a metadata field to the router management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1442: --- Summary: Add a metadata field to the router management entity (was: Add an annotation field to the router management entity) > Add a metadata field to the router management entity > > > Key: DISPATCH-1442 > URL: https://issues.apache.org/jira/browse/DISPATCH-1442 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Management Agent > Reporter: Ted Ross >Assignee: Ted Ross >Priority: Minor > Fix For: 1.10.0 > > > This improvement adds a new attribute to the router entity called > "annotation". This field is an opaque string that is set during > configuration and can be queried or read at any time via the management > protocol. > This field can be used by the user, the console, or controlling orchestration > layers to store identifying information about the router instance. > Examples of the kind of data that can be store in the annotation include but > are not limited to: public cloud availability zone, geographic map > coordinates, a user-friendly label, administrative owner, display color, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1442) Add an annotation field to the router management entity
Ted Ross created DISPATCH-1442: -- Summary: Add an annotation field to the router management entity Key: DISPATCH-1442 URL: https://issues.apache.org/jira/browse/DISPATCH-1442 Project: Qpid Dispatch Issue Type: New Feature Components: Management Agent Reporter: Ted Ross Assignee: Ted Ross Fix For: 1.10.0 This improvement adds a new attribute to the router entity called "annotation". This field is an opaque string that is set during configuration and can be queried or read at any time via the management protocol. This field can be used by the user, the console, or controlling orchestration layers to store identifying information about the router instance. Examples of the kind of data that can be store in the annotation include but are not limited to: public cloud availability zone, geographic map coordinates, a user-friendly label, administrative owner, display color, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1362) Shutdown crash when trying to clean up fallback addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1362:
---
Fix Version/s: 1.9.0
> Shutdown crash when trying to clean up fallback addresses
> -
>
> Key: DISPATCH-1362
> URL: https://issues.apache.org/jira/browse/DISPATCH-1362
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.9.0
>
>
> The following backtrace is occasionally seen when the router is being
> shutdown during the system_tests_fallback_dest
>
> {noformat}
> (gdb) bt
> #0 0x7f32afe4757f in raise () from /lib64/libc.so.6
> #1 0x7f32afe31895 in abort () from /lib64/libc.so.6
> #2 0x7f32afe8a9c7 in __libc_message () from /lib64/libc.so.6
> #3 0x7f32afe912cc in malloc_printerr () from /lib64/libc.so.6
> #4 0x7f32afe951ee in free_check.part () from /lib64/libc.so.6
> #5 0x7f32b051ba59 in qd_hash_remove_by_handle (h=,
> handle=) at
> /home/gmurthy/opensource/qpid-dispatch/src/hash.c:328
> #6 0x7f32b0540cbc in qdr_core_remove_address (core=core@entry=0x1b02230,
> addr=0x1b210d8) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core.c:492
> #7 0x7f32b05347eb in qdr_check_addr_CT (addr=,
> core=0x1b02230) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/connections.c:1176
> #8 qdr_check_addr_CT (core=core@entry=0x1b02230, addr=) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/connections.c:1158
> #9 0x7f32b0540dbc in qdr_core_remove_address (core=core@entry=0x1b02230,
> addr=0x1b21318) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core.c:524
> #10 0x7f32b0541420 in qdr_core_free (core=0x1b02230) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core.c:148
> #11 0x7f32b054fa23 in qd_router_free (router=0x1af3650) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_node.c:1772
> #12 0x7f32b051a2b5 in qd_dispatch_free (qd=0x16df1c0) at
> /home/gmurthy/opensource/qpid-dispatch/src/dispatch.c:359
> #13 0x004026c6 in main_process (config_path=0x7ffe3a46c069
> "INT.A.conf", python_pkgdir=, test_hooks=,
> fd=2) at /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:116
> #14 0x00402409 in main (argc=5, argv=0x7ffe3a46bc08) at
> /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:369{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] [Resolved] (DISPATCH-1362) Shutdown crash when trying to clean up fallback addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-1362.
Resolution: Fixed
> Shutdown crash when trying to clean up fallback addresses
> -
>
> Key: DISPATCH-1362
> URL: https://issues.apache.org/jira/browse/DISPATCH-1362
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Reporter: Ganesh Murthy
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.9.0
>
>
> The following backtrace is occasionally seen when the router is being
> shutdown during the system_tests_fallback_dest
>
> {noformat}
> (gdb) bt
> #0 0x7f32afe4757f in raise () from /lib64/libc.so.6
> #1 0x7f32afe31895 in abort () from /lib64/libc.so.6
> #2 0x7f32afe8a9c7 in __libc_message () from /lib64/libc.so.6
> #3 0x7f32afe912cc in malloc_printerr () from /lib64/libc.so.6
> #4 0x7f32afe951ee in free_check.part () from /lib64/libc.so.6
> #5 0x7f32b051ba59 in qd_hash_remove_by_handle (h=,
> handle=) at
> /home/gmurthy/opensource/qpid-dispatch/src/hash.c:328
> #6 0x7f32b0540cbc in qdr_core_remove_address (core=core@entry=0x1b02230,
> addr=0x1b210d8) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core.c:492
> #7 0x7f32b05347eb in qdr_check_addr_CT (addr=,
> core=0x1b02230) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/connections.c:1176
> #8 qdr_check_addr_CT (core=core@entry=0x1b02230, addr=) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/connections.c:1158
> #9 0x7f32b0540dbc in qdr_core_remove_address (core=core@entry=0x1b02230,
> addr=0x1b21318) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core.c:524
> #10 0x7f32b0541420 in qdr_core_free (core=0x1b02230) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core.c:148
> #11 0x7f32b054fa23 in qd_router_free (router=0x1af3650) at
> /home/gmurthy/opensource/qpid-dispatch/src/router_node.c:1772
> #12 0x7f32b051a2b5 in qd_dispatch_free (qd=0x16df1c0) at
> /home/gmurthy/opensource/qpid-dispatch/src/dispatch.c:359
> #13 0x004026c6 in main_process (config_path=0x7ffe3a46c069
> "INT.A.conf", python_pkgdir=, test_hooks=,
> fd=2) at /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:116
> #14 0x00402409 in main (argc=5, argv=0x7ffe3a46bc08) at
> /home/gmurthy/opensource/qpid-dispatch/router/src/main.c:369{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-1348) Avoid qdr_error_t allocation if not necessary
[ https://issues.apache.org/jira/browse/DISPATCH-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1348: --- Summary: Avoid qdr_error_t allocation if not necessary (was: Save qdr_error_t allocation if not necessary) > Avoid qdr_error_t allocation if not necessary > - > > Key: DISPATCH-1348 > URL: https://issues.apache.org/jira/browse/DISPATCH-1348 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.7.0 >Reporter: Francesco Nigro >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.8.0 > > > qdr_error_from_pn on error.c is allocating qdr_error_t on the hot path ie > AMQP_disposition_handler: saving those allocations would reduce CPU usage > (and cache misses) on both core and worker threads, making the router able to > scale better while under load. > Initial tests has shown some improvements under load (ie with core CPU thread > ~97% with the new version and ~99% with master): > 12 pairs master (no lock-free queues, no qdr_error_t fix): 285 K msg/sec > 12 pairs master (no lock-free queues, yes qdr_error_t fix): 402 K msg/sec > 12 pairs lock-free q (no qdr_error_t fix): 311 K msg/sec > 12 pairs lock-free q (yes qdr_error_t fix): 510 K msg/sec -- 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-1337) Fallback Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-1337.
Resolution: Fixed
> Fallback Destination for Unreachable Addresses
> --
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
> Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> fallback destination can be used to receive messages that are not deliverable
> to any normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to any fallback links that are attached.
> Once consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> enableFallback: yes
> {noformat}
> to an address configuration. This attribute tells the router that any address
> matching the configuration shall support the fallback destination capability.
> There are two ways to create a fallback link for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create a fallback
> link for an address. For example, assume that there is a route-container
> connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> enableFallback: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> fallback: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> fallback: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the fallback destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As an alternative to using auto-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.fallback". This will create the same behavior as the above example.
--
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-1337) Fallback Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847537#comment-16847537
]
Ted Ross commented on DISPATCH-1337:
The original description has been edited to reflect the final disposition of
this feature. Specifically, the feature has been renamed from "alternate" to
"fallback" to improve clarity.
> Fallback Destination for Unreachable Addresses
> --
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
> Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> fallback destination can be used to receive messages that are not deliverable
> to any normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to any fallback links that are attached.
> Once consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> enableFallback: yes
> {noformat}
> to an address configuration. This attribute tells the router that any address
> matching the configuration shall support the fallback destination capability.
> There are two ways to create a fallback link for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create a fallback
> link for an address. For example, assume that there is a route-container
> connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> enableFallback: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> fallback: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> fallback: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the fallback destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As an alternative to using auto-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.fallback". This will create the same behavior as the above example.
--
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-1337) Fallback Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1337:
---
Description:
This feature allows addresses to be configured such that an alternate fallback
destination can be used to receive messages that are not deliverable to any
normal consumers on the address.
Typically, this feature will be used to allow a message broker to store
messages that are not routable directly to consumers. When one or more
consumers are attached in the router network, messages shall be delivered
directly to the consumers. Where there are no reachable consumers, deliveries
shall then be diverted to any fallback links that are attached. Once consumers
re-connect to the network, messages shall again be delivered directly.
When a consumer comes online after messages have been stored in a broker, it
shall receive the stored messages interleaved with new messages from producers.
No attempt shall be made by the router network to preserve the original
delivery order of the messages.
This feature can be configured by adding the attribute
{noformat}
enableFallback: yes
{noformat}
to an address configuration. This attribute tells the router that any address
matching the configuration shall support the fallback destination capability.
There are two ways to create a fallback link for an address:
Using auto-links:
An auto-link (or a pair of auto-links) can be configured to create a fallback
link for an address. For example, assume that there is a route-container
connector or listener for a broker called "alternate-broker".
{noformat}
address {
prefix: position_update
enableFallback: yes
}
autoLink {
address: position_update.338
direction: in
connection: alternate-broker
fallback: yes
}
autoLink {
address: position_update.338
direction: out
connection: alternate-broker
fallback: yes
}
{noformat}
The above configuration will use a queue on the broker called
"position_update.338" as the fallback destination for direct consumers.
Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
shall send queued messages to newly attached direct consumers.
Using terminus capabilities:
As an alternative to using auto-links, the broker (or any other process) can
attach sending and receiving links to the address with terminus-capability
"qd.fallback". This will create the same behavior as the above example.
was:
This feature allows addresses to be configured such that an alternate
destination can be used to receive messages that are not deliverable to any
normal consumers on the address.
Typically, this feature will be used to allow a message broker to store
messages that are not routable directly to consumers. When one or more
consumers are attached in the router network, messages shall be delivered
directly to the consumers. Where there are no reachable consumers, deliveries
shall then be diverted to the alternate destination. Once consumers re-connect
to the network, messages shall again be delivered directly.
When a consumer comes online after messages have been stored in a broker, it
shall receive the stored messages interleaved with new messages from producers.
No attempt shall be made by the router network to preserve the original
delivery order of the messages.
This feature can be configured by adding the attribute
{noformat}
alternate: yes
{noformat}
to an address configuration. This attribute tells the router that any address
matching the configuration that appears shall support the alternate destination
capability.
There are two ways to create an alternate destination for an address:
Using auto-links:
An auto-link (or a pair of auto-links) can be configured to create an alternate
waypoint for an address. For example, assume that there is a route-container
connector or listener for a broker called "alternate-broker".
{noformat}
address {
prefix: position_update
alternate: yes
}
autoLink {
address: position_update.338
direction: in
connection: alternate-broker
alternate: yes
}
autoLink {
address: position_update.338
direction: out
connection: alternate-broker
alternate: yes
}
{noformat}
The above configuration will use a queue on the broker called
"position_update.338" as the alternate destination for direct consumers.
Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
shall send queued messages to newly attached direct consumers.
Using terminus capabilities:
As an alternative to using auto-links, the broker (or any other process) can
attach sending and receiving links to the address with terminus-capability
"qd.alternate". This will create the same behavior as the above example.
> Fallback Destination for Unreachable Addresses
> ---
[jira] [Updated] (DISPATCH-1337) Fallback Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1337:
---
Summary: Fallback Destination for Unreachable Addresses (was: Alternate
Destination for Unreachable Addresses)
> Fallback Destination for Unreachable Addresses
> --
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
> Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any address
> matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As an alternative to using auto-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
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-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1337:
---
Description:
This feature allows addresses to be configured such that an alternate
destination can be used to receive messages that are not deliverable to any
normal consumers on the address.
Typically, this feature will be used to allow a message broker to store
messages that are not routable directly to consumers. When one or more
consumers are attached in the router network, messages shall be delivered
directly to the consumers. Where there are no reachable consumers, deliveries
shall then be diverted to the alternate destination. Once consumers re-connect
to the network, messages shall again be delivered directly.
When a consumer comes online after messages have been stored in a broker, it
shall receive the stored messages interleaved with new messages from producers.
No attempt shall be made by the router network to preserve the original
delivery order of the messages.
This feature can be configured by adding the attribute
{noformat}
alternate: yes
{noformat}
to an address configuration. This attribute tells the router that any address
matching the configuration that appears shall support the alternate destination
capability.
There are two ways to create an alternate destination for an address:
Using auto-links:
An auto-link (or a pair of auto-links) can be configured to create an alternate
waypoint for an address. For example, assume that there is a route-container
connector or listener for a broker called "alternate-broker".
{noformat}
address {
prefix: position_update
alternate: yes
}
autoLink {
address: position_update.338
direction: in
connection: alternate-broker
alternate: yes
}
autoLink {
address: position_update.338
direction: out
connection: alternate-broker
alternate: yes
}
{noformat}
The above configuration will use a queue on the broker called
"position_update.338" as the alternate destination for direct consumers.
Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
shall send queued messages to newly attached direct consumers.
Using terminus capabilities:
As an alternative to using auto-links, the broker (or any other process) can
attach sending and receiving links to the address with terminus-capability
"qd.alternate". This will create the same behavior as the above example.
was:
This feature allows addresses to be configured such that an alternate
destination can be used to receive messages that are not deliverable to any
normal consumers on the address.
Typically, this feature will be used to allow a message broker to store
messages that are not routable directly to consumers. When one or more
consumers are attached in the router network, messages shall be delivered
directly to the consumers. Where there are no reachable consumers, deliveries
shall then be diverted to the alternate destination. Once consumers re-connect
to the network, messages shall again be delivered directly.
When a consumer comes online after messages have been stored in a broker, it
shall receive the stored messages interleaved with new messages from producers.
No attempt shall be made by the router network to preserve the original
delivery order of the messages.
This feature can be configured by adding the attribute
{noformat}
alternate: yes
{noformat}
to an address configuration. This attribute tells the router that any address
matching the configuration that appears shall support the alternate destination
capability.
There are two ways to create an alternate destination for an address:
Using auto-links:
An auto-link (or a pair of auto-links) can be configured to create an alternate
waypoint for an address. For example, assume that there is a route-container
connector or listener for a broker called "alternate-broker".
{noformat}
address {
prefix: position_update
alternate: yes
}
autoLink {
address: position_update.338
direction: in
connection: alternate-broker
alternate: yes
}
autoLink {
address: position_update.338
direction: out
connection: alternate-broker
alternate: yes
}
{noformat}
The above configuration will use a queue on the broker called
"position_update.338" as the alternate destination for direct consumers.
Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
shall send queued messages to newly attached direct consumers.
Using terminus capabilities:
As al alternative to using autl-links, the broker (or any other process) can
attach sending and receiving links to the address with terminus-capability
"qd.alternate". This will create the same behavior as the above example.
> Alternate Destination for Unreachable Addresses
> -
[jira] [Commented] (DISPATCH-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843998#comment-16843998
]
Ted Ross commented on DISPATCH-1337:
To be clear: The reason waypoint+alternate is not supported in the PR is
because there isn't a test for it yet.
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
> Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any
> address matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As al alternative to using autl-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
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-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843994#comment-16843994
]
Ted Ross commented on DISPATCH-1337:
{quote}What is the behaviour if both the `alternate` and `waypoint` are set to
true? (Is that an allowed configuration?)
{quote}
In the current pull-request, this is not fully supported. If both are
specified, the alternate-destination behavior will be applied only to the
"ingress" phase. In other words, if the waypoint isn't reachable, the alternate
destination will be used. If the alternate destination is itself a waypoint, it
will feed messages to the primary waypoint (on in ingress phase) once the
primary waypoint is reachable.
Note that there is a related bug (Jira pending) wherein multiple terminus
capabilities are not supported. Until this is fixed, the only way _waypoint_
and _alternate_ can be specified together is via an auto-link.
{quote}Does specifying the `qd.alternate` capability on a link require special
permission?
{quote}
Yes, it should. This is not yet implemented in the pull request.
{quote}Can it only be requested on route-container connections?
{quote}
The _waypoint_ and _alternate_ terminus capabilities may be used on normal
connections as well as route-container connections.
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any
> address matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As al alternative to using autl-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
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
