[jira] [Commented] (PROTON-2469) How to use proton-python properly to receive messages

2021-11-24 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2021-11-24 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2021-11-15 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2021-10-27 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2021-10-26 Thread Gordon Sim (Jira)


 [ 
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

2021-10-25 Thread Gordon Sim (Jira)


 [ 
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

2021-10-20 Thread Gordon Sim (Jira)
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

2021-10-20 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 Linux Workstation"}}
> {{VERSION="7.6 (Maipo)"}}
> {{ID="rhel"}}
> {{I

[jira] [Updated] (PROTON-2439) Python BlockingReceiver does not work with presettled deliveries

2021-10-20 Thread Gordon Sim (Jira)


 [ 
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_SUPPORT_PRODUCT="Red Hat Enterprise Linux"}}
> {{REDHAT_SUPPORT_PRODUCT_VERSION="7.

[jira] [Updated] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker

2021-10-20 Thread Gordon Sim (Jira)


 [ 
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"}}
> {{Red Hat Enterprise Linux Workstation release 7.6 (Maipo)}}
> {{Red Hat Enterprise Lin

[jira] [Updated] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker

2021-10-20 Thread Gordon Sim (Jira)


 [ 
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"}}
> {{Red Hat Enterprise Linux Workstation release 7.6 (Maipo)}}
> {{Red Hat Enterprise Linux Workstati

[jira] [Commented] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker

2021-10-19 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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}}
> {{REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"}}
> {{REDHAT_SUPPORT_PRODUCT_VERSION="7.6"}}
> {{Red Hat Enterpri

[jira] [Updated] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker

2021-10-19 Thread Gordon Sim (Jira)


 [ 
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 Enterprise Linux"}}
> {{REDHAT_SUPPORT_PRODUCT_VERSION="7.6"}}
> {{Red Hat Enterpri

[jira] [Commented] (PROTON-2439) Python BlockingReceiver accept() fails when used with qpidd broker

2021-10-19 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"}}
> {{CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:workstation"}}
> {{HOME_URL=[https://www.redhat.com/]}}
> {{BUG_REPO

[jira] [Assigned] (DISPATCH-1039) websocket listener with authenticatePeer=true requires client certs

2021-08-18 Thread Gordon Sim (Jira)


 [ 
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

2021-07-01 Thread Gordon Sim (Jira)


 [ 
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

2021-07-01 Thread Gordon Sim (Jira)


 [ 
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

2021-06-16 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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/qpid-dispatch/qpid-di

[jira] [Commented] (DISPATCH-2174) [tcp] Remove raw_closed_read. Use raw_closed_read instead. Also make q2_blocked atomic

2021-06-15 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2021-05-26 Thread Gordon Sim (Jira)


 [ 
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

2021-05-25 Thread Gordon Sim (Jira)


 [ 
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

2021-05-19 Thread Gordon Sim (Jira)
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

2021-04-28 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2021-04-16 Thread Gordon Sim (Jira)


 [ 
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

2021-04-15 Thread Gordon Sim (Jira)
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

2021-01-19 Thread Gordon Sim (Jira)


 [ 
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

2021-01-13 Thread Gordon Sim (Jira)


 [ 
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

2021-01-13 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2021-01-13 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-12-18 Thread Gordon Sim (Jira)
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

2020-12-17 Thread Gordon Sim (Jira)


 [ 
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

2020-12-17 Thread Gordon Sim (Jira)


 [ 
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

2020-12-17 Thread Gordon Sim (Jira)
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

2020-12-17 Thread Gordon Sim (Jira)
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

2020-12-17 Thread Gordon Sim (Jira)
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

2020-12-17 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-12-16 Thread Gordon Sim (Jira)
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

2020-11-25 Thread Gordon Sim (Jira)
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

2020-11-18 Thread Gordon Sim (Jira)


 [ 
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

2020-11-18 Thread Gordon Sim (Jira)


 [ 
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

2020-11-18 Thread Gordon Sim (Jira)
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

2020-11-18 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-11-18 Thread Gordon Sim (Jira)
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

2020-11-17 Thread Gordon Sim (Jira)


 [ 
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

2020-11-16 Thread Gordon Sim (Jira)


 [ 
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

2020-11-16 Thread Gordon Sim (Jira)


 [ 
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

2020-11-16 Thread Gordon Sim (Jira)


 [ 
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

2020-11-16 Thread Gordon Sim (Jira)
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

2020-11-16 Thread Gordon Sim (Jira)
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

2020-11-16 Thread Gordon Sim (Jira)
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

2020-11-13 Thread Gordon Sim (Jira)


 [ 
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

2020-11-11 Thread Gordon Sim (Jira)
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

2020-11-06 Thread Gordon Sim (Jira)
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

2020-11-04 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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/mhausenblas/gump:0.1 grp

[jira] [Assigned] (DISPATCH-1780) multicast support for http 1.1 adaptor

2020-11-02 Thread Gordon Sim (Jira)


 [ 
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

2020-10-26 Thread Gordon Sim (Jira)


 [ 
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)

2020-10-26 Thread Gordon Sim (Jira)


 [ 
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

2020-10-26 Thread Gordon Sim (Jira)


 [ 
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

2020-10-26 Thread Gordon Sim (Jira)


 [ 
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

2020-10-05 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 0  2

[jira] [Commented] (DISPATCH-1777) inter-router transfer of streaming message representing tcp connection is not delivered

2020-10-05 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-09-23 Thread Gordon Sim (Jira)
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

2020-09-22 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 
> 0  250   -
>   inte

[jira] [Updated] (DISPATCH-1655) http2 protocol bridging (ingress and egress)

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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)

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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)

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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)

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-22 Thread Gordon Sim (Jira)
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

2020-09-22 Thread Gordon Sim (Jira)
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)

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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)

2020-09-22 Thread Gordon Sim (Jira)


 [ 
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

2020-09-18 Thread Gordon Sim (Jira)
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

2020-09-18 Thread Gordon Sim (Jira)
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

2020-09-18 Thread Gordon Sim (Jira)
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

2020-09-10 Thread Gordon Sim (Jira)


 [ 
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

2020-09-10 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-09-10 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/QPID-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-08-21 Thread Gordon Sim (Jira)
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

2020-08-12 Thread Gordon Sim (Jira)


 [ 
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

2020-08-10 Thread Gordon Sim (Jira)


 [ 
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)

2020-08-04 Thread Gordon Sim (Jira)


 [ 
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)

2020-08-04 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

2020-08-04 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-07-30 Thread Gordon Sim (Jira)


 [ 
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

2020-07-30 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-07-30 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2020-07-30 Thread Gordon Sim (Jira)
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

2020-07-13 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/PROTON-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

2020-05-12 Thread Gordon Sim (Jira)
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)

2020-05-12 Thread Gordon Sim (Jira)
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)

2020-05-12 Thread Gordon Sim (Jira)
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

2020-05-12 Thread Gordon Sim (Jira)
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

2020-05-12 Thread Gordon Sim (Jira)
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

2020-05-11 Thread Gordon Sim (Jira)


[ 
https://issues.apache.org/jira/browse/DISPATCH-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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



  1   2   3   4   5   6   7   8   9   10   >