[jira] [Commented] (DISPATCH-179) Refactor Router Core

[ASF subversion and git services (JIRA)]

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

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

Commit 73e23866049a6db8380630fe7b4236bd632f0649 in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=73e2386 ]

DISPATCH-179 - All but one test in system_tests_two_routers are passing...


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
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-6983) [Web Management Console] Add UI support for queries

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-6983:
-
Attachment: query-ui-prototype.tar.gz

> [Web Management Console] Add UI support for queries
> ---
>
> Key: QPID-6983
> URL: https://issues.apache.org/jira/browse/QPID-6983
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Attachments: query-ui-prototype.tar.gz
>
>
> Add the ability to the Web Management Console to submit queries (using the 
> feature added by QPID-6969) and view the results.  The results may need to be 
> paginated for display.



--
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-6983) [Web Management Console] Add UI support for queries

[Alex Rudyy (JIRA)]

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

Alex Rudyy updated QPID-6983:
-
Attachment: (was: query-ui-prototype.tar.gz)

> [Web Management Console] Add UI support for queries
> ---
>
> Key: QPID-6983
> URL: https://issues.apache.org/jira/browse/QPID-6983
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Attachments: query-ui-prototype.tar.gz
>
>
> Add the ability to the Web Management Console to submit queries (using the 
> feature added by QPID-6969) and view the results.  The results may need to be 
> paginated for display.



--
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-179) Refactor Router Core

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-179 - Removed multicast from address in 
test_02b_disp_to_closed_connection since it was not testing multicasticity and 
was misleading


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
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] (DISPATCH-243) Requesting information about a remote router returns info about the connected router

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-243:
--

Assignee: Ganesh Murthy

> Requesting information about a remote router returns info about the connected 
> router
> 
>
> Key: DISPATCH-243
> URL: https://issues.apache.org/jira/browse/DISPATCH-243
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 0.6
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Attachments: jsmanage.html, jsmanage2.html
>
>
> When connected to Router A, and making a request for info about Router B, the 
> info that is returned is for Router A.
> I'm using the proton javascript binding rhea.js and making a QUERY request. 
> Here is Router B's log entry for the request.
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent request 
> Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') on 
> link 0 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:736)
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent response:
>   Message(address='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', 
> properties={'statusDescription': 'OK', 'statusCode': 200}, body={'results': 
> [[4, 'router/QDR.A', 1, '0', 3, 0, 60, 0, 'QDR.A', 30, 'interior', 
> 'org.apache.qpid.dispatch.router', 0, 60, 'router/QDR.A']], 'attributeNames': 
> [u'raIntervalFlux', u'name', u'helloInterval', u'area', u'helloMaxAge', 
> u'linkCount', u'remoteLsMaxAge', u'addrCount', u'routerId', u'raInterval', 
> u'mode', u'type', u'nodeCount', u'mobileAddrMaxAge', u'identity']}, 
> reply_to=None, correlation_id='60')
>   Responding to: 
>   Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:715)



--
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-179) Refactor Router Core

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-179 - Removed test_08a_test_strip_message_annotations_out_timeout. The 
router now uses link-exclusion set to prevent looping by dropping delivery 
before it loops rather than after it has already looped


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
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-179) Refactor Router Core

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-179 - Removed test_02_multicast because it is the same as 
test_10_semantics_multicast. Also removed test_00_discard


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
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-7162) Simple refactoring AbstractAMQPConnection & sub-classes

[ASF subversion and git services (JIRA)]

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

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

Commit 1736906 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1736906 ]

QPID-7162: [Java Broker] Pull up logging of connection close

* AMQP 1.0 path now runs connection close as the connection subject and 
distinguishes between normal/abnormal closes

> Simple refactoring AbstractAMQPConnection & sub-classes
> ---
>
> Key: QPID-7162
> URL: https://issues.apache.org/jira/browse/QPID-7162
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> There is an opportunity for a code clean up in {{AbstractAMQPConnection}} and 
> its sub-classes.
> Some methods in the base classed can be pulled-up to the Abstract.  Methods 
> like getUnderlyingConnection are now dead,



--
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-179) Refactor Router Core

[ASF subversion and git services (JIRA)]

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

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

Commit c6c03937aec85ec4d3b0c93740f015e69ff03389 in qpid-dispatch's branch 
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=c6c0393 ]

DISPATCH-179 - Renamed callbacks in router_node.c to be clearly in two groups:
AMQP_* for callbacks invoked "from below" by the AMQP container
CORE_* for callbacks invoked "from above" by the router core


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
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-243) Requesting information about a remote router returns info about the connected router

[Ernest Allen (JIRA)]

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

Ernest Allen commented on DISPATCH-243:
---

Ah. This does indeed work. Thanks.

> Requesting information about a remote router returns info about the connected 
> router
> 
>
> Key: DISPATCH-243
> URL: https://issues.apache.org/jira/browse/DISPATCH-243
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 0.6
>Reporter: Ernest Allen
> Attachments: jsmanage.html, jsmanage2.html
>
>
> When connected to Router A, and making a request for info about Router B, the 
> info that is returned is for Router A.
> I'm using the proton javascript binding rhea.js and making a QUERY request. 
> Here is Router B's log entry for the request.
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent request 
> Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') on 
> link 0 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:736)
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent response:
>   Message(address='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', 
> properties={'statusDescription': 'OK', 'statusCode': 200}, body={'results': 
> [[4, 'router/QDR.A', 1, '0', 3, 0, 60, 0, 'QDR.A', 30, 'interior', 
> 'org.apache.qpid.dispatch.router', 0, 60, 'router/QDR.A']], 'attributeNames': 
> [u'raIntervalFlux', u'name', u'helloInterval', u'area', u'helloMaxAge', 
> u'linkCount', u'remoteLsMaxAge', u'addrCount', u'routerId', u'raInterval', 
> u'mode', u'type', u'nodeCount', u'mobileAddrMaxAge', u'identity']}, 
> reply_to=None, correlation_id='60')
>   Responding to: 
>   Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:715)



--
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-179) Refactor Router Core

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-179 - Modified wait_address in system_test.py to use unicode strings 
for attribute_names


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
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-7138) [Java Broker] Broker should detect duplicate IDs in configured objects

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7138:
-
Description: 
Currently UUID uniqueness is enforced only amongst immediate siblings.  This 
means that, say, a virtual host with queue with UUID A would reject a second 
queue with the same UUID A.  Currently if a second virtual host had a queue 
with same UUID A, this would be allowed.  This presents a problem for clients 
(including the Web Management Console) that expect UUID to be universally 
unique.

Change ACO so that object UUID are universally so.The validatation would 
need to be applied as new objects are created, as the Broker starts up and as 
Virtualhosts are recovered.  This latter may or may not be at start-up time.



  was:
Currently UUID uniqueness is enforced only amongst immediate siblings.  This 
means that, say, a virtual host with queue with UUID A would reject a second 
queue with the same UUID A.  Currently if a second virtual host had a queue 
with same UUID A, this would be allowed.  This presents a problem for clients 
(including the Web Management Console) that expect UUID to be universally 
unique.

Change ACO so that object UUID are universally so.The validate would need 
to be applied as new objects are created, as the Broker starts up and as 
Virtualhosts are recovered.  This latter may or may not be at start-up time.




> [Java Broker] Broker should detect duplicate IDs in configured objects
> --
>
> Key: QPID-7138
> URL: https://issues.apache.org/jira/browse/QPID-7138
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> Currently UUID uniqueness is enforced only amongst immediate siblings.  This 
> means that, say, a virtual host with queue with UUID A would reject a second 
> queue with the same UUID A.  Currently if a second virtual host had a queue 
> with same UUID A, this would be allowed.  This presents a problem for clients 
> (including the Web Management Console) that expect UUID to be universally 
> unique.
> Change ACO so that object UUID are universally so.The validatation would 
> need to be applied as new objects are created, as the Broker starts up and as 
> Virtualhosts are recovered.  This latter may or may not be at start-up time.



--
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-7138) [Java Broker] Broker should detect duplicate IDs in configured objects

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7138:
-
Description: 
Currently UUID uniqueness is enforced only amongst immediate siblings.  This 
means that, say, a virtual host with queue with UUID A would reject a second 
queue with the same UUID A.  Currently if a second virtual host had a queue 
with same UUID A, this would be allowed.  This presents a problem for clients 
(including the Web Management Console) that expect UUID to be universally 
unique.

Change ACO so that object UUID are universally so.The validate would need 
to be applied as new objects are created, as the Broker starts up and as 
Virtualhosts are recovered.  This latter may or may not be at start-up time.



  was:Currently duplicate IDs are only checked on configuration store levels, 
i.e. broker configuration store, virtual host configuration stores. However, if 
duplicate IDs are used in different virtual host configuration stores that will 
be unnoticed by the broker. Configured object names are used to refer 
configured objects from each other at the moment but IDs can be used for object 
referencing as well, for example, in result of manual editing of configuration 
files. We need to enforce ID integrity check and detect any duplicate IDs on 
broker on startup .


> [Java Broker] Broker should detect duplicate IDs in configured objects
> --
>
> Key: QPID-7138
> URL: https://issues.apache.org/jira/browse/QPID-7138
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1
>
>
> Currently UUID uniqueness is enforced only amongst immediate siblings.  This 
> means that, say, a virtual host with queue with UUID A would reject a second 
> queue with the same UUID A.  Currently if a second virtual host had a queue 
> with same UUID A, this would be allowed.  This presents a problem for clients 
> (including the Web Management Console) that expect UUID to be universally 
> unique.
> Change ACO so that object UUID are universally so.The validate would need 
> to be applied as new objects are created, as the Broker starts up and as 
> Virtualhosts are recovered.  This latter may or may not be at start-up time.



--
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-157) Add support for send timeout and request timeout options

[ASF subversion and git services (JIRA)]

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

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

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

QPIDJMS-157 Add timeout tests for temp Topic and Queue create / delete
handling.  

> Add support for send timeout and request timeout options
> 
>
> Key: QPIDJMS-157
> URL: https://issues.apache.org/jira/browse/QPIDJMS-157
> Project: Qpid JMS
>  Issue Type: New Feature
>  Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
>
> Add support for a timeout option for message sends.  In the case of failover 
> allow the send to timeout after some configured interval with an error 
> indicating the send failed.



--
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-243) Requesting information about a remote router returns info about the connected router

[Ted Ross (JIRA)]

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

Ted Ross commented on DISPATCH-243:
---

You can still do it with one link if you like.  If you use the "$management" 
address in your first request message,  that will always refer to the connected 
management agent.

> Requesting information about a remote router returns info about the connected 
> router
> 
>
> Key: DISPATCH-243
> URL: https://issues.apache.org/jira/browse/DISPATCH-243
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 0.6
>Reporter: Ernest Allen
> Attachments: jsmanage.html, jsmanage2.html
>
>
> When connected to Router A, and making a request for info about Router B, the 
> info that is returned is for Router A.
> I'm using the proton javascript binding rhea.js and making a QUERY request. 
> Here is Router B's log entry for the request.
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent request 
> Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') on 
> link 0 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:736)
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent response:
>   Message(address='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', 
> properties={'statusDescription': 'OK', 'statusCode': 200}, body={'results': 
> [[4, 'router/QDR.A', 1, '0', 3, 0, 60, 0, 'QDR.A', 30, 'interior', 
> 'org.apache.qpid.dispatch.router', 0, 60, 'router/QDR.A']], 'attributeNames': 
> [u'raIntervalFlux', u'name', u'helloInterval', u'area', u'helloMaxAge', 
> u'linkCount', u'remoteLsMaxAge', u'addrCount', u'routerId', u'raInterval', 
> u'mode', u'type', u'nodeCount', u'mobileAddrMaxAge', u'identity']}, 
> reply_to=None, correlation_id='60')
>   Responding to: 
>   Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:715)



--
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] [Closed] (DISPATCH-243) Requesting information about a remote router returns info about the connected router

[Ernest Allen (JIRA)]

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

Ernest Allen closed DISPATCH-243.
-
Resolution: Not A Bug

This presents a catch-22 when making management requests. 

If I create the link without an address, I can then set the to: address in the 
message and the request is routed correctly. However, I can't know what the to: 
address is without first receiving it from a request.

The solution for me is to create two links. The first link will contain the 
/$management address of the router to which I'm connected. It will just get the 
address of all the routers in the network. The second link will not contain an 
address and will be used to send all subsequent management requests.


> Requesting information about a remote router returns info about the connected 
> router
> 
>
> Key: DISPATCH-243
> URL: https://issues.apache.org/jira/browse/DISPATCH-243
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 0.6
>Reporter: Ernest Allen
> Attachments: jsmanage.html, jsmanage2.html
>
>
> When connected to Router A, and making a request for info about Router B, the 
> info that is returned is for Router A.
> I'm using the proton javascript binding rhea.js and making a QUERY request. 
> Here is Router B's log entry for the request.
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent request 
> Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') on 
> link 0 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:736)
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent response:
>   Message(address='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', 
> properties={'statusDescription': 'OK', 'statusCode': 200}, body={'results': 
> [[4, 'router/QDR.A', 1, '0', 3, 0, 60, 0, 'QDR.A', 30, 'interior', 
> 'org.apache.qpid.dispatch.router', 0, 60, 'router/QDR.A']], 'attributeNames': 
> [u'raIntervalFlux', u'name', u'helloInterval', u'area', u'helloMaxAge', 
> u'linkCount', u'remoteLsMaxAge', u'addrCount', u'routerId', u'raInterval', 
> u'mode', u'type', u'nodeCount', u'mobileAddrMaxAge', u'identity']}, 
> reply_to=None, correlation_id='60')
>   Responding to: 
>   Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', correlation_id='60') 
> (/home/eallen/workspace/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py:715)



--
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 45340: turn off async ANONYMOUS SASL negotiation by default

[Andrew Stitcher]

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



NAK.

The implementation is fundamentally wrong.

But, I think this change is wrong headed, because it is my view that pipelining 
is in the protocol spec, and is a useful feature (in admittedly very limited 
circumstances)

However if you want to get rid of for interop reasons then there is no reason 
for a switch - a user can *never* know to turn it on as they can'tbe sure of 
the implementation at the other end.

The bigger issue is that peer implementations won't get fixed to accept 
pipeling and this will inhibit very small AMQP implementations from being 
usable because they won't interoperate.


proton-c/src/sasl/sasl.c (line 363)


You can't do this here.

It breaks the design of the code.

There are pn_output_write_*_header() routines in several places and their 
purpose is only to copy bytes around (for the appropriate protocol header).

Further pni_sasl_force_anonymous() is designed to happen on the input side 
as it changes the state machine. This change calls it on the output side.



proton-c/src/sasl/sasl.c (line 652)


I think adding more inscrutable booleans is a bad idea.

If we really need to stop pipelining. Then just stop doing it, there is no 
reasonable way a user can know to turn it on or off. It is part of the protocol 
so turning it on is purely an interop work around.

But presumable there is no way to know who is at the other end, so there is 
no way to ever turn it on if we suspect that some peer implementations may be 
broken.


- Andrew Stitcher


On March 25, 2016, 7:16 p.m., Cliff Jansen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45340/
> ---
> 
> (Updated March 25, 2016, 7:16 p.m.)
> 
> 
> Review request for qpid.
> 
> 
> Bugs: PROTON-1135
> https://issues.apache.org/jira/browse/PROTON-1135
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> Add new sasl api methods:
> 
>   pn_sasl_set_async_negotiation
>   pn_sasl_get_async_negotiation
>   
> Turn async off by default
> 
> Add python test.
> 
> 
> Diffs
> -
> 
>   proton-c/bindings/python/proton/__init__.py 5ffede8 
>   proton-c/include/proton/sasl.h 354982f 
>   proton-c/src/sasl/sasl-internal.h b3f4c7f 
>   proton-c/src/sasl/sasl.c 29d377e 
>   tests/python/proton_tests/engine.py 0a6eb8d 
>   tests/python/proton_tests/sasl.py 6adb77d 
> 
> Diff: https://reviews.apache.org/r/45340/diff/
> 
> 
> Testing
> ---
> 
> linux ctest
> 
> 
> Thanks,
> 
> Cliff Jansen
> 
>

[jira] [Updated] (QPID-7122) CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection fails sporadically on slow CI

[Keith Wall (JIRA)]

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

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

> CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection 
> fails sporadically on slow CI
> --
>
> Key: QPID-7122
> URL: https://issues.apache.org/jira/browse/QPID-7122
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> The following test failed on Apache CI:
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/2155/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-9-1/testReport/junit/org.apache.qpid.test.client/CloseOnNoRouteForMandatoryMessageTest/testNoRoute_brokerClosesConnection/
> The test is race because it depends on how quickly the socket is closed after 
> the connection level exception.
> {noformat}
> org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection
> Failing for the past 1 build (Since Failed#2155 )
> Took 0.71 sec.
> add description
> Error Message
> javax.jms.JMSException: Session exception occurred while trying to commit: 
> sender for socket /127.0.0.1:47193-localhost/127.0.0.1:33467 is closed 
> message should contain intended queue name
> Stacktrace
> java.lang.AssertionError: javax.jms.JMSException: Session exception occurred 
> while trying to commit: sender for socket 
> /127.0.0.1:47193-localhost/127.0.0.1:33467 is closed message should contain 
> intended queue name
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.qpid.test.client.UnroutableMessageTestExceptionListener.assertNoRoute(UnroutableMessageTestExceptionListener.java:140)
>   at 
> org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection(CloseOnNoRouteForMandatoryMessageTest.java:90)
> Standard Output
> 18:51:19,397 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - 
> About to instantiate appender of type [ch.qos.logback.core.FileAppender]
> 18:51:19,397 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - 
> Naming appender as 
> [FILE-org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection]
> 18:51:19,397 |-INFO in 
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default 
> type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] 
> property
> 18:51:19,398 |-INFO in 
> ch.qos.logback.core.FileAppender[FILE-org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection]
>  - File property is set to 
> [/home/jenkins/jenkins-slave/workspace/Qpid-Java-Java-BDB-TestMatrix/jdk/JDK 
> 1.7 
> (latest)/label/Ubuntu/profile/java-bdb.0-9-1/systests/target/surefire-reports/java-bdb.0-9-1/TEST-org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection.txt]
> {noformat}
> Stack trace:
> {noformat}
> javax.jms.JMSException: Session exception occurred while trying to commit: 
> sender for socket /127.0.0.1:47193-localhost/127.0.0.1:33467 is closed
>   at 
> org.apache.qpid.client.AMQSession.toJMSException(AMQSession.java:3701) 
> ~[qpid-client-6.1.0-SNAPSHOT.jar:na]
>   at org.apache.qpid.client.AMQSession.commit(AMQSession.java:880) 
> ~[qpid-client-6.1.0-SNAPSHOT.jar:na]
>   at 
> org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection(CloseOnNoRouteForMandatoryMessageTest.java:78)
>  ~[test-classes/:na]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.7.0_80]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> ~[na:1.7.0_80]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.7.0_80]
>   at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_80]
>   at junit.framework.TestCase.runTest(TestCase.java:176) 
> [junit-4.11.jar:na]
>   at 
> org.apache.qpid.test.utils.QpidTestCase.runTest(QpidTestCase.java:171) 
> [qpid-test-utils-6.1.0-SNAPSHOT.jar:na]
>   at junit.framework.TestCase.runBare(TestCase.java:141) 
> [junit-4.11.jar:na]
>   at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:138)
>  [classes/:na]
>   at junit.framework.TestResult$1.protect(TestResult.java:122) 
> [junit-4.11.jar:na]
>   at junit.framework.TestResult.runProtected(TestResult.java:142) 
> [junit-4.11.jar:na]
>   at junit.framework.TestResult.run(TestResult.java:125) 
> [junit-4.11.jar:na]
>   at junit.framewo

[jira] [Closed] (QPID-7122) CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection fails sporadically on slow CI

[Keith Wall (JIRA)]

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

Keith Wall closed QPID-7122.

Resolution: Fixed

> CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection 
> fails sporadically on slow CI
> --
>
> Key: QPID-7122
> URL: https://issues.apache.org/jira/browse/QPID-7122
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Tests
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> The following test failed on Apache CI:
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-BDB-TestMatrix/2155/jdk=JDK%201.7%20(latest),label=Ubuntu,profile=java-bdb.0-9-1/testReport/junit/org.apache.qpid.test.client/CloseOnNoRouteForMandatoryMessageTest/testNoRoute_brokerClosesConnection/
> The test is race because it depends on how quickly the socket is closed after 
> the connection level exception.
> {noformat}
> org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection
> Failing for the past 1 build (Since Failed#2155 )
> Took 0.71 sec.
> add description
> Error Message
> javax.jms.JMSException: Session exception occurred while trying to commit: 
> sender for socket /127.0.0.1:47193-localhost/127.0.0.1:33467 is closed 
> message should contain intended queue name
> Stacktrace
> java.lang.AssertionError: javax.jms.JMSException: Session exception occurred 
> while trying to commit: sender for socket 
> /127.0.0.1:47193-localhost/127.0.0.1:33467 is closed message should contain 
> intended queue name
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> org.apache.qpid.test.client.UnroutableMessageTestExceptionListener.assertNoRoute(UnroutableMessageTestExceptionListener.java:140)
>   at 
> org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection(CloseOnNoRouteForMandatoryMessageTest.java:90)
> Standard Output
> 18:51:19,397 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - 
> About to instantiate appender of type [ch.qos.logback.core.FileAppender]
> 18:51:19,397 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - 
> Naming appender as 
> [FILE-org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection]
> 18:51:19,397 |-INFO in 
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default 
> type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] 
> property
> 18:51:19,398 |-INFO in 
> ch.qos.logback.core.FileAppender[FILE-org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection]
>  - File property is set to 
> [/home/jenkins/jenkins-slave/workspace/Qpid-Java-Java-BDB-TestMatrix/jdk/JDK 
> 1.7 
> (latest)/label/Ubuntu/profile/java-bdb.0-9-1/systests/target/surefire-reports/java-bdb.0-9-1/TEST-org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection.txt]
> {noformat}
> Stack trace:
> {noformat}
> javax.jms.JMSException: Session exception occurred while trying to commit: 
> sender for socket /127.0.0.1:47193-localhost/127.0.0.1:33467 is closed
>   at 
> org.apache.qpid.client.AMQSession.toJMSException(AMQSession.java:3701) 
> ~[qpid-client-6.1.0-SNAPSHOT.jar:na]
>   at org.apache.qpid.client.AMQSession.commit(AMQSession.java:880) 
> ~[qpid-client-6.1.0-SNAPSHOT.jar:na]
>   at 
> org.apache.qpid.test.client.CloseOnNoRouteForMandatoryMessageTest.testNoRoute_brokerClosesConnection(CloseOnNoRouteForMandatoryMessageTest.java:78)
>  ~[test-classes/:na]
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.7.0_80]
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
> ~[na:1.7.0_80]
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.7.0_80]
>   at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_80]
>   at junit.framework.TestCase.runTest(TestCase.java:176) 
> [junit-4.11.jar:na]
>   at 
> org.apache.qpid.test.utils.QpidTestCase.runTest(QpidTestCase.java:171) 
> [qpid-test-utils-6.1.0-SNAPSHOT.jar:na]
>   at junit.framework.TestCase.runBare(TestCase.java:141) 
> [junit-4.11.jar:na]
>   at 
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:138)
>  [classes/:na]
>   at junit.framework.TestResult$1.protect(TestResult.java:122) 
> [junit-4.11.jar:na]
>   at junit.framework.TestResult.runProtected(TestResult.java:142) 
> [junit-4.11.jar:na]
>   at junit.framework.TestResult.run(TestResult.java:125) 
> [junit-4.11.jar:na]
>   at junit.framework.TestCase.r

[jira] [Commented] (DISPATCH-179) Refactor Router Core

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-179 - Increment counter j in qdr_agent_set_columns so that the 
query->columns is set correctly


> Refactor Router Core
> 
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the 
> significant lock contention issue that exists in 0.5.



--
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-243) Requesting information about a remote router returns info about the connected router

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy edited comment on DISPATCH-243 at 3/28/16 12:42 PM:
--

Case 1 (using Ernie's reproducer)
On using the reproducer provided by Ernie (jsmanage2.html), the first inbound 
attach frame has a target address of /$management like here -
{noformat}
[0x7ffbb4011230]:0 <- @attach(18) [name="ed3e3cb1-f719-4d97-91c3-4d00db5ce802", 
handle=0, role=false, target=@target(41) [address="/$management"], 
initial-delivery-count=0]
{noformat}
Notice above that the target address on the link is set to /$management. Also, 
the address on the message "to" field is set to amqp:/_topo/0/QDR.B/$management

Case 2 (using qdmanage)
Now, when I used the qdmanage tool to do a QUERY operation, I am seeing that 
the first inbound attach frame has a target address of 
_topo/0/QDR.B/$management like here -
{noformat}
[0xaaa720]:0 <- @attach(18) 
[name="38bb9314-055e-4485-927d-481250be534e-_topo/0/QDR.B/$management", 
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
[durable=0, timeout=0, dynamic=false], target=@target(41) 
[address="_topo/0/QDR.B/$management", durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0]
{noformat}
Note here that the target address on the link is set to 
_topo/0/QDR.B/$management (and not to /$management like in Case 1)

According to Ted Ross - 
Pre-merge, the router only looked at the link target address if there was no 
address in the message.  Post-merge, the link target address, if present, 
always takes precedence over an address in the message.  The post-merge 
behavior is the correct behavior.

To fix this issue, the javascript needs to be modified to exactly do what 
qdmanage is doing, namely create a link with a target address of 
_topo/0/QDR.B/$management and send the QUERY request over the link.

The other possibility is to create a link with no target address.  In
this case, the message addresses will be used individually as before.


was (Author: ganeshmurthy):

Case 1 (using Ernie's reproducer)
On using the reproducer provided by Ernie (jsmanage2.html), the first inbound 
attach frame has a target address of /$management like here -
{noformat}
[0x7ffbb4011230]:0 <- @attach(18) [name="ed3e3cb1-f719-4d97-91c3-4d00db5ce802", 
handle=0, role=false, target=@target(41) [address="/$management"], 
initial-delivery-count=0]
{noformat}
Notice above that the target address on the link is set to /$management. Also, 
the address on the message "to" field is set to amqp:/_topo/0/QDR.B/$management

Case 2 (using qdmanage)
Now, when I used the qdmanage tool to do a QUERY operation, I am seeing that 
the first inbound attach frame has a target address of 
_topo/0/QDR.B/$management like here -
{noformat}
[0xaaa720]:0 <- @attach(18) 
[name="38bb9314-055e-4485-927d-481250be534e-_topo/0/QDR.B/$management", 
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
[durable=0, timeout=0, dynamic=false], target=@target(41) 
[address="_topo/0/QDR.B/$management", durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0]
{noformat}
Note here that the target address on the link is set to 
_topo/0/QDR.B/$management (and not to /$management like in Case 1)

According to Ted Ross - 
Pre-merge, the router only looked at the link target address if there was no 
address in the message.  Post-merge, the link target address, if present, 
always takes precedence over an address in the message.  The post-merge 
behavior is the correct behavior.

To fix this issue, the javascript needs to be modified to exactly do what 
qdmanage is doing, namely create a link with a target address of 
_topo/0/QDR.B/$management and send the QUERY request over the link.

> Requesting information about a remote router returns info about the connected 
> router
> 
>
> Key: DISPATCH-243
> URL: https://issues.apache.org/jira/browse/DISPATCH-243
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 0.6
>Reporter: Ernest Allen
> Attachments: jsmanage.html, jsmanage2.html
>
>
> When connected to Router A, and making a request for info about Router B, the 
> info that is returned is for Router A.
> I'm using the proton javascript binding rhea.js and making a QUERY request. 
> Here is Router B's log entry for the request.
> Thu Mar 24 03:40:06 2016 AGENT (debug) Agent request 
> Message(address='amqp://0.0.0.0:5673/_topo/0/QDR.B/$management', 
> properties={'operation': 'QUERY', 'entityType': 'router', 'type': 
> 'org.amqp.management', 'name': 'self'}, body={'attributeNames': []}, 
> reply_to='amqp:/_topo/0/QDR.A/temp.43z0E5iKdp4hMed', cor

[jira] [Commented] (QPID-7095) [Java Broker] Add meta data for context variables describing their usage

[Rob Godfrey (JIRA)]

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

Rob Godfrey commented on QPID-7095:
---

{quote}
>From reviewing your changes I take the following:
* yes, my understanding of the intended use of {{@ManagedContextDependency}} is 
correct.
* no, the problem was not that {{doWithAllParents}} considers the type 
hierarchy instead of the model hierarchy
{quote}

Yep... The interesting thing I found when looking into the issue was that 
context defaults defined in {{Broker}} didn't seem to be being processed at 
all... I couldn't determine which change had caused this behaviour.

Separately, on your final point in your original comment:

bq. * While not being directly related to your patch I think I would like to 
see the default values for ManagedAttributes and ManagedContextDefaults in the 
ApiDocs and the MetaData.

I'm in two minds about this - at run time the default value may be overridden 
by a system property (potentially automatically overridden through packaged 
properties files) and obviously at different points in the configuration, the 
context may be overridden.  As such the "default" may be wildly misleading.

I think if we want to display the defaults somewhere, maybe there should be a 
separate page which just shows system context name -> default value or 
something.

> [Java Broker] Add meta data for context variables describing their usage
> 
>
> Key: QPID-7095
> URL: https://issues.apache.org/jira/browse/QPID-7095
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>
> Currently there is no way to discover which context variables are used by the 
> broker, and the description of what they do.  We should add meta data 
> covering this and also provide this information through the dynamic API docs.



--
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-7095) [Java Broker] Add meta data for context variables describing their usage

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7095:


tl;dr: I think this is okay, now! The mechanism is in place but we still need 
to add the actual information.

>From reviewing your changes I take the following:
* yes, my understanding of the intended use of {{@ManagedContextDependency}} is 
correct.
* no, the problem was not that {{doWithAllParents}} considers the type 
hierarchy instead of the model hierarchy

I found the last point a bit confusing because the declaration of a default 
context variable is a global operation while overriding/setting it is a local 
operation only affecting children in the model hierarchy. The code under review 
is only concerned with the declaration part not with the setting therefore 
considering the type hierarchy is fine as long as all are processed eventually.



> [Java Broker] Add meta data for context variables describing their usage
> 
>
> Key: QPID-7095
> URL: https://issues.apache.org/jira/browse/QPID-7095
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>
> Currently there is no way to discover which context variables are used by the 
> broker, and the description of what they do.  We should add meta data 
> covering this and also provide this information through the dynamic API docs.



--
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-6983) [Web Management Console] Add UI support for queries

[ASF subversion and git services (JIRA)]

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

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

Commit 1736850 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1736850 ]

QPID-6983: Revert unintendent changes with work in progress committed by mistake

> [Web Management Console] Add UI support for queries
> ---
>
> Key: QPID-6983
> URL: https://issues.apache.org/jira/browse/QPID-6983
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Attachments: query-ui-prototype.tar.gz
>
>
> Add the ability to the Web Management Console to submit queries (using the 
> feature added by QPID-6969) and view the results.  The results may need to be 
> paginated for display.



--
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-7112) Create UI for the CloudFoundry Group Provider

[Lorenz Quack (JIRA)]

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

Lorenz Quack commented on QPID-7112:


Thanks Alex.
For now I check explicitly for the string "undefined" and replace it with the 
empty string. This should revert to the old behaviour.
One problem with this is that if someone puts in "undefined" as the actual 
value it will be ignored :(
Unfortunately, I did not find a way to make dojo behave in a reasonable way. 
There seems to be no way to reliably determine whether an attribute is defined 
on a widget or not.

> Create UI for the CloudFoundry Group Provider
> -
>
> Key: QPID-7112
> URL: https://issues.apache.org/jira/browse/QPID-7112
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7112-Java-Broker-Add-UI-for-CloudFoundryDashboa.patch, 
> 0001-QPID-7112-Java-Broker-Add-UI-for-CloudFoundryDashboa.patch
>
>
> Create UI for the CloudFoundry Group Provider



--
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-6983) [Web Management Console] Add UI support for queries

[ASF subversion and git services (JIRA)]

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

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

Commit 1736847 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1736847 ]

QPID-6983: WIP - Add query UI

> [Web Management Console] Add UI support for queries
> ---
>
> Key: QPID-6983
> URL: https://issues.apache.org/jira/browse/QPID-6983
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Attachments: query-ui-prototype.tar.gz
>
>
> Add the ability to the Web Management Console to submit queries (using the 
> feature added by QPID-6969) and view the results.  The results may need to be 
> paginated for display.



--
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-7112) Create UI for the CloudFoundry Group Provider

[ASF subversion and git services (JIRA)]

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

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

Commit 1736848 from [~lorenz.quack] in branch 'java/trunk'
[ https://svn.apache.org/r1736848 ]

QPID-7112: [Java Broker] fixed util.getFormWidgetValues in util.js

dojo's widget.get() returns the string "undefined" whereas accessing the 
property directly return an empty string.
This commit should go back to the old behaviour by explicitly checking for the 
"undefined" string.
This will cause problems if there is a property or a value called "undefined".

> Create UI for the CloudFoundry Group Provider
> -
>
> Key: QPID-7112
> URL: https://issues.apache.org/jira/browse/QPID-7112
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7112-Java-Broker-Add-UI-for-CloudFoundryDashboa.patch, 
> 0001-QPID-7112-Java-Broker-Add-UI-for-CloudFoundryDashboa.patch
>
>
> Create UI for the CloudFoundry Group Provider



--
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-7156) Possible Java Broker crash if connection is formed whilst virtualhost is stopping

[Lorenz Quack (JIRA)]

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

Lorenz Quack resolved QPID-7156.

Resolution: Fixed

looks good to me.

> Possible Java Broker crash if connection is formed whilst virtualhost is 
> stopping
> -
>
> Key: QPID-7156
> URL: https://issues.apache.org/jira/browse/QPID-7156
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7156-Java-Broker-Stop-new-connections-from-bein.patch
>
>
> As reported here:
> http://qpid.2158936.n2.nabble.com/Java-broker-crashes-after-stopping-vhost-td7640284.html
> A race condition leads to the possibility of a NPE if the virtualhost is 
> stopped as a new connection is formed.   In the unlucky case, the task to 
> associate the connection with the virtualhost gets executed after the virtual 
> host's network connection scheduler is shutdown.  This leads to a NPE. The 
> Broker detects the NPE and shuts itself down.
> {noformat}
> 2016-03-18 06:41:06,748 ERROR [IO-/172.24.102.24:51029] (o.a.q.s.Main) - 
> Uncaught exception, shutting down.
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:142)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:505)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:338)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:87)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:463) 
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
> Source) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source) ~[na:1.8.0_51]
> at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_51]
> "
> {noformat}



--
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-7156) Possible Java Broker crash if connection is formed whilst virtualhost is stopping

[ASF subversion and git services (JIRA)]

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

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

Commit 1736843 from [~k-wall] in branch 'java/branches/6.0.x'
[ https://svn.apache.org/r1736843 ]

QPID-7156: Exclude new test from CPP Profile

> Possible Java Broker crash if connection is formed whilst virtualhost is 
> stopping
> -
>
> Key: QPID-7156
> URL: https://issues.apache.org/jira/browse/QPID-7156
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7156-Java-Broker-Stop-new-connections-from-bein.patch
>
>
> As reported here:
> http://qpid.2158936.n2.nabble.com/Java-broker-crashes-after-stopping-vhost-td7640284.html
> A race condition leads to the possibility of a NPE if the virtualhost is 
> stopped as a new connection is formed.   In the unlucky case, the task to 
> associate the connection with the virtualhost gets executed after the virtual 
> host's network connection scheduler is shutdown.  This leads to a NPE. The 
> Broker detects the NPE and shuts itself down.
> {noformat}
> 2016-03-18 06:41:06,748 ERROR [IO-/172.24.102.24:51029] (o.a.q.s.Main) - 
> Uncaught exception, shutting down.
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:142)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:505)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:338)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:87)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:463) 
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
> Source) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source) ~[na:1.8.0_51]
> at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_51]
> "
> {noformat}



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

qpid_tests/broker_1_0 not in tests/setup.py

[Keith W]

Hi all,

I am trying to automate the running of the existing Python AMQP 1.0
broker tests against the Java Broker with the proton-c/cpp binary
dependencies built from their respective trunks.

I am installing the Python modules to a private site-package
directory, but I notice the tests/setup.py does not seem to install
the broker_1_0 module.  Is this an oversight? Or is the running of the
broker_1_0 tests different to the others?

Thanks in advance, Keith

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

[jira] [Commented] (QPID-7156) Possible Java Broker crash if connection is formed whilst virtualhost is stopping

[ASF subversion and git services (JIRA)]

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

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

Commit 1736838 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1736838 ]

QPID-7156: Exclude new test from CPP Profile

Correct typo in excluded name in rev. 1736751

> Possible Java Broker crash if connection is formed whilst virtualhost is 
> stopping
> -
>
> Key: QPID-7156
> URL: https://issues.apache.org/jira/browse/QPID-7156
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
> Attachments: 
> 0001-QPID-7156-Java-Broker-Stop-new-connections-from-bein.patch
>
>
> As reported here:
> http://qpid.2158936.n2.nabble.com/Java-broker-crashes-after-stopping-vhost-td7640284.html
> A race condition leads to the possibility of a NPE if the virtualhost is 
> stopped as a new connection is formed.   In the unlucky case, the task to 
> associate the connection with the virtualhost gets executed after the virtual 
> host's network connection scheduler is shutdown.  This leads to a NPE. The 
> Broker detects the NPE and shuts itself down.
> {noformat}
> 2016-03-18 06:41:06,748 ERROR [IO-/172.24.102.24:51029] (o.a.q.s.Main) - 
> Uncaught exception, shutting down.
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:142)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:505)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:338)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:87)
>  ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:463) 
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
> Source) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
> Source) ~[na:1.8.0_51]
> at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_51]
> "
> {noformat}



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