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

2018-04-18 Thread Matthieu Simonin (JIRA) 

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

Matthieu Simonin commented on DISPATCH-957:
---

I've added the file mem_usage_idle_25_min.tar.gz

* The test ended at around 21:40
* I've qdstat-ed router1 25 minutes later
* in router1.log it seems that links get freed approx. from 21:55 
* I did't observe any decrease in the RSS memory of router1 (130MB vs 50MB for 
router0)

> 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, mem_usage_idle_25_min.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

2018-04-18 Thread 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: mem_usage_idle_25_min.tar.gz

> 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, mem_usage_idle_25_min.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] (QPID-8164) [Broker-J] [AMQP 1.0] [BINDMAP] Dynamic nodes created with the temporary-queue capability do not enforce connection exclusivity

2018-04-18 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy updated QPID-8164:
-
Attachment: 0001-QPID-8164-Make-sure-that-only-own-connection-consume.patch

> [Broker-J] [AMQP 1.0] [BINDMAP] Dynamic nodes created with the 
> temporary-queue capability do not enforce connection exclusivity
> ---
>
> Key: QPID-8164
> URL: https://issues.apache.org/jira/browse/QPID-8164
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Attachments: 
> 0001-QPID-8164-Make-sure-that-only-own-connection-consume.patch
>
>
> The JMS 2.0 specification, 6.2.2 Creating temporary destinations, says:
> {quote}Temporary destinations (TemporaryQueue or TemporaryTopic objects) are 
> destinations that are system-generated uniquely for their connection. Only 
> their own connection is allowed to create consumer objects for them.
> {quote}
> Currently when the Qpid JMS Client is used with Broker-J, the last sentence 
> whilst being enforced by the client is not enforced by the *Broker*.  This 
> means that if the temporary destination were to be passed to another party - 
> say as a JMSReplyTo, that client would be able to create a consumer, 
> violating the JMS specification.
> I think Broker-J ought to be detecting the terminus capability 
> {{temporary-queue}} specified by amqp-bindmap-jms-v1.0-wd09 and then applying 
> the correct queue exclusivity policy.
>  I think the same problem may apply to the temporary-topics too (but not 
> confirmed)
>  
>  



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

2018-04-18 Thread Ken Giusti (JIRA) 

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

Ken Giusti edited comment on DISPATCH-957 at 4/18/18 8:08 PM:
--

Thanks for the logs, they are quite revealing.

I don't think this is a router bug.  I think it's a client issue.

Taking a look at router1.log I see the following:

Periodically a client connects every 30 seconds, but seems to clean up its 
links.  I'm confident that's your status collector.   Ignoring that I see:

1) 19:59:23ish - Servers begin to connection.  4 links are created for each 
connection - this is expected for RPC servers
2) 19:58:08ish - Servers done connecting
3) 19:59:23ish - a "link storm" hits - a couple thousand links are established 
in less than 2 seconds.  
4) 20:01:07 - links storm over.  All links remain up for the rest of the log.

So here's what I think is happening:

After the servers finish connecting the test starts the RPC clients start 
making RPC calls.  Each client has created a read link for receiving the RPC 
reply.  Obviously each client has its own unique reply-to address.

Once the server receives and processes a request it then sends a reply to the 
reply-to address.  This means that the server is going to create a unique 
reply-to link for each client it received a request from.  That's a where all 
the links are coming from.

IIRC, the oslo.messaging driver has a periodic task that expires these reply-to 
links after they've been idle for > 600 seconds.  Once the test is over would 
it be possible to not disturb the servers for > 600 seconds, then get a qdstat 
-a from router1?   I suspect the number of in-use qdr_link_t's will drop after 
these links are cleaned up.



was (Author: kgiusti):
Thanks for the logs, they are quite revealing.

I don't think this is a router bug.  I think it's a client issue.

Taking a look at router1.log I see the following:

Periodically a client connects every 30 seconds, but seems to clean up its 
links.  I'm confident that's your status collector.   Ignoring that I see:

1) 19:59:23ish - Servers begin to connection.  4 links are created for each 
connection - this is expected for RPC servers
2) 19:58:08ish - Servers done connecting
3) 19:59:23ish - a "link storm" hits - a couple thousand links are established 
in less than 2 seconds.  
4) 20:01:07 - links storm over.  All links remain up for the rest of the log.

So here's what I think is happening:

After the servers finish connecting the test starts are the RPC clients start 
making RPC calls.  Each client has created a read link for receiving the RPC 
reply.  Obviously each client has its own unique reply-to address.

Once the server receives and processes a request it then sends a reply to the 
reply-to address.  This means that the server is going to create a unique 
reply-to link for each client it received a request from.  That's a where all 
the links are coming from.

IIRC, the oslo.messaging driver has a periodic task that expires these reply-to 
links after they've been idle for > 600 seconds.  Once the test is over would 
it be possible to not disturb the servers for > 600 seconds, then get a qdstat 
-a from router1?   I suspect the number of in-use qdr_link_t's will drop after 
these links are cleaned up.


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

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

2018-04-18 Thread Ken Giusti (JIRA) 

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

Ken Giusti commented on DISPATCH-957:
-

Thanks for the logs, they are quite revealing.

I don't think this is a router bug.  I think it's a client issue.

Taking a look at router1.log I see the following:

Periodically a client connects every 30 seconds, but seems to clean up its 
links.  I'm confident that's your status collector.   Ignoring that I see:

1) 19:59:23ish - Servers begin to connection.  4 links are created for each 
connection - this is expected for RPC servers
2) 19:58:08ish - Servers done connecting
3) 19:59:23ish - a "link storm" hits - a couple thousand links are established 
in less than 2 seconds.  
4) 20:01:07 - links storm over.  All links remain up for the rest of the log.

So here's what I think is happening:

After the servers finish connecting the test starts are the RPC clients start 
making RPC calls.  Each client has created a read link for receiving the RPC 
reply.  Obviously each client has its own unique reply-to address.

Once the server receives and processes a request it then sends a reply to the 
reply-to address.  This means that the server is going to create a unique 
reply-to link for each client it received a request from.  That's a where all 
the links are coming from.

IIRC, the oslo.messaging driver has a periodic task that expires these reply-to 
links after they've been idle for > 600 seconds.  Once the test is over would 
it be possible to not disturb the servers for > 600 seconds, then get a qdstat 
-a from router1?   I suspect the number of in-use qdr_link_t's will drop after 
these links are cleaned up.


> 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

Fwd: REMINDER - TAC Applications closes in 2 weeks for ACNA Montréal

2018-04-18 Thread Robbie Gemmell 
FYI

-- Forwarded message --
From: Gavin McDonald
Date: 18 April 2018 at 01:40

Reminder that travel assistance applications for ApacheCon NA 2018 are
still open but only for another 2 weeks!
Please get your applications in NOW.

We will be supporting ApacheCon NA Montréal, Canada on 24th - 29th
September 2018

 TAC exists to help those that would like to attend ApacheCon events,
but are unable to do so for financial reasons.
For more info on this years applications and qualifying criteria,
please visit the TAC website at < http://www.apache.org/travel/
 >. Applications are now open and will
close 1st May.

Important: Applications close on May 1st, 2018. Applicants have until
the closing date above to submit their applications (which should
contain as much supporting material as required to efficiently and
accurately process their request), this will enable TAC to announce
successful awards shortly afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds. We therefore encourage (as always)
anyone thinking about sending in an application to do so ASAP.
We look forward to greeting many of you in Montreal

Kind Regards,
Gavin - (On behalf of the Travel Assistance Committee)

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

[jira] [Resolved] (DISPATCH-970) Add a chord view of message flow to console

2018-04-18 Thread Ernest Allen (JIRA) 

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

Ernest Allen resolved DISPATCH-970.
---
   Resolution: Implemented
Fix Version/s: 1.2.0

> Add a chord view of message flow to console
> ---
>
> Key: DISPATCH-970
> URL: https://issues.apache.org/jira/browse/DISPATCH-970
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Console
>Affects Versions: 1.2.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.2.0
>
>
> Add a chord diagram to the console. This should show message flow between 
> routers and have the following features:
>  * ability to show either messages rates or total messages
>  * ability to break down message flow by address
>  * ability to filter addresses
>  * mouseover text to show details
>  * smooth (animated) transitions when the values change
>  



--
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-970) Add a chord view of message flow to console

2018-04-18 Thread ASF subversion and git services (JIRA) 

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

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

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

DISPATCH-970 Added Message flow page to console


> Add a chord view of message flow to console
> ---
>
> Key: DISPATCH-970
> URL: https://issues.apache.org/jira/browse/DISPATCH-970
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Console
>Affects Versions: 1.2.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> Add a chord diagram to the console. This should show message flow between 
> routers and have the following features:
>  * ability to show either messages rates or total messages
>  * ability to break down message flow by address
>  * ability to filter addresses
>  * mouseover text to show details
>  * smooth (animated) transitions when the values change
>  



--
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-970) Add a chord view of message flow to console

2018-04-18 Thread Ernest Allen (JIRA) 
Ernest Allen created DISPATCH-970:
-

 Summary: Add a chord view of message flow to console
 Key: DISPATCH-970
 URL: https://issues.apache.org/jira/browse/DISPATCH-970
 Project: Qpid Dispatch
  Issue Type: New Feature
  Components: Console
Affects Versions: 1.2.0
Reporter: Ernest Allen
Assignee: Ernest Allen


Add a chord diagram to the console. This should show message flow between 
routers and have the following features:
 * ability to show either messages rates or total messages
 * ability to break down message flow by address
 * ability to filter addresses
 * mouseover text to show details
 * smooth (animated) transitions when the values change

 



--
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-969) Dropdown menu doesn't work when browser is narrow

2018-04-18 Thread Ernest Allen (JIRA) 

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

Ernest Allen resolved DISPATCH-969.
---
   Resolution: Fixed
Fix Version/s: 1.2.0

> Dropdown menu doesn't work when browser is narrow
> -
>
> Key: DISPATCH-969
> URL: https://issues.apache.org/jira/browse/DISPATCH-969
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.8.0, 0.8.1, 1.0.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.2.0
>
>
> When the browser window is narrow, the top level menu will disappear and be 
> replaced by a menu button in the uppper right hand corner.
> Clicking on that button should show a dropdown menu with the same items as 
> the top level menu, but it doesn't.



--
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] [Assigned] (PROTON-1831) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-04-18 Thread Alan Conway (JIRA) 

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

Alan Conway reassigned PROTON-1831:
---

Assignee: Alan Conway

> [C++ binding] Nested complex types fail compilation with "incomplete type" 
> error
> 
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Assignee: Alan Conway
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
> ‘proton::internal::type_id_of >’ used 
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of::value);
> ~~^~~
> {noformat}
>  



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

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

[jira] [Updated] (PROTON-1831) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-04-18 Thread Kim van der Riet (JIRA) 

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

Kim van der Riet updated PROTON-1831:
-
Description: 
When using nested complex types (for example, a list of maps or an array of 
lists), the compiler fails to compile. For example, the following code snippet 
(saved as {{ctt.cpp}}):
{noformat}
#include 
#include 
#include 

int main(int, char**) {
std::map m1 = {{uint8_t(0), "zero"}, 
{uint8_t(1), "one"}};
std::map m2 = {{true, "true"}, {false, 
"false"}};
std::vector > am = {m1, m2};
proton::value pv = am;
}{noformat}
fails compilation with the following error:
{noformat}
In file included from install/include/proton/types.hpp:47:0,
from ctt.cpp:3:
install/include/proton/./codec/vector.hpp: In instantiation of 
‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
const std::vector<_Tp, _Alloc>&) [with T = std::map; A = std::allocator >]’:
install/include/proton/./value.hpp:84:11: required from ‘typename 
proton::value::assignable::type 
proton::value::operator=(const T&) [with T = 
std::vector >; typename 
proton::value::assignable::type = proton::value&]’
install/include/proton/./value.hpp:79:85: required from 
‘proton::value::value(const T&, typename proton::value::assignable::type*) 
[with T = std::vector >; typename 
proton::value::assignable::type = void]’
ctt.cpp:9:24: required from here
install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
‘proton::internal::type_id_of >’ used in 
nested name specifier
return e << encoder::array(x, internal::type_id_of::value);
~~^~~
{noformat}
 

  was:
When using nested complex types (for example, a list of maps or an array of 
lists), the compiler fails to compile. For example, the following code snippet 
(saved as {{ctt.cpp}}):
{noformat}
#include 
#include 
#include 

int main(int, char**) {
std::map m1 = {{uint8_t(0), "zero"}, {uint8_t(1), 
"one"}};
std::map m2 = {{true, "true"}, {false, "false"}};
std::vector > am = {m1, m2};
proton::value pv = am;
}{noformat}
fails compilation with the following error:
{noformat}
In file included from install/include/proton/types.hpp:47:0,
from ctt.cpp:3:
install/include/proton/./codec/vector.hpp: In instantiation of 
‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
const std::vector<_Tp, _Alloc>&) [with T = std::map; A = std::allocator >]’:
install/include/proton/./value.hpp:84:11: required from ‘typename 
proton::value::assignable::type 
proton::value::operator=(const T&) [with T = 
std::vector >; typename 
proton::value::assignable::type = proton::value&]’
install/include/proton/./value.hpp:79:85: required from 
‘proton::value::value(const T&, typename proton::value::assignable::type*) 
[with T = std::vector >; typename 
proton::value::assignable::type = void]’
ctt.cpp:9:24: required from here
install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
‘proton::internal::type_id_of >’ used in 
nested name specifier
return e << encoder::array(x, internal::type_id_of::value);
~~^~~
{noformat}
 


> [C++ binding] Nested complex types fail compilation with "incomplete type" 
> error
> 
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Reporter: Kim van der Riet
>Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of 
> lists), the compiler fails to compile. For example, the following code 
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include 
> #include 
> #include 
> int main(int, char**) {
> std::map m1 = {{uint8_t(0), "zero"}, 
> {uint8_t(1), "one"}};
> std::map m2 = {{true, "true"}, {false, 
> "false"}};
> std::vector > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of 
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
> const std::vector<_Tp, _Alloc>&) [with T = std::map proton::value>; A = std::allocator >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename 
> proton::value::assignable::type 
> proton::value::operator=(const T&) [with T = 
> std::vector >; typename 
> proton::value::assignable::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from 
> ‘proton::value::value(const T&, typename proton::value::assignable::type*) 
> [with T = std::vector >; typename 
> proton::value::assignable:

[jira] [Created] (PROTON-1831) [C++ binding] Nested complex types fail compilation with "incomplete type" error

2018-04-18 Thread Kim van der Riet (JIRA) 
Kim van der Riet created PROTON-1831:


 Summary: [C++ binding] Nested complex types fail compilation with 
"incomplete type" error
 Key: PROTON-1831
 URL: https://issues.apache.org/jira/browse/PROTON-1831
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Reporter: Kim van der Riet


When using nested complex types (for example, a list of maps or an array of 
lists), the compiler fails to compile. For example, the following code snippet 
(saved as {{ctt.cpp}}):
{noformat}
#include 
#include 
#include 

int main(int, char**) {
std::map m1 = {{uint8_t(0), "zero"}, {uint8_t(1), 
"one"}};
std::map m2 = {{true, "true"}, {false, "false"}};
std::vector > am = {m1, m2};
proton::value pv = am;
}{noformat}
fails compilation with the following error:
{noformat}
In file included from install/include/proton/types.hpp:47:0,
from ctt.cpp:3:
install/include/proton/./codec/vector.hpp: In instantiation of 
‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&, 
const std::vector<_Tp, _Alloc>&) [with T = std::map; A = std::allocator >]’:
install/include/proton/./value.hpp:84:11: required from ‘typename 
proton::value::assignable::type 
proton::value::operator=(const T&) [with T = 
std::vector >; typename 
proton::value::assignable::type = proton::value&]’
install/include/proton/./value.hpp:79:85: required from 
‘proton::value::value(const T&, typename proton::value::assignable::type*) 
[with T = std::vector >; typename 
proton::value::assignable::type = void]’
ctt.cpp:9:24: required from here
install/include/proton/./codec/vector.hpp:39:31: error: incomplete type 
‘proton::internal::type_id_of >’ used in 
nested name specifier
return e << encoder::array(x, internal::type_id_of::value);
~~^~~
{noformat}
 



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

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

[jira] [Commented] (DISPATCH-969) Dropdown menu doesn't work when browser is narrow

2018-04-18 Thread ASF subversion and git services (JIRA) 

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

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

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

DISPATCH-969 Add bootstrap 3.3.7 for automatic dropdown menu support


> Dropdown menu doesn't work when browser is narrow
> -
>
> Key: DISPATCH-969
> URL: https://issues.apache.org/jira/browse/DISPATCH-969
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 0.8.0, 0.8.1, 1.0.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> When the browser window is narrow, the top level menu will disappear and be 
> replaced by a menu button in the uppper right hand corner.
> Clicking on that button should show a dropdown menu with the same items as 
> the top level menu, but it doesn't.



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

2018-04-18 Thread ASF subversion and git services (JIRA) 

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

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

Commit 663365dd715f4241848804ca1022f031765c5d98 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=663365d ]

PROTON-1672: fix issue with sending offset and/or partial content 
ReadableBuffer, plus additional arrayOffset tests


> 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] (DISPATCH-969) Dropdown menu doesn't work when browser is narrow

2018-04-18 Thread Ernest Allen (JIRA) 
Ernest Allen created DISPATCH-969:
-

 Summary: Dropdown menu doesn't work when browser is narrow
 Key: DISPATCH-969
 URL: https://issues.apache.org/jira/browse/DISPATCH-969
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.0.1, 0.8.1, 0.8.0
Reporter: Ernest Allen
Assignee: Ernest Allen


When the browser window is narrow, the top level menu will disappear and be 
replaced by a menu button in the uppper right hand corner.

Clicking on that button should show a dropdown menu with the same items as the 
top level menu, but it doesn't.



--
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 #288: Refactor cmake to use modern feature

2018-04-18 Thread matlo607 
GitHub user matlo607 opened a pull request:

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

Refactor cmake to use modern feature

I wanted to create a recipe for [Conan](https://www.conan.io/) and I 
experienced some issue with the build system.

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

$ git pull https://github.com/matlo607/qpid-dispatch 
cmake-refactor-compiler-flags

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

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


commit 1a8e023fffe3bb6b6d130d96f2c03238af67d2a3
Author: Matthieu Longo 
Date:   2018-04-13T10:33:15Z

[cmake] fix indent

commit f6ac7e63891d188d507bba31efdb71fe21e1ade1
Author: Matthieu Longo 
Date:   2018-04-13T10:12:47Z

[cmake] change build scripts to use features from modern CMake 3.+




---

-
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

2018-04-18 Thread ASF subversion and git services (JIRA) 

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

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

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

PROTON-1672 Fix CompositeReadableBuffer arrayOffset

The arrayOffset should return a fixed position based on the state of the
buffer (slices will normally have a non-zero value)

> 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] [Resolved] (PROTON-1827) [c test] c-connection-driver-tests fail on windows

2018-04-18 Thread Chuck Rolke (JIRA) 

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

Chuck Rolke resolved PROTON-1827.
-
   Resolution: Fixed
Fix Version/s: proton-c-0.23.0

Fixed at commit a80d54e

 

> [c test] c-connection-driver-tests fail on windows
> --
>
> Key: PROTON-1827
> URL: https://issues.apache.org/jira/browse/PROTON-1827
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c
>Affects Versions: proton-c-0.23.0
>Reporter: Chuck Rolke
>Priority: Major
> Fix For: proton-c-0.23.0
>
>
> A new self test related to PROTON-1809 fails hard.
> {{10: ..\..\..\c\tests\connection_driver.c:438: check failed: 'session 
> capacity 1234 is less than frame size 12345' not in 'session capacity 1234 is 
> less than frame size 140707423596601 (connection aborted)' 
> [test_session_flow_control(&t)]}}
> {{ 10: FAIL: test_session_flow_control(&t) (1 errors)}}
> {{ 10/27 Test #10: c-connection-driver-tests ***Failed 0.08 sec}}
> The large frame size number varies from run to run but is always in the 
> region of 10^14.



--
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-955) Assure console works with updated schema attribute names

2018-04-18 Thread Ernest Allen (JIRA) 

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

Ernest Allen resolved DISPATCH-955.
---
Resolution: Fixed

Generated new schema from qdmanage and verified it works with the console 
config and console test utilities.

> Assure console works with updated schema attribute names 
> -
>
> Key: DISPATCH-955
> URL: https://issues.apache.org/jira/browse/DISPATCH-955
> Project: Qpid Dispatch
>  Issue Type: Task
>  Components: Console
>Affects Versions: 1.0.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.1.0
>
>
> Per #DISPATCH-918, the schema has been updated.
> Assure that the console works with the changes.
> Also, regenerate the schema.json files in the console/test and console/config 
> directories and ensure those tools work.



--
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-955) Assure console works with updated schema attribute names

2018-04-18 Thread ASF subversion and git services (JIRA) 

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

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

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

DISPATCH-955 Recreated new schema for config and console test utilities


> Assure console works with updated schema attribute names 
> -
>
> Key: DISPATCH-955
> URL: https://issues.apache.org/jira/browse/DISPATCH-955
> Project: Qpid Dispatch
>  Issue Type: Task
>  Components: Console
>Affects Versions: 1.0.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.1.0
>
>
> Per #DISPATCH-918, the schema has been updated.
> Assure that the console works with the changes.
> Also, regenerate the schema.json files in the console/test and console/config 
> directories and ensure those tools work.



--
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-955) Assure console works with updated schema attribute names

2018-04-18 Thread Ganesh Murthy (JIRA) 

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

Ganesh Murthy updated DISPATCH-955:
---
Fix Version/s: 1.1.0

> Assure console works with updated schema attribute names 
> -
>
> Key: DISPATCH-955
> URL: https://issues.apache.org/jira/browse/DISPATCH-955
> Project: Qpid Dispatch
>  Issue Type: Task
>  Components: Console
>Affects Versions: 1.0.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.1.0
>
>
> Per #DISPATCH-918, the schema has been updated.
> Assure that the console works with the changes.
> Also, regenerate the schema.json files in the console/test and console/config 
> directories and ensure those tools work.



--
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] [Assigned] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn

2018-04-18 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy reassigned QPID-8135:


Assignee: Keith Wall  (was: Alex Rudyy)

> [JMS AMQP 0-x] Connection URL options for end-to-end encryption 
> keystore/trustore passwords can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'
> ---
>
> Key: QPID-8135
> URL: https://issues.apache.org/jira/browse/QPID-8135
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> The connection URL password options can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'.
> The following cases are identified when password is logged
>  # when encryption keystore/trustore parameters are declared as part of 
> broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower 
> threshold and connectivity is not established, the 
> encryption_key_store_password or encryption_trust_store_password can be 
> logged with info log level as below
> {noformat}
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.c.AMQConnection Unable to connect 
> to broker at 
> tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'&encryption_trust_store_password='password'
> org.apache.qpid.transport.TransportException: Error connecting to broker
>   at 
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> ...
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers  
> Checking failoverAllowed() 
> 2018-03-16 12:56:02,197 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers 
> Cycle Servers:
> Cycle Retries:20
> Current Cycle:20
> Server Retries:0
> Current Retry:0
> Current Broker:0
> >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'&encryption_trust_store_password='password'
> {noformat}
> # when encryption keystore/trustore parameters  or/and SSL trust store  
> parameters or/and SSL client-auth parameters are declared as part of 
> connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or 
> lower threshold, the password options can be logged with DEBUG log level as 
> below:
> {noformat}
> 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection 
> Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'&trust_store='/path/to/trsustore.ts'&key_store_password='secret'&encryption_trust_store_password='password'&key_store='/path/to/keystore.ks'&trust_store_password='secret'&brokerlist='tcp://localhost:5672'&failover='roundrobin?cyclecount='20''
> {noformat}
> The work around for the issue would be to set debug log level to warn at 
> least for the following loggers:
> * org.apache.qpid.client.AMQConnection
> * org.apache.qpid.jms.failover.FailoverRoundRobinServers



--
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] [Assigned] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn

2018-04-18 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy reassigned QPID-8135:


Assignee: Alex Rudyy  (was: Keith Wall)

> [JMS AMQP 0-x] Connection URL options for end-to-end encryption 
> keystore/trustore passwords can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'
> ---
>
> Key: QPID-8135
> URL: https://issues.apache.org/jira/browse/QPID-8135
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> The connection URL password options can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'.
> The following cases are identified when password is logged
>  # when encryption keystore/trustore parameters are declared as part of 
> broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower 
> threshold and connectivity is not established, the 
> encryption_key_store_password or encryption_trust_store_password can be 
> logged with info log level as below
> {noformat}
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.c.AMQConnection Unable to connect 
> to broker at 
> tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'&encryption_trust_store_password='password'
> org.apache.qpid.transport.TransportException: Error connecting to broker
>   at 
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> ...
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers  
> Checking failoverAllowed() 
> 2018-03-16 12:56:02,197 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers 
> Cycle Servers:
> Cycle Retries:20
> Current Cycle:20
> Server Retries:0
> Current Retry:0
> Current Broker:0
> >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'&encryption_trust_store_password='password'
> {noformat}
> # when encryption keystore/trustore parameters  or/and SSL trust store  
> parameters or/and SSL client-auth parameters are declared as part of 
> connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or 
> lower threshold, the password options can be logged with DEBUG log level as 
> below:
> {noformat}
> 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection 
> Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'&trust_store='/path/to/trsustore.ts'&key_store_password='secret'&encryption_trust_store_password='password'&key_store='/path/to/keystore.ks'&trust_store_password='secret'&brokerlist='tcp://localhost:5672'&failover='roundrobin?cyclecount='20''
> {noformat}
> The work around for the issue would be to set debug log level to warn at 
> least for the following loggers:
> * org.apache.qpid.client.AMQConnection
> * org.apache.qpid.jms.failover.FailoverRoundRobinServers



--
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] [Reopened] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn

2018-04-18 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy reopened QPID-8135:
--

> [JMS AMQP 0-x] Connection URL options for end-to-end encryption 
> keystore/trustore passwords can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'
> ---
>
> Key: QPID-8135
> URL: https://issues.apache.org/jira/browse/QPID-8135
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> The connection URL password options can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'.
> The following cases are identified when password is logged
>  # when encryption keystore/trustore parameters are declared as part of 
> broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower 
> threshold and connectivity is not established, the 
> encryption_key_store_password or encryption_trust_store_password can be 
> logged with info log level as below
> {noformat}
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.c.AMQConnection Unable to connect 
> to broker at 
> tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'&encryption_trust_store_password='password'
> org.apache.qpid.transport.TransportException: Error connecting to broker
>   at 
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> ...
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers  
> Checking failoverAllowed() 
> 2018-03-16 12:56:02,197 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers 
> Cycle Servers:
> Cycle Retries:20
> Current Cycle:20
> Server Retries:0
> Current Retry:0
> Current Broker:0
> >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'&encryption_trust_store_password='password'
> {noformat}
> # when encryption keystore/trustore parameters  or/and SSL trust store  
> parameters or/and SSL client-auth parameters are declared as part of 
> connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or 
> lower threshold, the password options can be logged with DEBUG log level as 
> below:
> {noformat}
> 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection 
> Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'&trust_store='/path/to/trsustore.ts'&key_store_password='secret'&encryption_trust_store_password='password'&key_store='/path/to/keystore.ks'&trust_store_password='secret'&brokerlist='tcp://localhost:5672'&failover='roundrobin?cyclecount='20''
> {noformat}
> The work around for the issue would be to set debug log level to warn at 
> least for the following loggers:
> * org.apache.qpid.client.AMQConnection
> * org.apache.qpid.jms.failover.FailoverRoundRobinServers



--
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-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn'

2018-04-18 Thread Alex Rudyy (JIRA) 

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

Alex Rudyy updated QPID-8135:
-
Status: Reviewable  (was: In Progress)

> [JMS AMQP 0-x] Connection URL options for end-to-end encryption 
> keystore/trustore passwords can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'
> ---
>
> Key: QPID-8135
> URL: https://issues.apache.org/jira/browse/QPID-8135
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> The connection URL password options can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'.
> The following cases are identified when password is logged
>  # when encryption keystore/trustore parameters are declared as part of 
> broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower 
> threshold and connectivity is not established, the 
> encryption_key_store_password or encryption_trust_store_password can be 
> logged with info log level as below
> {noformat}
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.c.AMQConnection Unable to connect 
> to broker at 
> tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'&encryption_trust_store_password='password'
> org.apache.qpid.transport.TransportException: Error connecting to broker
>   at 
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> ...
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers  
> Checking failoverAllowed() 
> 2018-03-16 12:56:02,197 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers 
> Cycle Servers:
> Cycle Retries:20
> Current Cycle:20
> Server Retries:0
> Current Retry:0
> Current Broker:0
> >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'&encryption_trust_store_password='password'
> {noformat}
> # when encryption keystore/trustore parameters  or/and SSL trust store  
> parameters or/and SSL client-auth parameters are declared as part of 
> connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or 
> lower threshold, the password options can be logged with DEBUG log level as 
> below:
> {noformat}
> 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection 
> Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'&trust_store='/path/to/trsustore.ts'&key_store_password='secret'&encryption_trust_store_password='password'&key_store='/path/to/keystore.ks'&trust_store_password='secret'&brokerlist='tcp://localhost:5672'&failover='roundrobin?cyclecount='20''
> {noformat}
> The work around for the issue would be to set debug log level to warn at 
> least for the following loggers:
> * org.apache.qpid.client.AMQConnection
> * org.apache.qpid.jms.failover.FailoverRoundRobinServers



--
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-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'war

2018-04-18 Thread ASF subversion and git services (JIRA) 

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

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

Commit bcb5f70fd8bc0f628c868cf30b30f2f2ca349295 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=bcb5f70 ]

QPID-8135: Mask connection URL password options


> [JMS AMQP 0-x] Connection URL options for end-to-end encryption 
> keystore/trustore passwords can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'
> ---
>
> Key: QPID-8135
> URL: https://issues.apache.org/jira/browse/QPID-8135
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> The connection URL password options can be logged when log level for 
> 'org.apache.qpid' loggers is lower than 'warn'.
> The following cases are identified when password is logged
>  # when encryption keystore/trustore parameters are declared as part of 
> broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower 
> threshold and connectivity is not established, the 
> encryption_key_store_password or encryption_trust_store_password can be 
> logged with info log level as below
> {noformat}
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.c.AMQConnection Unable to connect 
> to broker at 
> tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'&encryption_trust_store_password='password'
> org.apache.qpid.transport.TransportException: Error connecting to broker
>   at 
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> ...
> 2018-03-16 12:56:02,196 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers  
> Checking failoverAllowed() 
> 2018-03-16 12:56:02,197 INFO  [main] o.a.q.j.f.FailoverRoundRobinServers 
> Cycle Servers:
> Cycle Retries:20
> Current Cycle:20
> Server Retries:0
> Current Retry:0
> Current Broker:0
> >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'&encryption_trust_store_password='password'
> {noformat}
> # when encryption keystore/trustore parameters  or/and SSL trust store  
> parameters or/and SSL client-auth parameters are declared as part of 
> connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or 
> lower threshold, the password options can be logged with DEBUG log level as 
> below:
> {noformat}
> 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection 
> Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'&trust_store='/path/to/trsustore.ts'&key_store_password='secret'&encryption_trust_store_password='password'&key_store='/path/to/keystore.ks'&trust_store_password='secret'&brokerlist='tcp://localhost:5672'&failover='roundrobin?cyclecount='20''
> {noformat}
> The work around for the issue would be to set debug log level to warn at 
> least for the following loggers:
> * org.apache.qpid.client.AMQConnection
> * org.apache.qpid.jms.failover.FailoverRoundRobinServers



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