[jira] [Commented] (PROTON-2469) How to use proton-python properly to receive messages
[ https://issues.apache.org/jira/browse/PROTON-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448730#comment-17448730 ] Gordon Sim commented on PROTON-2469: The dynamic=True argument would cause the broker to give it a unique source address, which is not what you want there. > How to use proton-python properly to receive messages > - > > Key: PROTON-2469 > URL: https://issues.apache.org/jira/browse/PROTON-2469 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Andreas Waider >Priority: Major > > My configuration: > Running qpidd on host: 192.168.80.81 with following exchanges (`qpid-config > exchanges`): > ``` > Type Exchange Name Attributes > == > direct --replicate=none > direct amq.direct --durable --replicate=none > fanout amq.fanout --durable --replicate=none > headers amq.match --durable --replicate=none > topic amq.topic --durable --replicate=none > direct qmf.default.direct --replicate=none > topic qmf.default.topic --replicate=none > topic qpid.management --replicate=none > ``` > I have multiple producers publishing to the topics like > `amq.topic/com.product.sample1`, `amq.topic/com.product.sample2`, you get the > pattern. > I can receive all messages from the producers by running `qpid-receive -b > 192.168.80.81 -a amq.topic/com.product.sample1 -f` on the commandline. > But when it comes to implementing this in Python using the > [python-qpid-proton](https://pypi.org/project/python-qpid-proton/) library > (version 0.35.0) it wont work as needed. This is my python file to receive > messages on a specific topic: > ``` > from proton.handlers import MessagingHandler > from proton.reactor import Container > broker_url = "192.168.80.81:5672" > topic = "amq.topic/com.product.sample" > class Client(MessagingHandler): > def __init__(self, broker_url, topic): > super(Client, self).__init__() > self.broker_url = broker_url > self.topic = topic > def on_start(self, event): > conn = event.container.connect(self.broker_url) > self.receiver = event.container.create_receiver( > conn, self.topic, dynamic=True) > def on_message(self, event): > print(event.message.body) > Container(Client(broker_url, topic)).run() > ``` > Can anyone help me and point me to where my mistake is? Help is much > appreciated! -- 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] (PROTON-2469) How to use proton-python properly to receive messages
[ https://issues.apache.org/jira/browse/PROTON-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448713#comment-17448713 ] Gordon Sim commented on PROTON-2469: The issue here is the broker. It does not recognise amq.topic/com.product.sample. It does however support the subject binding filter. To do so you would use something like: {noformat} from proton import Described, symbol from proton.handlers import MessagingHandler from proton.reactor import Container, Filter broker_url = "192.168.80.81:5672" topic = "amq.topic" class SubjectFilter(Filter): def __init__(self, value): super(SubjectFilter, self).__init__(\{symbol('subject-filter'): Described(symbol('apache.org:legacy-amqp-topic-binding:string'), value)}) class Client(MessagingHandler): def __init__(self, broker_url, topic): super(Client, self).__init__() self.broker_url = broker_url self.topic = topic def on_start(self, event): conn = event.container.connect(self.broker_url) self.receiver = event.container.create_receiver( conn, self.topic, options=SubjectFilter("com.product.sample")) def on_message(self, event): print(event.message.body) Container(Client(broker_url, topic)).run() {noformat} > How to use proton-python properly to receive messages > - > > Key: PROTON-2469 > URL: https://issues.apache.org/jira/browse/PROTON-2469 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Andreas Waider >Priority: Major > > My configuration: > Running qpidd on host: 192.168.80.81 with following exchanges (`qpid-config > exchanges`): > ``` > Type Exchange Name Attributes > == > direct --replicate=none > direct amq.direct --durable --replicate=none > fanout amq.fanout --durable --replicate=none > headers amq.match --durable --replicate=none > topic amq.topic --durable --replicate=none > direct qmf.default.direct --replicate=none > topic qmf.default.topic --replicate=none > topic qpid.management --replicate=none > ``` > I have multiple producers publishing to the topics like > `amq.topic/com.product.sample1`, `amq.topic/com.product.sample2`, you get the > pattern. > I can receive all messages from the producers by running `qpid-receive -b > 192.168.80.81 -a amq.topic/com.product.sample1 -f` on the commandline. > But when it comes to implementing this in Python using the > [python-qpid-proton](https://pypi.org/project/python-qpid-proton/) library > (version 0.35.0) it wont work as needed. This is my python file to receive > messages on a specific topic: > ``` > from proton.handlers import MessagingHandler > from proton.reactor import Container > broker_url = "192.168.80.81:5672" > topic = "amq.topic/com.product.sample" > class Client(MessagingHandler): > def __init__(self, broker_url, topic): > super(Client, self).__init__() > self.broker_url = broker_url > self.topic = topic > def on_start(self, event): > conn = event.container.connect(self.broker_url) > self.receiver = event.container.create_receiver( > conn, self.topic, dynamic=True) > def on_message(self, event): > print(event.message.body) > Container(Client(broker_url, topic)).run() > ``` > Can anyone help me and point me to where my mistake is? Help is much > appreciated! -- 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-2286) Segfault while running iperf3 tests due to null raw connection pointer
[ https://issues.apache.org/jira/browse/DISPATCH-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444115#comment-17444115 ] Gordon Sim commented on DISPATCH-2286: -- Out of curiousity is that a regression in proton? > Segfault while running iperf3 tests due to null raw connection pointer > -- > > Key: DISPATCH-2286 > URL: https://issues.apache.org/jira/browse/DISPATCH-2286 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors >Affects Versions: 1.18.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Critical > Attachments: qdrouterd-A.conf, qdrouterd-B.conf > > > AddressSanitizer:DEADLYSIGNAL > > = > > ==10828==ERROR: AddressSanitizer: SEGV on unknown address 0x0426 (pc > 0x7f2949176c40 bp 0x7fff76eaff00 sp 0x7fff76eafe38 T0) > ==10828==The signal is caused by a READ memory access. > > ==10828==Hint: address points to the zero page. > > #0 0x7f2949176c40 in pn_raw_connection_take_read_buffers > /home/kgiusti/work/proton/qpid-proton/c/src/proactor/raw_connection.c:318 > > #1 0x49d7b9 in handle_incoming_raw_read > /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/tcp_adaptor.c:254 > > #2 0x49eceb in handle_incoming > /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/tcp_adaptor.c:308 > > #3 0x4a884f in handle_connection_event > /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/tcp_adaptor.c:872 > > #4 0x6e4de2 in handle_event_with_context > /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:814 > > #5 0x6e4e23 in do_handle_raw_connection_event > /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:820 > > #6 0x6e91a7 in handle > /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1101 > > #7 0x6e945a in thread_run > /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1133 > > #8 0x6f0934 in qd_server_run > /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1527 > > #9 0x42d6a8 in main_process > /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:115 > > #10 0x42f528 in main > /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:369 > > #11 0x7f29481f31e1 in __libc_start_main (/lib64/libc.so.6+0x281e1) > > #12 0x42d3cd in _start (/opt/kgiusti/sbin/qdrouterd+0x42d3cd) > > > > AddressSanitizer can not provide additional info. > > SUMMARY: AddressSanitizer: SEGV > /home/kgiusti/work/proton/qpid-proton/c/src/proactor/raw_connection.c:318 in > pn_raw_connection_take_read_buffers > ==10828==ABORTING -- 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-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&focusedCommentId=17434949#comment-17434949 ] Gordon Sim commented on DISPATCH-2262: -- Could either of these be relevant? https://issues.apache.org/jira/browse/PROTON-2411 https://issues.apache.org/jira/browse/PROTON-2422 > 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] [Resolved] (DISPATCH-2259) server_name set by Dispatch Router contains illegal characters
[ https://issues.apache.org/jira/browse/DISPATCH-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-2259. -- Fix Version/s: 1.18.0 Resolution: Fixed > server_name set by Dispatch Router contains illegal characters > -- > > Key: DISPATCH-2259 > URL: https://issues.apache.org/jira/browse/DISPATCH-2259 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.16.1 >Reporter: Kai Hudalla >Priority: Major > Fix For: 1.18.0 > > > When the dispatch router is configured with an Auth Server Plugin that should > be accessed via a TLS connection, then the router includes the TLS Server > Name Indication extension ([https://datatracker.ietf.org/doc/html/rfc6066]) > in its TLS ServerHello message but sets the host_name to a value that is not > a domain name as mandated by the RFC. Instead, it sets the host_name to a > combination of the server name and the port configured for the Auth Server > Plugin. So, for Auth Server Plugin configuration > ["authServicePlugin", > { "name": "My Auth Server", "host": "my-auth-server.host} > ", > "port": 5671, > "sslProfile": "external" > }] > the host_name set in the server_name extension is > my-auth-server.host:5671 > which is not a valid domain name. > The TLS implementation that comes with Java 17 will fail the TLS handshake > with the dispatch router due to an illegal character in the host_name. > I believe that this problem may also arise with other outbound connections > that the router creates. > FMPOV the port suffix simply needs to be removed. -- 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-2257) listener with http=true uses AF_INTE6 even when ipv6 is not supported
[ https://issues.apache.org/jira/browse/DISPATCH-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-2257. -- Fix Version/s: 1.18.0 Resolution: Fixed > listener with http=true uses AF_INTE6 even when ipv6 is not supported > - > > Key: DISPATCH-2257 > URL: https://issues.apache.org/jira/browse/DISPATCH-2257 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.17.0 > Reporter: Gordon Sim >Priority: Major > Fix For: 1.18.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-2257) listener with http=true uses AF_INTE6 even when ipv6 is not supported
Gordon Sim created DISPATCH-2257: Summary: listener with http=true uses AF_INTE6 even when ipv6 is not supported Key: DISPATCH-2257 URL: https://issues.apache.org/jira/browse/DISPATCH-2257 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 1.17.0 Reporter: Gordon Sim -- 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] (PROTON-2439) Python BlockingReceiver does not work with presettled deliveries
[ https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17431144#comment-17431144 ] Gordon Sim commented on PROTON-2439: You are right, there is indeed a bug. BlockingReceiver does not work with presettled deliveries as it does not settle the delivery (required by proton to free the delivery), but also does not expose that to the user of the class so they can settle it themselves. It tracks unsettled deliveries that have been returned in response to a receive() call in a list. Presettled deliveries are not placed on this list, which is why the accept etc fail. I think there are two options for fixing this. One is to keep all returned deliveries until they are settled (i.e. remove the if clause that prevents presettled deliveries being appended). The other is to settle presettled messages instead of appending them. [~astitcher] [~jr...@redhat.com] thoughts? > Python BlockingReceiver does not work with presettled deliveries > > > Key: PROTON-2439 > URL: https://issues.apache.org/jira/browse/PROTON-2439 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.35.0 >Reporter: Greg Majszak >Priority: Minor > > ./qpidTest.bash script: > {{#!/usr/bin/env bash}} > {{ }} > {{function main() {}} > {{ # Display Linux distro}} > {{ echo "Linux distro:"}} > {{ cat /etc/*release*}} > {{ echo}} > {{ }} > {{ # Display Linux version}} > {{ echo "Linux version:"}} > {{ cat /proc/version}} > {{ echo}} > {{ }} > {{ # Display Python 3 version}} > {{ echo "Python3 version:"}} > {{ python3 --version}} > {{ echo}} > {{ }} > {{ # Display C++ Qpid qpidd broker version}} > {{ echo "C++ Qpid qpidd broker version:"}} > {{ qpidd --version}} > {{ echo}} > {{ }} > {{ echo "Run of Qpid Python 3 example broker and helloworld_blocking > scripts:"}} > {{ }} > {{ # Start and background Python 3 example Qpid broker}} > {{ python3 ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/broker.py > &}} > {{ local brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for Python 3 example Qpid broker to get up and > running}} > {{ sleep 1}} > {{ }} > {{ # Run helloworld_blocking.py (note no error, receiver.accept() performs > as expected)}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py) > ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "Command 'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background Python 3 example Qpid broker}} > {{ kill $\{brokerPid}}} > {{ echo}} > {{ }} > {{ echo "Run of C++ Qpid qpidd broker and helloworld_blocking script:"}} > {{ }} > {{ # Start and background C++ Qpid qpidd broker}} > {{ qpidd &}} > {{ brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for C++ Qpid qpidd broker to get up and running}} > {{ sleep 1}} > {{ }} > {{ # Add exchange topic 'examples'}} > {{ qpid-config add exchange topic examples '*' || {}} > {{ echo "Command 'qpid-config add exchange topic examples '*'' failed"}} > {{ }} > {{ # Run same helloworld_blocking.py (note error, receiver.accept() fails > with 'IndexError: pop from an empty deque')}} > {{ # If 'receiver.accept()' is commented out from helloworld_blocking.py, > command succeeds and returns 'Hello World!'}} > {{ # but message is 'leaked' and/or stored/queued awaiting acceptance}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py > || echo "${?}") ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background C++ Qpid qpidd broker}} > {{ kill $\{brokerPid}}} > {{}}} > {{ }} > {{main "${@}"}} > {{ }} > {{exit}} > ./qpidTest.bash script run output: > [gmajszak@xxx-u-dev-wks20 ~]$ ./qpidTest.bash > {{Linux distro:}} > {{NAME="Red Hat Enterprise
[jira] [Updated] (PROTON-2439) Python BlockingReceiver does not work with presettled deliveries
[ https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-2439: --- Summary: Python BlockingReceiver does not work with presettled deliveries (was: Python BlockingReceiver accept() fails when used with qpidd broker) > Python BlockingReceiver does not work with presettled deliveries > > > Key: PROTON-2439 > URL: https://issues.apache.org/jira/browse/PROTON-2439 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.35.0 >Reporter: Greg Majszak >Priority: Minor > > ./qpidTest.bash script: > {{#!/usr/bin/env bash}} > {{ }} > {{function main() {}} > {{ # Display Linux distro}} > {{ echo "Linux distro:"}} > {{ cat /etc/*release*}} > {{ echo}} > {{ }} > {{ # Display Linux version}} > {{ echo "Linux version:"}} > {{ cat /proc/version}} > {{ echo}} > {{ }} > {{ # Display Python 3 version}} > {{ echo "Python3 version:"}} > {{ python3 --version}} > {{ echo}} > {{ }} > {{ # Display C++ Qpid qpidd broker version}} > {{ echo "C++ Qpid qpidd broker version:"}} > {{ qpidd --version}} > {{ echo}} > {{ }} > {{ echo "Run of Qpid Python 3 example broker and helloworld_blocking > scripts:"}} > {{ }} > {{ # Start and background Python 3 example Qpid broker}} > {{ python3 ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/broker.py > &}} > {{ local brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for Python 3 example Qpid broker to get up and > running}} > {{ sleep 1}} > {{ }} > {{ # Run helloworld_blocking.py (note no error, receiver.accept() performs > as expected)}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py) > ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "Command 'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background Python 3 example Qpid broker}} > {{ kill $\{brokerPid}}} > {{ echo}} > {{ }} > {{ echo "Run of C++ Qpid qpidd broker and helloworld_blocking script:"}} > {{ }} > {{ # Start and background C++ Qpid qpidd broker}} > {{ qpidd &}} > {{ brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for C++ Qpid qpidd broker to get up and running}} > {{ sleep 1}} > {{ }} > {{ # Add exchange topic 'examples'}} > {{ qpid-config add exchange topic examples '*' || {}} > {{ echo "Command 'qpid-config add exchange topic examples '*'' failed"}} > {{ }} > {{ # Run same helloworld_blocking.py (note error, receiver.accept() fails > with 'IndexError: pop from an empty deque')}} > {{ # If 'receiver.accept()' is commented out from helloworld_blocking.py, > command succeeds and returns 'Hello World!'}} > {{ # but message is 'leaked' and/or stored/queued awaiting acceptance}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py > || echo "${?}") ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background C++ Qpid qpidd broker}} > {{ kill $\{brokerPid}}} > {{}}} > {{ }} > {{main "${@}"}} > {{ }} > {{exit}} > ./qpidTest.bash script run output: > [gmajszak@xxx-u-dev-wks20 ~]$ ./qpidTest.bash > {{Linux distro:}} > {{NAME="Red Hat Enterprise Linux Workstation"}} > {{VERSION="7.6 (Maipo)"}} > {{ID="rhel"}} > {{ID_LIKE="fedora"}} > {{VARIANT="Workstation"}} > {{VARIANT_ID="workstation"}} > {{VERSION_ID="7.6"}} > {{PRETTY_NAME="Red Hat Enterprise Linux Workstation 7.6 (Maipo)"}} > {{ANSI_COLOR="0;31"}} > {{CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:workstation"}} > {{HOME_URL=[https://www.redhat.com/]}} > {{BUG_REPORT_URL=[https://bugzilla.redhat.com/]}} > {{REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"}} > {{REDHAT_BUGZILLA_PRODUCT_VERSION=7.6}} > {{REDHAT_S
[jira] [Updated] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker
[ https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-2439: --- Component/s: (was: examples) > Python BlockingReceiver accept() fails when used with qpidd broker > -- > > Key: PROTON-2439 > URL: https://issues.apache.org/jira/browse/PROTON-2439 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: proton-c-0.35.0 >Reporter: Greg Majszak >Priority: Minor > > ./qpidTest.bash script: > {{#!/usr/bin/env bash}} > {{ }} > {{function main() {}} > {{ # Display Linux distro}} > {{ echo "Linux distro:"}} > {{ cat /etc/*release*}} > {{ echo}} > {{ }} > {{ # Display Linux version}} > {{ echo "Linux version:"}} > {{ cat /proc/version}} > {{ echo}} > {{ }} > {{ # Display Python 3 version}} > {{ echo "Python3 version:"}} > {{ python3 --version}} > {{ echo}} > {{ }} > {{ # Display C++ Qpid qpidd broker version}} > {{ echo "C++ Qpid qpidd broker version:"}} > {{ qpidd --version}} > {{ echo}} > {{ }} > {{ echo "Run of Qpid Python 3 example broker and helloworld_blocking > scripts:"}} > {{ }} > {{ # Start and background Python 3 example Qpid broker}} > {{ python3 ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/broker.py > &}} > {{ local brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for Python 3 example Qpid broker to get up and > running}} > {{ sleep 1}} > {{ }} > {{ # Run helloworld_blocking.py (note no error, receiver.accept() performs > as expected)}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py) > ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "Command 'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background Python 3 example Qpid broker}} > {{ kill $\{brokerPid}}} > {{ echo}} > {{ }} > {{ echo "Run of C++ Qpid qpidd broker and helloworld_blocking script:"}} > {{ }} > {{ # Start and background C++ Qpid qpidd broker}} > {{ qpidd &}} > {{ brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for C++ Qpid qpidd broker to get up and running}} > {{ sleep 1}} > {{ }} > {{ # Add exchange topic 'examples'}} > {{ qpid-config add exchange topic examples '*' || {}} > {{ echo "Command 'qpid-config add exchange topic examples '*'' failed"}} > {{ }} > {{ # Run same helloworld_blocking.py (note error, receiver.accept() fails > with 'IndexError: pop from an empty deque')}} > {{ # If 'receiver.accept()' is commented out from helloworld_blocking.py, > command succeeds and returns 'Hello World!'}} > {{ # but message is 'leaked' and/or stored/queued awaiting acceptance}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py > || echo "${?}") ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background C++ Qpid qpidd broker}} > {{ kill $\{brokerPid}}} > {{}}} > {{ }} > {{main "${@}"}} > {{ }} > {{exit}} > ./qpidTest.bash script run output: > [gmajszak@xxx-u-dev-wks20 ~]$ ./qpidTest.bash > {{Linux distro:}} > {{NAME="Red Hat Enterprise Linux Workstation"}} > {{VERSION="7.6 (Maipo)"}} > {{ID="rhel"}} > {{ID_LIKE="fedora"}} > {{VARIANT="Workstation"}} > {{VARIANT_ID="workstation"}} > {{VERSION_ID="7.6"}} > {{PRETTY_NAME="Red Hat Enterprise Linux Workstation 7.6 (Maipo)"}} > {{ANSI_COLOR="0;31"}} > {{CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:workstation"}} > {{HOME_URL=[https://www.redhat.com/]}} > {{BUG_REPORT_URL=[https://bugzilla.redhat.com/]}} > {{REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"}} > {{REDHAT_BUGZILLA_PRODUCT_VERSION=7.6}} > {{REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"}} > {{REDHAT_SUPPORT_PRODUCT_VERSION="7.6&quo
[jira] [Updated] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker
[ https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-2439: --- Issue Type: Bug (was: Improvement) > Python BlockingReceiver accept() fails when used with qpidd broker > -- > > Key: PROTON-2439 > URL: https://issues.apache.org/jira/browse/PROTON-2439 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.35.0 >Reporter: Greg Majszak >Priority: Minor > > ./qpidTest.bash script: > {{#!/usr/bin/env bash}} > {{ }} > {{function main() {}} > {{ # Display Linux distro}} > {{ echo "Linux distro:"}} > {{ cat /etc/*release*}} > {{ echo}} > {{ }} > {{ # Display Linux version}} > {{ echo "Linux version:"}} > {{ cat /proc/version}} > {{ echo}} > {{ }} > {{ # Display Python 3 version}} > {{ echo "Python3 version:"}} > {{ python3 --version}} > {{ echo}} > {{ }} > {{ # Display C++ Qpid qpidd broker version}} > {{ echo "C++ Qpid qpidd broker version:"}} > {{ qpidd --version}} > {{ echo}} > {{ }} > {{ echo "Run of Qpid Python 3 example broker and helloworld_blocking > scripts:"}} > {{ }} > {{ # Start and background Python 3 example Qpid broker}} > {{ python3 ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/broker.py > &}} > {{ local brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for Python 3 example Qpid broker to get up and > running}} > {{ sleep 1}} > {{ }} > {{ # Run helloworld_blocking.py (note no error, receiver.accept() performs > as expected)}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py) > ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "Command 'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background Python 3 example Qpid broker}} > {{ kill $\{brokerPid}}} > {{ echo}} > {{ }} > {{ echo "Run of C++ Qpid qpidd broker and helloworld_blocking script:"}} > {{ }} > {{ # Start and background C++ Qpid qpidd broker}} > {{ qpidd &}} > {{ brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for C++ Qpid qpidd broker to get up and running}} > {{ sleep 1}} > {{ }} > {{ # Add exchange topic 'examples'}} > {{ qpid-config add exchange topic examples '*' || {}} > {{ echo "Command 'qpid-config add exchange topic examples '*'' failed"}} > {{ }} > {{ # Run same helloworld_blocking.py (note error, receiver.accept() fails > with 'IndexError: pop from an empty deque')}} > {{ # If 'receiver.accept()' is commented out from helloworld_blocking.py, > command succeeds and returns 'Hello World!'}} > {{ # but message is 'leaked' and/or stored/queued awaiting acceptance}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py > || echo "${?}") ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background C++ Qpid qpidd broker}} > {{ kill $\{brokerPid}}} > {{}}} > {{ }} > {{main "${@}"}} > {{ }} > {{exit}} > ./qpidTest.bash script run output: > [gmajszak@xxx-u-dev-wks20 ~]$ ./qpidTest.bash > {{Linux distro:}} > {{NAME="Red Hat Enterprise Linux Workstation"}} > {{VERSION="7.6 (Maipo)"}} > {{ID="rhel"}} > {{ID_LIKE="fedora"}} > {{VARIANT="Workstation"}} > {{VARIANT_ID="workstation"}} > {{VERSION_ID="7.6"}} > {{PRETTY_NAME="Red Hat Enterprise Linux Workstation 7.6 (Maipo)"}} > {{ANSI_COLOR="0;31"}} > {{CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:workstation"}} > {{HOME_URL=[https://www.redhat.com/]}} > {{BUG_REPORT_URL=[https://bugzilla.redhat.com/]}} > {{REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"}} > {{REDHAT_BUGZILLA_PRODUCT_VERSION=7.6}} > {{REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"}} > {{REDHAT_SUPPORT_PRODUCT_VERSION="7.6"}} > {{
[jira] [Commented] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker
[ https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430555#comment-17430555 ] Gordon Sim commented on PROTON-2439: Where is the message 'leaked'? On the client or the broker? > Python BlockingReceiver accept() fails when used with qpidd broker > -- > > Key: PROTON-2439 > URL: https://issues.apache.org/jira/browse/PROTON-2439 > Project: Qpid Proton > Issue Type: Improvement > Components: examples, python-binding >Affects Versions: proton-c-0.35.0 >Reporter: Greg Majszak >Priority: Minor > > ./qpidTest.bash script: > {{#!/usr/bin/env bash}} > {{ }} > {{function main() {}} > {{ # Display Linux distro}} > {{ echo "Linux distro:"}} > {{ cat /etc/*release*}} > {{ echo}} > {{ }} > {{ # Display Linux version}} > {{ echo "Linux version:"}} > {{ cat /proc/version}} > {{ echo}} > {{ }} > {{ # Display Python 3 version}} > {{ echo "Python3 version:"}} > {{ python3 --version}} > {{ echo}} > {{ }} > {{ # Display C++ Qpid qpidd broker version}} > {{ echo "C++ Qpid qpidd broker version:"}} > {{ qpidd --version}} > {{ echo}} > {{ }} > {{ echo "Run of Qpid Python 3 example broker and helloworld_blocking > scripts:"}} > {{ }} > {{ # Start and background Python 3 example Qpid broker}} > {{ python3 ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/broker.py > &}} > {{ local brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for Python 3 example Qpid broker to get up and > running}} > {{ sleep 1}} > {{ }} > {{ # Run helloworld_blocking.py (note no error, receiver.accept() performs > as expected)}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py) > ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "Command 'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background Python 3 example Qpid broker}} > {{ kill $\{brokerPid}}} > {{ echo}} > {{ }} > {{ echo "Run of C++ Qpid qpidd broker and helloworld_blocking script:"}} > {{ }} > {{ # Start and background C++ Qpid qpidd broker}} > {{ qpidd &}} > {{ brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for C++ Qpid qpidd broker to get up and running}} > {{ sleep 1}} > {{ }} > {{ # Add exchange topic 'examples'}} > {{ qpid-config add exchange topic examples '*' || {}} > {{ echo "Command 'qpid-config add exchange topic examples '*'' failed"}} > {{ }} > {{ # Run same helloworld_blocking.py (note error, receiver.accept() fails > with 'IndexError: pop from an empty deque')}} > {{ # If 'receiver.accept()' is commented out from helloworld_blocking.py, > command succeeds and returns 'Hello World!'}} > {{ # but message is 'leaked' and/or stored/queued awaiting acceptance}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py > || echo "${?}") ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background C++ Qpid qpidd broker}} > {{ kill $\{brokerPid}}} > {{}}} > {{ }} > {{main "${@}"}} > {{ }} > {{exit}} > ./qpidTest.bash script run output: > [gmajszak@xxx-u-dev-wks20 ~]$ ./qpidTest.bash > {{Linux distro:}} > {{NAME="Red Hat Enterprise Linux Workstation"}} > {{VERSION="7.6 (Maipo)"}} > {{ID="rhel"}} > {{ID_LIKE="fedora"}} > {{VARIANT="Workstation"}} > {{VARIANT_ID="workstation"}} > {{VERSION_ID="7.6"}} > {{PRETTY_NAME="Red Hat Enterprise Linux Workstation 7.6 (Maipo)"}} > {{ANSI_COLOR="0;31"}} > {{CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:workstation"}} > {{HOME_URL=[https://www.redhat.com/]}} > {{BUG_REPORT_URL=[https://bugzilla.redhat.com/]}} > {{REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"}} > {{REDHAT_BUGZILLA_PRODUCT_VERSION=7.6}} > {{RE
[jira] [Updated] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker
[ https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-2439: --- Component/s: examples Issue Type: Improvement (was: Bug) Priority: Minor (was: Blocker) > Python BlockingReceiver accept() fails when used with qpidd broker > -- > > Key: PROTON-2439 > URL: https://issues.apache.org/jira/browse/PROTON-2439 > Project: Qpid Proton > Issue Type: Improvement > Components: examples, python-binding >Affects Versions: proton-c-0.35.0 >Reporter: Greg Majszak >Priority: Minor > > ./qpidTest.bash script: > {{#!/usr/bin/env bash}} > {{ }} > {{function main() {}} > {{ # Display Linux distro}} > {{ echo "Linux distro:"}} > {{ cat /etc/*release*}} > {{ echo}} > {{ }} > {{ # Display Linux version}} > {{ echo "Linux version:"}} > {{ cat /proc/version}} > {{ echo}} > {{ }} > {{ # Display Python 3 version}} > {{ echo "Python3 version:"}} > {{ python3 --version}} > {{ echo}} > {{ }} > {{ # Display C++ Qpid qpidd broker version}} > {{ echo "C++ Qpid qpidd broker version:"}} > {{ qpidd --version}} > {{ echo}} > {{ }} > {{ echo "Run of Qpid Python 3 example broker and helloworld_blocking > scripts:"}} > {{ }} > {{ # Start and background Python 3 example Qpid broker}} > {{ python3 ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/broker.py > &}} > {{ local brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for Python 3 example Qpid broker to get up and > running}} > {{ sleep 1}} > {{ }} > {{ # Run helloworld_blocking.py (note no error, receiver.accept() performs > as expected)}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py) > ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "Command 'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background Python 3 example Qpid broker}} > {{ kill $\{brokerPid}}} > {{ echo}} > {{ }} > {{ echo "Run of C++ Qpid qpidd broker and helloworld_blocking script:"}} > {{ }} > {{ # Start and background C++ Qpid qpidd broker}} > {{ qpidd &}} > {{ brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for C++ Qpid qpidd broker to get up and running}} > {{ sleep 1}} > {{ }} > {{ # Add exchange topic 'examples'}} > {{ qpid-config add exchange topic examples '*' || {}} > {{ echo "Command 'qpid-config add exchange topic examples '*'' failed"}} > {{ }} > {{ # Run same helloworld_blocking.py (note error, receiver.accept() fails > with 'IndexError: pop from an empty deque')}} > {{ # If 'receiver.accept()' is commented out from helloworld_blocking.py, > command succeeds and returns 'Hello World!'}} > {{ # but message is 'leaked' and/or stored/queued awaiting acceptance}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py > || echo "${?}") ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background C++ Qpid qpidd broker}} > {{ kill $\{brokerPid}}} > {{}}} > {{ }} > {{main "${@}"}} > {{ }} > {{exit}} > ./qpidTest.bash script run output: > [gmajszak@xxx-u-dev-wks20 ~]$ ./qpidTest.bash > {{Linux distro:}} > {{NAME="Red Hat Enterprise Linux Workstation"}} > {{VERSION="7.6 (Maipo)"}} > {{ID="rhel"}} > {{ID_LIKE="fedora"}} > {{VARIANT="Workstation"}} > {{VARIANT_ID="workstation"}} > {{VERSION_ID="7.6"}} > {{PRETTY_NAME="Red Hat Enterprise Linux Workstation 7.6 (Maipo)"}} > {{ANSI_COLOR="0;31"}} > {{CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:workstation"}} > {{HOME_URL=[https://www.redhat.com/]}} > {{BUG_REPORT_URL=[https://bugzilla.redhat.com/]}} > {{REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"}} > {{REDHAT_BUGZILLA_PRODUCT_VERSION=7.6}} > {{REDHAT_SUPPORT_PRODUCT="Red Hat Ente
[jira] [Commented] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker
[ https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430370#comment-17430370 ] Gordon Sim commented on PROTON-2439: As mentioned on the user list, this is simply a result of using the example with a topic ([https://mail-archives.apache.org/mod_mbox/qpid-users/202110.mbox/%3CCAL56gu8XdgqxO%3DPPBObuFpN8Z5B5b1D_j7MFuC2gsUictSuuKg%40mail.gmail.com%3E).] Arguably the example could be made to handle that case (or arguably it should remain very simple). In either case it is certainly not a blocker. > Python BlockingReceiver accept() fails when used with qpidd broker > -- > > Key: PROTON-2439 > URL: https://issues.apache.org/jira/browse/PROTON-2439 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.35.0 >Reporter: Greg Majszak >Priority: Blocker > > ./qpidTest.bash script: > {{#!/usr/bin/env bash}} > {{ }} > {{function main() {}} > {{ # Display Linux distro}} > {{ echo "Linux distro:"}} > {{ cat /etc/*release*}} > {{ echo}} > {{ }} > {{ # Display Linux version}} > {{ echo "Linux version:"}} > {{ cat /proc/version}} > {{ echo}} > {{ }} > {{ # Display Python 3 version}} > {{ echo "Python3 version:"}} > {{ python3 --version}} > {{ echo}} > {{ }} > {{ # Display C++ Qpid qpidd broker version}} > {{ echo "C++ Qpid qpidd broker version:"}} > {{ qpidd --version}} > {{ echo}} > {{ }} > {{ echo "Run of Qpid Python 3 example broker and helloworld_blocking > scripts:"}} > {{ }} > {{ # Start and background Python 3 example Qpid broker}} > {{ python3 ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/broker.py > &}} > {{ local brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for Python 3 example Qpid broker to get up and > running}} > {{ sleep 1}} > {{ }} > {{ # Run helloworld_blocking.py (note no error, receiver.accept() performs > as expected)}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py) > ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "Command 'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background Python 3 example Qpid broker}} > {{ kill $\{brokerPid}}} > {{ echo}} > {{ }} > {{ echo "Run of C++ Qpid qpidd broker and helloworld_blocking script:"}} > {{ }} > {{ # Start and background C++ Qpid qpidd broker}} > {{ qpidd &}} > {{ brokerPid=$\{!}}} > {{ }} > {{ # Allow some time for C++ Qpid qpidd broker to get up and running}} > {{ sleep 1}} > {{ }} > {{ # Add exchange topic 'examples'}} > {{ qpid-config add exchange topic examples '*' || {}} > {{ echo "Command 'qpid-config add exchange topic examples '*'' failed"}} > {{ }} > {{ # Run same helloworld_blocking.py (note error, receiver.accept() fails > with 'IndexError: pop from an empty deque')}} > {{ # If 'receiver.accept()' is commented out from helloworld_blocking.py, > command succeeds and returns 'Hello World!'}} > {{ # but message is 'leaked' and/or stored/queued awaiting acceptance}} > {{ if [[ "Hello World!" == $(python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py > || echo "${?}") ]]; then}} > {{ echo "Completed without error"}} > {{ else}} > {{ echo "'python3 > ~/Downloads/Qpid_Proton_0.35.0/Proton_Python_Examples/helloworld_blocking.py' > failed"}} > {{ fi}} > {{ }} > {{ # Stop background C++ Qpid qpidd broker}} > {{ kill $\{brokerPid}}} > {{}}} > {{ }} > {{main "${@}"}} > {{ }} > {{exit}} > ./qpidTest.bash script run output: > [gmajszak@xxx-u-dev-wks20 ~]$ ./qpidTest.bash > {{Linux distro:}} > {{NAME="Red Hat Enterprise Linux Workstation"}} > {{VERSION="7.6 (Maipo)"}} > {{ID="rhel"}} > {{ID_LIKE="fedora"}} > {{VARIANT="Workstation"}} > {{VARIANT_ID="workstation"}} > {{VERSION_ID="7.6"}} > {{PRETTY_NAME="Red Hat Enterprise Linux Workstation 7.6 (Maipo)"}} > {{ANSI_COLOR="0;31"}}
[jira] [Assigned] (DISPATCH-1039) websocket listener with authenticatePeer=true requires client certs
[ https://issues.apache.org/jira/browse/DISPATCH-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned DISPATCH-1039: Assignee: (was: Gordon Sim) > websocket listener with authenticatePeer=true requires client certs > --- > > Key: DISPATCH-1039 > URL: https://issues.apache.org/jira/browse/DISPATCH-1039 > Project: Qpid Dispatch > Issue Type: Bug > Reporter: Gordon Sim >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] (PROTON-2404) [python] Tornado container does not work both timer and connection
[ https://issues.apache.org/jira/browse/PROTON-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-2404: -- Assignee: Andrew Stitcher (was: Gordon Sim) > [python] Tornado container does not work both timer and connection > -- > > Key: PROTON-2404 > URL: https://issues.apache.org/jira/browse/PROTON-2404 > Project: Qpid Proton > Issue Type: Bug > Components: examples >Reporter: Fredrik Hallenberg >Assignee: Andrew Stitcher >Priority: Major > > I am trying to get the Python tornado container working with qpid proton > 0.34. My goal is to create a tornado server that can also send and receive > amqp messages using a timer. With the below example tornado server works fine > but I am not able to run both timer and amqp connection. If the schedule call > below is uncommented the amqp connection stops working. I can also comment > out create_sender/receive and then timer ticks works. > > It seems to me that something is missing in the tornado container. Although > it just an example I think it is essential to be able to combine the amqp > event loop with event loops in other libraries. It would be good to also have > a container based on asyncio. > > from proton import Message > from proton.handlers import MessagingHandler > from proton_tornado import Container > import tornado.ioloop > import tornado.web > class Client(MessagingHandler): > def __init__(self, url): > super(Client, self).__init__() > self.url = url > def on_timer_task(self, event): > print('tick') > self.container.schedule(1, self) > def on_start(self, event): > self.container = event.reactor > self.sender = event.container.create_sender(self.url) > self.receiver = > event.container.create_receiver(self.sender.connection) > #self.container.schedule(1, self) > def on_link_opened(self, event): > print(event) > class ExampleHandler(tornado.web.RequestHandler): > def get(self): > self.write('hello') > loop = tornado.ioloop.IOLoop.instance() > client = Client("localhost:5800") > client.container = Container(client, loop) > client.container.initialise() > app = tornado.web.Application([tornado.web.url(r"/hello", ExampleHandler)]) > app.listen() > loop.start() > > -- 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] (PROTON-2404) [python] Tornado container does not work both timer and connection
[ https://issues.apache.org/jira/browse/PROTON-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-2404: -- Assignee: Gordon Sim > [python] Tornado container does not work both timer and connection > -- > > Key: PROTON-2404 > URL: https://issues.apache.org/jira/browse/PROTON-2404 > Project: Qpid Proton > Issue Type: Bug > Components: examples >Reporter: Fredrik Hallenberg > Assignee: Gordon Sim >Priority: Major > > I am trying to get the Python tornado container working with qpid proton > 0.34. My goal is to create a tornado server that can also send and receive > amqp messages using a timer. With the below example tornado server works fine > but I am not able to run both timer and amqp connection. If the schedule call > below is uncommented the amqp connection stops working. I can also comment > out create_sender/receive and then timer ticks works. > > It seems to me that something is missing in the tornado container. Although > it just an example I think it is essential to be able to combine the amqp > event loop with event loops in other libraries. It would be good to also have > a container based on asyncio. > > from proton import Message > from proton.handlers import MessagingHandler > from proton_tornado import Container > import tornado.ioloop > import tornado.web > class Client(MessagingHandler): > def __init__(self, url): > super(Client, self).__init__() > self.url = url > def on_timer_task(self, event): > print('tick') > self.container.schedule(1, self) > def on_start(self, event): > self.container = event.reactor > self.sender = event.container.create_sender(self.url) > self.receiver = > event.container.create_receiver(self.sender.connection) > #self.container.schedule(1, self) > def on_link_opened(self, event): > print(event) > class ExampleHandler(tornado.web.RequestHandler): > def get(self): > self.write('hello') > loop = tornado.ioloop.IOLoop.instance() > client = Client("localhost:5800") > client.container = Container(client, loop) > client.container.initialise() > app = tornado.web.Application([tornado.web.url(r"/hello", ExampleHandler)]) > app.listen() > loop.start() > > -- 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-2175) Data race in system_tests_tcp_adaptor involving listener_final_free, qd_dispatch_delete_tcp_listener, pn_listener_close
[ https://issues.apache.org/jira/browse/DISPATCH-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364305#comment-17364305 ] Gordon Sim commented on DISPATCH-2175: -- This looks like it might be a proton issue? > Data race in system_tests_tcp_adaptor involving listener_final_free, > qd_dispatch_delete_tcp_listener, pn_listener_close > --- > > Key: DISPATCH-2175 > URL: https://issues.apache.org/jira/browse/DISPATCH-2175 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.17.0 >Reporter: Jiri Daněk >Priority: Major > Labels: race-condition, tsan > > https://github.com/jiridanek/qpid-dispatch/runs/2838892781?check_suite_focus=true#step:25:3147 > {noformat} > 71: WARNING: ThreadSanitizer: data race (pid=4187) > 71: Write of size 8 at 0x7b68fc28 by thread T4: > 71: #0 free (libtsan.so.0+0x37a28) > 71: #1 listener_final_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1584 > (libqpid-proton-proactor.so.1+0x8650) > 71: #2 pn_listener_free > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1602 > (libqpid-proton-proactor.so.1+0x8650) > 71: #3 listener_done > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1804 > (libqpid-proton-proactor.so.1+0xc31f) > 71: #4 pn_proactor_done > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:2684 > (libqpid-proton-proactor.so.1+0xc31f) > 71: #5 thread_run > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1139 > (libqpid-dispatch.so+0xf6094) > 71: #6 _thread_init > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:172 > (libqpid-dispatch.so+0x968c2) > 71: > 71: Previous read of size 8 at 0x7b68fc28 by thread T3 (mutexes: write > M13): > 71: #0 pn_listener_close > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-proton/c/src/proactor/epoll.c:1651 > (libqpid-proton-proactor.so.1+0x9404) > 71: #1 qd_dispatch_delete_tcp_listener > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/adaptors/tcp_adaptor.c:1204 > (libqpid-dispatch.so+0x5af7e) > 71: #2 ffi_call_unix64 (libffi.so.6+0x6c03) > 71: #3 qdr_forward_on_message > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/forwarder.c:336 > (libqpid-dispatch.so+0xbd5bc) > 71: #4 qdr_general_handler > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/router_core/router_core.c:942 > (libqpid-dispatch.so+0xc6c2b) > 71: #5 qd_timer_visit > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/timer.c:317 > (libqpid-dispatch.so+0xf7b9d) > 71: #6 handle > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1006 > (libqpid-dispatch.so+0xf1bae) > 71: #7 thread_run > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1121 > (libqpid-dispatch.so+0xf60c5) > 71: #8 _thread_init > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:172 > (libqpid-dispatch.so+0x968c2) > 71: > 71: Mutex M13 (0x7b100300) created at: > 71: #0 pthread_mutex_init (libtsan.so.0+0x49603) > 71: #1 sys_mutex > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:43 > (libqpid-dispatch.so+0x9691c) > 71: #2 qd_python_initialize > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/python_embedded.c:54 > (libqpid-dispatch.so+0x98eac) > 71: #3 qd_dispatch > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/dispatch.c:111 > (libqpid-dispatch.so+0x76af5) > 71: #4 main_process > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/router/src/main.c:92 > (qdrouterd+0x4027b9) > 71: #5 main > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/router/src/main.c:369 > (qdrouterd+0x4024fc) > 71: > 71: Thread T4 (tid=4192, running) created by main thread at: > 71: #0 pthread_create (libtsan.so.0+0x5bf45) > 71: #1 sys_thread > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/posix/threading.c:181 > (libqpid-dispatch.so+0x96d5e) > 71: #2 qd_server_run > /home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/src/server.c:1499 > (libqpid-dispatch.so+0xf6302) > 71: #3 main_process > /home/runner/work/qpid-dispatch/qp
[jira] [Commented] (DISPATCH-2174) [tcp] Remove raw_closed_read. Use raw_closed_read instead. Also make q2_blocked atomic
[ https://issues.apache.org/jira/browse/DISPATCH-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363867#comment-17363867 ] Gordon Sim commented on DISPATCH-2174: -- What is the difference between raw_closed_read and raw_closed_read? > [tcp] Remove raw_closed_read. Use raw_closed_read instead. Also make > q2_blocked atomic > -- > > Key: DISPATCH-2174 > URL: https://issues.apache.org/jira/browse/DISPATCH-2174 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > The raw_closed_read can be used to replace raw_closed_read. > The q2_blocked can be made atomic and locking around it can be removed. -- 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-2142) use dedicated buffers in tcp adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-2142. -- Resolution: Fixed > use dedicated buffers in tcp adaptor > > > Key: DISPATCH-2142 > URL: https://issues.apache.org/jira/browse/DISPATCH-2142 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors > Reporter: Gordon Sim >Priority: Major > Fix For: 1.17.0 > > > Proton's raw connection support reads and writes each buffer with a separate > read/write. As the routers buffers are very small, this is inefficient. The > tcp adaptor could have dedicated buffers which could be larger and more > efficient for use with proton, and then copy to/from these from the routers > buffers. -- 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-2142) use dedicated buffers in tcp adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-2142: - Fix Version/s: 1.17.0 > use dedicated buffers in tcp adaptor > > > Key: DISPATCH-2142 > URL: https://issues.apache.org/jira/browse/DISPATCH-2142 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors > Reporter: Gordon Sim >Priority: Major > Fix For: 1.17.0 > > > Proton's raw connection support reads and writes each buffer with a separate > read/write. As the routers buffers are very small, this is inefficient. The > tcp adaptor could have dedicated buffers which could be larger and more > efficient for use with proton, and then copy to/from these from the routers > buffers. -- 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-2142) use dedicated buffers in tcp adaptor
Gordon Sim created DISPATCH-2142: Summary: use dedicated buffers in tcp adaptor Key: DISPATCH-2142 URL: https://issues.apache.org/jira/browse/DISPATCH-2142 Project: Qpid Dispatch Issue Type: Improvement Components: Protocol Adaptors Reporter: Gordon Sim Proton's raw connection support reads and writes each buffer with a separate read/write. As the routers buffers are very small, this is inefficient. The tcp adaptor could have dedicated buffers which could be larger and more efficient for use with proton, and then copy to/from these from the routers buffers. -- 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-2088) SEGV in qd_buffer_dec_fanout
[ https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17334779#comment-17334779 ] Gordon Sim commented on DISPATCH-2088: -- {quote}There are at several cases where router calls into TCP adaptor code lead to calling handle_incoming on a thread that does not own the underlying TCP connection. * qdr_tcp_second_attach * qdr_tcp_flow * qdr_tcp_deliver * qdr_tcp_delivery_update The fix is for these handlers is to call thread-safe connection_wake and then call handle_incoming during the CONNECTION_WAKE event when the thread owns the raw connection. {quote} Is it not the case that those callbacks occur when calling qdr_connection_process() which is done on the io thread? I think flush_outgoing_buffs() should be called in handle_disconnected, which always happens on the IO thread, and not in free_qdr_tcp_connection, which actually happens on the core. > SEGV in qd_buffer_dec_fanout > > > Key: DISPATCH-2088 > URL: https://issues.apache.org/jira/browse/DISPATCH-2088 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors >Reporter: michael goulish >Assignee: Charles E. Rolke >Priority: Blocker > Fix For: 1.16.0 > > > *code from 2021-04-26-afternoon* > { > dispatch: (main) 22689e4f95ae1945e61eec814d3ab3e2d4259f04 > proton: (main) 08b301a97c834e002d41ee852bba1288fe83b936 > } > > *Test* > * Doing 1-router TCP throughput testing across high-bandwidth link. > * Router has 32 worker threads. > * iperf client is using "-P 10" flag, i.e. doing 10 parallel streams. > * Router is sustaining 10+ Gbit/sec during test. > * SEGV happens at end of test. > > Here's the backtrace: > > {color:#de350b}#0 sys_atomic_sub (value=1, ref=0x14){color} > {color:#de350b} at > /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:48{color} > {color:#de350b}#1 sys_atomic_dec (ref=0x14){color} > {color:#de350b} at > /home/mick/latest/qpid-dispatch/include/qpid/dispatch/atomic.h:212{color} > {color:#de350b}#2 qd_buffer_dec_fanout (buf=0x0){color} > {color:#de350b} at > /home/mick/latest/qpid-dispatch/include/qpid/dispatch/buffer.h:177{color} > {color:#de350b}#3 qd_message_stream_data_release > (stream_data=0x7f01b80038c8){color} > {color:#de350b} at /home/mick/latest/qpid-dispatch/src/message.c:2627{color} > {color:#de350b}#4 0x7f0237035895 in flush_outgoing_buffs > (conn=conn@entry=0x7f0218012a88){color} > {color:#de350b} at > /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:431{color} > {color:#de350b}#5 0x7f023703905e in free_qdr_tcp_connection > (tc=0x7f0218012a88){color} > {color:#de350b} at > /home/mick/latest/qpid-dispatch/src/adaptors/tcp_adaptor.c:455{color} > {color:#de350b}#6 0x7f023707491d in router_core_thread > (arg=0x1e6ccb0){color} > {color:#de350b} at > /home/mick/latest/qpid-dispatch/src/router_core/router_core_thread.c:239{color} > {color:#de350b}#7 0x7f0236f663f9 in start_thread () from > /lib64/libpthread.so.0{color} > {color:#de350b}#8 0x7f0236be5b53 in clone () from /lib64/libc.so.6{color} > -- 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-2050) fields for received delivery state are not relayed
[ https://issues.apache.org/jira/browse/DISPATCH-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-2050. -- Resolution: Fixed > fields for received delivery state are not relayed > --- > > Key: DISPATCH-2050 > URL: https://issues.apache.org/jira/browse/DISPATCH-2050 > Project: Qpid Dispatch > Issue Type: Bug > Reporter: Gordon Sim >Priority: Major > > If a disposition is sent with the RECEIVED state and values for > section_number and section_offset, those field values are lost in the > disposition as relayed back to the sender. > > E.g. > {noformat} > [0x55b6a79f6e50]: AMQP:FRAME:0 -> @open(16) > [container-id="558d2cff-3e5a-46c6-903e-47d21a4f0101", hostname="localhost", > channel-max=32767] > [0x55b6a79f6e50]: AMQP:FRAME:0 -> @begin(17) [next-outgoing-id=0, > incoming-window=2147483647, outgoing-window=2147483647] > [0x55b6a79f6e50]: AMQP:FRAME:0 -> @attach(18) > [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=0, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", > durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55b6a79f6e50]: AMQP:FRAME:0 -> @attach(18) > [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=1, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > timeout=0, dynamic=false], target=@target(41) [address="test", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55b6a79f6e50]: AMQP:FRAME:0 -> @flow(19) [incoming-window=2147483647, > next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, > link-credit=10, drain=false] > [0x55b6a79f6e50]: AMQP:FRAME: <- AMQP > [0x55b6a79f6e50]: AMQP:FRAME:0 <- @open(16) > [container-id="Standalone_V+zMPIsTle+Urdn", max-frame-size=16384, > channel-max=32767, idle-time-out=8000, > offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY", :"qd.streaming-links"], > desired-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY", :"qd.streaming-links"], > properties={:product="qpid-dispatch-router", :version="1.16.0-SNAPSHOT", > :"qd.conn-id"=5}] > [0x55b6a79f6e50]: AMQP:FRAME:0 <- @begin(17) [remote-channel=0, > next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647] > [0x55b6a79f6e50]: AMQP:FRAME:0 <- @attach(18) > [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=0, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", > durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false], > target=@target(41) [durable=0, expiry-policy=:"session-end", timeout=0, > dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55b6a79f6e50]: AMQP:FRAME:0 <- @attach(18) > [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=1, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > expiry-policy=:"session-end", timeout=0, dynamic=false], target=@target(41) > [address="test", durable=0, expiry-policy=:"session-end", timeout=0, > dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55b6a79f6e50]: AMQP:FRAME:0 <- @flow(19) [next-incoming-id=0, > incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, > handle=1, delivery-count=0, link-credit=250, drain=false] > [0x55b6a79f6e50]: AMQP:FRAME:0 -> @transfer(20) [handle=1, delivery-id=0, > delivery-tag=b"1", message-format=0] (25) "\x00SpE\x00SsE\x00Sw\xa1\x0cHello > World!" > [0x55b6a79f6e50]: AMQP:FRAME:0 <- @transfer(20) [handle=0, delivery-id=0, > delivery-tag=b"\x04\x00\x00\x00\x00\x00\x00\x00", message-format=0] (25) > "\x00SpE\x00SsE\x00Sw\xa1\x0cHello World!" > Got delivery: Hello World! > [0x55b6a79f6e50]: AMQP:FRAME:0 -> @disposition(21) [role=true, first=0, > state=@received(35) [section-number=10, section-offset=5]] > [0x55b6a79f6e50]: AMQP:FRAME:0 <- @disposition(21) [role=true, first=0, > state=@received(35) [section-number=0, section-offset=0]] > {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] [Created] (DISPATCH-2050) fields for received delivery state are not relayed
Gordon Sim created DISPATCH-2050: Summary: fields for received delivery state are not relayed Key: DISPATCH-2050 URL: https://issues.apache.org/jira/browse/DISPATCH-2050 Project: Qpid Dispatch Issue Type: Bug Reporter: Gordon Sim If a disposition is sent with the RECEIVED state and values for section_number and section_offset, those field values are lost in the disposition as relayed back to the sender. E.g. {noformat} [0x55b6a79f6e50]: AMQP:FRAME:0 -> @open(16) [container-id="558d2cff-3e5a-46c6-903e-47d21a4f0101", hostname="localhost", channel-max=32767] [0x55b6a79f6e50]: AMQP:FRAME:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647] [0x55b6a79f6e50]: AMQP:FRAME:0 -> @attach(18) [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] [0x55b6a79f6e50]: AMQP:FRAME:0 -> @attach(18) [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=1, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="test", durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] [0x55b6a79f6e50]: AMQP:FRAME:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, drain=false] [0x55b6a79f6e50]: AMQP:FRAME: <- AMQP [0x55b6a79f6e50]: AMQP:FRAME:0 <- @open(16) [container-id="Standalone_V+zMPIsTle+Urdn", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY", :"qd.streaming-links"], desired-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY", :"qd.streaming-links"], properties={:product="qpid-dispatch-router", :version="1.16.0-SNAPSHOT", :"qd.conn-id"=5}] [0x55b6a79f6e50]: AMQP:FRAME:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647] [0x55b6a79f6e50]: AMQP:FRAME:0 <- @attach(18) [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false], target=@target(41) [durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] [0x55b6a79f6e50]: AMQP:FRAME:0 <- @attach(18) [name="558d2cff-3e5a-46c6-903e-47d21a4f0101-test", handle=1, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false], target=@target(41) [address="test", durable=0, expiry-policy=:"session-end", timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] [0x55b6a79f6e50]: AMQP:FRAME:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, handle=1, delivery-count=0, link-credit=250, drain=false] [0x55b6a79f6e50]: AMQP:FRAME:0 -> @transfer(20) [handle=1, delivery-id=0, delivery-tag=b"1", message-format=0] (25) "\x00SpE\x00SsE\x00Sw\xa1\x0cHello World!" [0x55b6a79f6e50]: AMQP:FRAME:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x04\x00\x00\x00\x00\x00\x00\x00", message-format=0] (25) "\x00SpE\x00SsE\x00Sw\xa1\x0cHello World!" Got delivery: Hello World! [0x55b6a79f6e50]: AMQP:FRAME:0 -> @disposition(21) [role=true, first=0, state=@received(35) [section-number=10, section-offset=5]] [0x55b6a79f6e50]: AMQP:FRAME:0 <- @disposition(21) [role=true, first=0, state=@received(35) [section-number=0, section-offset=0]] {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-1829) multi-hop TCP does not seem to work
[ https://issues.apache.org/jira/browse/DISPATCH-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1829. -- Resolution: Fixed > multi-hop TCP does not seem to work > --- > > Key: DISPATCH-1829 > URL: https://issues.apache.org/jira/browse/DISPATCH-1829 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Gordon Sim >Priority: Major > Fix For: 1.15.0 > > > Attempting to connect through a chain of three routers, > ingress->interior->egress, does not work. This seems to be independent of > whether the ingress and egress routers are edge or interior mode. However > connecting with TCP through the interior to egress does work. -- 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-1898) support event channel option in http1 adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1898. -- Fix Version/s: 1.15.0 Resolution: Fixed > support event channel option in http1 adaptor > -- > > Key: DISPATCH-1898 > URL: https://issues.apache.org/jira/browse/DISPATCH-1898 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Protocol Adaptors > Reporter: Gordon Sim >Priority: Major > Fix For: 1.15.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] [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&focusedCommentId=17264141#comment-17264141 ] Gordon Sim commented on DISPATCH-1903: -- Agree with Robbie that it *might* be simpler overall to have e.g. caCertString, certString and privateKeyString, with pem encoded strings as values and never bother trying to write them out. Typical certs/keys are not that long, 2k or so. I wouldn't recommend this as an approach for the config file, but over the management protocol that would work fine. Alternatively you could have e.g caCertRef, certRef, privateKeyRef and then have a new 'named blob' entity that these refer to. The named blob would be created/deleted using management and held in memory. > 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&focusedCommentId=17264041#comment-17264041 ] Gordon Sim commented on DISPATCH-1903: -- What happens now if you use a relative path for certs? Will this alter previous behaviour? I.e. might an existing deployment that does not use absolute paths stop working on upgrade? > 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-1898) support event channel option in http1 adaptor
Gordon Sim created DISPATCH-1898: Summary: support event channel option in http1 adaptor Key: DISPATCH-1898 URL: https://issues.apache.org/jira/browse/DISPATCH-1898 Project: Qpid Dispatch Issue Type: New Feature Components: Protocol Adaptors Reporter: Gordon Sim -- 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-1887) Add ability to override host header in http connector
[ https://issues.apache.org/jira/browse/DISPATCH-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1887. -- Resolution: Fixed > Add ability to override host header in http connector > - > > Key: DISPATCH-1887 > URL: https://issues.apache.org/jira/browse/DISPATCH-1887 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors > Reporter: Gordon Sim > Assignee: Gordon Sim >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] [Closed] (DISPATCH-1780) multicast support for http 1.1 adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1780. Resolution: Fixed > multicast support for http 1.1 adaptor > -- > > Key: DISPATCH-1780 > URL: https://issues.apache.org/jira/browse/DISPATCH-1780 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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-1892) http1 json aggregation does not handle large messages
Gordon Sim created DISPATCH-1892: Summary: http1 json aggregation does not handle large messages Key: DISPATCH-1892 URL: https://issues.apache.org/jira/browse/DISPATCH-1892 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Environment: At some point above 8k the conversion of the message into a python message is truncating data. Reporter: Gordon Sim -- 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-1891) http1 multicast does not handle chunked content
Gordon Sim created DISPATCH-1891: Summary: http1 multicast does not handle chunked content Key: DISPATCH-1891 URL: https://issues.apache.org/jira/browse/DISPATCH-1891 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim -- 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-1890) need tests for http1 multicast
Gordon Sim created DISPATCH-1890: Summary: need tests for http1 multicast Key: DISPATCH-1890 URL: https://issues.apache.org/jira/browse/DISPATCH-1890 Project: Qpid Dispatch Issue Type: Improvement Components: Protocol Adaptors Reporter: Gordon Sim -- 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-1887) Add ability to override host header in http connector
[ https://issues.apache.org/jira/browse/DISPATCH-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17250961#comment-17250961 ] Gordon Sim commented on DISPATCH-1887: -- Thanks [~robbie]! > Add ability to override host header in http connector > - > > Key: DISPATCH-1887 > URL: https://issues.apache.org/jira/browse/DISPATCH-1887 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Protocol Adaptors > Reporter: Gordon Sim >Assignee: Gordon Sim >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] [Created] (DISPATCH-1887) Add ability toverride host header in http connector
Gordon Sim created DISPATCH-1887: Summary: Add ability toverride host header in http connector Key: DISPATCH-1887 URL: https://issues.apache.org/jira/browse/DISPATCH-1887 Project: Qpid Dispatch Issue Type: Improvement Components: Protocol Adaptors Reporter: Gordon Sim Assignee: Gordon Sim -- 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-1857) concurrent tcp connection attempts can result in hangs
Gordon Sim created DISPATCH-1857: Summary: concurrent tcp connection attempts can result in hangs Key: DISPATCH-1857 URL: https://issues.apache.org/jira/browse/DISPATCH-1857 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim -- 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-1847) http2 stats do not record client ip correctly
[ https://issues.apache.org/jira/browse/DISPATCH-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1847. -- Resolution: Fixed > http2 stats do not record client ip correctly > - > > Key: DISPATCH-1847 > URL: https://issues.apache.org/jira/browse/DISPATCH-1847 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Gordon Sim > Assignee: Gordon Sim >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] [Resolved] (DISPATCH-1843) http stats are not correctly separated by address
[ https://issues.apache.org/jira/browse/DISPATCH-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1843. -- Resolution: Fixed > http stats are not correctly separated by address > - > > Key: DISPATCH-1843 > URL: https://issues.apache.org/jira/browse/DISPATCH-1843 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Gordon Sim > Assignee: Gordon Sim >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] [Created] (DISPATCH-1847) http2 stats do not record client ip correctly
Gordon Sim created DISPATCH-1847: Summary: http2 stats do not record client ip correctly Key: DISPATCH-1847 URL: https://issues.apache.org/jira/browse/DISPATCH-1847 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim Assignee: Gordon Sim -- 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-1829) multi-hop TCP does not seem to work
[ https://issues.apache.org/jira/browse/DISPATCH-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17234911#comment-17234911 ] Gordon Sim commented on DISPATCH-1829: -- The original reported issue was much more prevalent and affected any case where more than a single inter-router transfer was involved. That was fixed. However I'm fine with repurposing the Jira for a more specific occurrence. Just noting here the fact that the description no longer matches the current issue. > multi-hop TCP does not seem to work > --- > > Key: DISPATCH-1829 > URL: https://issues.apache.org/jira/browse/DISPATCH-1829 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors >Reporter: Gordon Sim >Priority: Major > Fix For: 1.15.0 > > > Attempting to connect through a chain of three routers, > ingress->interior->egress, does not work. This seems to be independent of > whether the ingress and egress routers are edge or interior mode. However > connecting with TCP through the interior to egress does work. -- 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-1843) http stats are not correctly separated by address
Gordon Sim created DISPATCH-1843: Summary: http stats are not correctly separated by address Key: DISPATCH-1843 URL: https://issues.apache.org/jira/browse/DISPATCH-1843 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim Assignee: Gordon Sim -- 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-1838) Out link not closed when http1 connector is deleted
[ https://issues.apache.org/jira/browse/DISPATCH-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1838. Resolution: Duplicate > Out link not closed when http1 connector is deleted > --- > > Key: DISPATCH-1838 > URL: https://issues.apache.org/jira/browse/DISPATCH-1838 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Gordon Sim >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-1838) Out link not closed when http1 connector is deleted
[ https://issues.apache.org/jira/browse/DISPATCH-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1838: - Summary: Out link not closed when http1 connector is deleted (was: Http1 listeners and connectors need to close all associated connections when deleted) > Out link not closed when http1 connector is deleted > --- > > Key: DISPATCH-1838 > URL: https://issues.apache.org/jira/browse/DISPATCH-1838 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors > Reporter: Gordon Sim >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] [Closed] (DISPATCH-1839) http2 listeners and connectors need to close all associated connections when deleted
[ https://issues.apache.org/jira/browse/DISPATCH-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1839. Resolution: Won't Fix > http2 listeners and connectors need to close all associated connections when > deleted > > > Key: DISPATCH-1839 > URL: https://issues.apache.org/jira/browse/DISPATCH-1839 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors >Reporter: Gordon Sim >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] [Closed] (DISPATCH-1837) Tcp listeners and connectors need to close all associated connections when deleted
[ https://issues.apache.org/jira/browse/DISPATCH-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1837. Resolution: Won't Fix > Tcp listeners and connectors need to close all associated connections when > deleted > -- > > Key: DISPATCH-1837 > URL: https://issues.apache.org/jira/browse/DISPATCH-1837 > Project: Qpid Dispatch > Issue Type: Bug > Components: Protocol Adaptors >Reporter: Gordon Sim >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] [Created] (DISPATCH-1838) Http1 listeners and connectors need to close all associated connections when deleted
Gordon Sim created DISPATCH-1838: Summary: Http1 listeners and connectors need to close all associated connections when deleted Key: DISPATCH-1838 URL: https://issues.apache.org/jira/browse/DISPATCH-1838 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim -- 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-1839) http2 listeners and connectors need to close all associated connections when deleted
Gordon Sim created DISPATCH-1839: Summary: http2 listeners and connectors need to close all associated connections when deleted Key: DISPATCH-1839 URL: https://issues.apache.org/jira/browse/DISPATCH-1839 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim -- 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-1837) Tcp listeners and connectors need to close all associated connections when deleted
Gordon Sim created DISPATCH-1837: Summary: Tcp listeners and connectors need to close all associated connections when deleted Key: DISPATCH-1837 URL: https://issues.apache.org/jira/browse/DISPATCH-1837 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim -- 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-1832) deleting http/tcp listener/connectors causes segfault
[ https://issues.apache.org/jira/browse/DISPATCH-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1832. -- Resolution: Fixed > deleting http/tcp listener/connectors causes segfault > - > > Key: DISPATCH-1832 > URL: https://issues.apache.org/jira/browse/DISPATCH-1832 > Project: Qpid Dispatch > Issue Type: Bug > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > > Management requests to delete http or tcp listeners/connectors often (but not > always) causes a segfault. -- 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-1832) deleting http/tcp listener/connectors causes segfault
Gordon Sim created DISPATCH-1832: Summary: deleting http/tcp listener/connectors causes segfault Key: DISPATCH-1832 URL: https://issues.apache.org/jira/browse/DISPATCH-1832 Project: Qpid Dispatch Issue Type: Bug Reporter: Gordon Sim Assignee: Gordon Sim Management requests to delete http or tcp listeners/connectors often (but not always) causes a segfault. -- 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-1829) multi-hop TCP does not seem to work
Gordon Sim created DISPATCH-1829: Summary: multi-hop TCP does not seem to work Key: DISPATCH-1829 URL: https://issues.apache.org/jira/browse/DISPATCH-1829 Project: Qpid Dispatch Issue Type: Bug Components: Protocol Adaptors Reporter: Gordon Sim Attempting to connect through a chain of three routers, ingress->interior->egress, does not work. This seems to be independent of whether the ingress and egress routers are edge or interior mode. However connecting with TCP through the interior to egress does work. -- 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-1776) HTTP/2 - grpc call causes segfault
[ https://issues.apache.org/jira/browse/DISPATCH-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17226350#comment-17226350 ] Gordon Sim commented on DISPATCH-1776: -- With latest code the failure is much less frequent, but running the ping example abive several times I got: {noformat} Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `qdrouterd -c /home/gordon/projects/router-config-examples/http2-bridges.conf'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7fa1cbbb80cb in qd_message_stream_data_release (stream_data=0x0) at /home/gordon/projects/dispatch/src/message.c:2514 2514qd_message_pvt_t *pvt = stream_data->owning_message; [Current thread is 1 (Thread 0x7fa1c29bf700 (LWP 2061461))] Missing separate debuginfos, use: dnf debuginfo-install cyrus-sasl-lib-2.1.27-2.fc31.x86_64 glibc-2.30-10.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 0x7fa1cbbb80cb in qd_message_stream_data_release (stream_data=0x0) at /home/gordon/projects/dispatch/src/message.c:2514 #1 0x7fa1cbb8fde1 in read_data_callback (session=, stream_id=, buf=, length=, data_flags=0x7fa1c29bdcf4, source=, user_data=0x812c88) at /home/gordon/projects/dispatch/src/adaptors/http2/http2_adaptor.c:1009 #2 0x7fa1cb6d5ce9 in nghttp2_session_pack_data () from /lib64/libnghttp2.so.14 #3 0x7fa1cb6d68bb in nghttp2_session_mem_send_internal () from /lib64/libnghttp2.so.14 #4 0x7fa1cb6d7079 in nghttp2_session_send () from /lib64/libnghttp2.so.14 #5 0x7fa1cbb9387d in handle_outgoing_http (stream_data=stream_data@entry=0x7fa1b402a208) at /home/gordon/projects/dispatch/src/adaptors/http2/http2_adaptor.c:1539 #6 0x7fa1cbb93d84 in qdr_http_deliver (context=, link=0x7fa1b81626c8, delivery=0x7fa1ac01d8c8, settled=) at /home/gordon/projects/dispatch/src/adaptors/http2/http2_adaptor.c:1705 #7 0x7fa1cbbdfb15 in qdr_link_process_deliveries (core=0x7e50e0, link=0x7fa1b81626c8, credit=1) at /home/gordon/projects/dispatch/src/router_core/transfer.c:167 #8 0x7fa1cbbcb151 in qdr_connection_process (conn=0x82cb48) at /home/gordon/projects/dispatch/src/router_core/connections.c:383 #9 0x7fa1cbb941b9 in handle_connection_event (e=, qd_server=, context=0x812c88) at /home/gordon/projects/dispatch/src/adaptors/http2/http2_adaptor.c:2125 #10 0x7fa1cbbeff71 in handle_event_with_context (context=, qd_server=, e=) at /home/gordon/projects/dispatch/src/server.c:804 #11 do_handle_raw_connection_event (qd_server=, e=) at /home/gordon/projects/dispatch/src/server.c:810 #12 handle (qd_server=qd_server@entry=0x7a78e0, e=e@entry=0x7fa1b8006800, pn_conn=pn_conn@entry=0x0, ctx=ctx@entry=0x0) at /home/gordon/projects/dispatch/src/server.c:1090 #13 0x7fa1cbbf0fa8 in thread_run (arg=0x7a78e0) at /home/gordon/projects/dispatch/src/server.c:1122 #14 0x7fa1cbacb4e2 in start_thread () from /lib64/libpthread.so.0 #15 0x7fa1cb6006d3 in clone () from /lib64/libc.so.6 {noformat} > 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/
[jira] [Assigned] (DISPATCH-1780) multicast support for http 1.1 adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned DISPATCH-1780: Assignee: Gordon Sim > multicast support for http 1.1 adaptor > -- > > Key: DISPATCH-1780 > URL: https://issues.apache.org/jira/browse/DISPATCH-1780 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Resolved] (DISPATCH-1777) inter-router transfer of streaming message representing tcp connection is not delivered
[ https://issues.apache.org/jira/browse/DISPATCH-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1777. -- Resolution: Fixed > inter-router transfer of streaming message representing tcp connection is not > delivered > --- > > Key: DISPATCH-1777 > URL: https://issues.apache.org/jira/browse/DISPATCH-1777 > Project: Qpid Dispatch > Issue Type: Sub-task > Reporter: Gordon Sim >Priority: Major > > The message for a tcp connections gets correctly router to an inter-router > link, but that link seems not to be able to transfer it. It remains in the > undelivered state. > {noformat} > $ qdstat -l -r router-b > 2020-09-18 09:56:27.754348 UTC > router-b > Router Links > typedir conn id id peer class addr phs > cap pri undel unsett deliv presett psdrop acc rej rel mod delay > rate stuck cred blkd > > > router-control in 11 > 250 00 0 746746 0 00000 1 > 0 250 - > router-control out 12 local qdhello > 250 00 0 744744 0 00000 0 > 0 250 - > inter-routerin 13 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 14 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerin 15 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 16 > 250 10 0 0 00 00000 0 > 0 250 - > inter-routerin 17 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 18 > 250 20 0 0 00 00000 0 > 0 250 - > inter-routerin 19 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 110 > 250 30 0 0 00 00000 0 > 0 250 - > inter-routerin 111 > 250 00 0 5 00 50000 0 > 0 250 - > inter-routerout 112 > 250 40 0 4 40 00000 0 > 0 250 - > inter-routerin 113 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 114 > 250 50 0 0 00 00000 0 > 0 250 - > inter-routerin 115 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 116 > 250 60 0 0 00 00000 0 > 0 250 - > inter-routerin 117 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 118 > 250 70 0 0 00 00000 0 > 0 250 - > inter-routerin 119 > 250 00 0 0 00 00000 0
[jira] [Resolved] (DISPATCH-1654) tcp protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1654. -- Resolution: Fixed Marking resolved, will handle any updates/fixes through new JIRAs > tcp protocol bridging (ingress and egress) > -- > > Key: DISPATCH-1654 > URL: https://issues.apache.org/jira/browse/DISPATCH-1654 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Resolved] (DISPATCH-1779) http stats/metrics
[ https://issues.apache.org/jira/browse/DISPATCH-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved DISPATCH-1779. -- Resolution: Fixed > http stats/metrics > -- > > Key: DISPATCH-1779 > URL: https://issues.apache.org/jira/browse/DISPATCH-1779 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Updated] (DISPATCH-1779) http stats/metrics
[ https://issues.apache.org/jira/browse/DISPATCH-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1779: - Status: Reviewable (was: In Progress) > http stats/metrics > -- > > Key: DISPATCH-1779 > URL: https://issues.apache.org/jira/browse/DISPATCH-1779 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Commented] (DISPATCH-1777) inter-router transfer of streaming message representing tcp connection is not delivered
[ https://issues.apache.org/jira/browse/DISPATCH-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208343#comment-17208343 ] Gordon Sim commented on DISPATCH-1777: -- It looks like the issue is that the message won't be processed by AMQP_rx_handler until it hits the Q2 limit. I think we may need/want an annotation to make it explicit that the message is a streaming on so that it does not try to wait for the Q2 limit. The annotation could either be on the inter-router link, or on the message itself. > inter-router transfer of streaming message representing tcp connection is not > delivered > --- > > Key: DISPATCH-1777 > URL: https://issues.apache.org/jira/browse/DISPATCH-1777 > Project: Qpid Dispatch > Issue Type: Sub-task >Reporter: Gordon Sim >Priority: Major > > The message for a tcp connections gets correctly router to an inter-router > link, but that link seems not to be able to transfer it. It remains in the > undelivered state. > {noformat} > $ qdstat -l -r router-b > 2020-09-18 09:56:27.754348 UTC > router-b > Router Links > typedir conn id id peer class addr phs > cap pri undel unsett deliv presett psdrop acc rej rel mod delay > rate stuck cred blkd > > > router-control in 11 > 250 00 0 746746 0 00000 1 > 0 250 - > router-control out 12 local qdhello > 250 00 0 744744 0 00000 0 > 0 250 - > inter-routerin 13 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 14 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerin 15 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 16 > 250 10 0 0 00 00000 0 > 0 250 - > inter-routerin 17 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 18 > 250 20 0 0 00 00000 0 > 0 250 - > inter-routerin 19 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 110 > 250 30 0 0 00 00000 0 > 0 250 - > inter-routerin 111 > 250 00 0 5 00 50000 0 > 0 250 - > inter-routerout 112 > 250 40 0 4 40 00000 0 > 0 250 - > inter-routerin 113 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 114 > 250 50 0 0 00 00000 0 > 0 250 - > inter-routerin 115 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 116 > 250 60 0 0 00 00000 0 > 0 250 - > inter-routerin 117 > 250 00 0 0 00 00000 0 >
[jira] [Commented] (DISPATCH-1777) inter-router transfer of streaming message representing tcp connection is not delivered
[ https://issues.apache.org/jira/browse/DISPATCH-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208203#comment-17208203 ] Gordon Sim commented on DISPATCH-1777: -- The stats are a red-herring, the message remains in undelivered state until it is complete and since it is a streaming message that does not happen. The message *is* making its way to the egress router, but for some reason is not then getting delivered to the outgoing link for the address. > inter-router transfer of streaming message representing tcp connection is not > delivered > --- > > Key: DISPATCH-1777 > URL: https://issues.apache.org/jira/browse/DISPATCH-1777 > Project: Qpid Dispatch > Issue Type: Sub-task > Reporter: Gordon Sim >Priority: Major > > The message for a tcp connections gets correctly router to an inter-router > link, but that link seems not to be able to transfer it. It remains in the > undelivered state. > {noformat} > $ qdstat -l -r router-b > 2020-09-18 09:56:27.754348 UTC > router-b > Router Links > typedir conn id id peer class addr phs > cap pri undel unsett deliv presett psdrop acc rej rel mod delay > rate stuck cred blkd > > > router-control in 11 > 250 00 0 746746 0 00000 1 > 0 250 - > router-control out 12 local qdhello > 250 00 0 744744 0 00000 0 > 0 250 - > inter-routerin 13 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 14 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerin 15 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 16 > 250 10 0 0 00 00000 0 > 0 250 - > inter-routerin 17 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 18 > 250 20 0 0 00 00000 0 > 0 250 - > inter-routerin 19 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 110 > 250 30 0 0 00 00000 0 > 0 250 - > inter-routerin 111 > 250 00 0 5 00 50000 0 > 0 250 - > inter-routerout 112 > 250 40 0 4 40 00000 0 > 0 250 - > inter-routerin 113 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 114 > 250 50 0 0 00 00000 0 > 0 250 - > inter-routerin 115 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 116 > 250 60 0 0 00 00000 0 > 0 250 - > inter-routerin 117 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 118
[jira] [Created] (QPID-8467) [AMQP 1.0] annotations added by broker are sent with string keys rather than symbols
Gordon Sim created QPID-8467: Summary: [AMQP 1.0] annotations added by broker are sent with string keys rather than symbols Key: QPID-8467 URL: https://issues.apache.org/jira/browse/QPID-8467 Project: Qpid Issue Type: Bug Components: C++ Broker Reporter: Gordon Sim -- 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-1777) inter-router transfer of streaming message representing tcp connection is not delivered
[ https://issues.apache.org/jira/browse/DISPATCH-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17200334#comment-17200334 ] Gordon Sim commented on DISPATCH-1777: -- To reproduce, setup a pair of routers, one with a tcp listener, one with a tcp connector. Have some service running that the tcp connector is configured to connect to. Then try and use that service via the port the tcp listener is listening on. E.g. router 1 config: {noformat} router { id: router-a mode: interior } listener { host: 0.0.0.0 port: amqp authenticatePeer: no saslMechanisms: ANONYMOUS } listener { host: 0.0.0.0 port: 55672 role: inter-router authenticatePeer: no saslMechanisms: ANONYMOUS } tcpConnector { host: 127.0.0.1 port: 9090 address: foo siteId: bar } log { module: TCP_ADAPTOR enable: trace+ } {noformat} router 2 config: {noformat} router { id: router-b mode: interior } listener { host: 0.0.0.0 port: 5673 authenticatePeer: no saslMechanisms: ANONYMOUS } connector { host: 0.0.0.0 port: 55672 role: inter-router } tcpListener { host: 0.0.0.0 port: 9191 address: foo siteId: bar } log { module: TCP_ADAPTOR enable: trace+ } {noformat} For a service I used simple echo service, e.g. {{podman run -it -p9090:9090 quay.io/skupper/tcp-echo}} (or docker if you don't use podman), then {{telnet localhost 9191}} and type data to be echoed. > inter-router transfer of streaming message representing tcp connection is not > delivered > --- > > Key: DISPATCH-1777 > URL: https://issues.apache.org/jira/browse/DISPATCH-1777 > Project: Qpid Dispatch > Issue Type: Sub-task >Reporter: Gordon Sim >Priority: Major > > The message for a tcp connections gets correctly router to an inter-router > link, but that link seems not to be able to transfer it. It remains in the > undelivered state. > {noformat} > $ qdstat -l -r router-b > 2020-09-18 09:56:27.754348 UTC > router-b > Router Links > typedir conn id id peer class addr phs > cap pri undel unsett deliv presett psdrop acc rej rel mod delay > rate stuck cred blkd > > > router-control in 11 > 250 00 0 746746 0 00000 1 > 0 250 - > router-control out 12 local qdhello > 250 00 0 744744 0 00000 0 > 0 250 - > inter-routerin 13 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 14 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerin 15 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 16 > 250 10 0 0 00 00000 0 > 0 250 - > inter-routerin 17 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 18 > 250 20 0 0 00 00000 0 > 0 250 - > inter-routerin 19 > 250 00 0 0 00 00000 0 > 0 250 - > inter-routerout 110 > 250 30 0 0 00 00000 0 > 0 250 - > inter-routerin 111 > 250 00 0 5 00 50000 0 > 0 250 - > inter-routerout 112 > 250 40 0 4 40 00000 0 >
[jira] [Updated] (DISPATCH-1655) http2 protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1655: - Sprint: (was: Multi-Protocol Support) > http2 protocol bridging (ingress and egress) > > > Key: DISPATCH-1655 > URL: https://issues.apache.org/jira/browse/DISPATCH-1655 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >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-1779) http stats/metrics
[ https://issues.apache.org/jira/browse/DISPATCH-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned DISPATCH-1779: Assignee: Gordon Sim > http stats/metrics > -- > > Key: DISPATCH-1779 > URL: https://issues.apache.org/jira/browse/DISPATCH-1779 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Updated] (DISPATCH-1744) Add HTTP/1.1 support to the router
[ https://issues.apache.org/jira/browse/DISPATCH-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1744: - Sprint: Multi-Protocol Support > Add HTTP/1.1 support to the router > -- > > Key: DISPATCH-1744 > URL: https://issues.apache.org/jira/browse/DISPATCH-1744 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ganesh Murthy >Assignee: Ken Giusti >Priority: Major > > Add new feature to support HTTP/1.1 protocol on the router. > This feature involves the introduction of new entities to the router called > httpListener and httpConnector. The httpListener will accept HTTP/1.1 > connections and make an outbound connection using the httpConnector. > The router will use AMQP to route the messages. The router will act as a > protocol bridge. -- 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-1780) multicast support for http 1.1 adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1780: - Sprint: Multi-Protocol Support > multicast support for http 1.1 adaptor > -- > > Key: DISPATCH-1780 > URL: https://issues.apache.org/jira/browse/DISPATCH-1780 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Updated] (DISPATCH-1743) Add HTTP/2 support to the router
[ https://issues.apache.org/jira/browse/DISPATCH-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1743: - Sprint: Multi-Protocol Support > Add HTTP/2 support to the router > > > Key: DISPATCH-1743 > URL: https://issues.apache.org/jira/browse/DISPATCH-1743 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Add new feature to support HTTP/2 protocol on the router. > This feature involves the introduction of new entities to the router called > httpListener and httpConnector. The httpListener will accept HTTP/2 > connections and make an outbound connection using the httpConnector. > The router will use AMQP to route the messages. The router will act as a > protocol bridge. -- 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-1779) http stats/metrics
[ https://issues.apache.org/jira/browse/DISPATCH-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1779: - Sprint: Multi-Protocol Support > http stats/metrics > -- > > Key: DISPATCH-1779 > URL: https://issues.apache.org/jira/browse/DISPATCH-1779 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Closed] (DISPATCH-1655) http2 protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1655. Resolution: Duplicate > http2 protocol bridging (ingress and egress) > > > Key: DISPATCH-1655 > URL: https://issues.apache.org/jira/browse/DISPATCH-1655 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >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-1654) tcp protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1654: - Sprint: Extended Sprint 1 > tcp protocol bridging (ingress and egress) > -- > > Key: DISPATCH-1654 > URL: https://issues.apache.org/jira/browse/DISPATCH-1654 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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] [Updated] (DISPATCH-1655) http2 protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1655: - Sprint: Extended Sprint 1 > http2 protocol bridging (ingress and egress) > > > Key: DISPATCH-1655 > URL: https://issues.apache.org/jira/browse/DISPATCH-1655 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >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-1780) multicast support for http 1.1 adaptor
[ https://issues.apache.org/jira/browse/DISPATCH-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1780: - Fix Version/s: 1.15.0 > multicast support for http 1.1 adaptor > -- > > Key: DISPATCH-1780 > URL: https://issues.apache.org/jira/browse/DISPATCH-1780 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >Priority: Major > Fix For: 1.15.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-1780) multicast support for http 1.1 adaptor
Gordon Sim created DISPATCH-1780: Summary: multicast support for http 1.1 adaptor Key: DISPATCH-1780 URL: https://issues.apache.org/jira/browse/DISPATCH-1780 Project: Qpid Dispatch Issue Type: Improvement Reporter: Gordon Sim -- 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-1779) http stats/metrics
Gordon Sim created DISPATCH-1779: Summary: http stats/metrics Key: DISPATCH-1779 URL: https://issues.apache.org/jira/browse/DISPATCH-1779 Project: Qpid Dispatch Issue Type: Improvement Reporter: Gordon Sim Fix For: 1.15.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] [Updated] (DISPATCH-1654) tcp protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated DISPATCH-1654: - Fix Version/s: 1.15.0 > tcp protocol bridging (ingress and egress) > -- > > Key: DISPATCH-1654 > URL: https://issues.apache.org/jira/browse/DISPATCH-1654 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >Priority: Major > Fix For: 1.15.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-1654) tcp protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned DISPATCH-1654: Assignee: Gordon Sim > tcp protocol bridging (ingress and egress) > -- > > Key: DISPATCH-1654 > URL: https://issues.apache.org/jira/browse/DISPATCH-1654 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim > Assignee: Gordon Sim >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] [Created] (DISPATCH-1778) spurious buffer inserted in body data
Gordon Sim created DISPATCH-1778: Summary: spurious buffer inserted in body data Key: DISPATCH-1778 URL: https://issues.apache.org/jira/browse/DISPATCH-1778 Project: Qpid Dispatch Issue Type: Sub-task Reporter: Gordon Sim When running a simple telnet driven tcp-echo through the tcp adapater in the router I often see a spurious buffer in the body data read on egress from the message. This seems to consist of the data section header, binary code and length. -- 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-1777) inter-router transfer of streaming message representing tcp connection is not delivered
Gordon Sim created DISPATCH-1777: Summary: inter-router transfer of streaming message representing tcp connection is not delivered Key: DISPATCH-1777 URL: https://issues.apache.org/jira/browse/DISPATCH-1777 Project: Qpid Dispatch Issue Type: Sub-task Reporter: Gordon Sim The message for a tcp connections gets correctly router to an inter-router link, but that link seems not to be able to transfer it. It remains in the undelivered state. {noformat} $ qdstat -l -r router-b 2020-09-18 09:56:27.754348 UTC router-b Router Links typedir conn id id peer class addr phs cap pri undel unsett deliv presett psdrop acc rej rel mod delay rate stuck cred blkd router-control in 11 250 00 0 746746 0 00000 1 0 250 - router-control out 12 local qdhello 250 00 0 744744 0 00000 0 0 250 - inter-routerin 13 250 00 0 0 00 00000 0 0 250 - inter-routerout 14 250 00 0 0 00 00000 0 0 250 - inter-routerin 15 250 00 0 0 00 00000 0 0 250 - inter-routerout 16 250 10 0 0 00 00000 0 0 250 - inter-routerin 17 250 00 0 0 00 00000 0 0 250 - inter-routerout 18 250 20 0 0 00 00000 0 0 250 - inter-routerin 19 250 00 0 0 00 00000 0 0 250 - inter-routerout 110 250 30 0 0 00 00000 0 0 250 - inter-routerin 111 250 00 0 5 00 50000 0 0 250 - inter-routerout 112 250 40 0 4 40 00000 0 0 250 - inter-routerin 113 250 00 0 0 00 00000 0 0 250 - inter-routerout 114 250 50 0 0 00 00000 0 0 250 - inter-routerin 115 250 00 0 0 00 00000 0 0 250 - inter-routerout 116 250 60 0 0 00 00000 0 0 250 - inter-routerin 117 250 00 0 0 00 00000 0 0 250 - inter-routerout 118 250 70 0 0 00 00000 0 0 250 - inter-routerin 119 250 00 0 0 00 00000 0 0 250 - inter-routerout 120 250 80 0 0 00 00000 0 0 250 - inter-routerin 121 250 00 0 0 00 00000 0 0 250 - inter-routerout 122 250 90 0 0 00 00000 0 0 250 - endpointout 223local temp.dXw6fBQSSfhCbmZ 250 00 0 0 0
[jira] [Created] (DISPATCH-1776) grpc call causes segfault
Gordon Sim created DISPATCH-1776: Summary: grpc call causes segfault Key: DISPATCH-1776 URL: https://issues.apache.org/jira/browse/DISPATCH-1776 Project: Qpid Dispatch Issue Type: Sub-task Reporter: Gordon Sim Assignee: Ganesh Murthy 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=) 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] [Closed] (QPID-8462) Qpid broker memory increases when a receiver is paused with message pending acks
[ https://issues.apache.org/jira/browse/QPID-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed QPID-8462. Resolution: Not A Bug > Qpid broker memory increases when a receiver is paused with message pending > acks > - > > Key: QPID-8462 > URL: https://issues.apache.org/jira/browse/QPID-8462 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.39.0 > Environment: Linux > >Reporter: KALYANARAMAN SIVARAMAN >Priority: Major > Attachments: brokerMemoryIncrease.tar > > > Given the situation where we have a receiver "Receiver1" acquire 1 message > from a queue "ReceiverQueue" but if the message is not acknowledged and > Receiver1 process is paused using kill -STOP . > Any further messages sent to ReceiverQueue is marked as DELETED even though > we have another receiver "Receiver2" properly acquire messages from the queue > and also sends acknowledgements, the broker memory linearly increases until > all the memory in the box is used. Purger cleaning up messages does not help. > Once we kill Receiver1 the broker memory stabilizes. > All of the repro steps are automated in the attached reproducer. > > Please follow the steps to reproduce the issue > > Step 1: tar -xf brokerMemoryIncrease.tar > Step 2: cd brokerMemoryIncrease > Step 3: ./qpidRepro.sh > -- 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] (QPID-8462) Qpid broker memory increases when a receiver is paused with message pending acks
[ https://issues.apache.org/jira/browse/QPID-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193816#comment-17193816 ] Gordon Sim commented on QPID-8462: -- The purger will move expired messages to DELETED state. This means it does not hold on to the message data. However the record within the queue structure is still there. Using `qpid-stat -u` should show subscriptions with unacked messages. > Qpid broker memory increases when a receiver is paused with message pending > acks > - > > Key: QPID-8462 > URL: https://issues.apache.org/jira/browse/QPID-8462 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.39.0 > Environment: Linux > >Reporter: KALYANARAMAN SIVARAMAN >Priority: Major > Attachments: brokerMemoryIncrease.tar > > > Given the situation where we have a receiver "Receiver1" acquire 1 message > from a queue "ReceiverQueue" but if the message is not acknowledged and > Receiver1 process is paused using kill -STOP . > Any further messages sent to ReceiverQueue is marked as DELETED even though > we have another receiver "Receiver2" properly acquire messages from the queue > and also sends acknowledgements, the broker memory linearly increases until > all the memory in the box is used. Purger cleaning up messages does not help. > Once we kill Receiver1 the broker memory stabilizes. > All of the repro steps are automated in the attached reproducer. > > Please follow the steps to reproduce the issue > > Step 1: tar -xf brokerMemoryIncrease.tar > Step 2: cd brokerMemoryIncrease > Step 3: ./qpidRepro.sh > -- 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] (QPID-8462) Qpid broker memory increases when a receiver is paused with message pending acks
[ https://issues.apache.org/jira/browse/QPID-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193793#comment-17193793 ] Gordon Sim commented on QPID-8462: -- This is 'expected' behaviour. The way the queue is implemented, records can be marked deleted (and the message they refer to freed), but the records themselves can only be removed when at either end of the queue. (This is so as to make the cursors that can track positions in the queue and move them forward more efficient). So when you keep the oldest message locked, it can't be removed nor can any deleted message behind it. If you requires heartbeats then the broker would disconnect it if it does not send heartbeats which will prevent accidental locking of messages by hung clients. > Qpid broker memory increases when a receiver is paused with message pending > acks > - > > Key: QPID-8462 > URL: https://issues.apache.org/jira/browse/QPID-8462 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: qpid-cpp-1.39.0 > Environment: Linux > >Reporter: KALYANARAMAN SIVARAMAN >Priority: Major > Attachments: brokerMemoryIncrease.tar > > > Given the situation where we have a receiver "Receiver1" acquire 1 message > from a queue "ReceiverQueue" but if the message is not acknowledged and > Receiver1 process is paused using kill -STOP . > Any further messages sent to ReceiverQueue is marked as DELETED even though > we have another receiver "Receiver2" properly acquire messages from the queue > and also sends acknowledgements, the broker memory linearly increases until > all the memory in the box is used. Purger cleaning up messages does not help. > Once we kill Receiver1 the broker memory stabilizes. > All of the repro steps are automated in the attached reproducer. > > Please follow the steps to reproduce the issue > > Step 1: tar -xf brokerMemoryIncrease.tar > Step 2: cd brokerMemoryIncrease > Step 3: ./qpidRepro.sh > -- 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-1762) Setting verifyHostname to false on connector means certificate is not verified at all
Gordon Sim created DISPATCH-1762: Summary: Setting verifyHostname to false on connector means certificate is not verified at all Key: DISPATCH-1762 URL: https://issues.apache.org/jira/browse/DISPATCH-1762 Project: Qpid Dispatch Issue Type: Bug Reporter: Gordon Sim You can connect even of the CA path specified does not exist. (Expectation from the configuration option name is that only the hostname verification is disabled, but that the validity of the certificate is still verified). -- 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-1652) Define internal interfaces for protocol plugins
[ https://issues.apache.org/jira/browse/DISPATCH-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1652. Resolution: Duplicate > 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-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 ] Gordon Sim updated DISPATCH-1519: - Fix Version/s: (was: 1.13.0) Backlog > 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 > 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] [Closed] (DISPATCH-1653) http protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed DISPATCH-1653. Resolution: Duplicate > http protocol bridging (ingress and egress) > --- > > Key: DISPATCH-1653 > URL: https://issues.apache.org/jira/browse/DISPATCH-1653 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >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] [Commented] (DISPATCH-1653) http protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170961#comment-17170961 ] Gordon Sim commented on DISPATCH-1653: -- See also DISPATCH-1742 > http protocol bridging (ingress and egress) > --- > > Key: DISPATCH-1653 > URL: https://issues.apache.org/jira/browse/DISPATCH-1653 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >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] [Commented] (DISPATCH-1654) tcp protocol bridging (ingress and egress)
[ https://issues.apache.org/jira/browse/DISPATCH-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170960#comment-17170960 ] Gordon Sim commented on DISPATCH-1654: -- See also DISPATCH-1742 > tcp protocol bridging (ingress and egress) > -- > > Key: DISPATCH-1654 > URL: https://issues.apache.org/jira/browse/DISPATCH-1654 > Project: Qpid Dispatch > Issue Type: Improvement > Reporter: Gordon Sim >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-1732) segfault when connecting to multitenant listener with policy but no hostname in open
[ https://issues.apache.org/jira/browse/DISPATCH-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned DISPATCH-1732: Assignee: Charles E. Rolke > segfault when connecting to multitenant listener with policy but no hostname > in open > - > > Key: DISPATCH-1732 > URL: https://issues.apache.org/jira/browse/DISPATCH-1732 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Policy Engine >Affects Versions: 1.13.0 >Reporter: Gordon Sim >Assignee: Charles E. Rolke >Priority: Major > Fix For: 1.13.0 > > > Start router with following config file and then run qpid-receive against it > (which by default does not set a hostname in open). > > {noformat} > [ > ["listener", { "host": "0.0.0.0", "port": 5672, "multiTenant": true , > "policyVhost": "myhost"}], > ["policy", {"enableVhostPolicy": true }], > ["vhost", { "hostname": "myhost", "allowUnknownUser": true, > "groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}] > ] {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] [Commented] (DISPATCH-1732) segfault when connecting to multitenant listener with policy but no hostname in open
[ https://issues.apache.org/jira/browse/DISPATCH-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167825#comment-17167825 ] Gordon Sim commented on DISPATCH-1732: -- The following fixes the segfault. Not sure if it is the correct fix: {noformat} diff --git a/src/policy.c b/src/policy.c index ae093b13..7486dd7c 100644 --- a/src/policy.c +++ b/src/policy.c @@ -1294,7 +1294,7 @@ void qd_policy_amqp_open(qd_connection_t *qd_conn) { if (cf && cf->multi_tenant) { char vhost_name_buf[SETTINGS_NAME_SIZE]; if (qd_policy_lookup_vhost_alias(policy, vhost, vhost_name_buf, SETTINGS_NAME_SIZE)) { -if (!strcmp(pcrh, vhost_name_buf)) { +if (pcrh && !strcmp(pcrh, vhost_name_buf)) { // Default condition: use proton connection value; no action here } else { // Policy used a name different from what came in the AMQP Open hostname. {noformat} > segfault when connecting to multitenant listener with policy but no hostname > in open > - > > Key: DISPATCH-1732 > URL: https://issues.apache.org/jira/browse/DISPATCH-1732 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Policy Engine >Affects Versions: 1.13.0 >Reporter: Gordon Sim >Priority: Major > Fix For: 1.13.0 > > > Start router with following config file and then run qpid-receive against it > (which by default does not set a hostname in open). > > {noformat} > [ > ["listener", { "host": "0.0.0.0", "port": 5672, "multiTenant": true , > "policyVhost": "myhost"}], > ["policy", {"enableVhostPolicy": true }], > ["vhost", { "hostname": "myhost", "allowUnknownUser": true, > "groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}] > ] {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] [Commented] (DISPATCH-1732) segfault when connecting to multitenant listener with policy but no hostname in open
[ https://issues.apache.org/jira/browse/DISPATCH-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17167820#comment-17167820 ] Gordon Sim commented on DISPATCH-1732: -- Backtrace is: {noformat} #0 0x77a56d5e in __strcmp_avx2 () from /lib64/libc.so.6 #1 0x77f6808f in qd_policy_amqp_open (qd_conn=0x7fffe400f9c8) at /home/gordon/projects/dispatch/src/policy.c:1297 #2 0x77f9ad5a in handle (qd_server=qd_server@entry=0x53b8d0, e=e@entry=0x648f40, pn_conn=pn_conn@entry=0x7fffe4010b80, ctx=ctx@entry=0x7fffe400f9c8) at /home/gordon/projects/dispatch/src/server.c:1041 #3 0x77f9bd9c in thread_run (arg=arg@entry=0x53b8d0) at /home/gordon/projects/dispatch/src/server.c:1066 #4 0x77f9bfb0 in qd_server_run (qd=) at /home/gordon/projects/dispatch/src/server.c:1412 #5 0x004026b2 in main_process (config_path=0x7fffd372 "/home/gordon/projects/router-config-examples/multitenant.json", python_pkgdir=, test_hooks=, fd=2) at /home/gordon/projects/dispatch/router/src/main.c:113 #6 0x00402400 in main (argc=3, argv=0x7fffcf28) at /home/gordon/projects/dispatch/router/src/main.c:367 {noformat} > segfault when connecting to multitenant listener with policy but no hostname > in open > - > > Key: DISPATCH-1732 > URL: https://issues.apache.org/jira/browse/DISPATCH-1732 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Policy Engine >Affects Versions: 1.13.0 >Reporter: Gordon Sim >Priority: Major > Fix For: 1.13.0 > > > Start router with following config file and then run qpid-receive against it > (which by default does not set a hostname in open). > > {noformat} > [ > ["listener", { "host": "0.0.0.0", "port": 5672, "multiTenant": true , > "policyVhost": "myhost"}], > ["policy", {"enableVhostPolicy": true }], > ["vhost", { "hostname": "myhost", "allowUnknownUser": true, > "groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}] > ] {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] [Created] (DISPATCH-1732) segfault when connecting to multitenant listener with policy but no hostname in open
Gordon Sim created DISPATCH-1732: Summary: segfault when connecting to multitenant listener with policy but no hostname in open Key: DISPATCH-1732 URL: https://issues.apache.org/jira/browse/DISPATCH-1732 Project: Qpid Dispatch Issue Type: Improvement Components: Policy Engine Affects Versions: 1.13.0 Reporter: Gordon Sim Fix For: 1.13.0 Start router with following config file and then run qpid-receive against it (which by default does not set a hostname in open). {noformat} [ ["listener", { "host": "0.0.0.0", "port": 5672, "multiTenant": true , "policyVhost": "myhost"}], ["policy", {"enableVhostPolicy": true }], ["vhost", { "hostname": "myhost", "allowUnknownUser": true, "groups":{"$default":{"remoteHosts":"*","sources":"*","targets":"*","allowDynamicSource":true,"allowAnonymousSender":true}}}] ] {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] [Commented] (PROTON-2251) [python binding] MessagingHandler release function does not release message
[ https://issues.apache.org/jira/browse/PROTON-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17156896#comment-17156896 ] Gordon Sim commented on PROTON-2251: As a workaround you can {{'raise Released()'}} instead of invoking the {{release()}} method > [python binding] MessagingHandler release function does not release message > --- > > Key: PROTON-2251 > URL: https://issues.apache.org/jira/browse/PROTON-2251 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.31.0 > Environment: Proton master@4a22a; Python 3.7.7; Fedora 31 >Reporter: Charles E. Rolke >Priority: Major > > Documentation suggests that in a MessagingHandler on_message callback the > user may call `self.release(event.delivery)` to release the message. Using > this function the messages are still accepted. A modified > helloworld_direct.py output is: > {code:java} > > python helloworld_direct.py > Hello World! > Releasing that message > on_accepted > {code} > The source is > {code:java} > from __future__ import print_function, unicode_literals > from proton import Message > from proton.handlers import MessagingHandler > from proton.reactor import Container > class HelloWorld(MessagingHandler): > def __init__(self, url): > super(HelloWorld, self).__init__() > self.url = url > self.sent = False > def on_start(self, event): > self.acceptor = event.container.listen(self.url) > event.container.create_sender(self.url) > def on_sendable(self, event): > if not self.sent: > self.sent = True > event.sender.send(Message(body="Hello World!")) > def on_message(self, event): > print(event.message.body) > print("Releasing that message") > self.release(event.delivery) > def on_accepted(self, event): > print("on_accepted") > event.connection.close() > def on_released(self, event): > print("on_released") > event.connection.close() > def on_connection_closed(self, event): > self.acceptor.close() > Container(HelloWorld("localhost:/examples")).run() > {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-1654) tcp protocol bridging (ingress and egress)
Gordon Sim created DISPATCH-1654: Summary: tcp protocol bridging (ingress and egress) Key: DISPATCH-1654 URL: https://issues.apache.org/jira/browse/DISPATCH-1654 Project: Qpid Dispatch Issue Type: Improvement Reporter: Gordon Sim -- 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-1655) http2 protocol bridging (ingress and egress)
Gordon Sim created DISPATCH-1655: Summary: http2 protocol bridging (ingress and egress) Key: DISPATCH-1655 URL: https://issues.apache.org/jira/browse/DISPATCH-1655 Project: Qpid Dispatch Issue Type: Improvement Reporter: Gordon Sim -- 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-1653) http protocol bridging (ingress and egress)
Gordon Sim created DISPATCH-1653: Summary: http protocol bridging (ingress and egress) Key: DISPATCH-1653 URL: https://issues.apache.org/jira/browse/DISPATCH-1653 Project: Qpid Dispatch Issue Type: Improvement Reporter: Gordon Sim -- 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-1652) Define internal interfaces for protocol plugins
Gordon Sim created DISPATCH-1652: Summary: 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 -- 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-1651) Update management schema to include protocol bridges
Gordon Sim created DISPATCH-1651: Summary: 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 -- 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-1646) Unable to delete listener with http enabled
[ https://issues.apache.org/jira/browse/DISPATCH-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17104295#comment-17104295 ] Gordon Sim commented on DISPATCH-1646: -- See also https://issues.apache.org/jira/browse/DISPATCH-1037 > 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 >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