[jira] [Comment Edited] (DISPATCH-957) Unbalanced memory consumption in a 2 routers configuration and specific workload

[Matthieu Simonin (JIRA)]

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

Matthieu Simonin edited comment on DISPATCH-957 at 4/13/18 8:53 PM:


In attachment the log files of the two qdrouterd.
 * router0 is where clients are connected
 * router1 is where servers are connected

I ran (conf in attachment):
 * {{oo deploy --driver=router g5k}}
 * {{oo test_case_1 --nbr_clients=100 --nbr_servers=100 --nbr_calls=1000 
--pause=0.1 --timeout 200}}

 

edit: I forgot to mention that I observed the same behaviour (increased memory 
consumption on router1)


was (Author: msimonin):
In attachment the log files of the two qdrouterd.
 * router0 is where clients are connected
 * router1 is where servers are connected

I ran (conf in attachment):
 * {{oo deploy --driver=router g5k}}
 * {{oo test_case_1 --nbr_clients=100 --nbr_servers=100 --nbr_calls=1000 
--pause=0.1 --timeout 200}}

 

> Unbalanced memory consumption in a 2 routers configuration and specific 
> workload
> 
>
> Key: DISPATCH-957
> URL: https://issues.apache.org/jira/browse/DISPATCH-957
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
> Environment: * At the time I was experimenting, I built the router 
> from the source and
> used 22400df dockerized. It's available in docker hub : 
> msimonin/qdrouterd:22400df or msimonin/qdrouterd-collectd:22400f 
>  
>  * ombt version used embeds the following library
> oslo.messaging==5.35.0
> pyngus==2.2.2
> python-qpid-proton==0.19.0
>  
>  * I used ombt-orchestrator to deploy all the stack using the g5k provider 
> (see
> https://github.com/msimonin/ombt-orchestrator/) In a local machine setup,
> vagrant provider can be used but I'm not sure if it is reasonnable to scale 
> the
> above number of agents. I've attached nevertheless the configuration used.
>  
>  * Host Linux distribution is debian9
>  
>  
>Reporter: Matthieu Simonin
>Assignee: Ken Giusti
>Priority: Major
> Attachments: call.png, cast.png, conf.yaml, conf.yaml, inc-calls.png, 
> mem_usage.tar.gz, router0.log, router1.log
>
>
> After discussion with Ken Giusti we deem appropriate to fill a bug to track 
> the
> following behavior.
> Note also that the exact version used in the following description isn't 
> exactly 1.1.0 but one built from source 22400df (master back in february).
> I started two interconnected routers (router0 and router1)
> router0 is where all my consumers connect router1 is where all my producers
> connect .
> The workload is an RPC test using oslo.messaging library using calls
> (resp. casts) : clients keep sending message and block for the response 
> (resp. do not block).
> I've attached some observations:
> 1)
> With 100 consumers and 100 producers and calls I observe a higher memory
> consumption of router0 in comparison of the memory consumption of router1 (see
> calls.png). Casts seem to less affect the router memory. Calls usually 
> requires
> more ressources because of the return values flowing back to the producer but
> I wouldn't expect this big difference.
> I've attached a tgz in which, you'll find the results of qdtsat -a,-m,-l
> * before the benchmark (start)
> * early during the benchmark (during)
> * late during the benchmark (during-1)
> * after the benchmark completed (after)
> 2) I've run a second test increasing incrementaly the (#clients, #servers) : 
> [50, 100, 200, 500] (calls only)
> see inc-calls.png
> in this case the difference of the memory consumption between router0 and 
> router1 is [50MB, 100MB, 300MB, 1.5GB]



--
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-957) Unbalanced memory consumption in a 2 routers configuration and specific workload

[Matthieu Simonin (JIRA)]

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

Matthieu Simonin commented on DISPATCH-957:
---

In attachment the log files of the two qdrouterd.
 * router0 is where clients are connected
 * router1 is where servers are connected

I ran (conf in attachment):
 * {{oo deploy --driver=router g5k}}
 * {{oo test_case_1 --nbr_clients=100 --nbr_servers=100 --nbr_calls=1000 
--pause=0.1 --timeout 200}}

 

> Unbalanced memory consumption in a 2 routers configuration and specific 
> workload
> 
>
> Key: DISPATCH-957
> URL: https://issues.apache.org/jira/browse/DISPATCH-957
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
> Environment: * At the time I was experimenting, I built the router 
> from the source and
> used 22400df dockerized. It's available in docker hub : 
> msimonin/qdrouterd:22400df or msimonin/qdrouterd-collectd:22400f 
>  
>  * ombt version used embeds the following library
> oslo.messaging==5.35.0
> pyngus==2.2.2
> python-qpid-proton==0.19.0
>  
>  * I used ombt-orchestrator to deploy all the stack using the g5k provider 
> (see
> https://github.com/msimonin/ombt-orchestrator/) In a local machine setup,
> vagrant provider can be used but I'm not sure if it is reasonnable to scale 
> the
> above number of agents. I've attached nevertheless the configuration used.
>  
>  * Host Linux distribution is debian9
>  
>  
>Reporter: Matthieu Simonin
>Assignee: Ken Giusti
>Priority: Major
> Attachments: call.png, cast.png, conf.yaml, conf.yaml, inc-calls.png, 
> mem_usage.tar.gz, router0.log, router1.log
>
>
> After discussion with Ken Giusti we deem appropriate to fill a bug to track 
> the
> following behavior.
> Note also that the exact version used in the following description isn't 
> exactly 1.1.0 but one built from source 22400df (master back in february).
> I started two interconnected routers (router0 and router1)
> router0 is where all my consumers connect router1 is where all my producers
> connect .
> The workload is an RPC test using oslo.messaging library using calls
> (resp. casts) : clients keep sending message and block for the response 
> (resp. do not block).
> I've attached some observations:
> 1)
> With 100 consumers and 100 producers and calls I observe a higher memory
> consumption of router0 in comparison of the memory consumption of router1 (see
> calls.png). Casts seem to less affect the router memory. Calls usually 
> requires
> more ressources because of the return values flowing back to the producer but
> I wouldn't expect this big difference.
> I've attached a tgz in which, you'll find the results of qdtsat -a,-m,-l
> * before the benchmark (start)
> * early during the benchmark (during)
> * late during the benchmark (during-1)
> * after the benchmark completed (after)
> 2) I've run a second test increasing incrementaly the (#clients, #servers) : 
> [50, 100, 200, 500] (calls only)
> see inc-calls.png
> in this case the difference of the memory consumption between router0 and 
> router1 is [50MB, 100MB, 300MB, 1.5GB]



--
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-957) Unbalanced memory consumption in a 2 routers configuration and specific workload

[Matthieu Simonin (JIRA)]

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

Matthieu Simonin updated DISPATCH-957:
--
Attachment: router1.log

> Unbalanced memory consumption in a 2 routers configuration and specific 
> workload
> 
>
> Key: DISPATCH-957
> URL: https://issues.apache.org/jira/browse/DISPATCH-957
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
> Environment: * At the time I was experimenting, I built the router 
> from the source and
> used 22400df dockerized. It's available in docker hub : 
> msimonin/qdrouterd:22400df or msimonin/qdrouterd-collectd:22400f 
>  
>  * ombt version used embeds the following library
> oslo.messaging==5.35.0
> pyngus==2.2.2
> python-qpid-proton==0.19.0
>  
>  * I used ombt-orchestrator to deploy all the stack using the g5k provider 
> (see
> https://github.com/msimonin/ombt-orchestrator/) In a local machine setup,
> vagrant provider can be used but I'm not sure if it is reasonnable to scale 
> the
> above number of agents. I've attached nevertheless the configuration used.
>  
>  * Host Linux distribution is debian9
>  
>  
>Reporter: Matthieu Simonin
>Assignee: Ken Giusti
>Priority: Major
> Attachments: call.png, cast.png, conf.yaml, conf.yaml, inc-calls.png, 
> mem_usage.tar.gz, router0.log, router1.log
>
>
> After discussion with Ken Giusti we deem appropriate to fill a bug to track 
> the
> following behavior.
> Note also that the exact version used in the following description isn't 
> exactly 1.1.0 but one built from source 22400df (master back in february).
> I started two interconnected routers (router0 and router1)
> router0 is where all my consumers connect router1 is where all my producers
> connect .
> The workload is an RPC test using oslo.messaging library using calls
> (resp. casts) : clients keep sending message and block for the response 
> (resp. do not block).
> I've attached some observations:
> 1)
> With 100 consumers and 100 producers and calls I observe a higher memory
> consumption of router0 in comparison of the memory consumption of router1 (see
> calls.png). Casts seem to less affect the router memory. Calls usually 
> requires
> more ressources because of the return values flowing back to the producer but
> I wouldn't expect this big difference.
> I've attached a tgz in which, you'll find the results of qdtsat -a,-m,-l
> * before the benchmark (start)
> * early during the benchmark (during)
> * late during the benchmark (during-1)
> * after the benchmark completed (after)
> 2) I've run a second test increasing incrementaly the (#clients, #servers) : 
> [50, 100, 200, 500] (calls only)
> see inc-calls.png
> in this case the difference of the memory consumption between router0 and 
> router1 is [50MB, 100MB, 300MB, 1.5GB]



--
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-957) Unbalanced memory consumption in a 2 routers configuration and specific workload

[Matthieu Simonin (JIRA)]

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

Matthieu Simonin updated DISPATCH-957:
--
Attachment: conf.yaml

> Unbalanced memory consumption in a 2 routers configuration and specific 
> workload
> 
>
> Key: DISPATCH-957
> URL: https://issues.apache.org/jira/browse/DISPATCH-957
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
> Environment: * At the time I was experimenting, I built the router 
> from the source and
> used 22400df dockerized. It's available in docker hub : 
> msimonin/qdrouterd:22400df or msimonin/qdrouterd-collectd:22400f 
>  
>  * ombt version used embeds the following library
> oslo.messaging==5.35.0
> pyngus==2.2.2
> python-qpid-proton==0.19.0
>  
>  * I used ombt-orchestrator to deploy all the stack using the g5k provider 
> (see
> https://github.com/msimonin/ombt-orchestrator/) In a local machine setup,
> vagrant provider can be used but I'm not sure if it is reasonnable to scale 
> the
> above number of agents. I've attached nevertheless the configuration used.
>  
>  * Host Linux distribution is debian9
>  
>  
>Reporter: Matthieu Simonin
>Assignee: Ken Giusti
>Priority: Major
> Attachments: call.png, cast.png, conf.yaml, conf.yaml, inc-calls.png, 
> mem_usage.tar.gz, router0.log, router1.log
>
>
> After discussion with Ken Giusti we deem appropriate to fill a bug to track 
> the
> following behavior.
> Note also that the exact version used in the following description isn't 
> exactly 1.1.0 but one built from source 22400df (master back in february).
> I started two interconnected routers (router0 and router1)
> router0 is where all my consumers connect router1 is where all my producers
> connect .
> The workload is an RPC test using oslo.messaging library using calls
> (resp. casts) : clients keep sending message and block for the response 
> (resp. do not block).
> I've attached some observations:
> 1)
> With 100 consumers and 100 producers and calls I observe a higher memory
> consumption of router0 in comparison of the memory consumption of router1 (see
> calls.png). Casts seem to less affect the router memory. Calls usually 
> requires
> more ressources because of the return values flowing back to the producer but
> I wouldn't expect this big difference.
> I've attached a tgz in which, you'll find the results of qdtsat -a,-m,-l
> * before the benchmark (start)
> * early during the benchmark (during)
> * late during the benchmark (during-1)
> * after the benchmark completed (after)
> 2) I've run a second test increasing incrementaly the (#clients, #servers) : 
> [50, 100, 200, 500] (calls only)
> see inc-calls.png
> in this case the difference of the memory consumption between router0 and 
> router1 is [50MB, 100MB, 300MB, 1.5GB]



--
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-957) Unbalanced memory consumption in a 2 routers configuration and specific workload

[Matthieu Simonin (JIRA)]

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

Matthieu Simonin updated DISPATCH-957:
--
Attachment: router0.log

> Unbalanced memory consumption in a 2 routers configuration and specific 
> workload
> 
>
> Key: DISPATCH-957
> URL: https://issues.apache.org/jira/browse/DISPATCH-957
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.0.1
> Environment: * At the time I was experimenting, I built the router 
> from the source and
> used 22400df dockerized. It's available in docker hub : 
> msimonin/qdrouterd:22400df or msimonin/qdrouterd-collectd:22400f 
>  
>  * ombt version used embeds the following library
> oslo.messaging==5.35.0
> pyngus==2.2.2
> python-qpid-proton==0.19.0
>  
>  * I used ombt-orchestrator to deploy all the stack using the g5k provider 
> (see
> https://github.com/msimonin/ombt-orchestrator/) In a local machine setup,
> vagrant provider can be used but I'm not sure if it is reasonnable to scale 
> the
> above number of agents. I've attached nevertheless the configuration used.
>  
>  * Host Linux distribution is debian9
>  
>  
>Reporter: Matthieu Simonin
>Assignee: Ken Giusti
>Priority: Major
> Attachments: call.png, cast.png, conf.yaml, conf.yaml, inc-calls.png, 
> mem_usage.tar.gz, router0.log, router1.log
>
>
> After discussion with Ken Giusti we deem appropriate to fill a bug to track 
> the
> following behavior.
> Note also that the exact version used in the following description isn't 
> exactly 1.1.0 but one built from source 22400df (master back in february).
> I started two interconnected routers (router0 and router1)
> router0 is where all my consumers connect router1 is where all my producers
> connect .
> The workload is an RPC test using oslo.messaging library using calls
> (resp. casts) : clients keep sending message and block for the response 
> (resp. do not block).
> I've attached some observations:
> 1)
> With 100 consumers and 100 producers and calls I observe a higher memory
> consumption of router0 in comparison of the memory consumption of router1 (see
> calls.png). Casts seem to less affect the router memory. Calls usually 
> requires
> more ressources because of the return values flowing back to the producer but
> I wouldn't expect this big difference.
> I've attached a tgz in which, you'll find the results of qdtsat -a,-m,-l
> * before the benchmark (start)
> * early during the benchmark (during)
> * late during the benchmark (during-1)
> * after the benchmark completed (after)
> 2) I've run a second test increasing incrementaly the (#clients, #servers) : 
> [50, 100, 200, 500] (calls only)
> see inc-calls.png
> in this case the difference of the memory consumption between router0 and 
> router1 is [50MB, 100MB, 300MB, 1.5GB]



--
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-1830) [ruby] sporadic failure of ruby tests

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1830.
-
Resolution: Fixed

> [ruby] sporadic failure of ruby tests
> -
>
> Key: PROTON-1830
> URL: https://issues.apache.org/jira/browse/PROTON-1830
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Tests are sporadiclaly failing like this:
>  
> 38: 1) Failure:
> 38: ContainerTest#test_handler_raise 
> [/home/travis/build/alanconway/qpid-proton/ruby/tests/test_container.rb:328]:
> 38: Expected false to be truthy.
>  
> For example https://travis-ci.org/alanconway/qpid-proton/jobs/365799260



--
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-1830) [ruby] sporadic failure of ruby tests

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1830: [ruby] container sometimes fails to close listener

Fix race condition where the container might not close a listener if stopped by
an exception. Was causing this sporadic failure:

ContainerTest#test_handler_raise 
[/home/travis/build/alanconway/qpid-proton/ruby/tests/test_container.rb:328]:
Expected false to be truthy.


> [ruby] sporadic failure of ruby tests
> -
>
> Key: PROTON-1830
> URL: https://issues.apache.org/jira/browse/PROTON-1830
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Tests are sporadiclaly failing like this:
>  
> 38: 1) Failure:
> 38: ContainerTest#test_handler_raise 
> [/home/travis/build/alanconway/qpid-proton/ruby/tests/test_container.rb:328]:
> 38: Expected false to be truthy.
>  
> For example https://travis-ci.org/alanconway/qpid-proton/jobs/365799260



--
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-1830) [ruby] sporadic failure of ruby tests

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1830: [ruby] fix bug in test_container_work_queue_stop

Previously was scheduling tasks with a delay, so all tasks had different times.
For test to work reliably, must schedule tasks with the same absolute time.


> [ruby] sporadic failure of ruby tests
> -
>
> Key: PROTON-1830
> URL: https://issues.apache.org/jira/browse/PROTON-1830
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: ruby-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> Tests are sporadiclaly failing like this:
>  
> 38: 1) Failure:
> 38: ContainerTest#test_handler_raise 
> [/home/travis/build/alanconway/qpid-proton/ruby/tests/test_container.rb:328]:
> 38: Expected false to be truthy.
>  
> For example https://travis-ci.org/alanconway/qpid-proton/jobs/365799260



--
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-1830) [ruby] sporadic failure of ruby tests

[Alan Conway (JIRA)]

Alan Conway created PROTON-1830:
---

 Summary: [ruby] sporadic failure of ruby tests
 Key: PROTON-1830
 URL: https://issues.apache.org/jira/browse/PROTON-1830
 Project: Qpid Proton
  Issue Type: Bug
  Components: ruby-binding
Affects Versions: proton-c-0.22.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: proton-c-0.23.0


Tests are sporadiclaly failing like this:

 
38: 1) Failure:
38: ContainerTest#test_handler_raise 
[/home/travis/build/alanconway/qpid-proton/ruby/tests/test_container.rb:328]:
38: Expected false to be truthy.
 
For example https://travis-ci.org/alanconway/qpid-proton/jobs/365799260



--
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-1829) adjust fallback sizing for internal buffers

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved PROTON-1829.

Resolution: Fixed

> adjust fallback sizing for internal buffers
> ---
>
> Key: PROTON-1829
> URL: https://issues.apache.org/jira/browse/PROTON-1829
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.27.0
>
>
> Some of the frame parsing and transport impl bases internal buffers on the 
> size of the transports max frame size. If no max frame size is set (the 
> default), then fallback sizes of 4KB are used. Given how the engine works and 
> the potentially large frames from not having a max set these aren't great 
> values and can exacerbate some inefficiencies elsewhere. Proton-c starts its 
> equivalents at 16KB, we should match that.



--
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] (QPIDIT-121) [C++ shim] amqp_types_test Receiver not based on AmqpReceiverBase

[Kim van der Riet (JIRA)]

Kim van der Riet created QPIDIT-121:
---

 Summary: [C++ shim] amqp_types_test Receiver not based on 
AmqpReceiverBase
 Key: QPIDIT-121
 URL: https://issues.apache.org/jira/browse/QPIDIT-121
 Project: Apache QPID Interoperability Test Suite
  Issue Type: Task
  Components: Proton C++ Shim
Affects Versions: 0.1.0
Reporter: Kim van der Riet
Assignee: Kim van der Riet


The qpid-proton-cpp shims have defined a set of parent classes for Receiver and 
Sender. The amqp_types_test Sender is using its parent class, but the receiver 
does not. This is a refactoring task only, there is no error associated with 
this issue.



--
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 #287: NO-JIRA - Removed sleep and introduced a ti...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

NO-JIRA - Removed sleep and introduced a timer to test connector fail…

…over urls

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch 
SYSTEM-TESTS-HANDLE-FAILOVER-FIX

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

https://github.com/apache/qpid-dispatch/pull/287.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 #287


commit 557f579d6fd4ab94b2d050c4895faa058759fbdd
Author: Ganesh Murthy 
Date:   2018-04-13T17:36:35Z

NO-JIRA - Removed sleep and introduced a timer to test connector failover 
urls




---

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

[jira] [Resolved] (DISPATCH-967) Policy management interface does not forward log warning messages

[Chuck Rolke (JIRA)]

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

Chuck Rolke resolved DISPATCH-967.
--
   Resolution: Fixed
Fix Version/s: 1.1.0

Commit e6473b4c

 

> Policy management interface does not forward log warning messages
> -
>
> Key: DISPATCH-967
> URL: https://issues.apache.org/jira/browse/DISPATCH-967
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.1.0
>
>
> Some user policies may generate warnings. However, the warnings are unable to 
> be forwarded out of python code to the log code proper because the policy 
> manager does not have an interface to forward warnings.
>  



--
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] (QPIDJMS-378) Update Netty to latest 4.1.23.Final

[Timothy Bish (JIRA)]

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

Timothy Bish updated QPIDJMS-378:
-
Affects Version/s: 0.31.0

> Update Netty to latest 4.1.23.Final
> ---
>
> Key: QPIDJMS-378
> URL: https://issues.apache.org/jira/browse/QPIDJMS-378
> Project: Qpid JMS
>  Issue Type: Task
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 0.32.0
>
>
> Update netty to latest release



--
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] (QPIDJMS-378) Update Netty to latest 4.1.23.Final

[Timothy Bish (JIRA)]

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

Timothy Bish resolved QPIDJMS-378.
--
   Resolution: Fixed
 Assignee: Timothy Bish
Fix Version/s: 0.32.0

> Update Netty to latest 4.1.23.Final
> ---
>
> Key: QPIDJMS-378
> URL: https://issues.apache.org/jira/browse/QPIDJMS-378
> Project: Qpid JMS
>  Issue Type: Task
>Affects Versions: 0.31.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 0.32.0
>
>
> Update netty to latest release



--
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-1829) adjust fallback sizing for internal buffers

[ASF subversion and git services (JIRA)]

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

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

Commit 5a2631dcfa750287c4506097a625ab020018330c in qpid-proton-j's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=5a2631d ]

PROTON-1829: adjust fallback sizing for internal buffers


> adjust fallback sizing for internal buffers
> ---
>
> Key: PROTON-1829
> URL: https://issues.apache.org/jira/browse/PROTON-1829
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-j
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.27.0
>
>
> Some of the frame parsing and transport impl bases internal buffers on the 
> size of the transports max frame size. If no max frame size is set (the 
> default), then fallback sizes of 4KB are used. Given how the engine works and 
> the potentially large frames from not having a max set these aren't great 
> values and can exacerbate some inefficiencies elsewhere. Proton-c starts its 
> equivalents at 16KB, we should match that.



--
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] (QPIDJMS-378) Update Netty to latest 4.1.23.Final

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437570#comment-16437570
 ] 

ASF subversion and git services commented on QPIDJMS-378:
-

Commit 498fd7651f11031380e1a97dbcdb99ed3772eba4 in qpid-jms's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=498fd76 ]

QPIDJMS-378 Update to Netty 4.1.23.Final

> Update Netty to latest 4.1.23.Final
> ---
>
> Key: QPIDJMS-378
> URL: https://issues.apache.org/jira/browse/QPIDJMS-378
> Project: Qpid JMS
>  Issue Type: Task
>Reporter: Timothy Bish
>Priority: Minor
>
> Update netty to latest release



--
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-1829) adjust fallback sizing for internal buffers

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1829:
--

 Summary: adjust fallback sizing for internal buffers
 Key: PROTON-1829
 URL: https://issues.apache.org/jira/browse/PROTON-1829
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-j
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: proton-j-0.27.0


Some of the frame parsing and transport impl bases internal buffers on the size 
of the transports max frame size. If no max frame size is set (the default), 
then fallback sizes of 4KB are used. Given how the engine works and the 
potentially large frames from not having a max set these aren't great values 
and can exacerbate some inefficiencies elsewhere. Proton-c starts its 
equivalents at 16KB, we should match that.



--
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-1672) Large deliveries comprising many transfers are handled inefficiently

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1672: disable jacaco for the python tests module, it appears it provokes 
sporadic issues with jython


> Large deliveries comprising many transfers are handled inefficiently
> 
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: proton-j-0.27.0
>
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0) 
> shows that receipt of large messages is very slow in comparison with the send 
> of the same message.   For instance, sending 300MiB bytes message takes 5 
> seconds on my laptop.  The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.  
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}} 
> re-allocates/array copies the entire delivery buffer for ever transfer that 
> comprises it.  This leads to a non-linear loss of performance.   The stack 
> include Proton-J 0.23.0, but is looks like this code is unchanged.



--
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] (QPIDJMS-378) Update Netty to latest 4.1.23.Final

[Timothy Bish (JIRA)]

Timothy Bish created QPIDJMS-378:


 Summary: Update Netty to latest 4.1.23.Final
 Key: QPIDJMS-378
 URL: https://issues.apache.org/jira/browse/QPIDJMS-378
 Project: Qpid JMS
  Issue Type: Task
Reporter: Timothy Bish


Update netty to latest release



--
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] (QPIDIT-119) Add AMQP complex type test

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437557#comment-16437557
 ] 

ASF subversion and git services commented on QPIDIT-119:


Commit b4e6d0b56ef98c32eb4752032e512a46230e873e in qpid-interop-test's branch 
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=b4e6d0b ]

QPIDIT-119: WIP: Data JSON files, generator (with Python and C++ generation 
complete) and Python 2/3 shims.


> Add AMQP complex type test
> --
>
> Key: QPIDIT-119
> URL: https://issues.apache.org/jira/browse/QPIDIT-119
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Fix For: 0.2.0
>
>
> The AMQP types test cover the simple tests well, but do not do a good job of 
> the complex types. This is because the ability to represent the test data for 
> the complex types is itself a complex issue, as each complex type may contain 
> an arbitrary number of other complex types. For example, a list may contain 
> other lists or maps, and maps may contain other lists and maps as both keys 
> and values.
> Solving this problem requires that a mechanism exist to create and represent 
> an arbitrarily large and complex set of data for testing, and allow the sent 
> and received data to be compared to determine success or failure.



--
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-1828) add ability to limit outgoing frame sizes

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved PROTON-1828.

Resolution: Fixed

> add ability to limit outgoing frame sizes
> -
>
> Key: PROTON-1828
> URL: https://issues.apache.org/jira/browse/PROTON-1828
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: proton-j-0.26.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.27.0
>
>
> Current, proton-j (and c) will send the largest frames it can as permitted by 
> a peers max-frame size. Where peers don't set a max frame size, or use a very 
> large one, then this typically results in a single outgoing frame being 
> emitted, which for large messages can be inefficient and also requires more 
> memory than might be desirable. There is currently no way to govern the 
> maximum size of the outgoing frames (besides the peers advertised max frame 
> size), such a mechanism should be added.



--
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-1828) add ability to limit outgoing frame sizes

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1828:
---
Description: Current, proton-j (and c) will send the largest frames it can 
as permitted by a peers max-frame size. Where peers don't set a max frame size, 
or use a very large one, then this typically results in a single outgoing frame 
being emitted, which for large messages can be inefficient and also requires 
more memory than might be desirable. There is currently no way to govern the 
maximum size of the outgoing frames (besides the peers advertised max frame 
size), such a mechanism should be added.  (was: Current, proton-j (and c) will 
send the largest frames it can as permitted by a peers max-frame size. Where 
peers don't set a max frame size, or use a very large one, then this typically 
results in a single outgoing frame being emitted, which for large messages can 
be inefficient and also requires more memory than might be desirable. There is 
no currently way to govern the maximum size of the outgoing frames (besides the 
peers advertised max frame size), such a mechanism should be added.)

> add ability to limit outgoing frame sizes
> -
>
> Key: PROTON-1828
> URL: https://issues.apache.org/jira/browse/PROTON-1828
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: proton-j-0.26.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.27.0
>
>
> Current, proton-j (and c) will send the largest frames it can as permitted by 
> a peers max-frame size. Where peers don't set a max frame size, or use a very 
> large one, then this typically results in a single outgoing frame being 
> emitted, which for large messages can be inefficient and also requires more 
> memory than might be desirable. There is currently no way to govern the 
> maximum size of the outgoing frames (besides the peers advertised max frame 
> size), such a mechanism should be added.



--
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-1828) add ability to limit outgoing frame sizes

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1828: add ability limit outgoing frame sizes


> add ability to limit outgoing frame sizes
> -
>
> Key: PROTON-1828
> URL: https://issues.apache.org/jira/browse/PROTON-1828
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: proton-j-0.26.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.27.0
>
>
> Current, proton-j (and c) will send the largest frames it can as permitted by 
> a peers max-frame size. Where peers don't set a max frame size, or use a very 
> large one, then this typically results in a single outgoing frame being 
> emitted, which for large messages can be inefficient and also requires more 
> memory than might be desirable. There is no currently way to govern the 
> maximum size of the outgoing frames (besides the peers advertised max frame 
> size), such a mechanism should be added.



--
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-1828) add ability to limit outgoing frame sizes

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell updated PROTON-1828:
---
Issue Type: New Feature  (was: Bug)

> add ability to limit outgoing frame sizes
> -
>
> Key: PROTON-1828
> URL: https://issues.apache.org/jira/browse/PROTON-1828
> Project: Qpid Proton
>  Issue Type: New Feature
>  Components: proton-j
>Affects Versions: proton-j-0.26.0
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
> Fix For: proton-j-0.27.0
>
>
> Current, proton-j (and c) will send the largest frames it can as permitted by 
> a peers max-frame size. Where peers don't set a max frame size, or use a very 
> large one, then this typically results in a single outgoing frame being 
> emitted, which for large messages can be inefficient and also requires more 
> memory than might be desirable. There is no currently way to govern the 
> maximum size of the outgoing frames (besides the peers advertised max frame 
> size), such a mechanism should be added.



--
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-1828) add ability to limit outgoing frame sizes

[Robbie Gemmell (JIRA)]

Robbie Gemmell created PROTON-1828:
--

 Summary: add ability to limit outgoing frame sizes
 Key: PROTON-1828
 URL: https://issues.apache.org/jira/browse/PROTON-1828
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: proton-j-0.26.0
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: proton-j-0.27.0


Current, proton-j (and c) will send the largest frames it can as permitted by a 
peers max-frame size. Where peers don't set a max frame size, or use a very 
large one, then this typically results in a single outgoing frame being 
emitted, which for large messages can be inefficient and also requires more 
memory than might be desirable. There is no currently way to govern the maximum 
size of the outgoing frames (besides the peers advertised max frame size), such 
a mechanism should be added.



--
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-967) Policy management interface does not forward log warning messages

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-967: Add policy_manager log_warning interface

Add a self test that generates a policy warning and verify that the
router does not exit with a critical error.


> Policy management interface does not forward log warning messages
> -
>
> Key: DISPATCH-967
> URL: https://issues.apache.org/jira/browse/DISPATCH-967
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> Some user policies may generate warnings. However, the warnings are unable to 
> be forwarded out of python code to the log code proper because the policy 
> manager does not have an interface to forward warnings.
>  



--
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-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-8158:
---

Commit c2cdab1ea2689066eb4736309cfe2db0dc078fec in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c2cdab1 ]

QPID-8158: [Broker-J] [System Tests] Update README and cleanup legacy settings


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
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-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-8158:
---

Commit bc671f5fded7da402d3fdbe8af3f911aa303baa9 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=bc671f5 ]

Revert "QPID-8158: [Broker-J] [System Tests] Run protocol tests as part of unit 
tests"

This reverts commit b91ddb20ecd3b3178072ef39c08f47cf5ceb7e29.


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
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-8158) [Broker-J] [System Tests] Refactor BDB HA system tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-8158:
---

Commit 440824f39d6bab4aa90706db0cceb25ddc7252da in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=440824f ]

QPID-8158: [Broker-J] [System Tests] Fix issue with creation of folder 
test.output.dir_UNDEFINED by logback when variable test.output.dir is not 
defined


> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They 
> need to be refactored to run with {{QpidTestRunner}}  similar to other system 
> tests.
> The BDB HA nodes  should be started as spawn brokers using special  
> {{BrokerAdmin}} allowing to start broker in a separate JVM.



--
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-966) Qpid dispatch unstable inter-router connections

[Marcel Meulemans (JIRA)]

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

Marcel Meulemans edited comment on DISPATCH-966 at 4/13/18 11:18 AM:
-

Added to the configuration and ran the test again several times. However now I 
see some things I did not expect; the network seems to come up correctly, but 
after a while it seems to fail in a weird way. The inter-router connections do 
not seems to drop anymore but routing via the network does not seem to work 
(i.e.ROUTER_LS (info) Computed next hops: {} and qdstat -n show only a single 
router). Maybe this is the issue unmasked by allowing unsettled multicasts?

I attached two more files:
 * the logs of router-0 (from router start until slightly after the network 
fails) at info level
 * a tcpdump to the inter router communication to an from router-0 (tcpdump -i 
eth0 tcp port 55672 -s 65535) also from router start until slightly after the 
network fails

I hope this helps (the dump is fairly large, so I hope you can find any hidden 
needles).

-- 
 Marcel


was (Author: mmeulemans):
Added to the configuration and ran the test again several times. However now I 
see some things I did not expect; the network seems to come up correctly, but 
after a while it seems to fail in a weird way. The inter-router connections do 
not seems to drop anymore but routing via the network does not seem to work 
(i.e.ROUTER_LS (info) Computed next hops: {} and qdstat -n show only a single 
router). Maybe this is the issue unmasked by allowing unsettled multicasts?

I attached two more file:
 * the logs of router-0 (from router start until slightly after the network 
fails) at info level
 * a tcpdump to the inter router communication to an from router-0 (tcpdump -i 
eth0 tcp port 55672 -s 65535)

I hope this helps (the dump is fairly large, so I hope you can find any hidden 
needles).

-- 
Marcel

> 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
> 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] (QPID-8163) [Broker-J] [ACL] Owner ACL rules

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPID-8163:
---

Commit 2443fe648347e5775a1f1c41c20eada49f62970b in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2443fe6 ]

QPID-8163: [Access Control Plugin] Support OWNER psuedo principal in ACL rules.


> [Broker-J] [ACL] Owner ACL rules
> 
>
> Key: QPID-8163
> URL: https://issues.apache.org/jira/browse/QPID-8163
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 0001-QPID-8163.patch
>
>
> [http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
> The Broker-J's access-control-plugin currently has no way to express rules 
> that apply to subject that owns an object.  For instance, it is impossible to 
> say that only a user can consume from any queue that he created.
> If the ACL system supported a pseudo subject {{OWNER}} (in additional to the 
> pseudo subject {{ALL}} it already supports), then it would be possible to 
> write such rules.
> {noformat}
> ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
> It is noted that currently the model does not a have notion of object 
> ownership (QPID-8162).  It does have an immutable {{createdBy}} attribute.  
> The first version of this feature will use {{createdBy}}.



--
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-8165) [Broker-J][WMC] Validation of configured object names is too restrictive in Web Management Console

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-8165:
-
Description: 
WMC only allows to create (or edit) configured objects with names consisting 
only from any mixture of digits, letters, and underscores. This restriction was 
added into Web Management Console to meet the requirements of AMQP 0-8 
protocol. The queue and exchange names in  domain definition are defined as  
name consisting only from digits, letters, and underscores.

{quote}
The queue name identifies the queue within the vhost.  Queue
names may consist of any mixture of digits, letters, and
underscores.
{quote}

{quote}
The exchange name is a client-selected string that identifies
  the exchange for publish methods.  Exchange names may consist
  of any mixture of digits, letters, and underscores.  Exchange
  names are scoped by the virtual host.
{quote}

However, in definitions of declare commands for queue and exchange  the AMQP 
0-8 specifies a regular expression for the names allowing more characters:
{code}
^[a-zA-Z0-9-_.:]*$
{code}
The same regular expression is defined in specifications for AMQP 0-9 and 0-9-1.

The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
match regular expression (as per documentation of connection open)
{code}
^[a-zA-Z0-9-_.:]*$
{code}

AMQP 0-10 allows more characters in queue name

{quote}
 Queue names must have a length
of between 1 and 255 characters inclusive, must start with a digit, 
letter or underscores
('_') character, and must be otherwise encoded in UTF-8.
{quote}

As a minimum, the Web Management Console should allow creation of queues, 
exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}. The virtual host names 
matching regular expression {{^[a-zA-Z0-9/-_]+$}} should be allowed . The names 
of other configured objects can be unrestricted. 

Alternatively, we can add some sort of AMQP compatibility modes to Web 
Management Console and management API when required level compatibility can be 
configured by the user and different validation rules can apply based on 
required compatibility.



  was:
WMC only allows to create (or edit) configured object with names consisting 
only from any mixture of digits, letters, and underscores. This restriction was 
added into Web Management Console to meet the requirements of AMQP 0-8 
protocol. The queue and exchange names in  domain definition are defined as  
name consisting only from digits, letters, and underscores.

{quote}
The queue name identifies the queue within the vhost.  Queue
names may consist of any mixture of digits, letters, and
underscores.
{quote}

{quote}
The exchange name is a client-selected string that identifies
  the exchange for publish methods.  Exchange names may consist
  of any mixture of digits, letters, and underscores.  Exchange
  names are scoped by the virtual host.
{quote}

However, in definitions of declare commands for queue and exchange  the AMQP 
0-8 specifies a regular expression for the names allowing more characters:
{code}
^[a-zA-Z0-9-_.:]*$
{code}
The same regular expression is defined in specifications for AMQP 0-9 and 0-9-1.

The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
match regular expression (as per documentation of connection open)
{code}
^[a-zA-Z0-9-_.:]*$
{code}

AMQP 0-10 allows more characters in queue name

{quote}
 Queue names must have a length
of between 1 and 255 characters inclusive, must start with a digit, 
letter or underscores
('_') character, and must be otherwise encoded in UTF-8.
{quote}

As a minimum, the Web Management Console should allow creation of queues, 
exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}, the virtual host names 
can be allowed matching regular expression {{^[a-zA-Z0-9/-_]+$}}. The names of 
other configured objects can be unrestricted. 

Alternatively, we can add some sort of AMQP compatibility modes to Web 
Management Console and management API when required level compatibility can be 
configured by the user and different validation rules can apply based on 
required compatibility.




> [Broker-J][WMC] Validation of configured object names is too restrictive in 
> Web Management Console
> --
>
> Key: QPID-8165
> URL: https://issues.apache.org/jira/browse/QPID-8165
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, 
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, 

[jira] [Updated] (QPID-8165) [Broker-J][WMC] Validation of configured object names is too restrictive in Web Management Console

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-8165:
-
Affects Version/s: qpid-java-6.1.6
   qpid-java-broker-7.0.3
   qpid-java-broker-7.0.2
   qpid-java-6.0
   qpid-java-6.0.1
   qpid-java-6.0.2
   qpid-java-6.0.3
   qpid-java-6.0.4
   qpid-java-6.0.5
   qpid-java-6.1
   qpid-java-6.0.6
   qpid-java-6.1.1
   qpid-java-6.1.2
   qpid-java-6.0.7
   qpid-java-6.1.3
   qpid-java-6.0.8
   qpid-java-6.1.4
   qpid-java-broker-7.0.0
   qpid-java-6.1.5
   qpid-java-broker-7.0.1

> [Broker-J][WMC] Validation of configured object names is too restrictive in 
> Web Management Console
> --
>
> Key: QPID-8165
> URL: https://issues.apache.org/jira/browse/QPID-8165
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, 
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0, 
> qpid-java-6.1.5, qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> WMC only allows to create (or edit) configured object with names consisting 
> only from any mixture of digits, letters, and underscores. This restriction 
> was added into Web Management Console to meet the requirements of AMQP 0-8 
> protocol. The queue and exchange names in  domain definition are defined as  
> name consisting only from digits, letters, and underscores.
> {quote}
> The queue name identifies the queue within the vhost.  Queue
> names may consist of any mixture of digits, letters, and
> underscores.
> {quote}
> {quote}
> The exchange name is a client-selected string that identifies
>   the exchange for publish methods.  Exchange names may consist
>   of any mixture of digits, letters, and underscores.  Exchange
>   names are scoped by the virtual host.
> {quote}
> However, in definitions of declare commands for queue and exchange  the AMQP 
> 0-8 specifies a regular expression for the names allowing more characters:
> {code}
> ^[a-zA-Z0-9-_.:]*$
> {code}
> The same regular expression is defined in specifications for AMQP 0-9 and 
> 0-9-1.
> The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
> match regular expression (as per documentation of connection open)
> {code}
> ^[a-zA-Z0-9-_.:]*$
> {code}
> AMQP 0-10 allows more characters in queue name
> {quote}
>  Queue names must have a length
> of between 1 and 255 characters inclusive, must start with a digit, 
> letter or underscores
> ('_') character, and must be otherwise encoded in UTF-8.
> {quote}
> As a minimum, the Web Management Console should allow creation of queues, 
> exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}, the virtual host names 
> can be allowed matching regular expression {{^[a-zA-Z0-9/-_]+$}}. The names 
> of other configured objects can be unrestricted. 
> Alternatively, we can add some sort of AMQP compatibility modes to Web 
> Management Console and management API when required level compatibility can 
> be configured by the user and different validation rules can apply based on 
> required compatibility.



--
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-8165) [Broker-J][WMC] Validation of configured object names is too restrictive in Web Management Console

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-8165:
-
Fix Version/s: qpid-java-broker-7.0.4
   qpid-java-broker-7.1.0

> [Broker-J][WMC] Validation of configured object names is too restrictive in 
> Web Management Console
> --
>
> Key: QPID-8165
> URL: https://issues.apache.org/jira/browse/QPID-8165
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>
>
> WMC only allows to create (or edit) configured object with names consisting 
> only from any mixture of digits, letters, and underscores. This restriction 
> was added into Web Management Console to meet the requirements of AMQP 0-8 
> protocol. The queue and exchange names in  domain definition are defined as  
> name consisting only from digits, letters, and underscores.
> {quote}
> The queue name identifies the queue within the vhost.  Queue
> names may consist of any mixture of digits, letters, and
> underscores.
> {quote}
> {quote}
> The exchange name is a client-selected string that identifies
>   the exchange for publish methods.  Exchange names may consist
>   of any mixture of digits, letters, and underscores.  Exchange
>   names are scoped by the virtual host.
> {quote}
> However, in definitions of declare commands for queue and exchange  the AMQP 
> 0-8 specifies a regular expression for the names allowing more characters:
> {code}
> ^[a-zA-Z0-9-_.:]*$
> {code}
> The same regular expression is defined in specifications for AMQP 0-9 and 
> 0-9-1.
> The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
> match regular expression (as per documentation of connection open)
> {code}
> ^[a-zA-Z0-9-_.:]*$
> {code}
> AMQP 0-10 allows more characters in queue name
> {quote}
>  Queue names must have a length
> of between 1 and 255 characters inclusive, must start with a digit, 
> letter or underscores
> ('_') character, and must be otherwise encoded in UTF-8.
> {quote}
> As a minimum, the Web Management Console should allow creation of queues, 
> exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}, the virtual host names 
> can be allowed matching regular expression {{^[a-zA-Z0-9/-_]+$}}. The names 
> of other configured objects can be unrestricted. 
> Alternatively, we can add some sort of AMQP compatibility modes to Web 
> Management Console and management API when required level compatibility can 
> be configured by the user and different validation rules can apply based on 
> required compatibility.



--
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-8165) [Broker-J][WMC] Validation of configured object names is too restrictive in Web Management Console

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-8165:
-
Description: 
WMC only allows to create (or edit) configured object with names consisting 
only from any mixture of digits, letters, and underscores. This restriction was 
added into Web Management Console to meet the requirements of AMQP 0-8 
protocol. The queue and exchange names in  domain definition are defined as  
name consisting only from digits, letters, and underscores.

{quote}
The queue name identifies the queue within the vhost.  Queue
names may consist of any mixture of digits, letters, and
underscores.
{quote}

{quote}
The exchange name is a client-selected string that identifies
  the exchange for publish methods.  Exchange names may consist
  of any mixture of digits, letters, and underscores.  Exchange
  names are scoped by the virtual host.
{quote}

However, in definitions of declare commands for queue and exchange  the AMQP 
0-8 specifies a regular expression for the names allowing more characters:
{code}
^[a-zA-Z0-9-_.:]*$
{code}
The same regular expression is defined in specifications for AMQP 0-9 and 0-9-1.

The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
match regular expression (as per documentation of connection open)
{code}
^[a-zA-Z0-9-_.:]*$
{code}

AMQP 0-10 allows more characters in queue name

{quote}
 Queue names must have a length
of between 1 and 255 characters inclusive, must start with a digit, 
letter or underscores
('_') character, and must be otherwise encoded in UTF-8.
{quote}

As a minimum, the Web Management Console should allow creation of queues, 
exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}, the virtual host names 
can be allowed matching regular expression {{^[a-zA-Z0-9/-_]+$}}. The names of 
other configured objects can be unrestricted. 

Alternatively, we can add some sort of AMQP compatibility modes to Web 
Management Console and management API when required level compatibility can be 
configured by the user and different validation rules can apply based on 
required compatibility.



  was:
WMC only allows to create (or edit) configured object with names consisting 
only from any mixture of digits, letters, and underscores. This restriction was 
added into Web Management Console to meet the requirements of AMQP 0-8 
protocol. The queue and exchange names in  domain definition are defined as  
name consisting only from digits, letters, and underscores.

{quote}
The queue name identifies the queue within the vhost.  Queue
names may consist of any mixture of digits, letters, and
underscores.
{quote}

{quote}
The exchange name is a client-selected string that identifies
  the exchange for publish methods.  Exchange names may consist
  of any mixture of digits, letters, and underscores.  Exchange
  names are scoped by the virtual host.
{quote}

However, in definitions of declare commands for queue and exchange  the AMQP 
0-8 specifies a regular expression for the names allowing more characters:
{code}
^[a-zA-Z0-9-_.:]*$
{code}
The same regular expression is defined in specifications for AMQP 0-9 and 0-9-1.

AMQP 0-10 allows more characters in queue name

{quote}
 Queue names must have a length
of between 1 and 255 characters inclusive, must start with a digit, 
letter or underscores
('_') character, and must be otherwise encoded in UTF-8.
{quote}





> [Broker-J][WMC] Validation of configured object names is too restrictive in 
> Web Management Console
> --
>
> Key: QPID-8165
> URL: https://issues.apache.org/jira/browse/QPID-8165
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
>
> WMC only allows to create (or edit) configured object with names consisting 
> only from any mixture of digits, letters, and underscores. This restriction 
> was added into Web Management Console to meet the requirements of AMQP 0-8 
> protocol. The queue and exchange names in  domain definition are defined as  
> name consisting only from digits, letters, and underscores.
> {quote}
> The queue name identifies the queue within the vhost.  Queue
> names may consist of any mixture of digits, letters, and
> underscores.
> {quote}
> {quote}
> The exchange name is a client-selected string that identifies
>   the exchange for publish methods.  Exchange names may consist
>   of any mixture of digits, letters, and underscores.  Exchange
>   names are scoped by the virtual host.
> {quote}
> However, in definitions of declare commands for queue and exchange  the AMQP 
> 0-8 specifies a regular expression for the names allowing more characters:
> {code}

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

[Marcel Meulemans (JIRA)]

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

Marcel Meulemans updated DISPATCH-966:
--
Attachment: qdrouterd-unsettled-true.log
router-unsettled-true.dump

> 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
> 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-966) Qpid dispatch unstable inter-router connections

[Marcel Meulemans (JIRA)]

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

Marcel Meulemans commented on DISPATCH-966:
---

Added to the configuration and ran the test again several times. However now I 
see some things I did not expect; the network seems to come up correctly, but 
after a while it seems to fail in a weird way. The inter-router connections do 
not seems to drop anymore but routing via the network does not seem to work 
(i.e.ROUTER_LS (info) Computed next hops: {} and qdstat -n show only a single 
router). Maybe this is the issue unmasked by allowing unsettled multicasts?

I attached two more file:
 * the logs of router-0 (from router start until slightly after the network 
fails) at info level
 * a tcpdump to the inter router communication to an from router-0 (tcpdump -i 
eth0 tcp port 55672 -s 65535)

I hope this helps (the dump is fairly large, so I hope you can find any hidden 
needles).

-- 
Marcel

> 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
> 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] [Created] (QPID-8165) [Broker-J][WMC] Validation of configured object names is too restrictive in Web Management Console

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-8165:


 Summary: [Broker-J][WMC] Validation of configured object names is 
too restrictive in Web Management Console
 Key: QPID-8165
 URL: https://issues.apache.org/jira/browse/QPID-8165
 Project: Qpid
  Issue Type: Bug
  Components: Broker-J
Reporter: Alex Rudyy


WMC only allows to create (or edit) configured object with names consisting 
only from any mixture of digits, letters, and underscores. This restriction was 
added into Web Management Console to meet the requirements of AMQP 0-8 
protocol. The queue and exchange names in  domain definition are defined as  
name consisting only from digits, letters, and underscores.

{quote}
The queue name identifies the queue within the vhost.  Queue
names may consist of any mixture of digits, letters, and
underscores.
{quote}

{quote}
The exchange name is a client-selected string that identifies
  the exchange for publish methods.  Exchange names may consist
  of any mixture of digits, letters, and underscores.  Exchange
  names are scoped by the virtual host.
{quote}

However, in definitions of declare commands for queue and exchange  the AMQP 
0-8 specifies a regular expression for the names allowing more characters:
{code}
^[a-zA-Z0-9-_.:]*$
{code}
The same regular expression is defined in specifications for AMQP 0-9 and 0-9-1.

AMQP 0-10 allows more characters in queue name

{quote}
 Queue names must have a length
of between 1 and 255 characters inclusive, must start with a digit, 
letter or underscores
('_') character, and must be otherwise encoded in UTF-8.
{quote}






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