date:20180516

[jira] [Resolved] (PROTON-1847) container:schedule used from an external thread can stop container::run loop processing other events

2018-05-16 Thread Andrew Stitcher (JIRA)


 [ 
https://issues.apache.org/jira/browse/PROTON-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Stitcher resolved PROTON-1847.
-
Resolution: Fixed

> container:schedule used from an external thread can stop container::run loop 
> processing other events
> 
>
> Key: PROTON-1847
> URL: https://issues.apache.org/jira/browse/PROTON-1847
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> There are 2 potential problems:
>  # The code that runs the scheduled tasks still accepts new tasks at the same 
> time. So if you keep on scheduling new tasks continuously you could make the 
> scheduler run tasks continuously without ever leaving to process any other 
> events.
>  # The code that accepts timeout events will keep on reading the same event 
> batch until it is empty. So in this case too new tasks could prevent any 
> other events being processed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1847) container:schedule used from an external thread can stop container::run loop processing other events

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478276#comment-16478276
 ] 

ASF subversion and git services commented on PROTON-1847:
-

Commit 9fd19bcf960dacc046b2f6867c538149eceb8e5c in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9fd19bc ]

PROTON-1847: [C++ binding] Ensure that excessive scheduled events can't starve 
other events


> container:schedule used from an external thread can stop container::run loop 
> processing other events
> 
>
> Key: PROTON-1847
> URL: https://issues.apache.org/jira/browse/PROTON-1847
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> There are 2 potential problems:
>  # The code that runs the scheduled tasks still accepts new tasks at the same 
> time. So if you keep on scheduling new tasks continuously you could make the 
> scheduler run tasks continuously without ever leaving to process any other 
> events.
>  # The code that accepts timeout events will keep on reading the same event 
> batch until it is empty. So in this case too new tasks could prevent any 
> other events being processed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1847) container:schedule used from an external thread can stop container::run loop processing other events

2018-05-16 Thread Andrew Stitcher (JIRA)


 [ 
https://issues.apache.org/jira/browse/PROTON-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Stitcher updated PROTON-1847:

Description: 
There are 2 potential problems:
 # The code that runs the scheduled tasks still accepts new tasks at the same 
time. So if you keep on scheduling new tasks continuously you could make the 
scheduler run tasks continuously without ever leaving to process any other 
events.
 # The code that accepts timeout events will keep on reading the same event 
batch until it is empty. So in this case too new tasks could prevent any other 
events being processed.

> container:schedule used from an external thread can stop container::run loop 
> processing other events
> 
>
> Key: PROTON-1847
> URL: https://issues.apache.org/jira/browse/PROTON-1847
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> There are 2 potential problems:
>  # The code that runs the scheduled tasks still accepts new tasks at the same 
> time. So if you keep on scheduling new tasks continuously you could make the 
> scheduler run tasks continuously without ever leaving to process any other 
> events.
>  # The code that accepts timeout events will keep on reading the same event 
> batch until it is empty. So in this case too new tasks could prevent any 
> other events being processed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (PROTON-1847) container:schedule used from an external thread can stop container::run loop processing other events

2018-05-16 Thread Andrew Stitcher (JIRA)

Andrew Stitcher created PROTON-1847:
---

 Summary: container:schedule used from an external thread can stop 
container::run loop processing other events
 Key: PROTON-1847
 URL: https://issues.apache.org/jira/browse/PROTON-1847
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
 Fix For: proton-c-0.23.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #305: Dispatch 965 - Port to Python 3.x

2018-05-16 Thread kgiusti

Github user kgiusti commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/305#discussion_r188773750
  
--- Diff: console/config/mock/section.py ---
@@ -17,6 +17,11 @@
 # under the License.
 #
 
+from __future__ import print_function
+from __future__ import unicode_literals
+from __future__ import division
+from __future__ import absolute_import
+
 import json
 import re
 from schema import Schema
--- End diff --

Good catch - I'll push a fix...


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach

2018-05-16 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478091#comment-16478091
 ] 

ASF GitHub Bot commented on DISPATCH-994:
-

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/303


> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: router-a.conf, router-b.conf, router-c.conf, 
> topic_test.py, topic_test_v2.py
>
>
> Link routing from router A through router B to a 'broker', and closing and 
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674== 
> ==25674== 
> ==25674== Process terminating with default action of signal 11 (SIGSEGV): 
> dumping core
> ==25674==  Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674==  If you believe this happened as a result of a stack
> ==25674==  overflow in your program's main thread (unlikely but
> ==25674==  possible), you can try to increase the size of the
> ==25674==  main thread stack using the --main-stacksize= flag.
> ==25674==  The main thread stack size used in this run was 8388608
> {noformat}
> To reproduce, start three routers with the attached config files, then run 
> the attached python test program.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #303: DISPATCH-994 - Added null checks on links/c...

2018-05-16 Thread ganeshmurthy

Github user ganeshmurthy closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/303


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-966) Qpid dispatch unstable inter-router connections

2018-05-16 Thread Ted Ross (JIRA)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-966:
--
Priority: Blocker  (was: Major)

> Qpid dispatch unstable inter-router connections
> ---
>
> Key: DISPATCH-966
> URL: https://issues.apache.org/jira/browse/DISPATCH-966
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 1.1.0
>
> Attachments: qdrouterd-unsettled-true.log, qdrouterd.conf, 
> qdrouterd.log, router-unsettled-true.dump, router.dump
>
>
> I am running a three node fully connected mesh of dispatch routers with 1 
> attached clients and I am seeing some unstable inter-router connections (I am 
> sending around 1000 small, less than 1K, messages per second through the 
> network). The inter-router connections fail every so many seconds with the 
> message:
> {{Connection to router-2:55672 failed: amqp:session:invalid-field sequencing 
> error, expected delivery-id 7, got 6}}
> (the numbers 7 and 6 differ per connection loss)
> In wireshark, using the attached tcpdump capture, I can see that every time 
> before the inter router connection is dropped, therw is a rejected 
> disposition with the message:
> {{Condition: qd:forbidden}}
> {{Description: Deliveries to a multicast address must be pre-settled}}
> The routers are connected as follows:
>  * router-0 -> router-1
>  * router-0 -> router-2
>  * router-1 -> router-2
> The routers are running as a docker container (debian stretch) on google 
> compute engine machines (every router on a separate node).
> Attached are:
>  * my qdrouter.conf (from one of the routers)
>  * a log snippet from router-0 at debug level from connection drop to 
> connection re-established to connection drop again.
>  * a tcpdump capture of the inter-router connection between router-0 and 
> router-1 during which several of the failures occur
> Versions:
>  * qpid-dispatch@1.0.1-rc1
>  * qpid-proton@0.20.0
>  
> [^qdrouterd.log]
> [^qdrouterd.conf]
> [^router.dump]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (DISPATCH-966) Qpid dispatch unstable inter-router connections

2018-05-16 Thread Ted Ross (JIRA)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Ross updated DISPATCH-966:
--
Fix Version/s: (was: Backlog)
   1.1.0

> Qpid dispatch unstable inter-router connections
> ---
>
> Key: DISPATCH-966
> URL: https://issues.apache.org/jira/browse/DISPATCH-966
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
> Attachments: qdrouterd-unsettled-true.log, qdrouterd.conf, 
> qdrouterd.log, router-unsettled-true.dump, router.dump
>
>
> I am running a three node fully connected mesh of dispatch routers with 1 
> attached clients and I am seeing some unstable inter-router connections (I am 
> sending around 1000 small, less than 1K, messages per second through the 
> network). The inter-router connections fail every so many seconds with the 
> message:
> {{Connection to router-2:55672 failed: amqp:session:invalid-field sequencing 
> error, expected delivery-id 7, got 6}}
> (the numbers 7 and 6 differ per connection loss)
> In wireshark, using the attached tcpdump capture, I can see that every time 
> before the inter router connection is dropped, therw is a rejected 
> disposition with the message:
> {{Condition: qd:forbidden}}
> {{Description: Deliveries to a multicast address must be pre-settled}}
> The routers are connected as follows:
>  * router-0 -> router-1
>  * router-0 -> router-2
>  * router-1 -> router-2
> The routers are running as a docker container (debian stretch) on google 
> compute engine machines (every router on a separate node).
> Attached are:
>  * my qdrouter.conf (from one of the routers)
>  * a log snippet from router-0 at debug level from connection drop to 
> connection re-established to connection drop again.
>  * a tcpdump capture of the inter-router connection between router-0 and 
> router-1 during which several of the failures occur
> Versions:
>  * qpid-dispatch@1.0.1-rc1
>  * qpid-proton@0.20.0
>  
> [^qdrouterd.log]
> [^qdrouterd.conf]
> [^router.dump]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478016#comment-16478016
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit f90c2a805d663fb2ea15a0fec7c70c16ce0aa1aa in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f90c2a8 ]

DISPATCH-990: Add/remove policy hostname tree entries

Tie hostname lookup tree to life cycle of policy rulesets.


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478021#comment-16478021
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit 415b4568ecac113f3ea4212507407dba03f7cdd1 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=415b456 ]

DISPATCH-990: Add hostname pattern self test

Remove stray variables from log message.


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478022#comment-16478022
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit 8712cabdf8f37dddc7f8d1ffc4792fbd177f050d in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=8712cab ]

DISPATCH-990: add policy dir to support self test


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478014#comment-16478014
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit 10ad8cf370412ec424f92e1a3db0aee031f4afc4 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=10ad8cf ]

DISPATCH-990: Reorder config steps to init policy

Policy manager needs some setup before vhosts are processed.


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478019#comment-16478019
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit 2b0f3d066428f5c13eed83848f017c39ca56f565 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=2b0f3d0 ]

DISPATCH-990: Fix locks so hostname adds are atomic


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478023#comment-16478023
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit 63a56d6052e747a0043df621a67805989de5d255 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=63a56d6 ]

DISPATCH-990: Document name pattern match feature in old book.

Rename and touch up configuration settings to make docs read better.


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478017#comment-16478017
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit f17631cbe7a695fb4492a4437289d82a1a89a1c0 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f17631c ]

DISPATCH-990: integrate the pattern match with vhost lookups


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478018#comment-16478018
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit 9c0a09d793795acbc165df37a45f8fa86329da0f in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=9c0a09d ]

DISPATCH-990: Reject add of vhost that has pattern conflict.

Add self test showing how conflicts are managed.


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478020#comment-16478020
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit 82cef3abff91857871ba7e9ca88177a39db0f7a0 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=82cef3a ]

DISPATCH-990: Add hostname translation to settings lookup


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-990) Use patterns for policy vhost hostnames

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478015#comment-16478015
 ] 

ASF subversion and git services commented on DISPATCH-990:
--

Commit e1ae8d3022d680775a5f441ea677b1498453ee15 in qpid-dispatch's branch 
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e1ae8d3 ]

DISPATCH-990: Add c code to support tree hostname lookups


> Use patterns for policy vhost hostnames
> ---
>
> Key: DISPATCH-990
> URL: https://issues.apache.org/jira/browse/DISPATCH-990
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Chuck Rolke
>Priority: Major
>
> Currently policy vhost hostnames identify a single host. Vhost policy would 
> be much more flexible if the hostnames could be specified with pattern 
> matching wildcards:
> {{  #.corporate.example.com}}
> {{  #.labs.example.com}}
> {{  *.users.example.com}}
> {{  #.example.com}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #304: Dispatch 990 Use patterns for policy vhost ...

2018-05-16 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/qpid-dispatch/pull/304


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1771) [c-proactor] multi-thread race test for proactor

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478008#comment-16478008
 ] 

ASF subversion and git services commented on PROTON-1771:
-

Commit 1764c4d0cd27dce88df2db8e468f1e2f97054e5f in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1764c4d ]

PROTON-1771: [c] threaderciser.supp added bogus NSS races


> [c-proactor] multi-thread race test for proactor
> 
>
> Key: PROTON-1771
> URL: https://issues.apache.org/jira/browse/PROTON-1771
> Project: Qpid Proton
>  Issue Type: Test
>  Components: proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Crate a new test exe that runs for a (configurable, default short) period of
> time, with a single proactor acted on by multiple proactor and user threads. 
> Run
> with helgrind or tsan to detect races.
> Exercise potentially racy APIs concurrently:
> - making, accepting and closing (from both ends) a connection.
> - pn_connection_wake
> - pn_proactor_release_connection
> - re-use of released pn_connection_t on a new connection
> - timeout
> - concurrent with some normal use: sending/receiving messages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-997) reusing link name from link closed uncleanly on link routes no longer works

2018-05-16 Thread Gordon Sim (JIRA)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim resolved DISPATCH-997.
-
Resolution: Resolved

Fixed in proton not dispatch.

> reusing link name from link closed uncleanly on link routes no longer works
> ---
>
> Key: DISPATCH-997
> URL: https://issues.apache.org/jira/browse/DISPATCH-997
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: reuse_link_name.py, router-a.conf, router-b.conf, 
> router-c.conf
>
>
> Attach a link with a specific name that is routed from router A through 
> router B to a 'broker', then close the connection that attach was sent over 
> without detaching the link. Then try to reattach (on a new connection) with 
> the same link name. This fails as the attach does not get successfully routed 
> and now response is received back.
> Reproducer: run routers with attached configs router-a, router-b, router-c, 
> then run attached test script reuse_link_name.py. On 1.0.1, or direct against 
> a single router with no linkrouting, as expected the test iterates opening a 
> link the closing the connection. With 1.1.0 it gets stuck on second subscribe 
> attempt.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (DISPATCH-994) segfault in qdr_link_second_attach

2018-05-16 Thread Gordon Sim (JIRA)


 [ 
https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim resolved DISPATCH-994.
-
Resolution: Resolved

Fixed in proton not dispatch.

> segfault in qdr_link_second_attach
> --
>
> Key: DISPATCH-994
> URL: https://issues.apache.org/jira/browse/DISPATCH-994
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Gordon Sim
>Priority: Major
> Attachments: router-a.conf, router-b.conf, router-c.conf, 
> topic_test.py, topic_test_v2.py
>
>
> Link routing from router A through router B to a 'broker', and closing and 
> opening two receivers causes a segfault.
> {noformat}
> ==25674== Thread 4:
> ==25674== Invalid read of size 8
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==25674== 
> ==25674== 
> ==25674== Process terminating with default action of signal 11 (SIGSEGV): 
> dumping core
> ==25674==  Access not within mapped region at address 0x10
> ==25674==at 0x4E77EEF: qdr_link_second_attach (connections.c:474)
> ==25674==by 0x4E87142: AMQP_link_attach_handler (router_node.c:680)
> ==25674==by 0x4E8BF2B: handle (server.c:940)
> ==25674==by 0x4E8CBA7: thread_run (server.c:958)
> ==25674==by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so)
> ==25674==by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so)
> ==25674==  If you believe this happened as a result of a stack
> ==25674==  overflow in your program's main thread (unlikely but
> ==25674==  possible), you can try to increase the size of the
> ==25674==  main thread stack using the --main-stacksize= flag.
> ==25674==  The main thread stack size used in this run was 8388608
> {noformat}
> To reproduce, start three routers with the attached config files, then run 
> the attached python test program.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #305: Dispatch 965 - Port to Python 3.x

2018-05-16 Thread ErnieAllen

Github user ErnieAllen commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/305#discussion_r188746296
  
--- Diff: console/config/mock/section.py ---
@@ -17,6 +17,11 @@
 # under the License.
 #
 
+from __future__ import print_function
+from __future__ import unicode_literals
+from __future__ import division
+from __future__ import absolute_import
+
 import json
 import re
 from schema import Schema
--- End diff --

I think this needs to be:
from .schema import Schema
since the schema.py is in the same directory as the section.py file.


---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1771) [c-proactor] multi-thread race test for proactor

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477940#comment-16477940
 ] 

ASF subversion and git services commented on PROTON-1771:
-

Commit 3206378b0149c903f0507fc6429ae899e38f2368 in qpid-proton's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3206378 ]

PROTON-1771: [c] fix race conditions in threaderciser.c

Was incorrectly calling pn_connection_close() from non-handler threads.


> [c-proactor] multi-thread race test for proactor
> 
>
> Key: PROTON-1771
> URL: https://issues.apache.org/jira/browse/PROTON-1771
> Project: Qpid Proton
>  Issue Type: Test
>  Components: proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Crate a new test exe that runs for a (configurable, default short) period of
> time, with a single proactor acted on by multiple proactor and user threads. 
> Run
> with helgrind or tsan to detect races.
> Exercise potentially racy APIs concurrently:
> - making, accepting and closing (from both ends) a connection.
> - pn_connection_wake
> - pn_proactor_release_connection
> - re-use of released pn_connection_t on a new connection
> - timeout
> - concurrent with some normal use: sending/receiving messages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #305: Dispatch 965 - Port to Python 3.x

2018-05-16 Thread kgiusti

GitHub user kgiusti opened a pull request:

https://github.com/apache/qpid-dispatch/pull/305

Dispatch 965 - Port to Python 3.x

This patch is about as done as I can get it.  Unit tests pass on 2.6, 2.7, 
and 3.6.

Other than the fixups there are 2 major changes here:

1) using the __futures__ modules we're enabling python 3.x features in our 
python 2.x environment.  IOW your python 2.x interpreter will behave like a 3.x 
interpreter in some cases.  Reason: unless we're using both 2.x and 3.x 
development environments we'll continue to break compatibility .  Forcing us to 
write python 3 compatible code in a python 2.x environment should help mitigate 
the bit rot and keep us on track for when python 2.x is dropped in ~18 months.

Python 2.x behavior will change in the following ways:

- the print statement is disabled - only the print() function can be used
- all string literals are of the type unicode.  So type('foo') is now 
unicode, not str.  If you need a binary literal string use the 'b' prefix ala 
b'bintext'
- the division operator (/) now returns a **float** rather than an integer, 
even if the types involved in the division are integer. IOW 4/5 now returns 
0.8, not 0  (this is a nasty one - we need to be careful here)
- module inclusion is absolute unless '.' prefix is used - we've done this 
for awhile so likely this won't make a difference.

2) added a python linter check to the unit tests

This will flag most other incompatible code changes to help avoid breaking 
stuff. This new test runs under the tox environment.  I urge you to install the 
python-tox package so you can take advantage of this test.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kgiusti/dispatch DISPATCH-965

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/305.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #305


commit 878534ec682b13cc731197318c8e6f32f06d6216
Author: Kenneth Giusti 
Date:   2018-04-11T21:24:23Z

DISPATCH-965: port python code to Python 3. Stay compatible with 2.6-7

commit 7bdd55c7db7b010f204750c0e39fbc067180d26a
Author: Kenneth Giusti 
Date:   2018-05-14T01:11:31Z

DISPATCH-965: fixups for Python 2.7 compatibility

commit fb363cb55411eb96667f63637d0a1cacb56df655
Author: Kenneth Giusti 
Date:   2018-05-16T00:56:12Z

DISPATCH-965: restrict tox version, fixup 2.6 issues

commit a5c40dae9ac1f075c98826f1e1305cb506669672
Author: Kenneth Giusti 
Date:   2018-05-16T17:12:12Z

DISPATCH-965: fix the 2.x fixes for 3.x




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1843) Cannot use unicode string in Condition description

2018-05-16 Thread Justin Ross (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477768#comment-16477768
 ] 

Justin Ross commented on PROTON-1843:
-

[~kgiusti], so I understand, how is "dtag" involved?  Is it just a point of 
comparison in another part of the API?

I think there are cases where the python API should accept unicode and perform 
an .encode('utf-8') or ('ascii') under the covers.  This looks like one to me.

> Cannot use unicode string in Condition description
> --
>
> Key: PROTON-1843
> URL: https://issues.apache.org/jira/browse/PROTON-1843
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: test.py
>
>
> Under python2.7, attempting to set a condition on a delivery using a unicode 
> string causes a traceback:
> Traceback (most recent call last):
>   File "./test.py", line 64, in 
> Container(Test(opts.address)).run()
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3478, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3390, in dispatch
> self.dispatch(h, type)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3387, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 173, in on_delivery
> self.on_message(event)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 195, in on_message
> dispatch(self.delegate, 'on_message', event)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File "./test.py", line 48, in on_message
> self.reject(event.delivery)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 130, in reject
> self.settle(delivery, Delivery.REJECTED)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 146, in settle
> delivery.update(state)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 2631, in update
> obj2cond(self.local._condition, 
> pn_disposition_condition(self.local._impl))
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 1788, in obj2cond
> pn_condition_set_description(cond, obj.description)
> TypeError: in method 'pn_condition_set_description', argument 2 of type 'char 
> const *'
> See attached reproducer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1846) [proton-c] Message decode fails with PN_OUT_OF_MEMORY if there are large lists in the message

2018-05-16 Thread Gordon Sim (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477744#comment-16477744
 ] 

Gordon Sim commented on PROTON-1846:


Attached a javascript sender application that also shows the problem. If you 
use this to send to a proton client e.g. simple_send through a router/broker, 
or direct_send, in python or c++, the proton client fails with an error. A 
qpid::messaging client however, e.g. qpid-receive, can receive the message.

> [proton-c]  Message decode fails with PN_OUT_OF_MEMORY if there are large 
> lists in the message
> --
>
> Key: PROTON-1846
> URL: https://issues.apache.org/jira/browse/PROTON-1846
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Ganesh Murthy
>Priority: Major
> Attachments: send_large_structured_body.js
>
>
> Steps to reproduce -
>  
>  # Start the Qpid Dispatch router
>  # Run the following script that creates a bunch of addresses
>  # for i in `seq 1 6546`; do echo 
> "\{\"prefix\":\"address-$i\",\"distribution\":\"balanced\"}" | qdmanage 
> CREATE --type=org.apache.qpid.dispatch.router.config.address --name 
> address-$i --stdin; done
>  # now run qdmanage QUERY --type=address
>  # You will receive a Data error (-10)
> The following diff seems to fix the issue
> diff --git a/c/src/core/data.h b/c/src/core/data.h
> index 94dc7d67..f4320e2a 100644
> --- a/c/src/core/data.h
> +++ b/c/src/core/data.h
> @@ -27,7 +27,7 @@
>  #include "decoder.h"
>  #include "encoder.h"
>  
> -typedef uint16_t pni_nid_t;
> +typedef uint32_t pni_nid_t;
>  #define PNI_NID_MAX ((pni_nid_t)-1)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1843) Cannot use unicode string in Condition description

2018-05-16 Thread Ken Giusti (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477738#comment-16477738
 ] 

Ken Giusti commented on PROTON-1843:


Further observation:  on python 3.x the dtag must be unicode!  So there's a 
mismatch here.

I actually believe the Python 2.7 behavior is correct - the standard defines 
the tag as a binary type - so unicode should not be allowed and should require 
a conversion to binary via .encode('utf-8').  Perhaps the python binding can 
detect unicode tags in the case of 2.7 and do the encode in that case?

> Cannot use unicode string in Condition description
> --
>
> Key: PROTON-1843
> URL: https://issues.apache.org/jira/browse/PROTON-1843
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Ken Giusti
>Priority: Major
> Attachments: test.py
>
>
> Under python2.7, attempting to set a condition on a delivery using a unicode 
> string causes a traceback:
> Traceback (most recent call last):
>   File "./test.py", line 64, in 
> Container(Test(opts.address)).run()
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/reactor.py",
>  line 148, in run
> while self.process(): pass
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/reactor.py",
>  line 174, in process
> self._check_errors()
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/reactor.py",
>  line 170, in _check_errors
> _compat.raise_(exc, value, tb)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3478, in dispatch
> ev.dispatch(self.handler)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3390, in dispatch
> self.dispatch(h, type)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3387, in dispatch
> result = dispatch(handler, type.method, self)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 173, in on_delivery
> self.on_message(event)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 195, in on_message
> dispatch(self.delegate, 'on_message', event)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 3265, in dispatch
> return m(*args)
>   File "./test.py", line 48, in on_message
> self.reject(event.delivery)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 130, in reject
> self.settle(delivery, Delivery.REJECTED)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/handlers.py",
>  line 146, in settle
> delivery.update(state)
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 2631, in update
> obj2cond(self.local._condition, 
> pn_disposition_condition(self.local._impl))
>   File 
> "/home/kgiusti/tmp/051118/venv/lib/python2.7/site-packages/proton/__init__.py",
>  line 1788, in obj2cond
> pn_condition_set_description(cond, obj.description)
> TypeError: in method 'pn_condition_set_description', argument 2 of type 'char 
> const *'
> See attached reproducer.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (PROTON-1846) [proton-c] Message decode fails with PN_OUT_OF_MEMORY if there are large lists in the message

2018-05-16 Thread Gordon Sim (JIRA)


 [ 
https://issues.apache.org/jira/browse/PROTON-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim updated PROTON-1846:
---
Attachment: send_large_structured_body.js

> [proton-c]  Message decode fails with PN_OUT_OF_MEMORY if there are large 
> lists in the message
> --
>
> Key: PROTON-1846
> URL: https://issues.apache.org/jira/browse/PROTON-1846
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Ganesh Murthy
>Priority: Major
> Attachments: send_large_structured_body.js
>
>
> Steps to reproduce -
>  
>  # Start the Qpid Dispatch router
>  # Run the following script that creates a bunch of addresses
>  # for i in `seq 1 6546`; do echo 
> "\{\"prefix\":\"address-$i\",\"distribution\":\"balanced\"}" | qdmanage 
> CREATE --type=org.apache.qpid.dispatch.router.config.address --name 
> address-$i --stdin; done
>  # now run qdmanage QUERY --type=address
>  # You will receive a Data error (-10)
> The following diff seems to fix the issue
> diff --git a/c/src/core/data.h b/c/src/core/data.h
> index 94dc7d67..f4320e2a 100644
> --- a/c/src/core/data.h
> +++ b/c/src/core/data.h
> @@ -27,7 +27,7 @@
>  #include "decoder.h"
>  #include "encoder.h"
>  
> -typedef uint16_t pni_nid_t;
> +typedef uint32_t pni_nid_t;
>  #define PNI_NID_MAX ((pni_nid_t)-1)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1845) [c] Treat attach received after detach as implying new link

2018-05-16 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477622#comment-16477622
 ] 

ASF subversion and git services commented on PROTON-1845:
-

Commit cd4ecfd8a24bf979a63cd734b695c48c2b7cf7f9 in qpid-proton's branch 
refs/heads/master from [~gsim]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=cd4ecfd ]

PROTON-1845: treat attach after detach as starting new link


> [c] Treat attach received after detach as implying new link 
> 
>
> Key: PROTON-1845
> URL: https://issues.apache.org/jira/browse/PROTON-1845
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (PROTON-1845) [c] Treat attach received after detach as implying new link

2018-05-16 Thread Gordon Sim (JIRA)


 [ 
https://issues.apache.org/jira/browse/PROTON-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gordon Sim resolved PROTON-1845.

Resolution: Fixed

> [c] Treat attach received after detach as implying new link 
> 
>
> Key: PROTON-1845
> URL: https://issues.apache.org/jira/browse/PROTON-1845
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (DISPATCH-974) Getting connections via the router management protocol causes AMQP framing errors

2018-05-16 Thread Ganesh Murthy (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477543#comment-16477543
 ] 

Ganesh Murthy edited comment on DISPATCH-974 at 5/16/18 3:24 PM:
-

This issue will be fixed when proton fixes - 
https://issues.apache.org/jira/browse/PROTON-1846


was (Author: ganeshmurthy):
This issue will be fix when proton fixes - 
https://issues.apache.org/jira/browse/PROTON-1846

> Getting connections via the router management protocol causes AMQP framing 
> errors
> -
>
> Key: DISPATCH-974
> URL: https://issues.apache.org/jira/browse/DISPATCH-974
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Priority: Major
> Attachments: qdrouter-frame-errors.pcapng.gz
>
>
> I am running a standalone router with 5000 clients connected. When I try to 
> get all connections via qdstat (qdstat --limit 5000 -c) something goes wrong 
> (seems to be a framing error). The output from qdstat is:
> {{ MessageException: [-10]: data error: (null)}}
> The problems seems to somehow be related to result size because when I set 
> the limit to less I get the list of connections as expected. In my situation 
> the critical limit is 3447 (i.e. 3447 result in the expected list of 
> connections, 3448 result in the error above). It does not seem to be frame 
> size related because getting 3447 connection is already spread over transfer 
> frames (256182, 256512 and 159399 bytes).
> The error is not qdstat related because using some plain proton code to 
> create a management query results in the same problem. Ultimately the call to 
> pn_message_decode with data receive from the router fails (also wireshark can 
> not decode the final frame).
> I have attached a wireshark dump to the qdstat session with the router 
> ([^qdrouter-frame-errors.pcapng.gz]). The logs of the router (at info level) 
> contain no further information.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7153) Allow expired messages to be sent to DLQ

2018-05-16 Thread Keith Wall (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7153:
-
Description: Currently the Java Broker simply discards messages that expire 
(TTL). The behaviour should be configurable and allow for expired messages to 
be directed to the alternate exchange to allow for dead-lettering.  (was: 
Currently the Java Broker simply discards messages that expire (TLL).  The 
behaviour should be configurable and allow for expired messages to be directed 
to the alternate exchange to allow for dead-lettering.)

> Allow expired messages to be sent to DLQ
> 
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Attachments: QPID-7153.diff
>
>
> Currently the Java Broker simply discards messages that expire (TTL). The 
> behaviour should be configurable and allow for expired messages to be 
> directed to the alternate exchange to allow for dead-lettering.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ

2018-05-16 Thread Keith Wall (JIRA)


[ 
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477544#comment-16477544
 ] 

Keith Wall commented on QPID-7153:
--

Thanks, I'll take a look

> Allow expired messages to be sent to DLQ
> 
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Attachments: QPID-7153.diff
>
>
> Currently the Java Broker simply discards messages that expire (TLL).  The 
> behaviour should be configurable and allow for expired messages to be 
> directed to the alternate exchange to allow for dead-lettering.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-974) Getting connections via the router management protocol causes AMQP framing errors

2018-05-16 Thread Ganesh Murthy (JIRA)


[ 
https://issues.apache.org/jira/browse/DISPATCH-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477543#comment-16477543
 ] 

Ganesh Murthy commented on DISPATCH-974:


This issue will be fix when proton fixes - 
https://issues.apache.org/jira/browse/PROTON-1846

> Getting connections via the router management protocol causes AMQP framing 
> errors
> -
>
> Key: DISPATCH-974
> URL: https://issues.apache.org/jira/browse/DISPATCH-974
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Priority: Major
> Attachments: qdrouter-frame-errors.pcapng.gz
>
>
> I am running a standalone router with 5000 clients connected. When I try to 
> get all connections via qdstat (qdstat --limit 5000 -c) something goes wrong 
> (seems to be a framing error). The output from qdstat is:
> {{ MessageException: [-10]: data error: (null)}}
> The problems seems to somehow be related to result size because when I set 
> the limit to less I get the list of connections as expected. In my situation 
> the critical limit is 3447 (i.e. 3447 result in the expected list of 
> connections, 3448 result in the error above). It does not seem to be frame 
> size related because getting 3447 connection is already spread over transfer 
> frames (256182, 256512 and 159399 bytes).
> The error is not qdstat related because using some plain proton code to 
> create a management query results in the same problem. Ultimately the call to 
> pn_message_decode with data receive from the router fails (also wireshark can 
> not decode the final frame).
> I have attached a wireshark dump to the qdstat session with the router 
> ([^qdrouter-frame-errors.pcapng.gz]). The logs of the router (at info level) 
> contain no further information.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (PROTON-1846) [proton-c] Message decode fails with PN_OUT_OF_MEMORY if there are large lists in the message

2018-05-16 Thread Ganesh Murthy (JIRA)

Ganesh Murthy created PROTON-1846:
-

 Summary: [proton-c]  Message decode fails with PN_OUT_OF_MEMORY if 
there are large lists in the message
 Key: PROTON-1846
 URL: https://issues.apache.org/jira/browse/PROTON-1846
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: proton-c-0.22.0
Reporter: Ganesh Murthy


Steps to reproduce -

 
 # Start the Qpid Dispatch router
 # Run the following script that creates a bunch of addresses
 # for i in `seq 1 6546`; do echo 
"\{\"prefix\":\"address-$i\",\"distribution\":\"balanced\"}" | qdmanage CREATE 
--type=org.apache.qpid.dispatch.router.config.address --name address-$i 
--stdin; done
 # now run qdmanage QUERY --type=address
 # You will receive a Data error (-10)

The following diff seems to fix the issue

diff --git a/c/src/core/data.h b/c/src/core/data.h
index 94dc7d67..f4320e2a 100644
--- a/c/src/core/data.h
+++ b/c/src/core/data.h
@@ -27,7 +27,7 @@
 #include "decoder.h"
 #include "encoder.h"
 
-typedef uint16_t pni_nid_t;
+typedef uint32_t pni_nid_t;
 #define PNI_NID_MAX ((pni_nid_t)-1)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1845) [c] Treat attach received after detach as implying new link

2018-05-16 Thread Robbie Gemmell (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477530#comment-16477530
 ] 

Robbie Gemmell commented on PROTON-1845:


Related commentary:

[https://lists.apache.org/thread.html/fe489cf7de952cbe3ef8fdc5cd03ca9e4c1e1737cc176b622874bb07@%3Cdev.qpid.apache.org%3E]

[https://lists.apache.org/thread.html/cf7f8c44355326e5df898ca31ea1c096d06e96d1983f86558a6910ae@%3Cdev.qpid.apache.org%3E]

 

> [c] Treat attach received after detach as implying new link 
> 
>
> Key: PROTON-1845
> URL: https://issues.apache.org/jira/browse/PROTON-1845
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> It would be better to treat this as starting a new link object.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request 67139: treat attach after detach as new link

2018-05-16 Thread Alan Conway

Misread it the first time. Ship It!

On Wed, May 16, 2018 at 10:01 AM, Robbie Gemmell 
wrote:

> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67139/
>
> Ship it!
>
> I think this seems fair, it the remote handle indicates an existing link 
> object was already detached it doesnt seem there would be reason to return 
> that while looking up something to indicate an attach for.
>
>
> - Robbie Gemmell
>
> On May 15th, 2018, 7:03 p.m. UTC, Gordon Sim wrote:
> Review request for qpid, Alan Conway, Ganesh Murthy, Justin Ross, Robbie
> Gemmell, and Ted Ross.
> By Gordon Sim.
>
> *Updated May 15, 2018, 7:03 p.m.*
> *Bugs: * PROTON-1845 
> *Repository: * qpid-proton-git
> Description
>
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
>
> It would be better to treat this as starting a new link object.
>
> This fixes DISPATCH-994 and DISPATCH-997
>
> Diffs
>
>- c/src/core/transport.c (e0a2b5c)
>
> View Diff 
>

Re: Review Request 67139: treat attach after detach as new link

2018-05-16 Thread Alan Conway


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67139/#review203228
---


Ship it!




Ship It!

- Alan Conway


On May 15, 2018, 7:03 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67139/
> ---
> 
> (Updated May 15, 2018, 7:03 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Ganesh Murthy, Justin Ross, Robbie 
> Gemmell, and Ted Ross.
> 
> 
> Bugs: PROTON-1845
> https://issues.apache.org/jira/browse/PROTON-1845
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> 
> It would be better to treat this as starting a new link object.
> 
> This fixes DISPATCH-994 and DISPATCH-997
> 
> 
> Diffs
> -
> 
>   c/src/core/transport.c e0a2b5c 
> 
> 
> Diff: https://reviews.apache.org/r/67139/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 67139: treat attach after detach as new link

2018-05-16 Thread Robbie Gemmell


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67139/#review203223
---


Ship it!




I think this seems fair, it the remote handle indicates an existing link object 
was already detached it doesnt seem there would be reason to return that while 
looking up something to indicate an attach for.

- Robbie Gemmell


On May 15, 2018, 7:03 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67139/
> ---
> 
> (Updated May 15, 2018, 7:03 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Ganesh Murthy, Justin Ross, Robbie 
> Gemmell, and Ted Ross.
> 
> 
> Bugs: PROTON-1845
> https://issues.apache.org/jira/browse/PROTON-1845
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> If a peer sends attach, detach, attach with the same link name in the second 
> attach, the PN_LINK_REMOTE_OPEN event contains a reference to the link from 
> the first attach. This link is not in a state where it can be reused.
> 
> It would be better to treat this as starting a new link object.
> 
> This fixes DISPATCH-994 and DISPATCH-997
> 
> 
> Diffs
> -
> 
>   c/src/core/transport.c e0a2b5c 
> 
> 
> Diff: https://reviews.apache.org/r/67139/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

[jira] [Created] (DISPATCH-1002) Animate message flow on the console's topology page.

2018-05-16 Thread Ernest Allen (JIRA)

Ernest Allen created DISPATCH-1002:
--

 Summary: Animate message flow on the console's topology page.
 Key: DISPATCH-1002
 URL: https://issues.apache.org/jira/browse/DISPATCH-1002
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Console
Affects Versions: 1.1.0
Reporter: Ernest Allen
Assignee: Ernest Allen


Create an option on the topology page to show message flow through the network 
with the following features:
 * Checkbox to show/hide message flow.
 * Save show/hide state to local storage
 * Animate dots between the ingress client and egress client, through the 
network
 * In the legend, show addresses that are active
 ** with a unique color per address that matches the color of the dots in the 
animation for that address
 ** Add a checkbox per address to filter the animations
 ** When mouse rolls over an address in the legend, fade other addresses
 * Show relative rates of message flow by slightly varying the speed of the 
animation

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-1001) Deprecate the tools under the console directory and move them to a separate npm repistory.

2018-05-16 Thread Ernest Allen (JIRA)

Ernest Allen created DISPATCH-1001:
--

 Summary: Deprecate the tools under the console directory and move 
them to a separate npm repistory.
 Key: DISPATCH-1001
 URL: https://issues.apache.org/jira/browse/DISPATCH-1001
 Project: Qpid Dispatch
  Issue Type: Task
  Components: Console
Affects Versions: 1.1.0
Reporter: Ernest Allen
Assignee: Ernest Allen


Mark the console/config and console/dashboard directories as deprecated in 
preperation to move them to their own repositories with the next release.

These directories contain optional utilities. They are best stored in an npm 
repository for easy installation.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-8192) [Broker-J] Make bindingKey parameter mandatory in exchange bind/unbind operations

2018-05-16 Thread Alex Rudyy (JIRA)

Alex Rudyy created QPID-8192:


 Summary: [Broker-J] Make bindingKey parameter mandatory in 
exchange bind/unbind operations
 Key: QPID-8192
 URL: https://issues.apache.org/jira/browse/QPID-8192
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Affects Versions: qpid-java-broker-7.0.1, qpid-java-broker-7.0.0, 
qpid-java-broker-7.0.2, qpid-java-broker-7.0.3
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-7.0.4


Make bindingKey parameter mandatory in exchange bind/unbind operations but 
allow the value of the binding key to be the empty string. Optional bindingKey 
parameter causes confusions in understanding how bind/unbind operations works, 
as omitting  bindingKey in unbind operation could be misinterpreted as bulk 
bindings deletion for the given destination. The unbind operation description 
text should be fixed as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (DISPATCH-1000) Repatriate the console pages from npm repository

2018-05-16 Thread Ernest Allen (JIRA)

Ernest Allen created DISPATCH-1000:
--

 Summary: Repatriate the console pages from npm repository
 Key: DISPATCH-1000
 URL: https://issues.apache.org/jira/browse/DISPATCH-1000
 Project: Qpid Dispatch
  Issue Type: Task
  Components: Console
Affects Versions: 1.1.0
Reporter: Ernest Allen
Assignee: Ernest Allen


The console's html/css/js files where moved to a separate npm repository 
(dispatch-console-pages). This was done to facilitate development of a hawtio2 
console while reusing the same html/css/js.

These files need to be returned to the apache repository for Jira tracking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ

2018-05-16 Thread Rob Godfrey (JIRA)


[ 
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477245#comment-16477245
 ] 

Rob Godfrey commented on QPID-7153:
---

Attached an untested patch which might provide a way forward for this - 
following the conversation on the users list - it aims to prevent routing loops 
by only routing expired messages to queues where they will not immediately be 
re-expired. 

> Allow expired messages to be sent to DLQ
> 
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Attachments: QPID-7153.diff
>
>
> Currently the Java Broker simply discards messages that expire (TLL).  The 
> behaviour should be configurable and allow for expired messages to be 
> directed to the alternate exchange to allow for dead-lettering.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7153) Allow expired messages to be sent to DLQ

2018-05-16 Thread Rob Godfrey (JIRA)


 [ 
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Godfrey updated QPID-7153:
--
Attachment: QPID-7153.diff

> Allow expired messages to be sent to DLQ
> 
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Attachments: QPID-7153.diff
>
>
> Currently the Java Broker simply discards messages that expire (TLL).  The 
> behaviour should be configurable and allow for expired messages to be 
> directed to the alternate exchange to allow for dead-lettering.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

47 matches

Mail list logo