[jira] [Commented] (PROTON-1133) Proton C includes port number in AMQP Open hostname

[ASF subversion and git services (JIRA)]

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

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

Commit 8f27d0e735039e934a4fb4cc595f5b54ee794fc7 in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8f27d0e ]

PROTON-1133: windows fix for older compilers


> Proton C includes port number in AMQP Open hostname
> ---
>
> Key: PROTON-1133
> URL: https://issues.apache.org/jira/browse/PROTON-1133
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
>Assignee: Ken Giusti
> Fix For: 0.13.0
>
>
> A command like:
> {noformat}
> qdmanage -b amqp://u1:password@photoserver:21000 --type policyStats query
> {noformat}
> sends the port number in the hostname field of the AMQP Open:
> {noformat}
> Mon Feb  8 11:37:46 2016 SERVER (trace) [2]:0 <- @open(16) 
> [container-id="34e49947-b4df-4a01-9570-0a74e9e57b5b", 
> hostname="photoserver:21000", channel-max=32767] 
> (/home/chug/git/qpid-dispatch/src/server.c:75)
> {noformat}
> Built in C example code using Proton only does the same thing.
> This bug originally reported at 
> https://issues.apache.org/jira/browse/DISPATCH-214



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on QPID-7265:
--

Basic start, converted to docbook 5, added pom to build it (not hooked into 
main build yet), removed everything but the JMS section and address section, 
rearranged those a bit.

Still to do: perhaps some more tidyup, link fixups for it and the 0-8 book, 
looking into putting it on website (e.g release script changes).

> migrate the AMQP 0-10 JMS client docs out of the old combined doc book.
> ---
>
> Key: QPID-7265
> URL: https://issues.apache.org/jira/browse/QPID-7265
> Project: Qpid
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-java-6.1
>
>
> Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since 
> 0.32, despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its 
> because they are still part of the old 'Programming in Apache Qpid' book 
> along combined with the other older client docs.
> Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 
> client docs the qpid-java tree is challenging as there are a lot of areas the 
> two protocols differ in behaviour (which is the reason the two books exist).
> As per suggestion at \[1\], the quick and easy thing for now is to just pull 
> the JMS bits out of the 'programming' guide and migrate those into the 
> qpid-java tree, remainingg as a seperate book. This at least allows them to 
> be published with each new release and be updated if actually needed.
> Further consolidation and improvement can be done later as desired/time 
> allows.
> \[1\] 
> http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.

[ASF subversion and git services (JIRA)]

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

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

Commit 1743763 from [~gemmellr] in branch 'java/trunk'
[ https://svn.apache.org/r1743763 ]

QPID-7265: drop the addresses content in at end as a subsection of the 
'configuring' section

> migrate the AMQP 0-10 JMS client docs out of the old combined doc book.
> ---
>
> Key: QPID-7265
> URL: https://issues.apache.org/jira/browse/QPID-7265
> Project: Qpid
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-java-6.1
>
>
> Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since 
> 0.32, despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its 
> because they are still part of the old 'Programming in Apache Qpid' book 
> along combined with the other older client docs.
> Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 
> client docs the qpid-java tree is challenging as there are a lot of areas the 
> two protocols differ in behaviour (which is the reason the two books exist).
> As per suggestion at \[1\], the quick and easy thing for now is to just pull 
> the JMS bits out of the 'programming' guide and migrate those into the 
> qpid-java tree, remainingg as a seperate book. This at least allows them to 
> be published with each new release and be updated if actually needed.
> Further consolidation and improvement can be done later as desired/time 
> allows.
> \[1\] 
> http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.

[ASF subversion and git services (JIRA)]

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

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

Commit 1743762 from [~gemmellr] in branch 'java/trunk'
[ https://svn.apache.org/r1743762 ]

QPID-7265: remove the leftover addresses 'chapter' temporarily

> migrate the AMQP 0-10 JMS client docs out of the old combined doc book.
> ---
>
> Key: QPID-7265
> URL: https://issues.apache.org/jira/browse/QPID-7265
> Project: Qpid
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-java-6.1
>
>
> Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since 
> 0.32, despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its 
> because they are still part of the old 'Programming in Apache Qpid' book 
> along combined with the other older client docs.
> Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 
> client docs the qpid-java tree is challenging as there are a lot of areas the 
> two protocols differ in behaviour (which is the reason the two books exist).
> As per suggestion at \[1\], the quick and easy thing for now is to just pull 
> the JMS bits out of the 'programming' guide and migrate those into the 
> qpid-java tree, remainingg as a seperate book. This at least allows them to 
> be published with each new release and be updated if actually needed.
> Further consolidation and improvement can be done later as desired/time 
> allows.
> \[1\] 
> http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.

[ASF subversion and git services (JIRA)]

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

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

Commit 1743759 from [~gemmellr] in branch 'java/trunk'
[ https://svn.apache.org/r1743759 ]

QPID-7265: add existing 'programming' docbook source file, renamed only

> migrate the AMQP 0-10 JMS client docs out of the old combined doc book.
> ---
>
> Key: QPID-7265
> URL: https://issues.apache.org/jira/browse/QPID-7265
> Project: Qpid
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-java-6.1
>
>
> Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since 
> 0.32, despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its 
> because they are still part of the old 'Programming in Apache Qpid' book 
> along combined with the other older client docs.
> Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 
> client docs the qpid-java tree is challenging as there are a lot of areas the 
> two protocols differ in behaviour (which is the reason the two books exist).
> As per suggestion at \[1\], the quick and easy thing for now is to just pull 
> the JMS bits out of the 'programming' guide and migrate those into the 
> qpid-java tree, remainingg as a seperate book. This at least allows them to 
> be published with each new release and be updated if actually needed.
> Further consolidation and improvement can be done later as desired/time 
> allows.
> \[1\] 
> http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.

[ASF subversion and git services (JIRA)]

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

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

Commit 1743760 from [~gemmellr] in branch 'java/trunk'
[ https://svn.apache.org/r1743760 ]

QPID-7265: convert to docbook 5, tweak some more to get it building, add pom

> migrate the AMQP 0-10 JMS client docs out of the old combined doc book.
> ---
>
> Key: QPID-7265
> URL: https://issues.apache.org/jira/browse/QPID-7265
> Project: Qpid
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-java-6.1
>
>
> Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since 
> 0.32, despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its 
> because they are still part of the old 'Programming in Apache Qpid' book 
> along combined with the other older client docs.
> Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 
> client docs the qpid-java tree is challenging as there are a lot of areas the 
> two protocols differ in behaviour (which is the reason the two books exist).
> As per suggestion at \[1\], the quick and easy thing for now is to just pull 
> the JMS bits out of the 'programming' guide and migrate those into the 
> qpid-java tree, remainingg as a seperate book. This at least allows them to 
> be published with each new release and be updated if actually needed.
> Further consolidation and improvement can be done later as desired/time 
> allows.
> \[1\] 
> http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.

[ASF subversion and git services (JIRA)]

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

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

Commit 1743761 from [~gemmellr] in branch 'java/trunk'
[ https://svn.apache.org/r1743761 ]

QPID-7265: remove all the content not related to the JMS client

> migrate the AMQP 0-10 JMS client docs out of the old combined doc book.
> ---
>
> Key: QPID-7265
> URL: https://issues.apache.org/jira/browse/QPID-7265
> Project: Qpid
>  Issue Type: Task
>  Components: Documentation
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
> Fix For: qpid-java-6.1
>
>
> Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since 
> 0.32, despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its 
> because they are still part of the old 'Programming in Apache Qpid' book 
> along combined with the other older client docs.
> Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 
> client docs the qpid-java tree is challenging as there are a lot of areas the 
> two protocols differ in behaviour (which is the reason the two books exist).
> As per suggestion at \[1\], the quick and easy thing for now is to just pull 
> the JMS bits out of the 'programming' guide and migrate those into the 
> qpid-java tree, remainingg as a seperate book. This at least allows them to 
> be published with each new release and be updated if actually needed.
> Further consolidation and improvement can be done later as desired/time 
> allows.
> \[1\] 
> http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7265) migrate the AMQP 0-10 JMS client docs out of the old combined doc book.

[Robbie Gemmell (JIRA)]

Robbie Gemmell created QPID-7265:


 Summary: migrate the AMQP 0-10 JMS client docs out of the old 
combined doc book.
 Key: QPID-7265
 URL: https://issues.apache.org/jira/browse/QPID-7265
 Project: Qpid
  Issue Type: Task
  Components: Documentation
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
 Fix For: qpid-java-6.1


Jakub noted that the AMQP 0-10 JMS client docs havent been udpated since 0.32, 
despite the subsequent 6.0.x 'qpid-java' releases. Keith noted that its because 
they are still part of the old 'Programming in Apache Qpid' book along combined 
with the other older client docs.

Migrating the 0-10 client docs and consolidating them with the 0-8..0-91 client 
docs the qpid-java tree is challenging as there are a lot of areas the two 
protocols differ in behaviour (which is the reason the two books exist).

As per suggestion at \[1\], the quick and easy thing for now is to just pull 
the JMS bits out of the 'programming' guide and migrate those into the 
qpid-java tree, remainingg as a seperate book. This at least allows them to be 
published with each new release and be updated if actually needed.

Further consolidation and improvement can be done later as desired/time allows.

\[1\] 
http://mail-archives.apache.org/mod_mbox/qpid-users/201605.mbox/%3CCAFitrpQM4XO-Or822eVVCtBZtDNEM9hKSO-goqxruSksVc9EuQ%40mail.gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1133) Proton C includes port number in AMQP Open hostname

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1133: Policy for setting the virtual-host using the Reactor

The pn_connection_set_hostname() interface is used to set the
'hostname' field in the Open performative.  By definition this is the
'virtual host' and should not be used for the transport network address.

The network address for outgoing connections should be set
by using the reactor's pn_reactor_connection_to_host() factory, or the
pn_reactor_set_connection_host() when re-connecting to a different
host.

For inbound connections the peer address is provided by the acceptor
and cannot be modified.  In both cases, the
pn_reactor_get_connection_address() method can be used to obtain the
peer's network address.

By default if the application does not explicitly set the connection's
virtual host on an outbound connection Reactor will use the host
name/address from the network address.  Otherwise the virtual host is
sent as configured, with one exception: if the application sets the
virtual host to an empty string ("") then no virtual host will be sent
in the Open performative (e.g. disables the default behavior).

The Python Container now provides a virtual-host option for setting
the virtual host value via the connect() method.


> Proton C includes port number in AMQP Open hostname
> ---
>
> Key: PROTON-1133
> URL: https://issues.apache.org/jira/browse/PROTON-1133
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
>Assignee: Ken Giusti
> Fix For: 0.13.0
>
>
> A command like:
> {noformat}
> qdmanage -b amqp://u1:password@photoserver:21000 --type policyStats query
> {noformat}
> sends the port number in the hostname field of the AMQP Open:
> {noformat}
> Mon Feb  8 11:37:46 2016 SERVER (trace) [2]:0 <- @open(16) 
> [container-id="34e49947-b4df-4a01-9570-0a74e9e57b5b", 
> hostname="photoserver:21000", channel-max=32767] 
> (/home/chug/git/qpid-dispatch/src/server.c:75)
> {noformat}
> Built in C example code using Proton only does the same thing.
> This bug originally reported at 
> https://issues.apache.org/jira/browse/DISPATCH-214



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-dispatch pull request: DISPATCH-335 - Added code to balance l...

[ganeshmurthy]

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

https://github.com/apache/qpid-dispatch/pull/74#discussion_r63246808
  
--- Diff: src/router_core/forwarder.c ---
@@ -559,20 +559,34 @@ bool qdr_forward_link_balanced_CT(qdr_core_t 
*core,
 //
 // Look for a next-hop we can use to forward the link-attach.
 //
-int router_bit;
 qdr_node_t *next_node;
 
-if (qd_bitmask_first_set(addr->rnodes, _bit)) {
-qdr_node_t *rnode = core->routers_by_mask_bit[router_bit];
-if (rnode) {
-if (rnode->next_hop)
-next_node = rnode->next_hop;
-else
-next_node = rnode;
+if (addr->cost_epoch != core->cost_epoch) {
+addr->next_remote = -1;
+addr->cost_epoch  = core->cost_epoch;
+}
 
-if (next_node && next_node->peer_data_link)
-conn = next_node->peer_data_link->conn;
-}
+if (addr->next_remote < 0) {
+qd_bitmask_first_set(addr->rnodes, >next_remote);
--- End diff --

How about I check addr->next_remote >= 0 like below

qdr_node_t *next_node;

if (addr->cost_epoch != core->cost_epoch) {
addr->next_remote = -1;
addr->cost_epoch  = core->cost_epoch;
}

if (addr->next_remote < 0) {
qd_bitmask_first_set(addr->rnodes, >next_remote);
}

if (addr->next_remote >= 0) {

qdr_node_t *rnode = 
core->routers_by_mask_bit[addr->next_remote];

if (rnode) {
//
// Advance the addr->next_remote so there will be link 
balance across containers
//
_qdbm_next(addr->rnodes, >next_remote);
if (addr->next_remote == -1)
qd_bitmask_first_set(addr->rnodes, >next_remote);

if (rnode->next_hop)
next_node = rnode->next_hop;
else
next_node = rnode;

if (next_node && next_node->peer_data_link)
conn = next_node->peer_data_link->conn;
}
}


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (QPIDIT-32) Use Maven to build Java components

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on QPIDIT-32:
---

Commit 159efd475397f37f51327c078cb1ef9486063963 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=159efd4 ]

QPIDIT-32: Improvements to Maven pom.xml files from Robbie Gemmell.


> Use Maven to build Java components
> --
>
> Key: QPIDIT-32
> URL: https://issues.apache.org/jira/browse/QPIDIT-32
> Project: Apache QPID IT
>  Issue Type: Improvement
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
> Attachments: 0001-QPIDIT-32-misc-improvements-for-the-new-poms.patch
>
>
> Currently the Java components are built using copies of dependent jar files 
> in the jar directory and some simple bash scripts invoking javac and jar.
> Upgrade this so that dependency management and classpath management as well 
> as the java builds are more robustly maintained using Apache Maven (which is 
> a trend already established in other Qpid projects).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (DISPATCH-335) link routes aren't balanced over remote routers

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy edited comment on DISPATCH-335 at 5/13/16 8:21 PM:
-

After you pull down PR 74 (https://github.com/apache/qpid-dispatch/pull/74) and 
use the attached router config files (A.conf, B.conf and C.conf) you should see 
that the link routed messages are balanced over remote routers

gsim, please test when you get a chance.



was (Author: ganeshmurthy):
After you pull down PR 74 (https://github.com/apache/qpid-dispatch/pull/74) and 
use the attached router config files (A.conf, B.conf and C.conf) you should see 
that the link routed messages are balanced over remote routers


> link routes aren't balanced over remote routers
> ---
>
> Key: DISPATCH-335
> URL: https://issues.apache.org/jira/browse/DISPATCH-335
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Attachments: A.conf, B.conf, C.conf, linkroute_A.conf, 
> linkroute_B.conf, linkroute_C.conf
>
>
> Setup has three routers A, B and C with B and C both connected to A. I have a 
> linkRoute with the same prefix and dir on each of these. On B and C that 
> linkRoute has a connection referencing a connector to a broker (different 
> broker in each case).
> When I establish a link to A, it is always routed to the same broker. Only if 
> I kill that broker, will links be routed to the other broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] qpid-dispatch pull request: DISPATCH-335 - Added code to balance l...

[ted-ross]

Github user ted-ross commented on a diff in the pull request:

https://github.com/apache/qpid-dispatch/pull/74#discussion_r63245326
  
--- Diff: src/router_core/forwarder.c ---
@@ -559,20 +559,34 @@ bool qdr_forward_link_balanced_CT(qdr_core_t 
*core,
 //
 // Look for a next-hop we can use to forward the link-attach.
 //
-int router_bit;
 qdr_node_t *next_node;
 
-if (qd_bitmask_first_set(addr->rnodes, _bit)) {
-qdr_node_t *rnode = core->routers_by_mask_bit[router_bit];
-if (rnode) {
-if (rnode->next_hop)
-next_node = rnode->next_hop;
-else
-next_node = rnode;
+if (addr->cost_epoch != core->cost_epoch) {
+addr->next_remote = -1;
+addr->cost_epoch  = core->cost_epoch;
+}
 
-if (next_node && next_node->peer_data_link)
-conn = next_node->peer_data_link->conn;
-}
+if (addr->next_remote < 0) {
+qd_bitmask_first_set(addr->rnodes, >next_remote);
--- End diff --

You removed the check of the return value of qd_bitmask_first_set.  If 
there is no bit set in the mask, bad things will happen.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Updated] (DISPATCH-335) link routes aren't balanced over remote routers

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy updated DISPATCH-335:
---
Attachment: A.conf
B.conf
C.conf

> link routes aren't balanced over remote routers
> ---
>
> Key: DISPATCH-335
> URL: https://issues.apache.org/jira/browse/DISPATCH-335
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Attachments: A.conf, B.conf, C.conf, linkroute_A.conf, 
> linkroute_B.conf, linkroute_C.conf
>
>
> Setup has three routers A, B and C with B and C both connected to A. I have a 
> linkRoute with the same prefix and dir on each of these. On B and C that 
> linkRoute has a connection referencing a connector to a broker (different 
> broker in each case).
> When I establish a link to A, it is always routed to the same broker. Only if 
> I kill that broker, will links be routed to the other broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (DISPATCH-335) link routes aren't balanced over remote routers

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-335:


After you pull down PR 74 (https://github.com/apache/qpid-dispatch/pull/74) and 
use the attached router config files (A.conf, B.conf and C.conf) you should see 
that the link routed messages are balanced over remote routers


> link routes aren't balanced over remote routers
> ---
>
> Key: DISPATCH-335
> URL: https://issues.apache.org/jira/browse/DISPATCH-335
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Attachments: linkroute_A.conf, linkroute_B.conf, linkroute_C.conf
>
>
> Setup has three routers A, B and C with B and C both connected to A. I have a 
> linkRoute with the same prefix and dir on each of these. On B and C that 
> linkRoute has a connection referencing a connector to a broker (different 
> broker in each case).
> When I establish a link to A, it is always routed to the same broker. Only if 
> I kill that broker, will links be routed to the other broker.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPIDJMS-175) Add support for a timeout value for drain requests.

[ASF subversion and git services (JIRA)]

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

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

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

QPIDJMS-175 Add an initial bit of documentation for the drainTimeout
configuration.



> Add support for a timeout value for drain requests.
> ---
>
> Key: QPIDJMS-175
> URL: https://issues.apache.org/jira/browse/QPIDJMS-175
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.9.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.10.0
>
>
> Add an additional timeout value in the AMQP consumer to deal with a remote 
> that doesn't respond to a drain request.  The timeout handler should close 
> the MessageConsumer that is awaiting the drain with an exception since we 
> don't know what the remote state is following a lack of response to the 
> drain.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 47243: PROTON-1133: decouple the virtual host from the network address used by reactor

[Robbie Gemmell]

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



Looks good other than a couple niggles.


proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java (line 
310)


Try "this.port = port" rather than the trailing _. (or leading _ is used 
among much of the java code)



proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java (lines 
356 - 357)


We use camelCase for Java bits



tests/python/proton_tests/reactor.py (lines 612 - 614)


Perhaps a reason thats shorter/less alarming given it shows up on the 
console?

"Does not apply for proton-j" with a comment after to elaborate?


- Robbie Gemmell


On May 13, 2016, 7:21 p.m., Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47243/
> ---
> 
> (Updated May 13, 2016, 7:21 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Chug Rolke, Cliff Jansen, Justin Ross, 
> and Robbie Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> The pn_connection_set_hostname() interface is used to set the
> 'hostname' field in the Open performative.  By definition this is the
> 'virtual host' and should not be used by reactor for the network
> address.  The network address for outgoing connections should be set
> by using the reactor's pn_reactor_connection_to_host() factory, or the
> pn_reactor_set_connection_host() when re-connecting to a different
> host.  For inbound connections, the peer address is provided by the
> acceptor and cannot be modified.  In both cases, the
> pn_reactor_get_connection_address() method can be used to obtain the
> peer's network address.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/cpp/CMakeLists.txt 2aec4e2 
>   proton-c/bindings/cpp/include/proton/connection_options.hpp d736600 
>   proton-c/bindings/cpp/src/connection_options.cpp fed645c 
>   proton-c/bindings/cpp/src/connector.cpp dbf74be 
>   proton-c/bindings/cpp/src/container_impl.cpp a221f45 
>   proton-c/bindings/cpp/src/container_test.cpp PRE-CREATION 
>   proton-c/bindings/cpp/src/reactor.hpp 48d9ea1 
>   proton-c/bindings/cpp/src/reactor.cpp 9507d2b 
>   proton-c/bindings/python/proton/reactor.py 1631c35 
>   proton-c/include/proton/connection.h da20f94 
>   proton-c/include/proton/reactor.h be642a9 
>   proton-c/src/posix/io.c 3226594 
>   proton-c/src/reactor/acceptor.c 8f0e99b 
>   proton-c/src/reactor/connection.c 336d1f1 
>   proton-c/src/reactor/reactor.h f996dca 
>   proton-c/src/tests/reactor.c 9564569 
>   proton-c/src/windows/io.c 7ff928d 
>   
> proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ConnectionImpl.java 
> b708d83 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java a3307d2 
>   
> proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/AcceptorImpl.java 
> fb2f892 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java 
> 5a32824 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
> d13cfbe 
>   proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java 
> 4e92cd9 
>   tests/python/proton_tests/reactor.py 6ee107d 
> 
> Diff: https://reviews.apache.org/r/47243/diff/
> 
> 
> Testing
> ---
> 
> New unit tests added.
> 
> 
> Thanks,
> 
> Kenneth Giusti
> 
>

Re: Review Request 47243: PROTON-1133: decouple the virtual host from the network address used by reactor

[Kenneth Giusti]

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

(Updated May 13, 2016, 7:21 p.m.)


Review request for qpid, Alan Conway, Chug Rolke, Cliff Jansen, Justin Ross, 
and Robbie Gemmell.


Changes
---

camelCase for Java


Repository: qpid-proton-git


Description
---

The pn_connection_set_hostname() interface is used to set the
'hostname' field in the Open performative.  By definition this is the
'virtual host' and should not be used by reactor for the network
address.  The network address for outgoing connections should be set
by using the reactor's pn_reactor_connection_to_host() factory, or the
pn_reactor_set_connection_host() when re-connecting to a different
host.  For inbound connections, the peer address is provided by the
acceptor and cannot be modified.  In both cases, the
pn_reactor_get_connection_address() method can be used to obtain the
peer's network address.


Diffs (updated)
-

  proton-c/bindings/cpp/CMakeLists.txt 2aec4e2 
  proton-c/bindings/cpp/include/proton/connection_options.hpp d736600 
  proton-c/bindings/cpp/src/connection_options.cpp fed645c 
  proton-c/bindings/cpp/src/connector.cpp dbf74be 
  proton-c/bindings/cpp/src/container_impl.cpp a221f45 
  proton-c/bindings/cpp/src/container_test.cpp PRE-CREATION 
  proton-c/bindings/cpp/src/reactor.hpp 48d9ea1 
  proton-c/bindings/cpp/src/reactor.cpp 9507d2b 
  proton-c/bindings/python/proton/reactor.py 1631c35 
  proton-c/include/proton/connection.h da20f94 
  proton-c/include/proton/reactor.h be642a9 
  proton-c/src/posix/io.c 3226594 
  proton-c/src/reactor/acceptor.c 8f0e99b 
  proton-c/src/reactor/connection.c 336d1f1 
  proton-c/src/reactor/reactor.h f996dca 
  proton-c/src/tests/reactor.c 9564569 
  proton-c/src/windows/io.c 7ff928d 
  proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ConnectionImpl.java 
b708d83 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java a3307d2 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/AcceptorImpl.java 
fb2f892 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java 
5a32824 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
d13cfbe 
  proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java 
4e92cd9 
  tests/python/proton_tests/reactor.py 6ee107d 

Diff: https://reviews.apache.org/r/47243/diff/


Testing
---

New unit tests added.


Thanks,

Kenneth Giusti

[jira] [Commented] (DISPATCH-336) Very high latency for fire-and-forget sender

[Ted Ross (JIRA)]

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

Ted Ross commented on DISPATCH-336:
---

The increases in latency that you see are the result of buffering of the 
pre-settled (fire and forget) messages in the router.  This will also cause 
large memory usage in the router(s).

As of the current snapshot, end-to-end flow control is not in effect for 
pre-settled deliveries.  Since your producers are outrunning your consumers, 
the resultant buffering increases memory usage and latency.

You will get much better results if you use unsettled messages because the 
routers will apply flow control across the network and there will be no 
excessive buffering.  This should result in much more uniform latency that is 
consistent with the lowest latencies you see in your pre-settled test.  Our 
internal testing shows no throughput cost for using unsettled deliveries.

To solve the pre-settled problem, we can do one of two things:  We can drop 
excessive deliveries to avoid buffer expansion; Alternatively we've considered 
using an unsettled delivery mode across the network even for pre-settled 
deliveries to get the benefits of flow-control.  In this case, the producers 
and consumers would not see any different behavior. The messages would be 
delivered pre-settled.

If you have an opinion as to which works better, we'd be interested in hearing 
it.

As a comparison, doing a large-volume throughput/latency test using pre-settled 
deliveries is like doing the same over an IP network using UDP datagrams.  Such 
a test is very taxing on the underlying network. Real applications should not 
use pre-settled for high-volume traffic.

> Very high latency for fire-and-forget sender
> 
>
> Key: DISPATCH-336
> URL: https://issues.apache.org/jira/browse/DISPATCH-336
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Priority: Critical
> Attachments: config1.conf, config2.conf, output_1S_1R.txt
>
>
> We are running two interconnected routers with 1 fire-and-forget sender 
> connected to 1 router and 1 receiver connected to another router.  We are 
> observing increasing latency for the messages irrespective of number messages 
> sent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (DISPATCH-337) Huge memory leaks in Qpid Dispatch router

[Vishal Sharda (JIRA)]

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

Vishal Sharda updated DISPATCH-337:
---
Attachment: val2_sender.txt
val2_receiver.txt
config2.conf
config1.conf

Configuration files for two routers and the valgrind output with debug build of 
Qpid Dispatch running with 2 senders and 2 receivers.

> Huge memory leaks in Qpid Dispatch router
> -
>
> Key: DISPATCH-337
> URL: https://issues.apache.org/jira/browse/DISPATCH-337
> Project: Qpid Dispatch
>  Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Priority: Critical
> Attachments: config1.conf, config2.conf, val2_receiver.txt, 
> val2_sender.txt
>
>
> Valgrind shows huge memory leaks while running 2 interconnected routers with 
> 2 parallel senders connected to the one router and 2 parallel receivers 
> connected to the other router.
> The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here:
> https://issues.apache.org/jira/browse/PROTON-1115
> However, the rest of the leaks are from qdrouterd.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (DISPATCH-337) Huge memory leaks in Qpid Dispatch router

[Vishal Sharda (JIRA)]

Vishal Sharda created DISPATCH-337:
--

 Summary: Huge memory leaks in Qpid Dispatch router
 Key: DISPATCH-337
 URL: https://issues.apache.org/jira/browse/DISPATCH-337
 Project: Qpid Dispatch
  Issue Type: Bug
Affects Versions: 0.6.0
 Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
Reporter: Vishal Sharda
Priority: Critical


Valgrind shows huge memory leaks while running 2 interconnected routers with 2 
parallel senders connected to the one router and 2 parallel receivers connected 
to the other router.

The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here:

https://issues.apache.org/jira/browse/PROTON-1115

However, the rest of the leaks are from qdrouterd.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (DISPATCH-336) Very high latency for fire-and-forget sender

[Vishal Sharda (JIRA)]

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

Vishal Sharda updated DISPATCH-336:
---
Attachment: (was: output.txt)

> Very high latency for fire-and-forget sender
> 
>
> Key: DISPATCH-336
> URL: https://issues.apache.org/jira/browse/DISPATCH-336
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Priority: Critical
> Attachments: config1.conf, config2.conf, output_1S_1R.txt
>
>
> We are running two interconnected routers with 1 fire-and-forget sender 
> connected to 1 router and 1 receiver connected to another router.  We are 
> observing increasing latency for the messages irrespective of number messages 
> sent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (DISPATCH-336) Very high latency for fire-and-forget sender

[Vishal Sharda (JIRA)]

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

Vishal Sharda updated DISPATCH-336:
---
Attachment: output_1S_1R.txt

> Very high latency for fire-and-forget sender
> 
>
> Key: DISPATCH-336
> URL: https://issues.apache.org/jira/browse/DISPATCH-336
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Priority: Critical
> Attachments: config1.conf, config2.conf, output_1S_1R.txt
>
>
> We are running two interconnected routers with 1 fire-and-forget sender 
> connected to 1 router and 1 receiver connected to another router.  We are 
> observing increasing latency for the messages irrespective of number messages 
> sent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (DISPATCH-336) Very high latency for fire-and-forget sender

[Vishal Sharda (JIRA)]

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

Vishal Sharda updated DISPATCH-336:
---
Attachment: output.txt
config2.conf
config1.conf

Configuration files for two routers and the observed latency for 200K messages 
to arrive from sender to the receiver (Both sender and receiver were running on 
the same machine).

> Very high latency for fire-and-forget sender
> 
>
> Key: DISPATCH-336
> URL: https://issues.apache.org/jira/browse/DISPATCH-336
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and 
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Vishal Sharda
>Priority: Critical
> Attachments: config1.conf, config2.conf, output.txt
>
>
> We are running two interconnected routers with 1 fire-and-forget sender 
> connected to 1 router and 1 receiver connected to another router.  We are 
> observing increasing latency for the messages irrespective of number messages 
> sent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Review Request 47243: PROTON-1133: decouple the virtual host from the network address used by reactor

[Alan Conway]

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


Ship it!




This time I  mean it.

- Alan Conway


On May 13, 2016, 5:59 p.m., Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47243/
> ---
> 
> (Updated May 13, 2016, 5:59 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Chug Rolke, Cliff Jansen, Justin Ross, 
> and Robbie Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> The pn_connection_set_hostname() interface is used to set the
> 'hostname' field in the Open performative.  By definition this is the
> 'virtual host' and should not be used by reactor for the network
> address.  The network address for outgoing connections should be set
> by using the reactor's pn_reactor_connection_to_host() factory, or the
> pn_reactor_set_connection_host() when re-connecting to a different
> host.  For inbound connections, the peer address is provided by the
> acceptor and cannot be modified.  In both cases, the
> pn_reactor_get_connection_address() method can be used to obtain the
> peer's network address.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/cpp/CMakeLists.txt 2aec4e2 
>   proton-c/bindings/cpp/include/proton/connection_options.hpp d736600 
>   proton-c/bindings/cpp/src/connection_options.cpp fed645c 
>   proton-c/bindings/cpp/src/connector.cpp dbf74be 
>   proton-c/bindings/cpp/src/container_impl.cpp a221f45 
>   proton-c/bindings/cpp/src/container_test.cpp PRE-CREATION 
>   proton-c/bindings/cpp/src/reactor.hpp 48d9ea1 
>   proton-c/bindings/cpp/src/reactor.cpp 9507d2b 
>   proton-c/bindings/python/proton/reactor.py 1631c35 
>   proton-c/include/proton/connection.h da20f94 
>   proton-c/include/proton/reactor.h be642a9 
>   proton-c/src/posix/io.c 3226594 
>   proton-c/src/reactor/acceptor.c 8f0e99b 
>   proton-c/src/reactor/connection.c 336d1f1 
>   proton-c/src/reactor/reactor.h f996dca 
>   proton-c/src/tests/reactor.c 9564569 
>   proton-c/src/windows/io.c 7ff928d 
>   
> proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ConnectionImpl.java 
> b708d83 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java a3307d2 
>   
> proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/AcceptorImpl.java 
> fb2f892 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java 
> 5a32824 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
> d13cfbe 
>   proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java 
> 4e92cd9 
>   tests/python/proton_tests/reactor.py 6ee107d 
> 
> Diff: https://reviews.apache.org/r/47243/diff/
> 
> 
> Testing
> ---
> 
> New unit tests added.
> 
> 
> Thanks,
> 
> Kenneth Giusti
> 
>

Re: Review Request 47243: PROTON-1133: decouple the virtual host from the network address used by reactor

[Justin Ross]

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


Ship it!




Ship It!

- Justin Ross


On May 13, 2016, 5:59 p.m., Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47243/
> ---
> 
> (Updated May 13, 2016, 5:59 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Chug Rolke, Cliff Jansen, Justin Ross, 
> and Robbie Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> The pn_connection_set_hostname() interface is used to set the
> 'hostname' field in the Open performative.  By definition this is the
> 'virtual host' and should not be used by reactor for the network
> address.  The network address for outgoing connections should be set
> by using the reactor's pn_reactor_connection_to_host() factory, or the
> pn_reactor_set_connection_host() when re-connecting to a different
> host.  For inbound connections, the peer address is provided by the
> acceptor and cannot be modified.  In both cases, the
> pn_reactor_get_connection_address() method can be used to obtain the
> peer's network address.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/cpp/CMakeLists.txt 2aec4e2 
>   proton-c/bindings/cpp/include/proton/connection_options.hpp d736600 
>   proton-c/bindings/cpp/src/connection_options.cpp fed645c 
>   proton-c/bindings/cpp/src/connector.cpp dbf74be 
>   proton-c/bindings/cpp/src/container_impl.cpp a221f45 
>   proton-c/bindings/cpp/src/container_test.cpp PRE-CREATION 
>   proton-c/bindings/cpp/src/reactor.hpp 48d9ea1 
>   proton-c/bindings/cpp/src/reactor.cpp 9507d2b 
>   proton-c/bindings/python/proton/reactor.py 1631c35 
>   proton-c/include/proton/connection.h da20f94 
>   proton-c/include/proton/reactor.h be642a9 
>   proton-c/src/posix/io.c 3226594 
>   proton-c/src/reactor/acceptor.c 8f0e99b 
>   proton-c/src/reactor/connection.c 336d1f1 
>   proton-c/src/reactor/reactor.h f996dca 
>   proton-c/src/tests/reactor.c 9564569 
>   proton-c/src/windows/io.c 7ff928d 
>   
> proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ConnectionImpl.java 
> b708d83 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java a3307d2 
>   
> proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/AcceptorImpl.java 
> fb2f892 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java 
> 5a32824 
>   proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
> d13cfbe 
>   proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java 
> 4e92cd9 
>   tests/python/proton_tests/reactor.py 6ee107d 
> 
> Diff: https://reviews.apache.org/r/47243/diff/
> 
> 
> Testing
> ---
> 
> New unit tests added.
> 
> 
> Thanks,
> 
> Kenneth Giusti
> 
>

Re: Review Request 47243: PROTON-1133: decouple the virtual host from the network address used by reactor

[Kenneth Giusti]

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

(Updated May 13, 2016, 5:59 p.m.)


Review request for qpid, Alan Conway, Chug Rolke, Cliff Jansen, Justin Ross, 
and Robbie Gemmell.


Changes
---

Last update: addresses the last set of comments, and updates the Java Reactor 
to follow the policy for setting the virtual hostname used by Python, C, and 
C++.


Repository: qpid-proton-git


Description
---

The pn_connection_set_hostname() interface is used to set the
'hostname' field in the Open performative.  By definition this is the
'virtual host' and should not be used by reactor for the network
address.  The network address for outgoing connections should be set
by using the reactor's pn_reactor_connection_to_host() factory, or the
pn_reactor_set_connection_host() when re-connecting to a different
host.  For inbound connections, the peer address is provided by the
acceptor and cannot be modified.  In both cases, the
pn_reactor_get_connection_address() method can be used to obtain the
peer's network address.


Diffs (updated)
-

  proton-c/bindings/cpp/CMakeLists.txt 2aec4e2 
  proton-c/bindings/cpp/include/proton/connection_options.hpp d736600 
  proton-c/bindings/cpp/src/connection_options.cpp fed645c 
  proton-c/bindings/cpp/src/connector.cpp dbf74be 
  proton-c/bindings/cpp/src/container_impl.cpp a221f45 
  proton-c/bindings/cpp/src/container_test.cpp PRE-CREATION 
  proton-c/bindings/cpp/src/reactor.hpp 48d9ea1 
  proton-c/bindings/cpp/src/reactor.cpp 9507d2b 
  proton-c/bindings/python/proton/reactor.py 1631c35 
  proton-c/include/proton/connection.h da20f94 
  proton-c/include/proton/reactor.h be642a9 
  proton-c/src/posix/io.c 3226594 
  proton-c/src/reactor/acceptor.c 8f0e99b 
  proton-c/src/reactor/connection.c 336d1f1 
  proton-c/src/reactor/reactor.h f996dca 
  proton-c/src/tests/reactor.c 9564569 
  proton-c/src/windows/io.c 7ff928d 
  proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ConnectionImpl.java 
b708d83 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/Reactor.java a3307d2 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/AcceptorImpl.java 
fb2f892 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java 
5a32824 
  proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/ReactorImpl.java 
d13cfbe 
  proton-j/src/test/java/org/apache/qpid/proton/reactor/ReactorTest.java 
4e92cd9 
  tests/python/proton_tests/reactor.py 6ee107d 

Diff: https://reviews.apache.org/r/47243/diff/


Testing
---

New unit tests added.


Thanks,

Kenneth Giusti

[jira] [Commented] (DISPATCH-331) Allow for a default policy to apply when open.hostname doesn't match an existing policy

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-331: Add default policy details. Add disclaimer warning of pending 
changes


> Allow for a default policy to apply when open.hostname doesn't match an 
> existing policy
> ---
>
> Key: DISPATCH-331
> URL: https://issues.apache.org/jira/browse/DISPATCH-331
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Policy Engine
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 0.6.0
>
>
> Add a feature to the policy engine that allows the deployer to specify a 
> policy to be used for connections with no open.hostname or a hostname that 
> does not match any existing policy.
> For users that don't wish to use open.hostname or any multi-tennancy feature, 
> this default policy can be the only policy in effect for the network.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (DISPATCH-331) Allow for a default policy to apply when open.hostname doesn't match an existing policy

[Chuck Rolke (JIRA)]

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

Chuck Rolke resolved DISPATCH-331.
--
Resolution: Fixed

Fixed by commits 590d79e and 33cbeed

> Allow for a default policy to apply when open.hostname doesn't match an 
> existing policy
> ---
>
> Key: DISPATCH-331
> URL: https://issues.apache.org/jira/browse/DISPATCH-331
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Policy Engine
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Chuck Rolke
> Fix For: 0.6.0
>
>
> Add a feature to the policy engine that allows the deployer to specify a 
> policy to be used for connections with no open.hostname or a hostname that 
> does not match any existing policy.
> For users that don't wish to use open.hostname or any multi-tennancy feature, 
> this default policy can be the only policy in effect for the network.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (PROTON-1195) [C++ binding] Don't use default parameters in ABI relevant places

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher resolved PROTON-1195.
-
   Resolution: Fixed
Fix Version/s: 0.13.0

The git<->Jira integration failed for this issue.

> [C++ binding] Don't use default parameters in ABI relevant places
> -
>
> Key: PROTON-1195
> URL: https://issues.apache.org/jira/browse/PROTON-1195
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>
> Using default parameter arguments requires the client side of the API to 
> actually pass the default parameter.
> For maximal forward ABI flexibility, it is usually better to have different 
> ABI entry points corresponding to the different overloads of the function.
> The major exception to this is where the API is defined inline in the header 
> file: In this case the API client is doing all the work anyway and there is 
> no actual ABI symbol in any case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (PROTON-1196) Move connection options accessors from transport object to connection object

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher resolved PROTON-1196.
-
   Resolution: Fixed
Fix Version/s: 0.13.0

The git<->jira integration has failed with change

> Move connection options accessors from transport object to connection object
> 
>
> Key: PROTON-1196
> URL: https://issues.apache.org/jira/browse/PROTON-1196
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (PROTON-1197) Ensure that private members don't have exported symbols

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher resolved PROTON-1197.
-
   Resolution: Fixed
Fix Version/s: 0.13.0

> Ensure that private members don't have exported symbols
> ---
>
> Key: PROTON-1197
> URL: https://issues.apache.org/jira/browse/PROTON-1197
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: 0.13.0
>
>
> Except if there is a specific reason:
> The only one so far found is if the symbol is used in a template 
> instantiation. This is because this will actually happen when the library 
> client compiles the code as so will need the symbol from the library.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (PROTON-1198) Add senders/receivers range constructors to connection

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher resolved PROTON-1198.
-
   Resolution: Fixed
Fix Version/s: 0.13.0

> Add senders/receivers range constructors to connection
> --
>
> Key: PROTON-1198
> URL: https://issues.apache.org/jira/browse/PROTON-1198
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>
> It's convenient to be able to iterate over all sender/receivers for a 
> connection without having to use nested iterators.
> Ironically it's actually more efficient to do it this way in proton as well 
> as the list of links is per connection not per session.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1194) C++ flow control

[ASF subversion and git services (JIRA)]

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

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

Commit 887a4a09bf5de6e157093eef05d72ee4b0c60922 in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=887a4a0 ]

PROTON-1194: C++ flow control, assertion error in debug builds, wrong get_drain 
call


> C++ flow control
> 
>
> Key: PROTON-1194
> URL: https://issues.apache.org/jira/browse/PROTON-1194
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.12.2
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: 0.13.0
>
>
> Provide basic flow control primitives: receiver::add_credit, receiver::drain 
> and handler event callbacks to note drain begin and completion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1198) Add senders/receivers range constructors to connection

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1198: [C++ binding] senders/receivers range accessors for connection


> Add senders/receivers range constructors to connection
> --
>
> Key: PROTON-1198
> URL: https://issues.apache.org/jira/browse/PROTON-1198
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> It's convenient to be able to iterate over all sender/receivers for a 
> connection without having to use nested iterators.
> Ironically it's actually more efficient to do it this way in proton as well 
> as the list of links is per connection not per session.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (PROTON-1198) Add senders/receivers range constructors to connection

[Andrew Stitcher (JIRA)]

Andrew Stitcher created PROTON-1198:
---

 Summary: Add senders/receivers range constructors to connection
 Key: PROTON-1198
 URL: https://issues.apache.org/jira/browse/PROTON-1198
 Project: Qpid Proton
  Issue Type: Improvement
  Components: cpp-binding
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher


It's convenient to be able to iterate over all sender/receivers for a 
connection without having to use nested iterators.

Ironically it's actually more efficient to do it this way in proton as well as 
the list of links is per connection not per session.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (PROTON-1153) [C++ binding] Tidy up various details

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1153: [C++ binding] Make session constructor private and match all the 
other endpoints


> [C++ binding] Tidy up various details
> -
>
> Key: PROTON-1153
> URL: https://issues.apache.org/jira/browse/PROTON-1153
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7255) Support delivery delay

[Rob Godfrey (JIRA)]

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

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

I've attached a patch which supports the notion of checking for a "not valid 
before" header in the message.

Before proceeding down this path, would be good to get others to review the 
approach.  Before committing I think we'd want to promote the "not valid 
before" to a synthetic attribute of the AMQMessageHeader so that (for instance) 
in AMQP 1.0 we could model this as a MessageAnnotation rather than a message 
header... moreover the message implementations could cache the value once it 
has been parsed.  

There also should be a client side change to allow specifying the delivery 
delay in the address string for producers.

> Support delivery delay
> --
>
> Key: QPID-7255
> URL: https://issues.apache.org/jira/browse/QPID-7255
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
> Attachments: QPID-7255.diff
>
>
> Some enterprise messaging systems provide a delayed delivery feature whereby 
> a publisher can provide a delivery time when sending the message, with the 
> Broker taking care of not making the message available to consumers until 
> that time is reached.  The Java Broker should provide the same feature.
> In the Java space, JMS 2.0 has standardised this feature, however  there is 
> no reason why the feature could not be made available to older JMS 1.1 
> clients using a Qpid specific header.   Also if the BURL or ADDR address 
> could hint to the Producer that delivery delay was required for all messages 
> produced by it, this would mean message delay could be turned on from 
> configuration alone.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-6901) Fix inconsistent channel log subject for 0-10 and 1.0

[Alex Rudyy (JIRA)]

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

Alex Rudyy resolved QPID-6901.
--
Resolution: Fixed

It seems that formatting code could be encapsulated in static method either in 
ChannelLogSubject or AbstractMessageLogger and called from the protocols 
AMQPSessionModel implementations. Apart from this, the changes look reasonable  
to me

> Fix inconsistent channel log subject for 0-10 and 1.0
> -
>
> Key: QPID-6901
> URL: https://issues.apache.org/jira/browse/QPID-6901
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> The channel subject on the 0-8..0-91 path uses the userid whereas on the 
> 0-10/1.0 path the client id is used.  As other subjects that carry identity 
> use the user-id, the 0-10/1.0 paths should be changed to be consistent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (QPID-7215) [Java Broker, WMC] WMC should use query to retrieve connections

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-7215:


Assignee: Keith Wall  (was: Alex Rudyy)

> [Java Broker, WMC] WMC should use query to retrieve connections
> ---
>
> Key: QPID-7215
> URL: https://issues.apache.org/jira/browse/QPID-7215
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7215-Java-Broker-WMC-Use-query-to-retrieve-conn.patch
>
>
> currently the ManagedOperation getConnections on the VirtualHost returns the 
> connections and sessions with the full inherited context.
> Now that we have queries we should use them for this purpose instead.
> The ManagedOperation getConnections should be deprecated and removed in v7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (QPID-7215) [Java Broker, WMC] WMC should use query to retrieve connections

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-7215:


Assignee: Alex Rudyy  (was: Lorenz Quack)

> [Java Broker, WMC] WMC should use query to retrieve connections
> ---
>
> Key: QPID-7215
> URL: https://issues.apache.org/jira/browse/QPID-7215
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7215-Java-Broker-WMC-Use-query-to-retrieve-conn.patch
>
>
> currently the ManagedOperation getConnections on the VirtualHost returns the 
> connections and sessions with the full inherited context.
> Now that we have queries we should use them for this purpose instead.
> The ManagedOperation getConnections should be deprecated and removed in v7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7215) [Java Broker, WMC] WMC should use query to retrieve connections

[Alex Rudyy (JIRA)]

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

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

> [Java Broker, WMC] WMC should use query to retrieve connections
> ---
>
> Key: QPID-7215
> URL: https://issues.apache.org/jira/browse/QPID-7215
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Alex Rudyy
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7215-Java-Broker-WMC-Use-query-to-retrieve-conn.patch
>
>
> currently the ManagedOperation getConnections on the VirtualHost returns the 
> connections and sessions with the full inherited context.
> Now that we have queries we should use them for this purpose instead.
> The ManagedOperation getConnections should be deprecated and removed in v7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7215) [Java Broker, WMC] WMC should use query to retrieve connections

[Alex Rudyy (JIRA)]

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

Alex Rudyy commented on QPID-7215:
--

Keith,
I committed fix under revision [https://svn.apache.org/r1743655] against 
QPID-7214 as the changes in QPID-7214 caused the issue you had reported. Please 
review

> [Java Broker, WMC] WMC should use query to retrieve connections
> ---
>
> Key: QPID-7215
> URL: https://issues.apache.org/jira/browse/QPID-7215
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7215-Java-Broker-WMC-Use-query-to-retrieve-conn.patch
>
>
> currently the ManagedOperation getConnections on the VirtualHost returns the 
> connections and sessions with the full inherited context.
> Now that we have queries we should use them for this purpose instead.
> The ManagedOperation getConnections should be deprecated and removed in v7



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7214) [Java Broker, WMC] Do not use depth=2 in the REST request in Broker.js

[ASF subversion and git services (JIRA)]

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

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

Commit 1743655 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1743655 ]

QPID-7214: [Java Broker, WMC] Verify virtual host node existence before merging 
virtual host node and virtual host data

> [Java Broker, WMC] Do not use depth=2 in the REST request in Broker.js
> --
>
> Key: QPID-7214
> URL: https://issues.apache.org/jira/browse/QPID-7214
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1
>
>
> Currently in Broker.js we issue a REST request with {{depth=2}} because we 
> are interested in the VirtualHosts which are children of VirtualHostNodes and 
> not the Broker.
> However, this causes a lot of unnecessary data to be transmitted as well. 
> Namely all connections which are children of the Ports.
> We should remove the {{depth=2}} and request the VirtualHosts separately.
> We should use a query for this.
> We should also make sure that this request happens in parallel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7264) Model attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker to fail on restart

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7264:
--

Looks to me like the problem lies within 
AbstractConfiguredObject#asObjectRecord().  The derived path needs to encrypt 
the attributes value too.

> Model attributes that are derived and secure (such as 
> AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker 
> to fail on restart
> 
>
> Key: QPID-7264
> URL: https://issues.apache.org/jira/browse/QPID-7264
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2
>Reporter: Keith Wall
>Priority: Minor
>
> Model Attributes that are derived/secure do not get encrypted by the 
> configuration encryptor.   If you add an {{AutoGeneratedSelfSignedCert}}  
> then turn on encryption, the Broker continues to work until it is restarted, 
> at which point it fails as it tries to read the secure value as if it were 
> AES ciphered data.
> The only feature that currently has such an attribute is 
> AutoGeneratedSelfSignedCert.  This problem means that 
> AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is 
> also in use.
> The work around is to create the self signed keystore externally 
> (keytool/openssl etc), and import into Qpid as a Java or Non-Java Keystore.
> {noformat}
> 12:12:27.170 [main] INFO  qpid.message.keystore.create - [Broker] KST-1001 : 
> Create "myks"
> 12:12:27.595 [main] ERROR org.apache.qpid.server.Broker - Exception during 
> startup
> java.lang.IllegalArgumentException: Unable to encrypt secret
>   at 
> org.apache.qpid.server.security.encryption.AESKeyFileEncrypter.decrypt(AESKeyFileEncrypter.java:106)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.decryptSecrets(AbstractConfiguredObject.java:2788)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:187)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.perform(BrokerStoreUpgraderAndRecoverer.java:846)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:232)
>  ~[classes/:na]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_66]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_66]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_66]
>   at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1309)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1288)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:909)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:903)
>  ~[classes/:na]
>   at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319) 
> ~[guava-18.0.jar:na]
>   at 
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
>  ~[guava-18.0.jar:na]
>   at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
>  ~[guava-18.0.jar:na]
>   at 
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101) 
> 

[jira] [Updated] (QPID-7264) Model attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker to fail on restart

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7264:
-
Priority: Minor  (was: Major)

> Model attributes that are derived and secure (such as 
> AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker 
> to fail on restart
> 
>
> Key: QPID-7264
> URL: https://issues.apache.org/jira/browse/QPID-7264
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2
>Reporter: Keith Wall
>Priority: Minor
>
> Model Attributes that are derived/secure do not get encrypted by the 
> configuration encryptor.   If you add an {{AutoGeneratedSelfSignedCert}}  
> then turn on encryption, the Broker continues to work until it is restarted, 
> at which point it fails as it tries to read the secure value as if it were 
> AES ciphered data.
> The only feature that currently has such an attribute is 
> AutoGeneratedSelfSignedCert.  This problem means that 
> AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is 
> also in use.
> The work around is to create the self signed keystore externally, and import 
> into Qpid as a Java or Non-Java Keystore.
> {noformat}
> 12:12:27.170 [main] INFO  qpid.message.keystore.create - [Broker] KST-1001 : 
> Create "myks"
> 12:12:27.595 [main] ERROR org.apache.qpid.server.Broker - Exception during 
> startup
> java.lang.IllegalArgumentException: Unable to encrypt secret
>   at 
> org.apache.qpid.server.security.encryption.AESKeyFileEncrypter.decrypt(AESKeyFileEncrypter.java:106)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.decryptSecrets(AbstractConfiguredObject.java:2788)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:187)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.perform(BrokerStoreUpgraderAndRecoverer.java:846)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:232)
>  ~[classes/:na]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_66]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_66]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_66]
>   at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1309)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1288)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:909)
>  ~[classes/:na]
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:903)
>  ~[classes/:na]
>   at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319) 
> ~[guava-18.0.jar:na]
>   at 
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
>  ~[guava-18.0.jar:na]
>   at 
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
>  ~[guava-18.0.jar:na]
>   at 
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101) 
> ~[guava-18.0.jar:na]
>   at 
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
>  ~[guava-18.0.jar:na]
>   at 
> 

[jira] [Updated] (QPID-7264) Model attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker to fail on restart

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7264:
-
Description: 
Model Attributes that are derived/secure do not get encrypted by the 
configuration encryptor.   If you add an {{AutoGeneratedSelfSignedCert}}  then 
turn on encryption, the Broker continues to work until it is restarted, at 
which point it fails as it tries to read the secure value as if it were AES 
ciphered data.

The only feature that currently has such an attribute is 
AutoGeneratedSelfSignedCert.  This problem means that 
AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is 
also in use.

The work around is to create the self signed keystore externally 
(keytool/openssl etc), and import into Qpid as a Java or Non-Java Keystore.

{noformat}
12:12:27.170 [main] INFO  qpid.message.keystore.create - [Broker] KST-1001 : 
Create "myks"
12:12:27.595 [main] ERROR org.apache.qpid.server.Broker - Exception during 
startup
java.lang.IllegalArgumentException: Unable to encrypt secret
at 
org.apache.qpid.server.security.encryption.AESKeyFileEncrypter.decrypt(AESKeyFileEncrypter.java:106)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.decryptSecrets(AbstractConfiguredObject.java:2788)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:187)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
 ~[classes/:na]
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
 ~[classes/:na]
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
 ~[classes/:na]
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54) 
~[classes/:na]
at 
org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.perform(BrokerStoreUpgraderAndRecoverer.java:846)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:232)
 ~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
~[na:1.8.0_66]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[na:1.8.0_66]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[na:1.8.0_66]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1309)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1288)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:909)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:903)
 ~[classes/:na]
at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319) 
~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
 ~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
 ~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101) 
~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
 ~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322) 
~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258) 
~[guava-18.0.jar:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:902)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:81)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:514)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:501)
 ~[classes/:na]
at 

[jira] [Updated] (QPID-7264) Model attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker to fail on restart

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7264:
-
Description: 
Model Attributes that are derived/secure do not get encrypted by the 
configuration encryptor.   If you add an {{AutoGeneratedSelfSignedCert}}  then 
turn on encryption, the Broker continues to work until it is restarted, at 
which point it fails as it tries to read the secure value as if it were AES 
ciphered data.

The only feature that currently has such an attribute is 
AutoGeneratedSelfSignedCert.  This problem means that 
AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is 
also in use.

The work around is to create the self signed keystore externally, and import 
into Qpid as a Java or Non-Java Keystore.

{noformat}
12:12:27.170 [main] INFO  qpid.message.keystore.create - [Broker] KST-1001 : 
Create "myks"
12:12:27.595 [main] ERROR org.apache.qpid.server.Broker - Exception during 
startup
java.lang.IllegalArgumentException: Unable to encrypt secret
at 
org.apache.qpid.server.security.encryption.AESKeyFileEncrypter.decrypt(AESKeyFileEncrypter.java:106)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.decryptSecrets(AbstractConfiguredObject.java:2788)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:187)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
 ~[classes/:na]
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
 ~[classes/:na]
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
 ~[classes/:na]
at 
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
 ~[classes/:na]
at 
org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54) 
~[classes/:na]
at 
org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.perform(BrokerStoreUpgraderAndRecoverer.java:846)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:232)
 ~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
~[na:1.8.0_66]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
~[na:1.8.0_66]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[na:1.8.0_66]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1309)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1288)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:909)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:903)
 ~[classes/:na]
at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319) 
~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
 ~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
 ~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101) 
~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
 ~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322) 
~[guava-18.0.jar:na]
at 
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1258) 
~[guava-18.0.jar:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:902)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject.access$300(AbstractConfiguredObject.java:81)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:514)
 ~[classes/:na]
at 
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:501)
 ~[classes/:na]
at 

[jira] [Commented] (PROTON-1164) Update handlers to align with current proposal

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1164: Add synthesised on_transport_open event
- Event is generated just before on_connection_open


> Update handlers to align with current proposal
> --
>
> Key: PROTON-1164
> URL: https://issues.apache.org/jira/browse/PROTON-1164
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>
> The current event handler proposal includes the primary object that the event 
> is concerned with in the handler signature. This makes it more convenient to 
> process the event by giving the most likely object to be needed directly to 
> the handler without any other lookups.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7264) Mode attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get encrypted

[Keith Wall (JIRA)]

Keith Wall created QPID-7264:


 Summary: Mode attributes that are derived and secure (such as 
AutoGeneratedSelfSignedKeyStore) do not get encrypted
 Key: QPID-7264
 URL: https://issues.apache.org/jira/browse/QPID-7264
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Affects Versions: qpid-java-6.0.2, qpid-java-6.0.1, qpid-java-6.0
Reporter: Keith Wall


Model Attributes that are derived/secure do not get encrypted by the 
configuration encryptor.   If you add an {{AutoGeneratedSelfSignedCert}}  then 
turn on encryption, the Broker continues to work until it is restarted, at 
which point it fails as it tries to read the secure value as if it were AES 
ciphered data.

The only feature that currently has such an attribute is 
AutoGeneratedSelfSignedCert.  This problem means that 
AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is 
also in use.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7263) Make HA feature integrate more nicely with clients referencing the group via a VIP

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7263:
-
Description: 
One possible deployment pattern for HA is that clients reference the HA group 
via a VIP rather than utilising a failover url.  This isolates the client from 
knowledge of the individual node addresses.  This deployment pattern is 
currently possible but it needs a relatively deep integration: custom scripting 
is required to track the location of the master node (using the Java Broker's 
REST API) with changes causing the VIP's target to be updated.

VIPs usually have a feature which is able to detect when a target is down (port 
closed, host down etc) and direct traffic to another target instead.  In our 
case, this feature cannot be used become the Broker continues to listen on the 
AMPQ Port even if the Virtualhost is not the master.  (This is because in the 
model a Port services many virtual hosts).

It would be desirable if a cleanly integration could be found:

* somehow arranging for AMQP Port associated with HA to become unbound when the 
mastership goes away.
* perhaps by providing an additional 'ping' port related to the virtualhost 
that is only bound when the master is present at the node.



 

 

  was:
One possible deployment pattern for HA is that clients reference the HA group 
via a VIP rather than utilising a failover url.  This isolates the client from 
knowledge of the individual node addresses.  This deployment pattern is 
currently possible but it needs a relatively deep integration: custom scripting 
is required to track the location of the master node (using the Java Broker's 
REST API) with changes causing the VIP's target to be updated.

VIPs usually have a feature which is able to detect when a target is down (port 
closed, host down etc) and direct traffic to another target instead.  In our 
case, this feature cannot be used become the Broker continues to listen on the 
AMPQ Port even if the Virtualhost is not the master.  (This is because in the 
model a Port services many virtual hosts).

It would be desirable if a cleanly integration could be found:

* somehow arranging for Ports associated with HA to become unbound when the 
mastership goes away.
* perhaps by providing an additional 'ping' port related to the virtualhost 
that is only bound when the master is present at the node.



 

 


> Make HA feature integrate more nicely with clients referencing the group via 
> a VIP
> --
>
> Key: QPID-7263
> URL: https://issues.apache.org/jira/browse/QPID-7263
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>
> One possible deployment pattern for HA is that clients reference the HA group 
> via a VIP rather than utilising a failover url.  This isolates the client 
> from knowledge of the individual node addresses.  This deployment pattern is 
> currently possible but it needs a relatively deep integration: custom 
> scripting is required to track the location of the master node (using the 
> Java Broker's REST API) with changes causing the VIP's target to be updated.
> VIPs usually have a feature which is able to detect when a target is down 
> (port closed, host down etc) and direct traffic to another target instead.  
> In our case, this feature cannot be used become the Broker continues to 
> listen on the AMPQ Port even if the Virtualhost is not the master.  (This is 
> because in the model a Port services many virtual hosts).
> It would be desirable if a cleanly integration could be found:
> * somehow arranging for AMQP Port associated with HA to become unbound when 
> the mastership goes away.
> * perhaps by providing an additional 'ping' port related to the virtualhost 
> that is only bound when the master is present at the node.
>  
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7263) Make HA feature integrate more nicely with clients referencing the group via a VIP

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7263:
-
Description: 
One possible deployment pattern for HA is that clients reference the HA group 
via a VIP rather than utilising a failover url.  This isolates the client from 
knowledge of the individual node addresses.  This deployment pattern is 
currently possible but it needs a relatively deep integration: custom scripting 
is required to track the location of the master node (using the Java Broker's 
REST API) with changes causing the VIP's target to be updated.

VIPs usually have a feature which is able to detect when a target is down (port 
closed, host down etc) and direct traffic to another target instead.  In our 
case, this feature cannot be used become the Broker continues to listen on the 
AMPQ Port even if the Virtualhost is not the master.  (This is because in the 
model a Port services many virtual hosts).

It would be desirable if a cleanly integration could be found:

* somehow arranging for Ports associated with HA to become unbound when the 
mastership goes away.
* perhaps by providing an additional 'ping' port related to the virtualhost 
that is only bound when the master is present at the node.



 

 

  was:
One possible deployment pattern for HA is that clients reference the HA group 
via a VIP rather than utilising a failover url.  This isolates the client from 
knowledge of the individual node addresses.  This deployment pattern is 
currently possible but it needs a relatively deep integration: custom scripting 
is required to track the location of the master node (using the Java Broker's 
REST API) with changes causing the VIP's target to be updated.

VIPs usually have a feature which is able to detect when a target is down (port 
closed) and direct traffic to another target instead.  In our case, this 
feature cannot be used become the Broker continues to listen on the Port even 
if the Virtualhost is not the master.  (This is because in the model a services 
many virtual hosts).

It would be desirable if a cleanly integration could be found:

* somehow arranging for Ports associated with HA to become unbound when the 
mastership goes away.
* perhaps by providing an additional 'ping' port related to the virtualhost 
that is only bound when the master is present at the node.



 

 


> Make HA feature integrate more nicely with clients referencing the group via 
> a VIP
> --
>
> Key: QPID-7263
> URL: https://issues.apache.org/jira/browse/QPID-7263
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>
> One possible deployment pattern for HA is that clients reference the HA group 
> via a VIP rather than utilising a failover url.  This isolates the client 
> from knowledge of the individual node addresses.  This deployment pattern is 
> currently possible but it needs a relatively deep integration: custom 
> scripting is required to track the location of the master node (using the 
> Java Broker's REST API) with changes causing the VIP's target to be updated.
> VIPs usually have a feature which is able to detect when a target is down 
> (port closed, host down etc) and direct traffic to another target instead.  
> In our case, this feature cannot be used become the Broker continues to 
> listen on the AMPQ Port even if the Virtualhost is not the master.  (This is 
> because in the model a Port services many virtual hosts).
> It would be desirable if a cleanly integration could be found:
> * somehow arranging for Ports associated with HA to become unbound when the 
> mastership goes away.
> * perhaps by providing an additional 'ping' port related to the virtualhost 
> that is only bound when the master is present at the node.
>  
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7263) Make HA feature integrate more nicely with clients referencing the group via a VIP

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7263:
-
Summary: Make HA feature integrate more nicely with clients referencing the 
group via a VIP  (was: Make HA feature integrate more nicely with clients 
referencing the Broker via a VIP)

> Make HA feature integrate more nicely with clients referencing the group via 
> a VIP
> --
>
> Key: QPID-7263
> URL: https://issues.apache.org/jira/browse/QPID-7263
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>
> One possible deployment pattern for HA is that clients reference the HA group 
> via a VIP rather than utilising a failover url.  This isolates the client 
> from knowledge of the individual node addresses.  This deployment pattern is 
> currently possible but it needs a relatively deep integration: custom 
> scripting is required to track the location of the master node (using the 
> Java Broker's REST API) with changes causing the VIP's target to be updated.
> VIPs usually have a feature which is able to detect when a target is down 
> (port closed) and direct traffic to another target instead.  In our case, 
> this feature cannot be used become the Broker continues to listen on the Port 
> even if the Virtualhost is not the master.  (This is because in the model a 
> services many virtual hosts).
> It would be desirable if a cleanly integration could be found:
> * somehow arranging for Ports associated with HA to become unbound when the 
> mastership goes away.
> * perhaps by providing an additional 'ping' port related to the virtualhost 
> that is only bound when the master is present at the node.
>  
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7263) Make HA feature integrate more nicely with clients referencing the Broker via a VIP

[Keith Wall (JIRA)]

Keith Wall created QPID-7263:


 Summary: Make HA feature integrate more nicely with clients 
referencing the Broker via a VIP
 Key: QPID-7263
 URL: https://issues.apache.org/jira/browse/QPID-7263
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall


One possible deployment pattern for HA is that clients reference the HA group 
via a VIP rather than utilising a failover url.  This isolates the client from 
knowledge of the individual node addresses.  This deployment pattern is 
currently possible but it needs a relatively deep integration: custom scripting 
is required to track the location of the master node (using the Java Broker's 
REST API) with changes causing the VIP's target to be updated.

VIPs usually have a feature which is able to detect when a target is down (port 
closed) and direct traffic to another target instead.  In our case, this 
feature cannot be used become the Broker continues to listen on the Port even 
if the Virtualhost is not the master.  (This is because in the model a services 
many virtual hosts).

It would be desirable if a cleanly integration could be found:

* somehow arranging for Ports associated with HA to become unbound when the 
mastership goes away.
* perhaps by providing an additional 'ping' port related to the virtualhost 
that is only bound when the master is present at the node.



 

 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (QPID-7262) [Python Test Suite] Add tests for SSL/TLS

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7262:
--

 Summary: [Python Test Suite] Add tests for SSL/TLS
 Key: QPID-7262
 URL: https://issues.apache.org/jira/browse/QPID-7262
 Project: Qpid
  Issue Type: Improvement
  Components: Python Test Suite
Reporter: Lorenz Quack


We should add tests to the Python Test Suite to test the clients ability to 
handle SSL/TLS connections and associated features (e.g., hostname verification)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (QPID-7261) [Java Broker] Deletion of virtual host node does not close active connections

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7261:
-
Affects Version/s: qpid-java-6.0

> [Java Broker] Deletion of virtual host node does not close active connections
> -
>
> Key: QPID-7261
> URL: https://issues.apache.org/jira/browse/QPID-7261
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> Deletion of virtual host node does not close active connections on virtual 
> host. If not closed connection is attempted to be closed from client side 
> Broker crushes with exception like the one below:
> {noformat}
> 
> #
> # Unhandled Exception java.lang.IllegalStateException: Task executor 
> VirtualHostNode-test-Config is not in ACTIVE state in Thread 
> IO-/127.0.0.1:52792
> #
> # Exiting
> #
> 
> java.lang.IllegalStateException: Task executor VirtualHostNode-test-Config is 
> not in ACTIVE state
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.checkState(TaskExecutorImpl.java:225)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:147)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:142)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:554)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnectionAsync(AbstractVirtualHost.java:1808)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnection(AbstractVirtualHost.java:1803)
>   at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.closed(AMQPConnection_0_8.java:716)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.closed(MultiVersionProtocolEngine.java:114)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:405)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:328)
>   at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
>   at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:504)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:337)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:87)
>   at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> {noformat}
> 
> #
> # Unhandled Exception java.lang.IllegalStateException: Task executor 
> VirtualHostNode-test-Config is not in ACTIVE state in Thread 
> IO-/127.0.0.1:54390
> #
> # Exiting
> #
> 
> java.lang.IllegalStateException: Task executor VirtualHostNode-test-Config is 
> not in ACTIVE state
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.checkState(TaskExecutorImpl.java:225)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:147)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:142)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:554)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnectionAsync(AbstractVirtualHost.java:1808)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnection(AbstractVirtualHost.java:1803)
>   at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.closed(AMQPConnection_0_8.java:716)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.closed(MultiVersionProtocolEngine.java:114)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:405)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:328)
>   at 
> 

[jira] [Updated] (QPID-7261) [Java Broker] Deletion of virtual host node does not close active connections

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7261:
-
Fix Version/s: qpid-java-6.1

> [Java Broker] Deletion of virtual host node does not close active connections
> -
>
> Key: QPID-7261
> URL: https://issues.apache.org/jira/browse/QPID-7261
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> Deletion of virtual host node does not close active connections on virtual 
> host. If not closed connection is attempted to be closed from client side 
> Broker crushes with exception like the one below:
> {noformat}
> 
> #
> # Unhandled Exception java.lang.IllegalStateException: Task executor 
> VirtualHostNode-test-Config is not in ACTIVE state in Thread 
> IO-/127.0.0.1:52792
> #
> # Exiting
> #
> 
> java.lang.IllegalStateException: Task executor VirtualHostNode-test-Config is 
> not in ACTIVE state
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.checkState(TaskExecutorImpl.java:225)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:147)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:142)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:554)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnectionAsync(AbstractVirtualHost.java:1808)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnection(AbstractVirtualHost.java:1803)
>   at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.closed(AMQPConnection_0_8.java:716)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.closed(MultiVersionProtocolEngine.java:114)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:405)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:328)
>   at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
>   at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:504)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:337)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:87)
>   at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> {noformat}
> 
> #
> # Unhandled Exception java.lang.IllegalStateException: Task executor 
> VirtualHostNode-test-Config is not in ACTIVE state in Thread 
> IO-/127.0.0.1:54390
> #
> # Exiting
> #
> 
> java.lang.IllegalStateException: Task executor VirtualHostNode-test-Config is 
> not in ACTIVE state
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.checkState(TaskExecutorImpl.java:225)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:147)
>   at 
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:142)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:554)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnectionAsync(AbstractVirtualHost.java:1808)
>   at 
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.deregisterConnection(AbstractVirtualHost.java:1803)
>   at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.closed(AMQPConnection_0_8.java:716)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.closed(MultiVersionProtocolEngine.java:114)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:405)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:328)
>   at 
> 

[jira] [Updated] (QPID-7255) Support delivery delay

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7255:
-
Description: 
Some enterprise messaging systems provide a delayed delivery feature whereby a 
publisher can provide a delivery time when sending the message, with the Broker 
taking care of not making the message available to consumers until that time is 
reached.  The Java Broker should provide the same feature.

In the Java space, JMS 2.0 has standardised this feature, however  there is no 
reason why the feature could not be made available to older JMS 1.1 clients 
using a Qpid specific header.   Also if the BURL or ADDR address could hint to 
the Producer that delivery delay was required for all messages produced by it, 
this would mean message delay could be turned on from configuration alone.

  was:
Some enterprise messaging systems provide a delayed delivery feature whereby a 
publisher can provide a delivery time when sending the message, with the Broker 
taking care of not making the message available to consumers until that time is 
reached.  The Java Broker should provide the same feature.

In the Java space, JMS 2.0 has standardised this feature, however  there is no 
reason why the feature could not be made available to older JMS 1.1 clients 
using a Qpid specific header. 


> Support delivery delay
> --
>
> Key: QPID-7255
> URL: https://issues.apache.org/jira/browse/QPID-7255
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
>
> Some enterprise messaging systems provide a delayed delivery feature whereby 
> a publisher can provide a delivery time when sending the message, with the 
> Broker taking care of not making the message available to consumers until 
> that time is reached.  The Java Broker should provide the same feature.
> In the Java space, JMS 2.0 has standardised this feature, however  there is 
> no reason why the feature could not be made available to older JMS 1.1 
> clients using a Qpid specific header.   Also if the BURL or ADDR address 
> could hint to the Producer that delivery delay was required for all messages 
> produced by it, this would mean message delay could be turned on from 
> configuration alone.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed

[Steven (JIRA)]

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

Steven commented on QPID-7256:
--

I use the Qpid Proton framework to test my code,The latest release of the new 
JMS AMQP 1.0 client is 0.9.0,According to my testing,The loop times is 
1000,After 117 messages had been sent out,It still reported following error.

org.apache.qpid.jms.JmsOperationTimedOutException: Request to open resource 
AmqpConnection { ID::a16215dc-1f3a-4e05-be79-f2f0b157349b:1 } timed out
message 117 sent.
at 
org.apache.qpid.jms.provider.amqp.builders.AmqpResourceBuilder.buildResource(AmqpResourceBuilder.java:83)
at 
org.apache.qpid.jms.provider.amqp.builders.AmqpConnectionBuilder.buildResource(AmqpConnectionBuilder.java:94)
at 
org.apache.qpid.jms.provider.amqp.AmqpProvider$4$1.processConnectionInfo(AmqpProvider.java:324)
at 
org.apache.qpid.jms.meta.JmsConnectionInfo.visit(JmsConnectionInfo.java:318)
at 
org.apache.qpid.jms.provider.amqp.AmqpProvider$4.run(AmqpProvider.java:253)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

> When invoke the method "connection.start" in a loop,reporting socket closed
> ---
>
> Key: QPID-7256
> URL: https://issues.apache.org/jira/browse/QPID-7256
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: 0.32
> Environment: windows7、 jdk7
>Reporter: Steven
>
> I use the for loop,It will loop 1000 times,every time,I create a 
> connection,then send message,After the message has been sent,close the 
> connection.
> this loop executed it for some times,It will report error,as you can see the 
> screen shot



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (QPID-7258) [Python Client for AMQP 0-8...0-9-1] Perform hostname verification of ssl/tls connections

[Lorenz Quack (JIRA)]

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

Lorenz Quack resolved QPID-7258.

Resolution: Fixed

> [Python Client for AMQP 0-8...0-9-1] Perform hostname verification of ssl/tls 
> connections
> -
>
> Key: QPID-7258
> URL: https://issues.apache.org/jira/browse/QPID-7258
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Reporter: Lorenz Quack
> Fix For: qpid-python-next
>
> Attachments: 
> 0001-QPID-7258-Python-Client-for-AMQP-0-8.0-9-1-Perform-h.patch
>
>
> Currently, the Python client for AMQP 0-8...0-9-1 does not perform hostname 
> verification of tls connections. this opens the possibility of 
> Man-in-the-Middle attacks.
> We should enhance the client to have this ability, make it configurable and 
> turn the feature on by default.
> It should respect hostnames from both CN and SANs, and support wildcards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7258) [Python Client for AMQP 0-8...0-9-1] Perform hostname verification of ssl/tls connections

[ASF subversion and git services (JIRA)]

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

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

Commit 1743615 from [~lorenz.quack] in branch 'qpid/trunk'
[ https://svn.apache.org/r1743615 ]

QPID-7258: [Python Client for AMQP 0-8...0-9-1] Remove superfluous import 
(review comment from @kwall)

> [Python Client for AMQP 0-8...0-9-1] Perform hostname verification of ssl/tls 
> connections
> -
>
> Key: QPID-7258
> URL: https://issues.apache.org/jira/browse/QPID-7258
> Project: Qpid
>  Issue Type: Bug
>  Components: Python Client
>Reporter: Lorenz Quack
> Fix For: qpid-python-next
>
> Attachments: 
> 0001-QPID-7258-Python-Client-for-AMQP-0-8.0-9-1-Perform-h.patch
>
>
> Currently, the Python client for AMQP 0-8...0-9-1 does not perform hostname 
> verification of tls connections. this opens the possibility of 
> Man-in-the-Middle attacks.
> We should enhance the client to have this ability, make it configurable and 
> turn the feature on by default.
> It should respect hostnames from both CN and SANs, and support wildcards.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (QPID-7255) Support delivery delay

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-7255 at 5/13/16 8:06 AM:
---

I agree that it would be odd if the messages with delay were available for 
browsing.

What would the behaviour of the feature be if the Broker or Virtualhost was 
stopped for a period?  Or a HA master switch?   One would hope that after a 
restart, the delay on any existing persistent message would continue to be 
respected and be released to consumers at the publisher's originally intended 
release time (or immediately if the time has already passed).  I think this 
implies that the Broker's store needs to be capable of storing an absolute 
delayExpirationTime.


Also are there any implications for federation?   Would it be the 
responsibility of the Broker the first receives the message to not release the 
message until the delay expires and then ensure that the message is transferred 
to other Brokers in the federated network in such a way that they don't 
reimpose the delay again.



was (Author: k-wall):
I agree that it would be odd if the messages with delay were available for 
browsing.

What would the behaviour of the feature be if the Broker or Virtualhost was 
stopped for a period?One would hope that after a restart, the delay on any 
existing persistent message would continue to be respected and be released to 
consumers at the publisher's originally intended release time (or immediately 
if the time has already passed).  I think this implies that the Broker's store 
needs to be capable of storing an absolute delayExpirationTime.



> Support delivery delay
> --
>
> Key: QPID-7255
> URL: https://issues.apache.org/jira/browse/QPID-7255
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
>
> Some enterprise messaging systems provide a delayed delivery feature whereby 
> a publisher can provide a delivery time when sending the message, with the 
> Broker taking care of not making the message available to consumers until 
> that time is reached.  The Java Broker should provide the same feature.
> In the Java space, JMS 2.0 has standardised this feature, however  there is 
> no reason why the feature could not be made available to older JMS 1.1 
> clients using a Qpid specific header. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (QPID-7255) Support delivery delay

[Keith Wall (JIRA)]

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

Keith Wall edited comment on QPID-7255 at 5/13/16 8:01 AM:
---

https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq/

Implements delay using a special exchange behaviour {{"x-delayed-message"}}.   
Application specifies messages delayed by adding a {{x-delay}} header which 
contains the number of milliseconds the message should be delayed by.

http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html_single/index.html#d0e5312

Application sets message header {{_HQ_SCHED_DELIVERY}} containing an absolute 
time.  (Wonder if there is some compensation for clock skew?).
 
http://activemq.apache.org/delay-and-schedule-message-delivery.html

Application sets message header {{AMQ_SCHEDULED_DELAY}} containing contains the 
number of milliseconds the message should be delayed by.
ActiveMQ also implements other value-add features in this same space - repeat 
periods, repetitions etc

https://www.ibm.com/support/knowledgecenter/#!/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q119200_.htm
Uses the JMS 2.0 API {{JMSProducer.setDeliveryDelay(long deliveryDelay)}}


was (Author: k-wall):

https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq/

Implements delay using a special exchange behaviour {{"x-delayed-message"}}.   
Application specifies messages delayed by adding a {{x-delay}} header which 
contains the number of milliseconds the message should be delayed by.

http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html_single/index.html#d0e5312

Application sets message header {{_HQ_SCHED_DELIVERY}} containing an absolute 
time.  (Wonder if there is some compensation for clock skew).
 
http://activemq.apache.org/delay-and-schedule-message-delivery.html

Application sets message header {{AMQ_SCHEDULED_DELAY}} containing contains the 
number of milliseconds the message should be delayed by.
ActiveMQ also implements other value-add features in this same space - repeat 
periods, repetitions etc

https://www.ibm.com/support/knowledgecenter/#!/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q119200_.htm
Uses the JMS 2.0 API {{JMSProducer.setDeliveryDelay(long deliveryDelay)}}

> Support delivery delay
> --
>
> Key: QPID-7255
> URL: https://issues.apache.org/jira/browse/QPID-7255
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
>
> Some enterprise messaging systems provide a delayed delivery feature whereby 
> a publisher can provide a delivery time when sending the message, with the 
> Broker taking care of not making the message available to consumers until 
> that time is reached.  The Java Broker should provide the same feature.
> In the Java space, JMS 2.0 has standardised this feature, however  there is 
> no reason why the feature could not be made available to older JMS 1.1 
> clients using a Qpid specific header. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7255) Support delivery delay

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7255:
--


https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq/

Implements delay using a special exchange behaviour {{"x-delayed-message"}}.   
Application specifies messages delayed by adding a {{x-delay}} header which 
contains the number of milliseconds the message should be delayed by.

http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html_single/index.html#d0e5312

Application sets message header {{_HQ_SCHED_DELIVERY}} containing an absolute 
time.  (Wonder if there is some compensation for clock skew).
 
http://activemq.apache.org/delay-and-schedule-message-delivery.html

Application sets message header {{AMQ_SCHEDULED_DELAY}} containing contains the 
number of milliseconds the message should be delayed by.
ActiveMQ also implements other value-add features in this same space - repeat 
periods, repetitions etc

https://www.ibm.com/support/knowledgecenter/#!/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q119200_.htm
Uses the JMS 2.0 API {{JMSProducer.setDeliveryDelay(long deliveryDelay)}}

> Support delivery delay
> --
>
> Key: QPID-7255
> URL: https://issues.apache.org/jira/browse/QPID-7255
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
>
> Some enterprise messaging systems provide a delayed delivery feature whereby 
> a publisher can provide a delivery time when sending the message, with the 
> Broker taking care of not making the message available to consumers until 
> that time is reached.  The Java Broker should provide the same feature.
> In the Java space, JMS 2.0 has standardised this feature, however  there is 
> no reason why the feature could not be made available to older JMS 1.1 
> clients using a Qpid specific header. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (QPID-7255) Support delivery delay

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-7255:
--

I agree that it would be odd if the messages with delay were available for 
browsing.

What would the behaviour of the feature be if the Broker or Virtualhost was 
stopped for a period?One would hope that after a restart, the delay on any 
existing persistent message would continue to be respected and be released to 
consumers at the publisher's originally intended release time (or immediately 
if the time has already passed).  I think this implies that the Broker's store 
needs to be capable of storing an absolute delayExpirationTime.



> Support delivery delay
> --
>
> Key: QPID-7255
> URL: https://issues.apache.org/jira/browse/QPID-7255
> Project: Qpid
>  Issue Type: New Feature
>  Components: Java Broker
>Reporter: Keith Wall
>
> Some enterprise messaging systems provide a delayed delivery feature whereby 
> a publisher can provide a delivery time when sending the message, with the 
> Broker taking care of not making the message available to consumers until 
> that time is reached.  The Java Broker should provide the same feature.
> In the Java space, JMS 2.0 has standardised this feature, however  there is 
> no reason why the feature could not be made available to older JMS 1.1 
> clients using a Qpid specific header. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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