[jira] [Resolved] (QPIDJMS-588) failover URI with invalid/unused user-info in component URI not rejected, can be logged

[Robbie Gemmell (Jira)]

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

Robbie Gemmell resolved QPIDJMS-588.

Resolution: Fixed

> failover URI with invalid/unused user-info in component URI not rejected, can 
> be logged
> ---
>
> Key: QPIDJMS-588
> URL: https://issues.apache.org/jira/browse/QPIDJMS-588
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 1.8.0, 2.2.0
> Environment: We are currently using Apache Qpid 2.2.0
>Reporter: Patrick Gell
>Assignee: Robbie Gemmell
>Priority: Minor
>  Labels: password, security
> Fix For: 1.9.0, 2.3.0
>
>
> The clients documented connection URI config does not utilise user-info 
> details from the URI, with it actively refusing its presence in the base 
> non-failover connection URI, for example using 
> "amqp://erroneous-user:erroneous-pass@localhost:5672" will result in an 
> IllegalArgumentException when creating the connection factory.
> If however a failover URI is supplied with a component server connection URI 
> nested within it erroneously containing user-info detail, e.g 
> "failover:(amqp://erroneous-user:erroneous-pass@localhost:5672)", then they 
> remain invalid/unused as expected but do not currently result in the 
> IllegalArgumentException as in the non-failover case. Later code within the 
> client does not expect this invalid/unused user-info detail to be present, 
> and so can then log it.
> The erroneous presence of the invalid/unused user-info within a component of 
> a failover URI should also cause an IllegalArgumentException when creating 
> the connection factory.
>  
> 
> Original Description:
> If I have a failover URL with `user:password` configured than the password is 
> logged in plain text.
> {+}BrokerURL{+}: 
> failover:(amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672)
> +Log extract:+
> 2023-05-15 13:04:42.484  INFO [localhost:5672]] 
> org.apache.qpid.jms.JmsConnection        : Connection 
> ID:83323730-746c-4430-988f-e9e5f699dc1c:1 connected to server: 
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672
>  
> Expected behaviour:
> The password is masked in the log or an IllegalArgumentException is thrown 
> similar to the non failover URL:
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672 results in a 
> ...
> Caused by: java.lang.IllegalArgumentException: The supplied URI cannot 
> contain a User-Info section
>     at 
> org.apache.qpid.jms.JmsConnectionFactory.setRemoteURI(JmsConnectionFactory.java:406)
>     at 
> org.amqphub.spring.boot.jms.autoconfigure.AMQP10JMSConnectionFactoryFactory.createConnectionFactory(AMQP10JMSConnectionFactoryFactory.java:66)
>     ... 69 common frames omitted
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Assigned] (QPIDJMS-588) failover URI with invalid/unused user-info in component URI not rejected, can be logged

[Robbie Gemmell (Jira)]

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

Robbie Gemmell reassigned QPIDJMS-588:
--

Fix Version/s: 1.9.0
   2.3.0
Affects Version/s: 1.8.0
 Assignee: Robbie Gemmell

> failover URI with invalid/unused user-info in component URI not rejected, can 
> be logged
> ---
>
> Key: QPIDJMS-588
> URL: https://issues.apache.org/jira/browse/QPIDJMS-588
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 1.8.0, 2.2.0
> Environment: We are currently using Apache Qpid 2.2.0
>Reporter: Patrick Gell
>Assignee: Robbie Gemmell
>Priority: Minor
>  Labels: password, security
> Fix For: 1.9.0, 2.3.0
>
>
> The clients documented connection URI config does not utilise user-info 
> details from the URI, with it actively refusing its presence in the base 
> non-failover connection URI, for example using 
> "amqp://erroneous-user:erroneous-pass@localhost:5672" will result in an 
> IllegalArgumentException when creating the connection factory.
> If however a failover URI is supplied with a component server connection URI 
> nested within it erroneously containing user-info detail, e.g 
> "failover:(amqp://erroneous-user:erroneous-pass@localhost:5672)", then they 
> remain invalid/unused as expected but do not currently result in the 
> IllegalArgumentException as in the non-failover case. Later code within the 
> client does not expect this invalid/unused user-info detail to be present, 
> and so can then log it.
> The erroneous presence of the invalid/unused user-info within a component of 
> a failover URI should also cause an IllegalArgumentException when creating 
> the connection factory.
>  
> 
> Original Description:
> If I have a failover URL with `user:password` configured than the password is 
> logged in plain text.
> {+}BrokerURL{+}: 
> failover:(amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672)
> +Log extract:+
> 2023-05-15 13:04:42.484  INFO [localhost:5672]] 
> org.apache.qpid.jms.JmsConnection        : Connection 
> ID:83323730-746c-4430-988f-e9e5f699dc1c:1 connected to server: 
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672
>  
> Expected behaviour:
> The password is masked in the log or an IllegalArgumentException is thrown 
> similar to the non failover URL:
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672 results in a 
> ...
> Caused by: java.lang.IllegalArgumentException: The supplied URI cannot 
> contain a User-Info section
>     at 
> org.apache.qpid.jms.JmsConnectionFactory.setRemoteURI(JmsConnectionFactory.java:406)
>     at 
> org.amqphub.spring.boot.jms.autoconfigure.AMQP10JMSConnectionFactoryFactory.createConnectionFactory(AMQP10JMSConnectionFactoryFactory.java:66)
>     ... 69 common frames omitted
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (QPIDJMS-588) failover URI with invalid/unused user-info in component URI not rejected, can be logged

[ASF subversion and git services (Jira)]

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

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

Commit 01e49dc5706976a87c02976a17ae8691d7666356 in qpid-jms's branch 
refs/heads/1.x from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=01e49dc5 ]

QPIDJMS-588: throw IAE on attempt to create connection factory with invalid 
failover URI components containing User-Info

(cherry picked from commit b42d890e60308881eb654c4f115a786eaa7ba118)


> failover URI with invalid/unused user-info in component URI not rejected, can 
> be logged
> ---
>
> Key: QPIDJMS-588
> URL: https://issues.apache.org/jira/browse/QPIDJMS-588
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 2.2.0
> Environment: We are currently using Apache Qpid 2.2.0
>Reporter: Patrick Gell
>Priority: Minor
>  Labels: password, security
>
> The clients documented connection URI config does not utilise user-info 
> details from the URI, with it actively refusing its presence in the base 
> non-failover connection URI, for example using 
> "amqp://erroneous-user:erroneous-pass@localhost:5672" will result in an 
> IllegalArgumentException when creating the connection factory.
> If however a failover URI is supplied with a component server connection URI 
> nested within it erroneously containing user-info detail, e.g 
> "failover:(amqp://erroneous-user:erroneous-pass@localhost:5672)", then they 
> remain invalid/unused as expected but do not currently result in the 
> IllegalArgumentException as in the non-failover case. Later code within the 
> client does not expect this invalid/unused user-info detail to be present, 
> and so can then log it.
> The erroneous presence of the invalid/unused user-info within a component of 
> a failover URI should also cause an IllegalArgumentException when creating 
> the connection factory.
>  
> 
> Original Description:
> If I have a failover URL with `user:password` configured than the password is 
> logged in plain text.
> {+}BrokerURL{+}: 
> failover:(amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672)
> +Log extract:+
> 2023-05-15 13:04:42.484  INFO [localhost:5672]] 
> org.apache.qpid.jms.JmsConnection        : Connection 
> ID:83323730-746c-4430-988f-e9e5f699dc1c:1 connected to server: 
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672
>  
> Expected behaviour:
> The password is masked in the log or an IllegalArgumentException is thrown 
> similar to the non failover URL:
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672 results in a 
> ...
> Caused by: java.lang.IllegalArgumentException: The supplied URI cannot 
> contain a User-Info section
>     at 
> org.apache.qpid.jms.JmsConnectionFactory.setRemoteURI(JmsConnectionFactory.java:406)
>     at 
> org.amqphub.spring.boot.jms.autoconfigure.AMQP10JMSConnectionFactoryFactory.createConnectionFactory(AMQP10JMSConnectionFactoryFactory.java:66)
>     ... 69 common frames omitted
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (QPIDJMS-588) failover URI with invalid/unused user-info in component URI not rejected, can be logged

[ASF subversion and git services (Jira)]

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

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

Commit b42d890e60308881eb654c4f115a786eaa7ba118 in qpid-jms's branch 
refs/heads/main from Robbie Gemmell
[ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=b42d890e ]

QPIDJMS-588: throw IAE on attempt to create connection factory with invalid 
failover URI components containing User-Info


> failover URI with invalid/unused user-info in component URI not rejected, can 
> be logged
> ---
>
> Key: QPIDJMS-588
> URL: https://issues.apache.org/jira/browse/QPIDJMS-588
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 2.2.0
> Environment: We are currently using Apache Qpid 2.2.0
>Reporter: Patrick Gell
>Priority: Minor
>  Labels: password, security
>
> The clients documented connection URI config does not utilise user-info 
> details from the URI, with it actively refusing its presence in the base 
> non-failover connection URI, for example using 
> "amqp://erroneous-user:erroneous-pass@localhost:5672" will result in an 
> IllegalArgumentException when creating the connection factory.
> If however a failover URI is supplied with a component server connection URI 
> nested within it erroneously containing user-info detail, e.g 
> "failover:(amqp://erroneous-user:erroneous-pass@localhost:5672)", then they 
> remain invalid/unused as expected but do not currently result in the 
> IllegalArgumentException as in the non-failover case. Later code within the 
> client does not expect this invalid/unused user-info detail to be present, 
> and so can then log it.
> The erroneous presence of the invalid/unused user-info within a component of 
> a failover URI should also cause an IllegalArgumentException when creating 
> the connection factory.
>  
> 
> Original Description:
> If I have a failover URL with `user:password` configured than the password is 
> logged in plain text.
> {+}BrokerURL{+}: 
> failover:(amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672)
> +Log extract:+
> 2023-05-15 13:04:42.484  INFO [localhost:5672]] 
> org.apache.qpid.jms.JmsConnection        : Connection 
> ID:83323730-746c-4430-988f-e9e5f699dc1c:1 connected to server: 
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672
>  
> Expected behaviour:
> The password is masked in the log or an IllegalArgumentException is thrown 
> similar to the non failover URL:
> amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672 results in a 
> ...
> Caused by: java.lang.IllegalArgumentException: The supplied URI cannot 
> contain a User-Info section
>     at 
> org.apache.qpid.jms.JmsConnectionFactory.setRemoteURI(JmsConnectionFactory.java:406)
>     at 
> org.amqphub.spring.boot.jms.autoconfigure.AMQP10JMSConnectionFactoryFactory.createConnectionFactory(AMQP10JMSConnectionFactoryFactory.java:66)
>     ... 69 common frames omitted
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Updated] (QPIDJMS-588) failover URI with invalid/unused user-info in component URI not rejected, can be logged

[Robbie Gemmell (Jira)]

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

Robbie Gemmell updated QPIDJMS-588:
---
Description: 
The clients documented connection URI config does not utilise user-info details 
from the URI, with it actively refusing its presence in the base non-failover 
connection URI, for example using 
"amqp://erroneous-user:erroneous-pass@localhost:5672" will result in an 
IllegalArgumentException when creating the connection factory.

If however a failover URI is supplied with a component server connection URI 
nested within it erroneously containing user-info detail, e.g 
"failover:(amqp://erroneous-user:erroneous-pass@localhost:5672)", then they 
remain invalid/unused as expected but do not currently result in the 
IllegalArgumentException as in the non-failover case. Later code within the 
client does not expect this invalid/unused user-info detail to be present, and 
so can then log it.

The erroneous presence of the invalid/unused user-info within a component of a 
failover URI should also cause an IllegalArgumentException when creating the 
connection factory.

 



Original Description:

If I have a failover URL with `user:password` configured than the password is 
logged in plain text.

{+}BrokerURL{+}: 
failover:(amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672)

+Log extract:+
2023-05-15 13:04:42.484  INFO [localhost:5672]] 
org.apache.qpid.jms.JmsConnection        : Connection 
ID:83323730-746c-4430-988f-e9e5f699dc1c:1 connected to server: 
amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672

 

Expected behaviour:

The password is masked in the log or an IllegalArgumentException is thrown 
similar to the non failover URL:

amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672 results in a 

...

Caused by: java.lang.IllegalArgumentException: The supplied URI cannot contain 
a User-Info section
    at 
org.apache.qpid.jms.JmsConnectionFactory.setRemoteURI(JmsConnectionFactory.java:406)
    at 
org.amqphub.spring.boot.jms.autoconfigure.AMQP10JMSConnectionFactoryFactory.createConnectionFactory(AMQP10JMSConnectionFactoryFactory.java:66)
    ... 69 common frames omitted

 

  was:
If I have a failover URL with `user:password` configured than the password is 
logged in plain text.


{+}BrokerURL{+}: 
failover:(amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672)


+Log extract:+
2023-05-15 13:04:42.484  INFO [localhost:5672]] 
org.apache.qpid.jms.JmsConnection        : Connection 
ID:83323730-746c-4430-988f-e9e5f699dc1c:1 connected to server: 
amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672

 

Expected behaviour:

The password is masked in the log or an IllegalArgumentException is thrown 
similar to the non failover URL:

amqp://{*}myactivemquser:my-secure-password{*}@localhost:5672 results in a 

...

Caused by: java.lang.IllegalArgumentException: The supplied URI cannot contain 
a User-Info section
    at 
org.apache.qpid.jms.JmsConnectionFactory.setRemoteURI(JmsConnectionFactory.java:406)
    at 
org.amqphub.spring.boot.jms.autoconfigure.AMQP10JMSConnectionFactoryFactory.createConnectionFactory(AMQP10JMSConnectionFactoryFactory.java:66)
    ... 69 common frames omitted

 

Summary: failover URI with invalid/unused user-info in component URI 
not rejected, can be logged  (was: when invalid failover URI supplied, password 
can be present in log file)

> failover URI with invalid/unused user-info in component URI not rejected, can 
> be logged
> ---
>
> Key: QPIDJMS-588
> URL: https://issues.apache.org/jira/browse/QPIDJMS-588
> Project: Qpid JMS
>  Issue Type: Bug
>  Components: qpid-jms-client
>Affects Versions: 2.2.0
> Environment: We are currently using Apache Qpid 2.2.0
>Reporter: Patrick Gell
>Priority: Minor
>  Labels: password, security
>
> The clients documented connection URI config does not utilise user-info 
> details from the URI, with it actively refusing its presence in the base 
> non-failover connection URI, for example using 
> "amqp://erroneous-user:erroneous-pass@localhost:5672" will result in an 
> IllegalArgumentException when creating the connection factory.
> If however a failover URI is supplied with a component server connection URI 
> nested within it erroneously containing user-info detail, e.g 
> "failover:(amqp://erroneous-user:erroneous-pass@localhost:5672)", then they 
> remain invalid/unused as expected but do not currently result in the 
> IllegalArgumentException as in the non-failover case. Later code within the 
> client does not expect this invalid/unused user-i

[GitHub] [qpid-dispatch] ganeshmurthy closed pull request #1200: NO-JIRA: Added info about the -j flag so tests can execute faster

[GitBox]

ganeshmurthy closed pull request #1200:
URL: https://github.com/apache/qpid-dispatch/pull/1200


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [qpid-dispatch] jiridanek commented on a change in pull request #1200: NO-JIRA: Added info about the -j flag so tests can execute faster

[GitBox]

jiridanek commented on a change in pull request #1200:
URL: https://github.com/apache/qpid-dispatch/pull/1200#discussion_r628465112



##
File path: README
##
@@ -134,6 +134,13 @@ option.  Example:
 
 ctest --timeout 1500 -VV
 
+The Dispatch test suite has a number of tests. To shorten execution time of 
the test suite, use the -j2 flag. Example:
+
+ctest -j2 -VV
+
+The integer following the -j specifies the maximum number of concurrent jobs 
that are used to execute the tests.
+Higher numbers could lead to unexpected test failures.

Review comment:
   "... due to machine overload, which then causes missed timeouts in 
tests." Users should know that the tests themselves run concurrently just fine 
(or they should run fine), it's only the hardware which is not keeping up.
   
   "Reasonable value to use on a powerful developer laptop which provides good 
speed while does not suffer from spurious failures is `-j6`"




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [qpid-dispatch] jiridanek commented on a change in pull request #1200: NO-JIRA: Added info about the -j flag so tests can execute faster

[GitBox]

jiridanek commented on a change in pull request #1200:
URL: https://github.com/apache/qpid-dispatch/pull/1200#discussion_r628465112



##
File path: README
##
@@ -134,6 +134,13 @@ option.  Example:
 
 ctest --timeout 1500 -VV
 
+The Dispatch test suite has a number of tests. To shorten execution time of 
the test suite, use the -j2 flag. Example:
+
+ctest -j2 -VV
+
+The integer following the -j specifies the maximum number of concurrent jobs 
that are used to execute the tests.
+Higher numbers could lead to unexpected test failures.

Review comment:
   "... due to machine overload, which then causes missed timeouts in 
tests." Users should know that the tests themselves run concurrently just fine 
(or they should), it's only the hardware which is not keeping up.
   
   "Reasonable value to use on a powerful developer laptop which provides good 
speed while does not suffer from spurious failures is `-j6`"




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [qpid-dispatch] ganeshmurthy opened a new pull request #1200: NO-JIRA: Added info about the -j flag so tests can execute faster

[GitBox]

ganeshmurthy opened a new pull request #1200:
URL: https://github.com/apache/qpid-dispatch/pull/1200


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[jira] [Updated] (DISPATCH-1137) Connection info contains stale pointer to container id

[Robbie Gemmell (Jira)]

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

Robbie Gemmell updated DISPATCH-1137:
-
Fix Version/s: (was: 2.0.0)

> Connection info contains stale pointer to container id
> --
>
> Key: DISPATCH-1137
> URL: https://issues.apache.org/jira/browse/DISPATCH-1137
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.4.0
>
>
> On connection close the memory pointed to by the container name pointer in 
> the connection info structure has been freed (as found by valgrind).  Need to 
> keep a copy of the name.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Comment Edited] (DISPATCH-1414) Include source/target address in the policy DENY info messages

[Keith Wall (Jira)]

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

Keith Wall edited comment on DISPATCH-1414 at 9/10/19 7:24 AM:
---

Sorry - my error.  I thought that '' was the link name.  I see now that I 
am wrong.  It would of course, be nice to see the link name in the message too 
:).


was (Author: k-wall):
Sorry - my error.  I thought that '' was the link name.  I see now that I 
am wrong,

> Include source/target address in the policy DENY info messages
> --
>
> Key: DISPATCH-1414
> URL: https://issues.apache.org/jira/browse/DISPATCH-1414
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Chuck Rolke
>Priority: Major
> Attachments: DISPATCH-1414.txt
>
>
> The policy DENY info message currently omits the source/target address.  This 
> impedes the diagnosis of policy misconfigurations.  Currently the message 
> looks like this:
> {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', 
> rhost '10.128.6.1', vhost 'vv' based on link target name}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (DISPATCH-1414) Include source/target address in the policy DENY info messages

[Keith Wall (Jira)]

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

Keith Wall commented on DISPATCH-1414:
--

Sorry - my error.  I thought that '' was the link name.  I see now that I 
am wrong,

> Include source/target address in the policy DENY info messages
> --
>
> Key: DISPATCH-1414
> URL: https://issues.apache.org/jira/browse/DISPATCH-1414
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Chuck Rolke
>Priority: Major
> Attachments: DISPATCH-1414.txt
>
>
> The policy DENY info message currently omits the source/target address.  This 
> impedes the diagnosis of policy misconfigurations.  Currently the message 
> looks like this:
> {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', 
> rhost '10.128.6.1', vhost 'vv' based on link target name}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Closed] (DISPATCH-1414) Include source/target address in the policy DENY info messages

[Chuck Rolke (Jira)]

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

Chuck Rolke closed DISPATCH-1414.
-
  Assignee: Chuck Rolke
Resolution: Not A Bug

The requested information is already present.

> Include source/target address in the policy DENY info messages
> --
>
> Key: DISPATCH-1414
> URL: https://issues.apache.org/jira/browse/DISPATCH-1414
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Chuck Rolke
>Priority: Major
> Attachments: DISPATCH-1414.txt
>
>
> The policy DENY info message currently omits the source/target address.  This 
> impedes the diagnosis of policy misconfigurations.  Currently the message 
> looks like this:
> {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', 
> rhost '10.128.6.1', vhost 'vv' based on link target name}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (DISPATCH-1414) Include source/target address in the policy DENY info messages

[Chuck Rolke (Jira)]

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

Chuck Rolke updated DISPATCH-1414:
--
Attachment: DISPATCH-1414.txt

> Include source/target address in the policy DENY info messages
> --
>
> Key: DISPATCH-1414
> URL: https://issues.apache.org/jira/browse/DISPATCH-1414
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Keith Wall
>Priority: Major
> Attachments: DISPATCH-1414.txt
>
>
> The policy DENY info message currently omits the source/target address.  This 
> impedes the diagnosis of policy misconfigurations.  Currently the message 
> looks like this:
> {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', 
> rhost '10.128.6.1', vhost 'vv' based on link target name}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (DISPATCH-1414) Include source/target address in the policy DENY info messages

[Chuck Rolke (Jira)]

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

Chuck Rolke commented on DISPATCH-1414:
---

In the log entry the '' field is the name of the requested source or target.

Attached find a text file that shows two trace snippets. Each has the proton 
trace of the attach frame and policy log of the denial. There you can correlate 
the name requested by the attach and the policy message showing the name when 
the request was denied.

> Include source/target address in the policy DENY info messages
> --
>
> Key: DISPATCH-1414
> URL: https://issues.apache.org/jira/browse/DISPATCH-1414
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Keith Wall
>    Priority: Major
>
> The policy DENY info message currently omits the source/target address.  This 
> impedes the diagnosis of policy misconfigurations.  Currently the message 
> looks like this:
> {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', 
> rhost '10.128.6.1', vhost 'vv' based on link target name}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Created] (DISPATCH-1414) Include source/target address in the policy DENY info messages

[Keith Wall (Jira)]

Keith Wall created DISPATCH-1414:


 Summary: Include source/target address in the policy DENY info 
messages
 Key: DISPATCH-1414
 URL: https://issues.apache.org/jira/browse/DISPATCH-1414
 Project: Qpid Dispatch
  Issue Type: Improvement
Reporter: Keith Wall


The policy DENY info message currently omits the source/target address.  This 
impedes the diagnosis of policy misconfigurations.  Currently the message looks 
like this:

{{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', 
rhost '10.128.6.1', vhost 'vv' based on link target name}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Resolved] (DISPATCH-1331) Add popup for routers/edge routers to display basic info

[Ernest Allen (JIRA)]

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

Ernest Allen resolved DISPATCH-1331.

Resolution: Implemented

> Add popup for routers/edge routers to display basic info
> 
>
> Key: DISPATCH-1331
> URL: https://issues.apache.org/jira/browse/DISPATCH-1331
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.7.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> There is a popup when you click on a client that displays connection and link 
> info.
> It would be useful to have a popup for a router/edge router that shows basic 
> router info like  Id and mode.
> In addition it should show columns for AddressCount, ConnectionCount, 
> LinkCount, and statistics. Each of these columns should be expandable to show 
> the appropriate detailed info



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

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

[jira] [Commented] (DISPATCH-1331) Add popup for routers/edge routers to display basic info

[ASF subversion and git services (JIRA)]

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

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

Commit ca6f853661a995b58473daa276e427278c7e7494 in qpid-dispatch's branch 
refs/heads/master from Ernest Allen
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=ca6f853 ]

DISPATCH-1331 Add router info popup to console's topology page


> Add popup for routers/edge routers to display basic info
> 
>
> Key: DISPATCH-1331
> URL: https://issues.apache.org/jira/browse/DISPATCH-1331
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.7.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> There is a popup when you click on a client that displays connection and link 
> info.
> It would be useful to have a popup for a router/edge router that shows basic 
> router info like  Id and mode.
> In addition it should show columns for AddressCount, ConnectionCount, 
> LinkCount, and statistics. Each of these columns should be expandable to show 
> the appropriate detailed info



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

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

[jira] [Created] (DISPATCH-1331) Add popup for routers/edge routers to display basic info

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-1331:
--

 Summary: Add popup for routers/edge routers to display basic info
 Key: DISPATCH-1331
 URL: https://issues.apache.org/jira/browse/DISPATCH-1331
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Console
Affects Versions: 1.7.0
Reporter: Ernest Allen
Assignee: Ernest Allen


There is a popup when you click on a client that displays connection and link 
info.

It would be useful to have a popup for a router/edge router that shows basic 
router info like  Id and mode.

In addition it should show columns for AddressCount, ConnectionCount, 
LinkCount, and statistics. Each of these columns should be expandable to show 
the appropriate detailed info



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

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

[jira] [Updated] (DISPATCH-1169) Remove stranded link info popup on console's topology page

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy updated DISPATCH-1169:

Fix Version/s: 1.5.0

> Remove stranded link info popup on console's topology page
> --
>
> Key: DISPATCH-1169
> URL: https://issues.apache.org/jira/browse/DISPATCH-1169
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.4.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.5.0
>
>
> Occasionally on the console's topology page when you mouse over a link to 
> display the link info popup, the popup will stay visible even when you mouse 
> out of the link. This obscures the display and you must either slowly mouse 
> over and out of a link again or click somewhere on the topolgy diagram.
> Make sure the link info popup is removed when the mouse leaves the link.



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

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

[jira] [Updated] (DISPATCH-1195) Continually update detail info on conole topology page

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy updated DISPATCH-1195:

Fix Version/s: 1.5.0

> Continually update detail info on conole topology page
> --
>
> Key: DISPATCH-1195
> URL: https://issues.apache.org/jira/browse/DISPATCH-1195
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.5.0
>
>
> When you click on clients (single or groups) on the topology page, a popup 
> appears that shows connection info in the case of clients, or edge router 
> info in the case of edge routers.
> This info is a snapshot taken at the time the client is clicked. The info 
> should be updated periodically while the popup is still visible.



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

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

[jira] [Commented] (DISPATCH-1195) Continually update detail info on conole topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-1195 Remove extraneous console log messages


> Continually update detail info on conole topology page
> --
>
> Key: DISPATCH-1195
> URL: https://issues.apache.org/jira/browse/DISPATCH-1195
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> When you click on clients (single or groups) on the topology page, a popup 
> appears that shows connection info in the case of clients, or edge router 
> info in the case of edge routers.
> This info is a snapshot taken at the time the client is clicked. The info 
> should be updated periodically while the popup is still visible.



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

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

[jira] [Commented] (DISPATCH-1195) Continually update detail info on conole topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-1195 Batch requests for large lists of edge routers.


> Continually update detail info on conole topology page
> --
>
> Key: DISPATCH-1195
> URL: https://issues.apache.org/jira/browse/DISPATCH-1195
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> When you click on clients (single or groups) on the topology page, a popup 
> appears that shows connection info in the case of clients, or edge router 
> info in the case of edge routers.
> This info is a snapshot taken at the time the client is clicked. The info 
> should be updated periodically while the popup is still visible.



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

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

[jira] [Commented] (DISPATCH-1169) Remove stranded link info popup on console's topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-1169 Avoid popup appearing after mouseout event


> Remove stranded link info popup on console's topology page
> --
>
> Key: DISPATCH-1169
> URL: https://issues.apache.org/jira/browse/DISPATCH-1169
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.4.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> Occasionally on the console's topology page when you mouse over a link to 
> display the link info popup, the popup will stay visible even when you mouse 
> out of the link. This obscures the display and you must either slowly mouse 
> over and out of a link again or click somewhere on the topolgy diagram.
> Make sure the link info popup is removed when the mouse leaves the link.



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

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

[jira] [Resolved] (DISPATCH-1195) Continually update detail info on conole topology page

[Ernest Allen (JIRA)]

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

Ernest Allen resolved DISPATCH-1195.

Resolution: Fixed

> Continually update detail info on conole topology page
> --
>
> Key: DISPATCH-1195
> URL: https://issues.apache.org/jira/browse/DISPATCH-1195
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> When you click on clients (single or groups) on the topology page, a popup 
> appears that shows connection info in the case of clients, or edge router 
> info in the case of edge routers.
> This info is a snapshot taken at the time the client is clicked. The info 
> should be updated periodically while the popup is still visible.



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

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

[jira] [Commented] (DISPATCH-1195) Continually update detail info on conole topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-1195 Periodically update popup detail on topology page


> Continually update detail info on conole topology page
> --
>
> Key: DISPATCH-1195
> URL: https://issues.apache.org/jira/browse/DISPATCH-1195
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> When you click on clients (single or groups) on the topology page, a popup 
> appears that shows connection info in the case of clients, or edge router 
> info in the case of edge routers.
> This info is a snapshot taken at the time the client is clicked. The info 
> should be updated periodically while the popup is still visible.



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

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

[jira] [Created] (DISPATCH-1195) Continually update detail info on conole topology page

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-1195:
--

 Summary: Continually update detail info on conole topology page
 Key: DISPATCH-1195
 URL: https://issues.apache.org/jira/browse/DISPATCH-1195
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Console
Reporter: Ernest Allen
Assignee: Ernest Allen


When you click on clients (single or groups) on the topology page, a popup 
appears that shows connection info in the case of clients, or edge router info 
in the case of edge routers.

This info is a snapshot taken at the time the client is clicked. The info 
should be updated periodically while the popup is still visible.



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

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

[jira] [Resolved] (DISPATCH-1169) Remove stranded link info popup on console's topology page

[Ernest Allen (JIRA)]

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

Ernest Allen resolved DISPATCH-1169.

Resolution: Fixed

The trick was to add a mouseout handler to the popup itself that sets the 
popup's display style to 'none'.

> Remove stranded link info popup on console's topology page
> --
>
> Key: DISPATCH-1169
> URL: https://issues.apache.org/jira/browse/DISPATCH-1169
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.4.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> Occasionally on the console's topology page when you mouse over a link to 
> display the link info popup, the popup will stay visible even when you mouse 
> out of the link. This obscures the display and you must either slowly mouse 
> over and out of a link again or click somewhere on the topolgy diagram.
> Make sure the link info popup is removed when the mouse leaves the link.



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

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

[jira] [Commented] (DISPATCH-1169) Remove stranded link info popup on console's topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-1169 Fix link info popup remaining on console's topology page


> Remove stranded link info popup on console's topology page
> --
>
> Key: DISPATCH-1169
> URL: https://issues.apache.org/jira/browse/DISPATCH-1169
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Console
>Affects Versions: 1.4.1
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> Occasionally on the console's topology page when you mouse over a link to 
> display the link info popup, the popup will stay visible even when you mouse 
> out of the link. This obscures the display and you must either slowly mouse 
> over and out of a link again or click somewhere on the topolgy diagram.
> Make sure the link info popup is removed when the mouse leaves the link.



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

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

[jira] [Created] (DISPATCH-1169) Remove stranded link info popup on console's topology page

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-1169:
--

 Summary: Remove stranded link info popup on console's topology page
 Key: DISPATCH-1169
 URL: https://issues.apache.org/jira/browse/DISPATCH-1169
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Console
Affects Versions: 1.4.1
Reporter: Ernest Allen
Assignee: Ernest Allen


Occasionally on the console's topology page when you mouse over a link to 
display the link info popup, the popup will stay visible even when you mouse 
out of the link. This obscures the display and you must either slowly mouse 
over and out of a link again or click somewhere on the topolgy diagram.

Make sure the link info popup is removed when the mouse leaves the link.



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

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

[jira] [Commented] (QPIDJMS-423) Avoid disclosing sensitive info when logging Remote Broker URI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on QPIDJMS-423:


Github user benoitdevos commented on the issue:

https://github.com/apache/qpid-jms/pull/23
  
@tabish121 I created 
[QPIDJMS-423](https://issues.apache.org/jira/browse/QPIDJMS-423) and changed 
the commit message.


> Avoid disclosing sensitive info when logging Remote Broker URI
> --
>
> Key: QPIDJMS-423
> URL: https://issues.apache.org/jira/browse/QPIDJMS-423
> Project: Qpid JMS
>  Issue Type: Improvement
>  Components: qpid-jms-client
>Affects Versions: 0.37.0
>Reporter: Benoit Devos
>Priority: Minor
>
> The broker URI may contain sensitive info (like path to trust / key stores, 
> and related *passwords*), and this info is being logged.
> Sample:
> {code:xml}
>  class="org.apache.qpid.jms.JmsConnectionFactory">
> 
> 
> {code}
> The method JmsConnection.onConnectionEstablished(final URI remoteURI) logs 
> this URI as is, therefore disclosing some passwords.
> Only essential info just be logged, i.e. scheme, host and port.



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

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

[jira] [Created] (QPIDJMS-423) Avoid disclosing sensitive info when logging Remote Broker URI

[Benoit Devos (JIRA)]

Benoit Devos created QPIDJMS-423:


 Summary: Avoid disclosing sensitive info when logging Remote 
Broker URI
 Key: QPIDJMS-423
 URL: https://issues.apache.org/jira/browse/QPIDJMS-423
 Project: Qpid JMS
  Issue Type: Improvement
  Components: qpid-jms-client
Affects Versions: 0.37.0
Reporter: Benoit Devos


The broker URI may contain sensitive info (like path to trust / key stores, and 
related *passwords*), and this info is being logged.

Sample:
{code:xml}



{code}

The method JmsConnection.onConnectionEstablished(final URI remoteURI) logs this 
URI as is, therefore disclosing some passwords.

Only essential info just be logged, i.e. scheme, host and port.



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

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

[jira] [Resolved] (DISPATCH-1137) Connection info contains stale pointer to container id

[Ken Giusti (JIRA)]

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

Ken Giusti resolved DISPATCH-1137.
--
Resolution: Fixed

> Connection info contains stale pointer to container id
> --
>
> Key: DISPATCH-1137
> URL: https://issues.apache.org/jira/browse/DISPATCH-1137
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.4.0, 2.0.0
>
>
> On connection close the memory pointed to by the container name pointer in 
> the connection info structure has been freed (as found by valgrind).  Need to 
> keep a copy of the name.



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

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

[jira] [Commented] (DISPATCH-1137) Connection info contains stale pointer to container id

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-1137:
--

Github user asfgit closed the pull request at:

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


> Connection info contains stale pointer to container id
> --
>
> Key: DISPATCH-1137
> URL: https://issues.apache.org/jira/browse/DISPATCH-1137
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.4.0, 2.0.0
>
>
> On connection close the memory pointed to by the container name pointer in 
> the connection info structure has been freed (as found by valgrind).  Need to 
> keep a copy of the name.



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

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

[jira] [Commented] (DISPATCH-1137) Connection info contains stale pointer to container id

[ASF subversion and git services (JIRA)]

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

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

Commit 3b1d84c969dad91d66641a719bc4374728902b58 in qpid-dispatch's branch 
refs/heads/master from Kenneth Giusti
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=3b1d84c ]

DISPATCH-1137: fix stale container name pointer in connection info

This closes #386


> Connection info contains stale pointer to container id
> --
>
> Key: DISPATCH-1137
> URL: https://issues.apache.org/jira/browse/DISPATCH-1137
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.4.0, 2.0.0
>
>
> On connection close the memory pointed to by the container name pointer in 
> the connection info structure has been freed (as found by valgrind).  Need to 
> keep a copy of the name.



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

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

[jira] [Commented] (DISPATCH-1137) Connection info contains stale pointer to container id

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-1137:
--

Github user codecov-io commented on the issue:

https://github.com/apache/qpid-dispatch/pull/386
  
# 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/386?src=pr&el=h1) 
Report
> Merging 
[#386](https://codecov.io/gh/apache/qpid-dispatch/pull/386?src=pr&el=desc) into 
[master](https://codecov.io/gh/apache/qpid-dispatch/commit/6689d5f1d6dc343ab0482befcf3286479aef2e04?src=pr&el=desc)
 will **decrease** coverage by `0.03%`.
> The diff coverage is `100%`.

[![Impacted file tree 
graph](https://codecov.io/gh/apache/qpid-dispatch/pull/386/graphs/tree.svg?width=650&token=rk2Cgd27pP&height=150&src=pr)](https://codecov.io/gh/apache/qpid-dispatch/pull/386?src=pr&el=tree)

```diff
@@Coverage Diff @@
##   master #386  +/-   ##
==
- Coverage   84.82%   84.79%   -0.04% 
==
  Files  73   73  
  Lines   1647516477   +2 
==
- Hits1397513971   -4 
- Misses   2500 2506   +6
```


| [Impacted 
Files](https://codecov.io/gh/apache/qpid-dispatch/pull/386?src=pr&el=tree) | 
Coverage Δ | |
|---|---|---|
| 
[src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/386/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=)
 | `93.08% <100%> (+0.01%)` | :arrow_up: |
| 
[src/router\_core/modules/core\_test\_hooks.c](https://codecov.io/gh/apache/qpid-dispatch/pull/386/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL21vZHVsZXMvY29yZV90ZXN0X2hvb2tzLmM=)
 | `87.02% <0%> (-1.63%)` | :arrow_down: |
| 
[src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/386/diff?src=pr&el=tree#diff-c3JjL21lc3NhZ2UuYw==)
 | `88.06% <0%> (-0.21%)` | :arrow_down: |
| 
[src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/386/diff?src=pr&el=tree#diff-c3JjL2NvbnRhaW5lci5j)
 | `76.55% <0%> (-0.2%)` | :arrow_down: |
| 
[src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/386/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=)
 | `93.61% <0%> (-0.14%)` | :arrow_down: |
| 
[src/router\_core/router\_core.c](https://codecov.io/gh/apache/qpid-dispatch/pull/386/diff?src=pr&el=tree#diff-c3JjL3JvdXRlcl9jb3JlL3JvdXRlcl9jb3JlLmM=)
 | `92.4% <0%> (+0.33%)` | :arrow_up: |

--

[Continue to review full report at 
Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/386?src=pr&el=continue).
> **Legend** - [Click here to learn 
more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute  (impact)`, `ø = not affected`, `? = missing data`
> Powered by 
[Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/386?src=pr&el=footer).
 Last update 
[6689d5f...91f16e6](https://codecov.io/gh/apache/qpid-dispatch/pull/386?src=pr&el=lastupdated).
 Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).



> Connection info contains stale pointer to container id
> --
>
> Key: DISPATCH-1137
> URL: https://issues.apache.org/jira/browse/DISPATCH-1137
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.4.0, 2.0.0
>
>
> On connection close the memory pointed to by the container name pointer in 
> the connection info structure has been freed (as found by valgrind).  Need to 
> keep a copy of the name.



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

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

[jira] [Commented] (DISPATCH-1137) Connection info contains stale pointer to container id

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-1137:
--

GitHub user kgiusti opened a pull request:

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

DISPATCH-1137: fix stale container name pointer in connection info



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

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

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

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

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

This closes #386


commit 91f16e6f4ee5ea65181e4ed2c22f2d4f50cdbf06
Author: Kenneth Giusti 
Date:   2018-10-03T15:22:13Z

DISPATCH-1137: fix stale container name pointer in connection info




> Connection info contains stale pointer to container id
> --
>
> Key: DISPATCH-1137
> URL: https://issues.apache.org/jira/browse/DISPATCH-1137
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.4.0, 2.0.0
>
>
> On connection close the memory pointed to by the container name pointer in 
> the connection info structure has been freed (as found by valgrind).  Need to 
> keep a copy of the name.



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

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

[jira] [Created] (DISPATCH-1137) Connection info contains stale pointer to container id

[Ken Giusti (JIRA)]

Ken Giusti created DISPATCH-1137:


 Summary: Connection info contains stale pointer to container id
 Key: DISPATCH-1137
 URL: https://issues.apache.org/jira/browse/DISPATCH-1137
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 1.3.0
Reporter: Ken Giusti
Assignee: Ken Giusti
 Fix For: 1.4.0, 2.0.0


On connection close the memory pointed to by the container name pointer in the 
connection info structure has been freed (as found by valgrind).  Need to keep 
a copy of the name.



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

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

[jira] [Resolved] (DISPATCH-1107) Need info for logs to help disambiguate router connections

[Chuck Rolke (JIRA)]

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

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

fixed at Commit df7667e

> Need info for logs to help disambiguate router connections
> --
>
> Key: DISPATCH-1107
> URL: https://issues.apache.org/jira/browse/DISPATCH-1107
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.4.0
>
>
> When connections are started by routers to other routers there is no reliable 
> way in the log files for telling the connections apart. Consider a pair of 
> routers where router A creates two connections and sends two Opens to router 
> B. A's log will show that connections [5] and [7] sent the Opens and B's log 
> will show that connections [4] and [6] received and replied to the Opens. But 
> there is no way to know if the connection pairs are '[A-5][B-4] and 
> [A-7][B-6]' or '[A-5][B-6] and [A-7][B-4]'.
> A simple solution to expose this relationship is for the routers to embed the 
> _connid_ in the Open properties. Then the connection relationships between 
> the two routers could be resolved from either router log file.



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

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

[jira] [Assigned] (DISPATCH-1107) Need info for logs to help disambiguate router connections

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-1107:
---

Assignee: Chuck Rolke

> Need info for logs to help disambiguate router connections
> --
>
> Key: DISPATCH-1107
> URL: https://issues.apache.org/jira/browse/DISPATCH-1107
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.4.0
>
>
> When connections are started by routers to other routers there is no reliable 
> way in the log files for telling the connections apart. Consider a pair of 
> routers where router A creates two connections and sends two Opens to router 
> B. A's log will show that connections [5] and [7] sent the Opens and B's log 
> will show that connections [4] and [6] received and replied to the Opens. But 
> there is no way to know if the connection pairs are '[A-5][B-4] and 
> [A-7][B-6]' or '[A-5][B-6] and [A-7][B-4]'.
> A simple solution to expose this relationship is for the routers to embed the 
> _connid_ in the Open properties. Then the connection relationships between 
> the two routers could be resolved from either router log file.



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

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

[jira] [Commented] (DISPATCH-1107) Need info for logs to help disambiguate router connections

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-1107: Add router connection id interrouter Opens

This feature helps disambiguate interrouter connections.
Topology tests generate many connections and resulting logs have the
connection ids. There is nothing topology-specific about this feature.


> Need info for logs to help disambiguate router connections
> --
>
> Key: DISPATCH-1107
> URL: https://issues.apache.org/jira/browse/DISPATCH-1107
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Affects Versions: 1.3.0
>Reporter: Chuck Rolke
>Priority: Major
> Fix For: 1.4.0
>
>
> When connections are started by routers to other routers there is no reliable 
> way in the log files for telling the connections apart. Consider a pair of 
> routers where router A creates two connections and sends two Opens to router 
> B. A's log will show that connections [5] and [7] sent the Opens and B's log 
> will show that connections [4] and [6] received and replied to the Opens. But 
> there is no way to know if the connection pairs are '[A-5][B-4] and 
> [A-7][B-6]' or '[A-5][B-6] and [A-7][B-4]'.
> A simple solution to expose this relationship is for the routers to embed the 
> _connid_ in the Open properties. Then the connection relationships between 
> the two routers could be resolved from either router log file.



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

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

[jira] [Created] (DISPATCH-1107) Need info for logs to help disambiguate router connections

[Chuck Rolke (JIRA)]

Chuck Rolke created DISPATCH-1107:
-

 Summary: Need info for logs to help disambiguate router connections
 Key: DISPATCH-1107
 URL: https://issues.apache.org/jira/browse/DISPATCH-1107
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Router Node
Affects Versions: 1.3.0
Reporter: Chuck Rolke
 Fix For: 1.4.0


When connections are started by routers to other routers there is no reliable 
way in the log files for telling the connections apart. Consider a pair of 
routers where router A creates two connections and sends two Opens to router B. 
A's log will show that connections [5] and [7] sent the Opens and B's log will 
show that connections [4] and [6] received and replied to the Opens. But there 
is no way to know if the connection pairs are '[A-5][B-4] and [A-7][B-6]' or 
'[A-5][B-6] and [A-7][B-4]'.


A simple solution to expose this relationship is for the routers to embed the 
_connid_ in the Open properties. Then the connection relationships between the 
two routers could be resolved from either router log file.



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

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

[jira] [Resolved] (DISPATCH-1015) Improve visualization of connection and link info on console's topology page.

[Ernest Allen (JIRA)]

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

Ernest Allen resolved DISPATCH-1015.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Improve visualization of connection and link info on console's topology page. 
> --
>
> Key: DISPATCH-1015
> URL: https://issues.apache.org/jira/browse/DISPATCH-1015
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.1.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
> Fix For: 1.2.0
>
>
> Change the way connection and link info is presented on the topology page. 
> Changes should include:
>  * Remove the sliding panel on the left
>  * Remove connection cross-section that appeared when clicking on a line
>  * Remove grid of connections/links that appeared when clicking on a circle
>  * When page is narrow (mobile phone size)
>  ** hide legend
>  ** show page menu icon in banner
>  ** when page menu icon is clicked popup legend
>  * When mouseover a router, popup tooltip that shows
>  ** Full router name
>  ** list of listener ports
>  ** router version
>  * When mouseover a client/service/broker, popup tooltip that shows
>  ** type (sender/receiver/service/console/broker)
>  ** host
>  * When mouseover a line connecting circles, popup tooltip that shows
>  ** connection security, authentication, tenant
>  ** list of links
>  *** sorted descending by link statistics
>  *** up to 10 links
>  *** show link address, direction, statistics (undelivered, unsettled, 
> rejected, released, modified
>  
>  



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

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

[jira] [Commented] (DISPATCH-1015) Improve visualization of connection and link info on console's topology page.

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-1015 Clean up popups on topology page.


> Improve visualization of connection and link info on console's topology page. 
> --
>
> Key: DISPATCH-1015
> URL: https://issues.apache.org/jira/browse/DISPATCH-1015
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.1.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> Change the way connection and link info is presented on the topology page. 
> Changes should include:
>  * Remove the sliding panel on the left
>  * Remove connection cross-section that appeared when clicking on a line
>  * Remove grid of connections/links that appeared when clicking on a circle
>  * When page is narrow (mobile phone size)
>  ** hide legend
>  ** show page menu icon in banner
>  ** when page menu icon is clicked popup legend
>  * When mouseover a router, popup tooltip that shows
>  ** Full router name
>  ** list of listener ports
>  ** router version
>  * When mouseover a client/service/broker, popup tooltip that shows
>  ** type (sender/receiver/service/console/broker)
>  ** host
>  * When mouseover a line connecting circles, popup tooltip that shows
>  ** connection security, authentication, tenant
>  ** list of links
>  *** sorted descending by link statistics
>  *** up to 10 links
>  *** show link address, direction, statistics (undelivered, unsettled, 
> rejected, released, modified
>  
>  



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

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

[jira] [Updated] (DISPATCH-1015) Improve visualization of connection and link info on console's topology page.

[Ernest Allen (JIRA)]

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

Ernest Allen updated DISPATCH-1015:
---
Description: 
Change the way connection and link info is presented on the topology page. 
Changes should include:
 * Remove the sliding panel on the left
 * Remove connection cross-section that appeared when clicking on a line
 * Remove grid of connections/links that appeared when clicking on a circle
 * When page is narrow (mobile phone size)
 ** hide legend
 ** show page menu icon in banner
 ** when page menu icon is clicked popup legend
 * When mouseover a router, popup tooltip that shows
 ** Full router name
 ** list of listener ports
 ** router version
 * When mouseover a client/service/broker, popup tooltip that shows
 ** type (sender/receiver/service/console/broker)
 ** host
 * When mouseover a line connecting circles, popup tooltip that shows
 ** connection security, authentication, tenant
 ** list of links
 *** sorted descending by link statistics
 *** up to 10 links
 *** show link address, direction, statistics (undelivered, unsettled, 
rejected, released, modified

 

 

  was:
Change the way connection and link info is presented on the topology page. 
Changes should include:
 * Remove the sliding panel on the left
 * When page is narrow (mobile phone size)
 ** hide legend
 ** show page menu icon in banner
 ** when page menu icon is clicked popup legend
 * When mouseover a router, popup tooltip that shows
 ** Full router name
 ** list of listener ports
 ** router version
 * When mouseover a client/service/broker, popup tooltip that shows
 ** type (sender/receiver/service/console/broker)
 ** host
 ** connection properties if any
 ** security, authentication, tenant
 * When mouseover a line from routers to clients, popup tooltip that shows
 ** same info as mouseover the client circle
 ** list of links
 *** sorted descending by link statistics
 *** up to 10 links
 *** show link address, direction, statistics
 * When mouseover a line from router to router, popup tooltip that shows
 ** security, authentication, tenant
 ** same list of links as mouseover line to client (without address)
 * When click on line or router or client
 ** show modal dialog with same info as mouseover
 *** for list of links, show up to 20 links with ability to filter

 

 


> Improve visualization of connection and link info on console's topology page. 
> --
>
> Key: DISPATCH-1015
> URL: https://issues.apache.org/jira/browse/DISPATCH-1015
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Affects Versions: 1.1.0
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Major
>
> Change the way connection and link info is presented on the topology page. 
> Changes should include:
>  * Remove the sliding panel on the left
>  * Remove connection cross-section that appeared when clicking on a line
>  * Remove grid of connections/links that appeared when clicking on a circle
>  * When page is narrow (mobile phone size)
>  ** hide legend
>  ** show page menu icon in banner
>  ** when page menu icon is clicked popup legend
>  * When mouseover a router, popup tooltip that shows
>  ** Full router name
>  ** list of listener ports
>  ** router version
>  * When mouseover a client/service/broker, popup tooltip that shows
>  ** type (sender/receiver/service/console/broker)
>  ** host
>  * When mouseover a line connecting circles, popup tooltip that shows
>  ** connection security, authentication, tenant
>  ** list of links
>  *** sorted descending by link statistics
>  *** up to 10 links
>  *** show link address, direction, statistics (undelivered, unsettled, 
> rejected, released, modified
>  
>  



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

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

[jira] [Created] (DISPATCH-1015) Improve visualization of connection and link info on console's topology page.

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-1015:
--

 Summary: Improve visualization of connection and link info on 
console's topology page. 
 Key: DISPATCH-1015
 URL: https://issues.apache.org/jira/browse/DISPATCH-1015
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Console
Affects Versions: 1.1.0
Reporter: Ernest Allen
Assignee: Ernest Allen


Change the way connection and link info is presented on the topology page. 
Changes should include:
 * Remove the sliding panel on the left
 * When page is narrow (mobile phone size)
 ** hide legend
 ** show page menu icon in banner
 ** when page menu icon is clicked popup legend
 * When mouseover a router, popup tooltip that shows
 ** Full router name
 ** list of listener ports
 ** router version
 * When mouseover a client/service/broker, popup tooltip that shows
 ** type (sender/receiver/service/console/broker)
 ** host
 ** connection properties if any
 ** security, authentication, tenant
 * When mouseover a line from routers to clients, popup tooltip that shows
 ** same info as mouseover the client circle
 ** list of links
 *** sorted descending by link statistics
 *** up to 10 links
 *** show link address, direction, statistics
 * When mouseover a line from router to router, popup tooltip that shows
 ** security, authentication, tenant
 ** same list of links as mouseover line to client (without address)
 * When click on line or router or client
 ** show modal dialog with same info as mouseover
 *** for list of links, show up to 20 links with ability to filter

 

 



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

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

[jira] [Updated] (PROTON-1750) Create test for address info on inbound sockets

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1750:

Fix Version/s: proton-c-0.21.0

> Create test for address info on inbound sockets
> ---
>
> Key: PROTON-1750
> URL: https://issues.apache.org/jira/browse/PROTON-1750
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Cliff Jansen
>Priority: Minor
> Fix For: proton-c-0.21.0
>
>
> PROTON-1745 fixed changed behavior required by qpid-dispatch.
> It is thought that all proactors currently work correctly.  Create test to 
> verify and prevent future regressions.
> Also review if Doc needs corresponding updating.



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

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

[jira] [Created] (PROTON-1750) Create test for address info on inbound sockets

[Cliff Jansen (JIRA)]

Cliff Jansen created PROTON-1750:


 Summary: Create test for address info on inbound sockets
 Key: PROTON-1750
 URL: https://issues.apache.org/jira/browse/PROTON-1750
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Affects Versions: proton-c-0.20.0
Reporter: Cliff Jansen


PROTON-1745 fixed changed behavior required by qpid-dispatch.

It is thought that all proactors currently work correctly.  Create test to 
verify and prevent future regressions.

Also review if Doc needs corresponding updating.



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

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

[jira] [Resolved] (QPID-8003) [Broker-J] Use log level 'info' to report conditions when no new rolled over log file is detected by the file logger

[Lorenz Quack (JIRA)]

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

Lorenz Quack resolved QPID-8003.

Resolution: Fixed

looks good

> [Broker-J] Use log level 'info' to report conditions when no new rolled over 
> log file is detected by the file logger
> 
>
> Key: QPID-8003
> URL: https://issues.apache.org/jira/browse/QPID-8003
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The log level 'warn' is currently used to report a condition when no new 
> rolled over log file is detected by the file logger. This issue does not 
> effect any core broker functionality. Thus, the log level can be safely 
> reduced to 'info'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (QPID-8003) [Broker-J] Use log level 'info' to report conditions when no new rolled over log file is detected by the file logger

[Alex Rudyy (JIRA)]

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

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

> [Broker-J] Use log level 'info' to report conditions when no new rolled over 
> log file is detected by the file logger
> 
>
> Key: QPID-8003
> URL: https://issues.apache.org/jira/browse/QPID-8003
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The log level 'warn' is currently used to report a condition when no new 
> rolled over log file is detected by the file logger. This issue does not 
> effect any core broker functionality. Thus, the log level can be safely 
> reduced to 'info'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (QPID-8003) [Broker-J] Use log level 'info' to report conditions when no new rolled over log file is detected by the file logger

[Alex Rudyy (JIRA)]

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

Alex Rudyy reassigned QPID-8003:


Assignee: Alex Rudyy

> [Broker-J] Use log level 'info' to report conditions when no new rolled over 
> log file is detected by the file logger
> 
>
> Key: QPID-8003
> URL: https://issues.apache.org/jira/browse/QPID-8003
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The log level 'warn' is currently used to report a condition when no new 
> rolled over log file is detected by the file logger. This issue does not 
> effect any core broker functionality. Thus, the log level can be safely 
> reduced to 'info'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8003) [Broker-J] Use log level 'info' to report conditions when no new rolled over log file is detected by the file logger

[ASF subversion and git services (JIRA)]

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

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

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

QPID-8003:[Broker-J] Use log level 'info' to report conditions when no new 
rolled over log file is detected by the file logger


> [Broker-J] Use log level 'info' to report conditions when no new rolled over 
> log file is detected by the file logger
> 
>
> Key: QPID-8003
> URL: https://issues.apache.org/jira/browse/QPID-8003
> Project: Qpid
>  Issue Type: Task
>  Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The log level 'warn' is currently used to report a condition when no new 
> rolled over log file is detected by the file logger. This issue does not 
> effect any core broker functionality. Thus, the log level can be safely 
> reduced to 'info'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (QPID-8003) [Broker-J] Use log level 'info' to report conditions when no new rolled over log file is detected by the file logger

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-8003:


 Summary: [Broker-J] Use log level 'info' to report conditions when 
no new rolled over log file is detected by the file logger
 Key: QPID-8003
 URL: https://issues.apache.org/jira/browse/QPID-8003
 Project: Qpid
  Issue Type: Task
  Components: Java Broker
Reporter: Alex Rudyy
 Fix For: qpid-java-broker-7.0.0


The log level 'warn' is currently used to report a condition when no new rolled 
over log file is detected by the file logger. This issue does not effect any 
core broker functionality. Thus, the log level can be safely reduced to 'info'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #195: DISPATCH-818 - Added connection info list t...

[ganeshmurthy]

Github user ganeshmurthy closed the pull request at:

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


---

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

[GitHub] qpid-dispatch pull request #195: DISPATCH-818 - Added connection info list t...

[ted-ross]

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

https://github.com/apache/qpid-dispatch/pull/195#discussion_r139231310
  
--- Diff: src/connection_manager.c ---
@@ -633,7 +633,46 @@ qd_error_t qd_entity_refresh_listener(qd_entity_t* 
entity, void *impl)
 
 qd_error_t qd_entity_refresh_connector(qd_entity_t* entity, void *impl)
 {
-return QD_ERROR_NONE;
+qd_connector_t *ct = (qd_connector_t*) impl;
+
+if (DEQ_SIZE(ct->conn_info_list) > 1) {
+qd_failover_item_list_t   conn_info_list = ct->conn_info_list;
+
+qd_failover_item_t *item = DEQ_HEAD(conn_info_list);
+
+//
+// As you can see we are skipping the head of the list. The
+// first item in the list is always the original connection 
information
+// and we dont want to display that information as part of the 
failover list.
+//
+char failover_info[250];
--- End diff --

Having a fixed-length string and later using strcat (not strncat) causes 
this to be a buffer/stack overflow vulnerability.  Please ensure that the 
failover_info buffer cannot be overfilled.


---

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

[GitHub] qpid-dispatch pull request #195: DISPATCH-818 - Added connection info list t...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-818 - Added connection info list to the connector which stor…

…es the initial connection information and the backup connection 
information

1. If the primary connection goes down, the primary and the backup 
connections will be tried in quick succession
2. If the new backup connection does not provide failover-server-list, the 
list on the server is cleaned up to contain only the one pertinent connection 
info.
3. The connection info list always has at least one element in it which 
represents the initial successful connection information

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-818

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

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

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

This closes #195


commit 5e11d471feec3c4e51d8587b1dbb0e0bfe446848
Author: Ganesh Murthy 
Date:   2017-09-15T13:57:16Z

DISPATCH-818 - Added connection info list to the connector which stores the 
initial connection information and the backup connection information
1. If the primary connection goes down, the primary and the backup 
connections will be tried in quick succession
2. If the new backup connection does not provide failover-server-list, the 
list on the server is cleaned up to contain only the one pertinent connection 
info.
3. The connection info list always has at least one element in it which 
represents the initial successful connection information




---

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

Fwd: Request for info

[Sheetal Kadam]

Hi,

Is the qpid c++ thread safe.
I have a requirement. 1 thread used for connection with rmq and multiple
threads with different channel ( 1 channel per thread). Can the connection
object be shared with different threads? Is it thread safe?

Also, what are the libraries it is using? Boost? Does it require c++11
compiler?

Thanks in advance, request for a response as early as possible.

Thanks,
Sheetal

Request for info

[Sheetal Kadam]

Hi,

Is the qpid c++ thread safe.
I have a requirement. 1 thread used for connection with rmq and multiple
threads with different channel ( 1 channel per thread). Can the connection
object be shared with different threads? Is it thread safe?

Also, what are the libraries it is using? Boost? Does it require c++11
compiler?

Thanks in advance, request for a response as early as possible.

Thanks,
Sheetal

[jira] [Commented] (PROTON-1437) c proactor address info

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1437: clarify apidoc for pn_proactor_addr_str


> c proactor address info
> ---
>
> Key: PROTON-1437
> URL: https://issues.apache.org/jira/browse/PROTON-1437
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> The C proactor should provide access to the remote network address for 
> incoming connections. The standard BSD `struct addrinfo` will be used to 
> represent the address, this is portable to any platform that supports BSD 
> sockets and is (in principle) extensible to cover new types of address by 
> adding new values for ai_family. 
> (The original JIRA also mentioned listeners, that has moved to a separate 
> issue PROTON-1438)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (PROTON-1437) c proactor address info

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1437: clarify apidoc for pn_proactor_addr_str


> c proactor address info
> ---
>
> Key: PROTON-1437
> URL: https://issues.apache.org/jira/browse/PROTON-1437
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> The C proactor should provide access to the remote network address for 
> incoming connections. The standard BSD `struct addrinfo` will be used to 
> represent the address, this is portable to any platform that supports BSD 
> sockets and is (in principle) extensible to cover new types of address by 
> adding new values for ai_family. 
> (The original JIRA also mentioned listeners, that has moved to a separate 
> issue PROTON-1438)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (PROTON-1437) c proactor address info

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1437: c proactor address info

Provides actual address information for both ends of a proactor-managed
connection using pn_proactor_addr_* functions.

- pn_proactor_addr_* functions are clearly identified as part of proactor lib
- portable print local/remote address as string with no platform-specific 
headers
- POSIX/windows can test pn_proactor_addr_is_sockaddr() to use native sockaddr 
API

This can be extended safely to non-sockaddr platforms by making
pn_proactor_addr_is_sockaddr() return false and adding pn_proactor_addr_is_foo()
to indicate the underlying address type


> c proactor address info
> ---
>
> Key: PROTON-1437
> URL: https://issues.apache.org/jira/browse/PROTON-1437
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> The C proactor should provide access to the remote network address for 
> incoming connections. The standard BSD `struct addrinfo` will be used to 
> represent the address, this is portable to any platform that supports BSD 
> sockets and is (in principle) extensible to cover new types of address by 
> adding new values for ai_family. 
> (The original JIRA also mentioned listeners, that has moved to a separate 
> issue PROTON-1438)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (PROTON-1437) c proactor address info

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1437.
-
Resolution: Fixed

> c proactor address info
> ---
>
> Key: PROTON-1437
> URL: https://issues.apache.org/jira/browse/PROTON-1437
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> The C proactor should provide access to the remote network address for 
> incoming connections. The standard BSD `struct addrinfo` will be used to 
> represent the address, this is portable to any platform that supports BSD 
> sockets and is (in principle) extensible to cover new types of address by 
> adding new values for ai_family. 
> (The original JIRA also mentioned listeners, that has moved to a separate 
> issue PROTON-1438)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Review Request 58028: PROTON-1437: c proactor address info

[Andrew Stitcher]

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




proton-c/include/proton/proactor.h
Lines 213 (patched)


Sorry to nitpick - I should have noticed this before:

The usual proton convention is to have the "subject" first in the parameter 
list. So I think this should be:

```size_t pn_proactor_addr_str(pn_proactor_addr_t*, ...);


- Andrew Stitcher


On March 29, 2017, 5:19 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58028/
> ---
> 
> (Updated March 29, 2017, 5:19 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> (also on https://github.com/alanconway/qpid-proton/tree/transport-addr)
> 
> Provides actual address information for both ends of a proactor-managed
> connection using pn_proactor_addr_* functions.
> 
> - pn_proactor_addr_* functions are clearly identified as part of proactor lib
> - portable print local/remote address as string with no platform-specific 
> headers
> - POSIX/windows can test pn_proactor_addr_is_sockaddr() to use native 
> sockaddr API
> 
> This can be extended safely to non-sockaddr platforms by making
> pn_proactor_addr_is_sockaddr() return false and adding 
> pn_proactor_addr_is_foo()
> to indicate the underlying address type
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/proactor.h 974b4329c8679a105cfa2d141d48b9214be13231 
>   proton-c/src/proactor/libuv.c aa10f83aa6c251e869e482da5533bf771ef5a180 
>   proton-c/src/tests/proactor.c 80eeb9a7652e39cb5650eba35732c3df3781fbad 
>   proton-c/src/tests/test_tools.h 0c913ff2b1c7de8d22b03faadba4b1d1b385e504 
> 
> 
> Diff: https://reviews.apache.org/r/58028/diff/2/
> 
> 
> Testing
> ---
> 
> ctest on gcc, cl, debug, release
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

Re: Review Request 58028: PROTON-1437: c proactor address info

[Alan Conway]

> On March 29, 2017, 4:03 p.m., Andrew Stitcher wrote:
> > I basically like this approach -I've commented on the github change:
> > 
> > Some thoughts though:
> > 
> > * I Think you want to get the proactor address from pn_transport_t not 
> > pn_connection_t: Transport models the low level byte stream source (which 
> > is what has the sockaddr), whereas connection models the AMQP connection 
> > stream. A disconnected connection has no address, but you can't have a 
> > disconnected transport (except maybe transiently).
> > 
> > * You should consider an explicit sockaddr "dynamic_cast" instead of a 
> > boolean return:
> >  ```struct sockaddr* pn_proactor_addr_sockaddr(...)``` rather than ```bool 
> > pn_proactor_addr_is_sockaddr(...)```.

+1 to all


- Alan


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


On March 29, 2017, 3:11 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58028/
> ---
> 
> (Updated March 29, 2017, 3:11 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> (also on https://github.com/alanconway/qpid-proton/tree/transport-addr)
> 
> Provides actual address information for both ends of a proactor-managed
> connection using pn_proactor_addr_* functions.
> 
> - pn_proactor_addr_* functions are clearly identified as part of proactor lib
> - portable print local/remote address as string with no platform-specific 
> headers
> - POSIX/windows can test pn_proactor_addr_is_sockaddr() to use native 
> sockaddr API
> 
> This can be extended safely to non-sockaddr platforms by making
> pn_proactor_addr_is_sockaddr() return false and adding 
> pn_proactor_addr_is_foo()
> to indicate the underlying address type
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/proactor.h 974b4329c8679a105cfa2d141d48b9214be13231 
>   proton-c/src/proactor/libuv.c aa10f83aa6c251e869e482da5533bf771ef5a180 
>   proton-c/src/tests/proactor.c 80eeb9a7652e39cb5650eba35732c3df3781fbad 
>   proton-c/src/tests/test_tools.h 0c913ff2b1c7de8d22b03faadba4b1d1b385e504 
> 
> 
> Diff: https://reviews.apache.org/r/58028/diff/1/
> 
> 
> Testing
> ---
> 
> ctest on gcc, cl, debug, release
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

Re: Review Request 58028: PROTON-1437: c proactor address info

[Alan Conway]

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

(Updated March 29, 2017, 5:19 p.m.)


Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross.


Changes
---

Apply andrew's suggestions


Repository: qpid-proton-git


Description
---

(also on https://github.com/alanconway/qpid-proton/tree/transport-addr)

Provides actual address information for both ends of a proactor-managed
connection using pn_proactor_addr_* functions.

- pn_proactor_addr_* functions are clearly identified as part of proactor lib
- portable print local/remote address as string with no platform-specific 
headers
- POSIX/windows can test pn_proactor_addr_is_sockaddr() to use native sockaddr 
API

This can be extended safely to non-sockaddr platforms by making
pn_proactor_addr_is_sockaddr() return false and adding pn_proactor_addr_is_foo()
to indicate the underlying address type


Diffs (updated)
-

  proton-c/include/proton/proactor.h 974b4329c8679a105cfa2d141d48b9214be13231 
  proton-c/src/proactor/libuv.c aa10f83aa6c251e869e482da5533bf771ef5a180 
  proton-c/src/tests/proactor.c 80eeb9a7652e39cb5650eba35732c3df3781fbad 
  proton-c/src/tests/test_tools.h 0c913ff2b1c7de8d22b03faadba4b1d1b385e504 


Diff: https://reviews.apache.org/r/58028/diff/2/

Changes: https://reviews.apache.org/r/58028/diff/1-2/


Testing
---

ctest on gcc, cl, debug, release


Thanks,

Alan Conway

Re: Review Request 58028: PROTON-1437: c proactor address info

[Andrew Stitcher]

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



I basically like this approach -I've commented on the github change:

Some thoughts though:

* I Think you want to get the proactor address from pn_transport_t not 
pn_connection_t: Transport models the low level byte stream source (which is 
what has the sockaddr), whereas connection models the AMQP connection stream. A 
disconnected connection has no address, but you can't have a disconnected 
transport (except maybe transiently).

* You should consider an explicit sockaddr "dynamic_cast" instead of a boolean 
return:
 ```struct sockaddr* pn_proactor_addr_sockaddr(...)``` rather than ```bool 
pn_proactor_addr_is_sockaddr(...)```.

- Andrew Stitcher


On March 29, 2017, 3:11 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58028/
> ---
> 
> (Updated March 29, 2017, 3:11 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> (also on https://github.com/alanconway/qpid-proton/tree/transport-addr)
> 
> Provides actual address information for both ends of a proactor-managed
> connection using pn_proactor_addr_* functions.
> 
> - pn_proactor_addr_* functions are clearly identified as part of proactor lib
> - portable print local/remote address as string with no platform-specific 
> headers
> - POSIX/windows can test pn_proactor_addr_is_sockaddr() to use native 
> sockaddr API
> 
> This can be extended safely to non-sockaddr platforms by making
> pn_proactor_addr_is_sockaddr() return false and adding 
> pn_proactor_addr_is_foo()
> to indicate the underlying address type
> 
> 
> Diffs
> -
> 
>   proton-c/include/proton/proactor.h 974b4329c8679a105cfa2d141d48b9214be13231 
>   proton-c/src/proactor/libuv.c aa10f83aa6c251e869e482da5533bf771ef5a180 
>   proton-c/src/tests/proactor.c 80eeb9a7652e39cb5650eba35732c3df3781fbad 
>   proton-c/src/tests/test_tools.h 0c913ff2b1c7de8d22b03faadba4b1d1b385e504 
> 
> 
> Diff: https://reviews.apache.org/r/58028/diff/1/
> 
> 
> Testing
> ---
> 
> ctest on gcc, cl, debug, release
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

Review Request 58028: PROTON-1437: c proactor address info

[Alan Conway]

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

Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross.


Repository: qpid-proton-git


Description
---

(also on https://github.com/alanconway/qpid-proton/tree/transport-addr)

Provides actual address information for both ends of a proactor-managed
connection using pn_proactor_addr_* functions.

- pn_proactor_addr_* functions are clearly identified as part of proactor lib
- portable print local/remote address as string with no platform-specific 
headers
- POSIX/windows can test pn_proactor_addr_is_sockaddr() to use native sockaddr 
API

This can be extended safely to non-sockaddr platforms by making
pn_proactor_addr_is_sockaddr() return false and adding pn_proactor_addr_is_foo()
to indicate the underlying address type


Diffs
-

  proton-c/include/proton/proactor.h 974b4329c8679a105cfa2d141d48b9214be13231 
  proton-c/src/proactor/libuv.c aa10f83aa6c251e869e482da5533bf771ef5a180 
  proton-c/src/tests/proactor.c 80eeb9a7652e39cb5650eba35732c3df3781fbad 
  proton-c/src/tests/test_tools.h 0c913ff2b1c7de8d22b03faadba4b1d1b385e504 


Diff: https://reviews.apache.org/r/58028/diff/1/


Testing
---

ctest on gcc, cl, debug, release


Thanks,

Alan Conway

[jira] [Updated] (PROTON-1437) c proactor address info

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1437:

Summary: c proactor address info  (was: c proactor address info and listen 
hints )

> c proactor address info
> ---
>
> Key: PROTON-1437
> URL: https://issues.apache.org/jira/browse/PROTON-1437
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> The C proactor should provide access to the remote network address for 
> incoming connections. The standard BSD `struct addrinfo` will be used to 
> represent the address, this is portable to any platform that supports BSD 
> sockets and is (in principle) extensible to cover new types of address by 
> adding new values for ai_family. 
> (The original JIRA also mentioned listeners, that has moved to a separate 
> issue PROTON-1438)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (PROTON-1437) c proactor address info and listen hints

[Alan Conway (JIRA)]

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

Alan Conway updated PROTON-1437:

Description: 
The C proactor should provide access to the remote network address for incoming 
connections. The standard BSD `struct addrinfo` will be used to represent the 
address, this is portable to any platform that supports BSD sockets and is (in 
principle) extensible to cover new types of address by adding new values for 
ai_family. 
(The original JIRA also mentioned listeners, that has moved to a separate issue 
PROTON-1438)

  was:The C proactor should provide access to the remote network address for 
incoming connections and allow listener hints to be set to control protocols 
etc. The standard BSD `struct addrinfo` will be used to represent the address, 
this is portable to any platform that supports BSD sockets and is (in 
principle) extensible to cover new types of address by adding new values for 
ai_family


> c proactor address info and listen hints 
> -
>
> Key: PROTON-1437
> URL: https://issues.apache.org/jira/browse/PROTON-1437
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: 0.17.0
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.18.0
>
>
> The C proactor should provide access to the remote network address for 
> incoming connections. The standard BSD `struct addrinfo` will be used to 
> represent the address, this is portable to any platform that supports BSD 
> sockets and is (in principle) extensible to cover new types of address by 
> adding new values for ai_family. 
> (The original JIRA also mentioned listeners, that has moved to a separate 
> issue PROTON-1438)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (PROTON-1437) c proactor address info and listen hints

[Alan Conway (JIRA)]

Alan Conway created PROTON-1437:
---

 Summary: c proactor address info and listen hints 
 Key: PROTON-1437
 URL: https://issues.apache.org/jira/browse/PROTON-1437
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Affects Versions: 0.17.0
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: 0.18.0


The C proactor should provide access to the remote network address for incoming 
connections and allow listener hints to be set to control protocols etc. The 
standard BSD `struct addrinfo` will be used to represent the address, this is 
portable to any platform that supports BSD sockets and is (in principle) 
extensible to cover new types of address by adding new values for ai_family



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (DISPATCH-572) Adding log info with proton transport id and related remote IP/port

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy resolved DISPATCH-572.

Resolution: Fixed

> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy commented on DISPATCH-572:


When you now start the router with PN_TRACE_FRM=1, the "Accepted from 
127.0.0.1:48192" message that you previously saw has been moved as a log 
statement. To see this message turn on trace level logging on by adding the 
following to the router config file like this - 

{noformat}
log {
module: DEFAULT
enable: trace+
output: qdrouterd.log
}
{noformat}

Make a connection to the router via simple_send.py or simple_recv.py and you 
will see the following - 

{noformat}
Tue Nov 29 17:22:10 2016 SERVER (trace) Accepting incoming connection from 
127.0.0.1:43072 to 0.0.0.0:amqp with connection id [1]
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:  <- SASL
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:  -> SASL
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:0 -> @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:0 <- @sasl-init(65) 
[mechanism=:ANONYMOUS, initial-response=b"anonymous@localhost.localdomain"]
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:0 -> @sasl-outcome(68) [code=0]
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:  <- AMQP
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:0 <- @open(16) 
[container-id="60d1e762-22ae-4611-b450-e6c373287c1e", hostname="localhost", 
channel-max=32767]
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:0 <- @begin(17) 
[next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647]
Tue Nov 29 17:22:10 2016 SERVER (trace) [1]:0 <- @attach(18) 
[name="60d1e762-22ae-4611-b450-e6c373287c1e-examples", 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="examples", durable=0, timeout=0, 
dynamic=false], initial-delivery-count=0]
{noformat}

Above, you will notice the introduction of a connection id [1]
connection_id has replaced the transport reference. Using the connection id, 
you will be able to correlate messages that belong to the same connection


> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-572 - Added connection identifier to 'Accepted from' log message so 
one can easily identify log messages on a specific connection


> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-572:
-

Github user ganeshmurthy closed the pull request at:

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


> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-572:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-572 - Add connection id to the Accepting connection log mess…

…age so one can easily identify log messages on a specific connection

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-572

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

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

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

This closes #118


commit 3d07eaafd2f278295d2baca808da830034659147
Author: Ganesh Murthy 
Date:   2016-11-29T15:54:27Z

DISPATCH-572 - Add connection id to the Accepting connection log message so 
one can easily identify log messages on a specific connection




> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-7542) [Java Broker] Add connection and user info to log messages

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-7542:
-
Fix Version/s: Future

> [Java Broker] Add connection and user info to log messages
> --
>
> Key: QPID-7542
> URL: https://issues.apache.org/jira/browse/QPID-7542
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: Future
>
>
> Currently some log messages lack sufficient information to be helpful. 
> Especially, connection and user information is usually desirable. We should 
> add them by default to log messages.
> Example of unhelpful log messages:
> {code}
> 2016-11-22 13:24:45,180 DEBUG [HttpManagement-HTTP-106] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
> 2016-11-22 13:24:45,180 DEBUG [HttpManagement-HTTP-106] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
> default: ALLOWED
> {code}



--
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-572) Adding log info with proton transport id and related remote IP/port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-572:
-

Github user ganeshmurthy closed the pull request at:

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


> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-572:
-

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

https://github.com/apache/qpid-dispatch/pull/116#discussion_r89379660
  
--- Diff: src/server.c ---
@@ -687,6 +688,11 @@ static void thread_process_listeners_LH(qd_server_t 
*qd_server)
 pn_transport_set_tracer(tport, qd_transport_tracer);
 }
 
+if (tport && ctx->pn_cxtr) {
+   if (qdpn_connector_trace(ctx->pn_cxtr) & (PN_TRACE_FRM | 
PN_TRACE_RAW | PN_TRACE_DRV))
+   fprintf(stderr, "Transport [%p] on %s\n", tport, 
qdpn_connector_name(ctx->pn_cxtr));
--- End diff --

Why are you using fprintf when you should be using a log?


> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on DISPATCH-572:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-572 - Added fprintf message that associates the transport po…

…inter to the connector name

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

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-572

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

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

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

This closes #116


commit fbfe9375a339d4e839e9aca275dd8360a62e74a7
Author: Ganesh Murthy 
Date:   2016-11-23T18:43:30Z

DISPATCH-572 - Added fprintf message that associates the transport pointer 
to the connector name




> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[Ganesh Murthy (JIRA)]

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

Ganesh Murthy reassigned DISPATCH-572:
--

Assignee: Ganesh Murthy

> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-572:
--
Fix Version/s: 0.8.0

> Adding log info with proton transport id and related remote IP/port
> ---
>
> Key: DISPATCH-572
> URL: https://issues.apache.org/jira/browse/DISPATCH-572
> Project: Qpid Dispatch
>  Issue Type: Improvement
>Reporter: Paolo Patierno
> Fix For: 0.8.0
>
>
> Hi,
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>  
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>  
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
> Thanks,
> Paolo.



--
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-572) Adding log info with proton transport id and related remote IP/port

[Paolo Patierno (JIRA)]

Paolo Patierno created DISPATCH-572:
---

 Summary: Adding log info with proton transport id and related 
remote IP/port
 Key: DISPATCH-572
 URL: https://issues.apache.org/jira/browse/DISPATCH-572
 Project: Qpid Dispatch
  Issue Type: Improvement
Reporter: Paolo Patierno


Hi,

enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
Dispatch Router, I need sometimes to know who is the remote peer is exchanging 
traced messages.

For example, considering these few lines of trace (running the Qpid Dispatch 
Router) :

 
Accepted from 127.0.0.1:48192
Accepted from 127.0.0.1:48190
[0x7fbc44016390]:  <- SASL
[0x7fbc44016390]:  -> SASL
[0x7fbc44003b70]:  <- SASL
[0x7fbc44003b70]:  -> SASL
[0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]

 
The router accepts two connections from remote clients (we see IP and port) but 
then every message is related to an "identifier" (I guess it should be the file 
descriptor related to the used socket).
If I need to match these information with Wireshark (where I can see remote 
port) I don't know if remote clients using remote port 48192 is related to 
0x7fbc44016390 or 0x7fbc44003b70.

I think it could be a good information to add into the trace at least showing 
the "identifier" after the accepted message, i.e. :

Accepted from 127.0.0.1:48192 [0x7fbc44016390]

It's also true, that messages related to something like [0x7fbc44016390] come 
from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
Router.

Thanks,
Paolo.



--
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-7542) [Java Broker] Add connection and user info to log messages

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7542:
--

 Summary: [Java Broker] Add connection and user info to log messages
 Key: QPID-7542
 URL: https://issues.apache.org/jira/browse/QPID-7542
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Lorenz Quack


Currently some log messages lack sufficient information to be helpful. 
Especially, connection and user information is usually desirable. We should add 
them by default to log messages.

Example of unhelpful log messages:
{code}
2016-11-22 13:24:45,180 DEBUG [HttpManagement-HTTP-106] 
(o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
2016-11-22 13:24:45,180 DEBUG [HttpManagement-HTTP-106] 
(o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
default: ALLOWED
{code}



--
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] (PROTON-894) ErrorCondition 'info' map should be typed to enforce required use of Symbol keys

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-894:
---
Fix Version/s: Future

> ErrorCondition 'info' map should be typed to enforce required use of Symbol 
> keys
> 
>
> Key: PROTON-894
> URL: https://issues.apache.org/jira/browse/PROTON-894
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.9.1
>Reporter: Robbie Gemmell
>  Labels: api
> Fix For: Future
>
>
> The 'info' field of amqp-error [1] condition is of type 'fields' [2], a 
> Symbol keyed map. The 'info' map in the ErrorCondition object should thus be 
> typed for Symbol keys, whereas currently it is not typed at all implying use 
> of any type is permissable, e.g. the common use of String keys.
> [1] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-error
> [2] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-fields



--
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] (PROTON-894) ErrorCondition 'info' map should be typed to enforce required use of Symbol keys

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-894:
---
Labels: api  (was: )

> ErrorCondition 'info' map should be typed to enforce required use of Symbol 
> keys
> 
>
> Key: PROTON-894
> URL: https://issues.apache.org/jira/browse/PROTON-894
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-j
>Affects Versions: 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.9.1
>Reporter: Robbie Gemmell
>  Labels: api
>
> The 'info' field of amqp-error [1] condition is of type 'fields' [2], a 
> Symbol keyed map. The 'info' map in the ErrorCondition object should thus be 
> typed for Symbol keys, whereas currently it is not typed at all implying use 
> of any type is permissable, e.g. the common use of String keys.
> [1] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-error
> [2] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-fields



--
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-544) Add ability to hide the info panel on the left of the topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-544 Clean up css of hide/show left panel buttons for Firefox


> Add ability to hide the info panel on the left of the topology page
> ---
>
> Key: DISPATCH-544
> URL: https://issues.apache.org/jira/browse/DISPATCH-544
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
>
> When there are a large number of routers we can use all the page area to 
> display the topology graph. However, the left side of the page is dedicated 
> to the panel that displays info about the router or link that the mouse is 
> hovering over.
> Add a way to hide and re-show the info panel. When the panel is hidden, the 
> graph should expand to the full page. 
> Also, save and restore the state of the panel. 



--
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-544) Add ability to hide the info panel on the left of the topology page

[Ernest Allen (JIRA)]

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

Ernest Allen resolved DISPATCH-544.
---
   Resolution: Fixed
Fix Version/s: 0.8.0

> Add ability to hide the info panel on the left of the topology page
> ---
>
> Key: DISPATCH-544
> URL: https://issues.apache.org/jira/browse/DISPATCH-544
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
> Fix For: 0.8.0
>
>
> When there are a large number of routers we can use all the page area to 
> display the topology graph. However, the left side of the page is dedicated 
> to the panel that displays info about the router or link that the mouse is 
> hovering over.
> Add a way to hide and re-show the info panel. When the panel is hidden, the 
> graph should expand to the full page. 
> Also, save and restore the state of the panel. 



--
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-544) Add ability to hide the info panel on the left of the topology page

[ASF subversion and git services (JIRA)]

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

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

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

DISPATCH-544 Add ability to hide/show the left panel on topology page


> Add ability to hide the info panel on the left of the topology page
> ---
>
> Key: DISPATCH-544
> URL: https://issues.apache.org/jira/browse/DISPATCH-544
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Console
>Reporter: Ernest Allen
>Assignee: Ernest Allen
>Priority: Minor
>
> When there are a large number of routers we can use all the page area to 
> display the topology graph. However, the left side of the page is dedicated 
> to the panel that displays info about the router or link that the mouse is 
> hovering over.
> Add a way to hide and re-show the info panel. When the panel is hidden, the 
> graph should expand to the full page. 
> Also, save and restore the state of the panel. 



--
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-544) Add ability to hide the info panel on the left of the topology page

[Ernest Allen (JIRA)]

Ernest Allen created DISPATCH-544:
-

 Summary: Add ability to hide the info panel on the left of the 
topology page
 Key: DISPATCH-544
 URL: https://issues.apache.org/jira/browse/DISPATCH-544
 Project: Qpid Dispatch
  Issue Type: Improvement
  Components: Console
Reporter: Ernest Allen
Assignee: Ernest Allen
Priority: Minor


When there are a large number of routers we can use all the page area to 
display the topology graph. However, the left side of the page is dedicated to 
the panel that displays info about the router or link that the mouse is 
hovering over.

Add a way to hide and re-show the info panel. When the panel is hidden, the 
graph should expand to the full page. 
Also, save and restore the state of the panel. 



--
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-499) in propagating link detach the info field is dropped

[ASF subversion and git services (JIRA)]

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

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

Commit 58d8aab971a2cd8b011b34420c01a9e6f73338b2 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=58d8aab ]

DISPATCH-499 - Copy error.info field when propagating a detach. [Patch from 
Gordon Sim]


> in propagating link detach the info field is dropped
> 
>
> Key: DISPATCH-499
> URL: https://issues.apache.org/jira/browse/DISPATCH-499
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ted Ross
> Fix For: 0.7.0
>
> Attachments: DISPATCH-499.patch
>
>
> The router does not propagate the info field of any error condition in a link 
> detach. The info field may contain important information e.g. when used with 
> amqp:redirect.
> In the following snippet you can see the info field being dropped as the 
> detach is propagated:
> {noformat}
> [0x1df1750]:  <- AMQP
> [0x1df1750]:0 <- @open(16) 
> [container-id="19937f43-391c-457f-856d-83097ac9e20b", hostname="localhost", 
> channel-max=32767]
> [0x1df1750]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=2147483647]
> [0x1df1750]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 <- @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x1df1750]:  -> AMQP
> [0x1df1750]:0 -> @open(16) [container-id="Router.A", max-frame-size=16384, 
> channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.7.0"}]
> [0x1df1750]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=61, outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, 
> outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 -> @flow(19) [incoming-window=15, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x7fa128002df0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7fa128002df0]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test", 
> info={"address"="elsewhere"}]]
> [0x1df1750]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test"]]
> {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] [Resolved] (DISPATCH-499) in propagating link detach the info field is dropped

[Ted Ross (JIRA)]

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

Ted Ross resolved DISPATCH-499.
---
Resolution: Fixed

> in propagating link detach the info field is dropped
> 
>
> Key: DISPATCH-499
> URL: https://issues.apache.org/jira/browse/DISPATCH-499
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ted Ross
> Fix For: 0.7.0
>
> Attachments: DISPATCH-499.patch
>
>
> The router does not propagate the info field of any error condition in a link 
> detach. The info field may contain important information e.g. when used with 
> amqp:redirect.
> In the following snippet you can see the info field being dropped as the 
> detach is propagated:
> {noformat}
> [0x1df1750]:  <- AMQP
> [0x1df1750]:0 <- @open(16) 
> [container-id="19937f43-391c-457f-856d-83097ac9e20b", hostname="localhost", 
> channel-max=32767]
> [0x1df1750]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=2147483647]
> [0x1df1750]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 <- @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x1df1750]:  -> AMQP
> [0x1df1750]:0 -> @open(16) [container-id="Router.A", max-frame-size=16384, 
> channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.7.0"}]
> [0x1df1750]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=61, outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, 
> outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 -> @flow(19) [incoming-window=15, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x7fa128002df0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7fa128002df0]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test", 
> info={"address"="elsewhere"}]]
> [0x1df1750]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test"]]
> {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] [Assigned] (DISPATCH-499) in propagating link detach the info field is dropped

[Ted Ross (JIRA)]

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

Ted Ross reassigned DISPATCH-499:
-

Assignee: Ted Ross

> in propagating link detach the info field is dropped
> 
>
> Key: DISPATCH-499
> URL: https://issues.apache.org/jira/browse/DISPATCH-499
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ted Ross
> Fix For: 0.7.0
>
> Attachments: DISPATCH-499.patch
>
>
> The router does not propagate the info field of any error condition in a link 
> detach. The info field may contain important information e.g. when used with 
> amqp:redirect.
> In the following snippet you can see the info field being dropped as the 
> detach is propagated:
> {noformat}
> [0x1df1750]:  <- AMQP
> [0x1df1750]:0 <- @open(16) 
> [container-id="19937f43-391c-457f-856d-83097ac9e20b", hostname="localhost", 
> channel-max=32767]
> [0x1df1750]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=2147483647]
> [0x1df1750]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 <- @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x1df1750]:  -> AMQP
> [0x1df1750]:0 -> @open(16) [container-id="Router.A", max-frame-size=16384, 
> channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.7.0"}]
> [0x1df1750]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=61, outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, 
> outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 -> @flow(19) [incoming-window=15, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x7fa128002df0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7fa128002df0]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test", 
> info={"address"="elsewhere"}]]
> [0x1df1750]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test"]]
> {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] [Updated] (DISPATCH-499) in propagating link detach the info field is dropped

[Ted Ross (JIRA)]

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

Ted Ross updated DISPATCH-499:
--
Fix Version/s: 0.7.0

> in propagating link detach the info field is dropped
> 
>
> Key: DISPATCH-499
> URL: https://issues.apache.org/jira/browse/DISPATCH-499
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
> Fix For: 0.7.0
>
> Attachments: DISPATCH-499.patch
>
>
> The router does not propagate the info field of any error condition in a link 
> detach. The info field may contain important information e.g. when used with 
> amqp:redirect.
> In the following snippet you can see the info field being dropped as the 
> detach is propagated:
> {noformat}
> [0x1df1750]:  <- AMQP
> [0x1df1750]:0 <- @open(16) 
> [container-id="19937f43-391c-457f-856d-83097ac9e20b", hostname="localhost", 
> channel-max=32767]
> [0x1df1750]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=2147483647]
> [0x1df1750]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 <- @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x1df1750]:  -> AMQP
> [0x1df1750]:0 -> @open(16) [container-id="Router.A", max-frame-size=16384, 
> channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.7.0"}]
> [0x1df1750]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=61, outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, 
> outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 -> @flow(19) [incoming-window=15, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x7fa128002df0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7fa128002df0]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test", 
> info={"address"="elsewhere"}]]
> [0x1df1750]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test"]]
> {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] [Updated] (DISPATCH-499) in propagating link detach the info field is dropped

[Gordon Sim (JIRA)]

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

Gordon Sim updated DISPATCH-499:

Attachment: DISPATCH-499.patch

Simple fix.

> in propagating link detach the info field is dropped
> 
>
> Key: DISPATCH-499
> URL: https://issues.apache.org/jira/browse/DISPATCH-499
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
> Attachments: DISPATCH-499.patch
>
>
> The router does not propagate the info field of any error condition in a link 
> detach. The info field may contain important information e.g. when used with 
> amqp:redirect.
> In the following snippet you can see the info field being dropped as the 
> detach is propagated:
> {noformat}
> [0x1df1750]:  <- AMQP
> [0x1df1750]:0 <- @open(16) 
> [container-id="19937f43-391c-457f-856d-83097ac9e20b", hostname="localhost", 
> channel-max=32767]
> [0x1df1750]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=2147483647]
> [0x1df1750]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 <- @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x1df1750]:  -> AMQP
> [0x1df1750]:0 -> @open(16) [container-id="Router.A", max-frame-size=16384, 
> channel-max=32767, idle-time-out=8000, 
> offered-capabilities=:"ANONYMOUS-RELAY", 
> properties={:product="qpid-dispatch-router", :version="0.7.0"}]
> [0x1df1750]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=61, outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, 
> outgoing-window=2147483647]
> [0x7fa128002df0]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 -> @flow(19) [incoming-window=15, next-outgoing-id=0, 
> outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
> drain=false]
> [0x7fa128002df0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7fa128002df0]:0 <- @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x7fa128002df0]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test", 
> info={"address"="elsewhere"}]]
> [0x1df1750]:0 -> @attach(18) 
> [name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, 
> timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x1df1750]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) 
> [condition=:"amqp:redirect", description="redirect test"]]
> {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] [Created] (DISPATCH-499) in propagating link detach the info field is dropped

[Gordon Sim (JIRA)]

Gordon Sim created DISPATCH-499:
---

 Summary: in propagating link detach the info field is dropped
 Key: DISPATCH-499
 URL: https://issues.apache.org/jira/browse/DISPATCH-499
 Project: Qpid Dispatch
  Issue Type: Bug
Reporter: Gordon Sim


The router does not propagate the info field of any error condition in a link 
detach. The info field may contain important information e.g. when used with 
amqp:redirect.

In the following snippet you can see the info field being dropped as the detach 
is propagated:

{noformat}
[0x1df1750]:  <- AMQP
[0x1df1750]:0 <- @open(16) 
[container-id="19937f43-391c-457f-856d-83097ac9e20b", hostname="localhost", 
channel-max=32767]
[0x1df1750]:0 <- @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
outgoing-window=2147483647]
[0x1df1750]:0 <- @attach(18) [name="19937f43-391c-457f-856d-83097ac9e20b-test", 
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
[address="test", durable=0, timeout=0, dynamic=false], target=@target(41) 
[durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x1df1750]:0 <- @flow(19) [incoming-window=2147483647, next-outgoing-id=0, 
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
drain=false]
[0x1df1750]:  -> AMQP
[0x1df1750]:0 -> @open(16) [container-id="Router.A", max-frame-size=16384, 
channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", 
properties={:product="qpid-dispatch-router", :version="0.7.0"}]
[0x1df1750]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, 
incoming-window=61, outgoing-window=2147483647]
[0x7fa128002df0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, 
outgoing-window=2147483647]
[0x7fa128002df0]:0 -> @attach(18) 
[name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=true, 
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="test", 
durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, 
dynamic=false], initial-delivery-count=0]
[0x7fa128002df0]:0 -> @flow(19) [incoming-window=15, next-outgoing-id=0, 
outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=10, 
drain=false]
[0x7fa128002df0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0, 
incoming-window=2147483647, outgoing-window=2147483647]
[0x7fa128002df0]:0 <- @attach(18) 
[name="19937f43-391c-457f-856d-83097ac9e20b-test", handle=0, role=false, 
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, 
dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], 
initial-delivery-count=0]
[0x7fa128002df0]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) 
[condition=:"amqp:redirect", description="redirect test", 
info={"address"="elsewhere"}]]
[0x1df1750]:0 -> @attach(18) [name="19937f43-391c-457f-856d-83097ac9e20b-test", 
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
[durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, 
timeout=0, dynamic=false], initial-delivery-count=0]
[0x1df1750]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) 
[condition=:"amqp:redirect", description="redirect test"]]
{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] (PROTON-1231) python: proton.utils.BlockingConnection hides disconnect error info

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1231: Fixed failing proton_tests..test_allowed_mechs_external

The test was comparing exact error message text, changed by previous fix to
include the transport error. Modified to check for a reliable substring.


> python: proton.utils.BlockingConnection hides disconnect error info
> ---
>
> Key: PROTON-1231
> URL: https://issues.apache.org/jira/browse/PROTON-1231
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.12.2
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.14.0
>
>
> proton.utils.BlockingConnection does not report the transport.condition error 
> information on a disconnect. This makes it very difficult to figure out what 
> is going on e.g. if the client cannot connect because of an authentication 
> problem.



--
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-1231) python: proton.utils.BlockingConnection hides disconnect error info

[ASF subversion and git services (JIRA)]

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

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

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

PROTON-1231: python BlockingConnection hides disconnect error info

Added the transport.condition error to the exception thrown on disconnect.


> python: proton.utils.BlockingConnection hides disconnect error info
> ---
>
> Key: PROTON-1231
> URL: https://issues.apache.org/jira/browse/PROTON-1231
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.12.2
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.14.0
>
>
> proton.utils.BlockingConnection does not report the transport.condition error 
> information on a disconnect. This makes it very difficult to figure out what 
> is going on e.g. if the client cannot connect because of an authentication 
> problem.



--
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-1231) python: proton.utils.BlockingConnection hides disconnect error info

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1231.
-
Resolution: Fixed

> python: proton.utils.BlockingConnection hides disconnect error info
> ---
>
> Key: PROTON-1231
> URL: https://issues.apache.org/jira/browse/PROTON-1231
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: python-binding
>Affects Versions: 0.12.2
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: 0.14.0
>
>
> proton.utils.BlockingConnection does not report the transport.condition error 
> information on a disconnect. This makes it very difficult to figure out what 
> is going on e.g. if the client cannot connect because of an authentication 
> problem.



--
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-1231) python: proton.utils.BlockingConnection hides disconnect error info

[Alan Conway (JIRA)]

Alan Conway created PROTON-1231:
---

 Summary: python: proton.utils.BlockingConnection hides disconnect 
error info
 Key: PROTON-1231
 URL: https://issues.apache.org/jira/browse/PROTON-1231
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Affects Versions: 0.12.2
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: 0.14.0


proton.utils.BlockingConnection does not report the transport.condition error 
information on a disconnect. This makes it very difficult to figure out what is 
going on e.g. if the client cannot connect because of an authentication problem.



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