[jira] [Commented] (PROTON-1897) Sporadic build failures in cpp_container_test
[
https://issues.apache.org/jira/browse/PROTON-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547415#comment-16547415
]
Andrew Stitcher commented on PROTON-1897:
-
The fix just applied should allow us to see the actual build failure which is
being hidden by the "terminate called..." message.
> Sporadic build failures in cpp_container_test
> -
>
> Key: PROTON-1897
> URL: https://issues.apache.org/jira/browse/PROTON-1897
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Environment: Travis CI Ubuntu 14.04.05 LTS
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
>
> {noformat}
> Start 25: cpp-container_test
> 25: Test command: /usr/bin/valgrind "--error-exitcode=42" "--quiet"
> "--leak-check=full" "--trace-children=yes"
> "--suppressions=/home/travis/build/astitcher/qpid-proton/c/tests/valgrind.supp"
> "/home/travis/build/astitcher/qpid-proton/build/cpp/container_test"
> 25: Test timeout computed to be: 1500
> 25: TEST: test_container_default_container_id()
> 25: TEST: test_container_vhost()
> ...
> 25: TEST: test_container_mt_stop_empty()
> 25: TEST: test_container_mt_stop()
> 25: terminate called without an active exception{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1881) C++ code is not built with warning flags
[ https://issues.apache.org/jira/browse/PROTON-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1881. - Resolution: Fixed Fix Version/s: proton-c-0.25.0 > C++ code is not built with warning flags > > > Key: PROTON-1881 > URL: https://issues.apache.org/jira/browse/PROTON-1881 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.23.0, proton-c-0.24.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.25.0 > > > The source tree reorganisation moved setting the CXX_WARNING_FLAG variable > into the c compilation tree of proton. These variables are inherited > downwards in the build tree. > Since the C++ code is not in the directory heirarchy below the setting of the > variables the warning flags are not set for the C++ builds any more . > So for some number of weeks we have not been getting adequate build warnings > on our C++ code. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1896) Python binding doesn't work correctly with IPv6 literals on python 2.6.6
[ https://issues.apache.org/jira/browse/PROTON-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1896. - Resolution: Fixed Fix Version/s: proton-c-0.25.0 > Python binding doesn't work correctly with IPv6 literals on python 2.6.6 > > > Key: PROTON-1896 > URL: https://issues.apache.org/jira/browse/PROTON-1896 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 > Environment: python 2.6.6, RHEL 6 or CentOS 6 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.25.0 > > > This is because the urlparse class under python 2.6.6 doesn't correctly > parse hostname from netloc. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1896) Python binding doesn't work correctly with IPv6 literals on python 2.6.6
[ https://issues.apache.org/jira/browse/PROTON-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547386#comment-16547386 ] ASF subversion and git services commented on PROTON-1896: - Commit f48e4cf4f8bfe014c242dd94928bb1800241282e in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f48e4cf ] PROTON-1896: Implement hostname parsing from netloc for our Url class - The builtin url parser in python 2.6 can't correctly parse IPv6 literals > Python binding doesn't work correctly with IPv6 literals on python 2.6.6 > > > Key: PROTON-1896 > URL: https://issues.apache.org/jira/browse/PROTON-1896 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 > Environment: python 2.6.6, RHEL 6 or CentOS 6 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > This is because the urlparse class under python 2.6.6 doesn't correctly > parse hostname from netloc. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1881) C++ code is not built with warning flags
[ https://issues.apache.org/jira/browse/PROTON-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547377#comment-16547377 ] ASF subversion and git services commented on PROTON-1881: - Commit 0abd876b26ab40a6ccd4c0d1a9f3e483d2b8e192 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0abd876 ] PROTON-1881: Fix c++ flags (warnings etc.) - Also fix a couple of issues that crept in whilst warnings were gone > C++ code is not built with warning flags > > > Key: PROTON-1881 > URL: https://issues.apache.org/jira/browse/PROTON-1881 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.23.0, proton-c-0.24.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > The source tree reorganisation moved setting the CXX_WARNING_FLAG variable > into the c compilation tree of proton. These variables are inherited > downwards in the build tree. > Since the C++ code is not in the directory heirarchy below the setting of the > variables the warning flags are not set for the C++ builds any more . > So for some number of weeks we have not been getting adequate build warnings > on our C++ code. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1897) Sporadic build failures in cpp_container_test
[
https://issues.apache.org/jira/browse/PROTON-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547373#comment-16547373
]
ASF subversion and git services commented on PROTON-1897:
-
Commit 4e87a519c5b86015b236cbdaacefc84ff4298c4b in qpid-proton's branch
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4e87a51 ]
PROTON-1897: Make sure that we don't exit tests with unjoined threads
- The tests signal assertion failures with exceptions if there are unjoined
threads
the assertion failure exceptions get overridden by terminate due to threads
still
hanging about.
> Sporadic build failures in cpp_container_test
> -
>
> Key: PROTON-1897
> URL: https://issues.apache.org/jira/browse/PROTON-1897
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Environment: Travis CI Ubuntu 14.04.05 LTS
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
>
> {noformat}
> Start 25: cpp-container_test
> 25: Test command: /usr/bin/valgrind "--error-exitcode=42" "--quiet"
> "--leak-check=full" "--trace-children=yes"
> "--suppressions=/home/travis/build/astitcher/qpid-proton/c/tests/valgrind.supp"
> "/home/travis/build/astitcher/qpid-proton/build/cpp/container_test"
> 25: Test timeout computed to be: 1500
> 25: TEST: test_container_default_container_id()
> 25: TEST: test_container_vhost()
> ...
> 25: TEST: test_container_mt_stop_empty()
> 25: TEST: test_container_mt_stop()
> 25: terminate called without an active exception{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1897) Sporadic build failures in cpp_container_test
Andrew Stitcher created PROTON-1897:
---
Summary: Sporadic build failures in cpp_container_test
Key: PROTON-1897
URL: https://issues.apache.org/jira/browse/PROTON-1897
Project: Qpid Proton
Issue Type: Bug
Components: cpp-binding
Environment: Travis CI Ubuntu 14.04.05 LTS
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
{noformat}
Start 25: cpp-container_test
25: Test command: /usr/bin/valgrind "--error-exitcode=42" "--quiet"
"--leak-check=full" "--trace-children=yes"
"--suppressions=/home/travis/build/astitcher/qpid-proton/c/tests/valgrind.supp"
"/home/travis/build/astitcher/qpid-proton/build/cpp/container_test"
25: Test timeout computed to be: 1500
25: TEST: test_container_default_container_id()
25: TEST: test_container_vhost()
...
25: TEST: test_container_mt_stop_empty()
25: TEST: test_container_mt_stop()
25: terminate called without an active exception{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1881) C++ code is not built with warning flags
[ https://issues.apache.org/jira/browse/PROTON-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-1881: --- Assignee: Andrew Stitcher > C++ code is not built with warning flags > > > Key: PROTON-1881 > URL: https://issues.apache.org/jira/browse/PROTON-1881 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: proton-c-0.23.0, proton-c-0.24.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > > The source tree reorganisation moved setting the CXX_WARNING_FLAG variable > into the c compilation tree of proton. These variables are inherited > downwards in the build tree. > Since the C++ code is not in the directory heirarchy below the setting of the > variables the warning flags are not set for the C++ builds any more . > So for some number of weeks we have not been getting adequate build warnings > on our C++ code. -- 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-1896) Python binding doesn't work correctly with IPv6 literals on python 2.6.6
Andrew Stitcher created PROTON-1896: --- Summary: Python binding doesn't work correctly with IPv6 literals on python 2.6.6 Key: PROTON-1896 URL: https://issues.apache.org/jira/browse/PROTON-1896 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: proton-c-0.24.0 Environment: python 2.6.6, RHEL 6 or CentOS 6 Reporter: Andrew Stitcher Assignee: Andrew Stitcher This is because the urlparse class under python 2.6.6 doesn't correctly parse hostname from netloc. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1884) [c] example broker does not configure SASL correctly
[ https://issues.apache.org/jira/browse/PROTON-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-1884: --- Assignee: Andrew Stitcher (was: Alan Conway) > [c] example broker does not configure SASL correctly > > > Key: PROTON-1884 > URL: https://issues.apache.org/jira/browse/PROTON-1884 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.25.0 > > > The C example broker does not configure SASL correctly, it calls pn_sasl() > before pn_transport_server() which creates a client-side SASL config that > does not respond to incoming SASL requests. > Note: the original description of this issue described it as a python client > problem which is not the case. The python client has SASL on by default > whereas other clients have it off by default, so the python client showed the > problem immediatley. Turning SASL on in other clients showed the same problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1884) [c] example broker does not configure SASL correctly
[ https://issues.apache.org/jira/browse/PROTON-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reopened PROTON-1884: - I think this is the wrong solution. You shouldn't need to call pn_transport_set_server() before pn_sasl(). Rather when you call pn_transport_ser_server() as long as you are not connected yet it should update any existing transport->sasl member. There is no need to enforce the somewhat error-prone and unintuitive ordering. > [c] example broker does not configure SASL correctly > > > Key: PROTON-1884 > URL: https://issues.apache.org/jira/browse/PROTON-1884 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.23.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.25.0 > > > The C example broker does not configure SASL correctly, it calls pn_sasl() > before pn_transport_server() which creates a client-side SASL config that > does not respond to incoming SASL requests. > Note: the original description of this issue described it as a python client > problem which is not the case. The python client has SASL on by default > whereas other clients have it off by default, so the python client showed the > problem immediatley. Turning SASL on in other clients showed the same problem. -- 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-1067) Doc improvements for router policies
[ https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547121#comment-16547121 ] ASF GitHub Bot commented on DISPATCH-1067: -- Github user bhardesty commented on the issue: https://github.com/apache/qpid-dispatch/pull/343 @ganeshmurthy this is ready to merge. > Doc improvements for router policies > > > Key: DISPATCH-1067 > URL: https://issues.apache.org/jira/browse/DISPATCH-1067 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.2.0 >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > The router policy doc needs to be updated to cover the following enhancements: > * Patterns for policy hostnames (DISPATCH-990) > * New policy config attributes (DISPATCH-976) > * Policy username substitution improvements (DISPATCH-1011) > * Allow vhost policies to be configured in the router configuration file > (DISPATCH-1013) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #343: DISPATCH-1067 - updates to policy doc (updated)
Github user bhardesty commented on the issue: https://github.com/apache/qpid-dispatch/pull/343 @ganeshmurthy this is ready to merge. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-403) Failover handler doesn't release pending tasks that could complete on connection drop
[ https://issues.apache.org/jira/browse/QPIDJMS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-403. -- Resolution: Fixed > Failover handler doesn't release pending tasks that could complete on > connection drop > - > > Key: QPIDJMS-403 > URL: https://issues.apache.org/jira/browse/QPIDJMS-403 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.35.0 > > > Some tasks that are in flight in the Failover handler could complete when a > connection drops instead of waiting for a reconnect to occur but are not > having their off line behavior handler triggered when the connection drop is > detected and are forced to wait until a reconnect before they complete. One > such example is a session close which when in flight and the connection drops > we can allow the request to complete because there nothing more to do for > that request on reconnect. -- 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-403) Failover handler doesn't release pending tasks that could complete on connection drop
[ https://issues.apache.org/jira/browse/QPIDJMS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547118#comment-16547118 ] ASF subversion and git services commented on QPIDJMS-403: - Commit 3244adc3adf14e90f0367df683f672a0b4e87d80 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=3244adc ] QPIDJMS-403 Trigger whenOffline event on queued requests on drop When the handle connection failure method runs it should trigger the when off line behavior of any currently queued tasks in order to allow timely completion of requests that do not need to wait for a new connection to happen such as session close, message acknowledge etc. > Failover handler doesn't release pending tasks that could complete on > connection drop > - > > Key: QPIDJMS-403 > URL: https://issues.apache.org/jira/browse/QPIDJMS-403 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.35.0 > > > Some tasks that are in flight in the Failover handler could complete when a > connection drops instead of waiting for a reconnect to occur but are not > having their off line behavior handler triggered when the connection drop is > detected and are forced to wait until a reconnect before they complete. One > such example is a session close which when in flight and the connection drops > we can allow the request to complete because there nothing more to do for > that request on reconnect. -- 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-403) Failover handler doesn't release pending tasks that could complete on connection drop
Timothy Bish created QPIDJMS-403: Summary: Failover handler doesn't release pending tasks that could complete on connection drop Key: QPIDJMS-403 URL: https://issues.apache.org/jira/browse/QPIDJMS-403 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.34.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.35.0 Some tasks that are in flight in the Failover handler could complete when a connection drops instead of waiting for a reconnect to occur but are not having their off line behavior handler triggered when the connection drop is detected and are forced to wait until a reconnect before they complete. One such example is a session close which when in flight and the connection drops we can allow the request to complete because there nothing more to do for that request on reconnect. -- 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-1067) Doc improvements for router policies
[
https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547099#comment-16547099
]
ASF GitHub Bot commented on DISPATCH-1067:
--
Github user bhardesty commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203176550
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are
delimited by either `.` or `/` characters. They also may contain special
wildcard characters that represent words:
--- End diff --
Changed to "can"
> Doc improvements for router policies
>
>
> Key: DISPATCH-1067
> URL: https://issues.apache.org/jira/browse/DISPATCH-1067
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.2.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> The router policy doc needs to be updated to cover the following enhancements:
> * Patterns for policy hostnames (DISPATCH-990)
> * New policy config attributes (DISPATCH-976)
> * Policy username substitution improvements (DISPATCH-1011)
> * Allow vhost policies to be configured in the router configuration file
> (DISPATCH-1013)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...
Github user bhardesty commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203176550
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are
delimited by either `.` or `/` characters. They also may contain special
wildcard characters that represent words:
--- End diff --
Changed to "can"
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1067) Doc improvements for router policies
[
https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547098#comment-16547098
]
ASF GitHub Bot commented on DISPATCH-1067:
--
Github user bhardesty commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203176226
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
--- End diff --
Done.
> Doc improvements for router policies
>
>
> Key: DISPATCH-1067
> URL: https://issues.apache.org/jira/browse/DISPATCH-1067
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.2.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> The router policy doc needs to be updated to cover the following enhancements:
> * Patterns for policy hostnames (DISPATCH-990)
> * New policy config attributes (DISPATCH-976)
> * Policy username substitution improvements (DISPATCH-1011)
> * Allow vhost policies to be configured in the router configuration file
> (DISPATCH-1013)
--
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-1067) Doc improvements for router policies
[
https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547097#comment-16547097
]
ASF GitHub Bot commented on DISPATCH-1067:
--
Github user bhardesty commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203175947
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -442,290 +442,367 @@ For more information about these attributes, see
xref:adding-sasl-authentication
== Authorizing Access to Messaging Resources
-You can restrict the number of user connections, and control access to
AMQP messaging resources by configuring _policies_.
+You can configure _policies_ to secure messaging resources in your
messaging environment. Policies ensure that only authorized users can access
messaging endpoints through the router network, and that the resources on those
endpoints are used in an authorized way.
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and
_vhost policies_.
+{RouterName} provides the following types of policies:
Global policies::
-Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all vhost policies), and
defines how the router should use vhost policies.
+Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all messaging endpoints), and
defines how the router should use vhost policies.
Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or _vhost_). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
-+
-[NOTE]
-
-A vhost is typically the name of the host to which the client connection
is directed. For example, if a client application opens a connection to the
`amqp://mybroker.example.com:5672/queue01` URL, the vhost would be
`mybroker.example.com`.
-
+Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or vhost). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
The resource limits defined in global and vhost policies are applied to
user connections only. The limits do not affect inter-router connections or
router connections that are outbound to waypoints.
-=== How {RouterName} Applies Policies
+=== How {RouterName} Enforces Connection and Resource Limits
-{RouterName} uses both global and vhost policies to determine whether to
permit a connection, and if it is permitted, to apply the appropriate resource
limits.
+{RouterName} uses policies to determine whether to permit a connection,
and if it is permitted, to apply the appropriate resource limits.
When a client creates a connection to the router, the router first
determines whether to allow or deny the connection. This decision is based on
the following criteria:
-* Whether the connection will exceed the router's global connection limit
(defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
+* Whether the connection will exceed the router’s global connection limit
(defined in the global policy)
-If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user group's resource limits for the lifetime of the connection.
+* Whether the connection will exceed the vhost’s connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
-=== Configuring Global Policies
+If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user group’s resource limits for the lifetime of the connection.
-You can set the incoming connection limit for the router and define how it
should use vhost policies by configuring a global policy.
+=== Setting Global Connection Limits
+
+You can set the incoming connection limit for the router. This limit
defines the total number of concurrent client connections that can be open for
this router.
.Procedure
-* In the router configuration file, add a `policy` section.
+* In the router configuration file, add a `policy` section and set the
`maxConnections`.
+
--
[options="nowrap",subs="+quotes"]
-policy = {
-maxConnections: 1 // <1>
-enableVhostPolicy: true // <2>
-policyDir:
[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...
Github user bhardesty commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203175947
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -442,290 +442,367 @@ For more information about these attributes, see
xref:adding-sasl-authentication
== Authorizing Access to Messaging Resources
-You can restrict the number of user connections, and control access to
AMQP messaging resources by configuring _policies_.
+You can configure _policies_ to secure messaging resources in your
messaging environment. Policies ensure that only authorized users can access
messaging endpoints through the router network, and that the resources on those
endpoints are used in an authorized way.
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and
_vhost policies_.
+{RouterName} provides the following types of policies:
Global policies::
-Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all vhost policies), and
defines how the router should use vhost policies.
+Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all messaging endpoints), and
defines how the router should use vhost policies.
Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or _vhost_). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
-+
-[NOTE]
-
-A vhost is typically the name of the host to which the client connection
is directed. For example, if a client application opens a connection to the
`amqp://mybroker.example.com:5672/queue01` URL, the vhost would be
`mybroker.example.com`.
-
+Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or vhost). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
The resource limits defined in global and vhost policies are applied to
user connections only. The limits do not affect inter-router connections or
router connections that are outbound to waypoints.
-=== How {RouterName} Applies Policies
+=== How {RouterName} Enforces Connection and Resource Limits
-{RouterName} uses both global and vhost policies to determine whether to
permit a connection, and if it is permitted, to apply the appropriate resource
limits.
+{RouterName} uses policies to determine whether to permit a connection,
and if it is permitted, to apply the appropriate resource limits.
When a client creates a connection to the router, the router first
determines whether to allow or deny the connection. This decision is based on
the following criteria:
-* Whether the connection will exceed the router's global connection limit
(defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
+* Whether the connection will exceed the routerâs global connection
limit (defined in the global policy)
-If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user group's resource limits for the lifetime of the connection.
+* Whether the connection will exceed the vhostâs connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
-=== Configuring Global Policies
+If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user groupâs resource limits for the lifetime of the connection.
-You can set the incoming connection limit for the router and define how it
should use vhost policies by configuring a global policy.
+=== Setting Global Connection Limits
+
+You can set the incoming connection limit for the router. This limit
defines the total number of concurrent client connections that can be open for
this router.
.Procedure
-* In the router configuration file, add a `policy` section.
+* In the router configuration file, add a `policy` section and set the
`maxConnections`.
+
--
[options="nowrap",subs="+quotes"]
-policy = {
-maxConnections: 1 // <1>
-enableVhostPolicy: true // <2>
-policyDir: /etc/qpid-dispatch/policies/ // <3>
-defaultVhost: $default // <4>
+policy {
+maxConnections: 1
}
-<1> The maximum number of concurrent client connections allowed for this
router. This limit is always
[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...
Github user bhardesty commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203176226
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
--- End diff --
Done.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1067) Doc improvements for router policies
[
https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547067#comment-16547067
]
ASF GitHub Bot commented on DISPATCH-1067:
--
Github user jenmalloy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203164612
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are
delimited by either `.` or `/` characters. They also may contain special
wildcard characters that represent words:
--- End diff --
Change "may" to "might"
> Doc improvements for router policies
>
>
> Key: DISPATCH-1067
> URL: https://issues.apache.org/jira/browse/DISPATCH-1067
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.2.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> The router policy doc needs to be updated to cover the following enhancements:
> * Patterns for policy hostnames (DISPATCH-990)
> * New policy config attributes (DISPATCH-976)
> * Policy username substitution improvements (DISPATCH-1011)
> * Allow vhost policies to be configured in the router configuration file
> (DISPATCH-1013)
--
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-1067) Doc improvements for router policies
[
https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547066#comment-16547066
]
ASF GitHub Bot commented on DISPATCH-1067:
--
Github user jenmalloy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r20316
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
--- End diff --
Change "may" to "might"
> Doc improvements for router policies
>
>
> Key: DISPATCH-1067
> URL: https://issues.apache.org/jira/browse/DISPATCH-1067
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.2.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>Priority: Major
>
> The router policy doc needs to be updated to cover the following enhancements:
> * Patterns for policy hostnames (DISPATCH-990)
> * New policy config attributes (DISPATCH-976)
> * Policy username substitution improvements (DISPATCH-1011)
> * Allow vhost policies to be configured in the router configuration file
> (DISPATCH-1013)
--
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-1067) Doc improvements for router policies
[
https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547068#comment-16547068
]
ASF GitHub Bot commented on DISPATCH-1067:
--
Github user jenmalloy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203152559
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -442,290 +442,367 @@ For more information about these attributes, see
xref:adding-sasl-authentication
== Authorizing Access to Messaging Resources
-You can restrict the number of user connections, and control access to
AMQP messaging resources by configuring _policies_.
+You can configure _policies_ to secure messaging resources in your
messaging environment. Policies ensure that only authorized users can access
messaging endpoints through the router network, and that the resources on those
endpoints are used in an authorized way.
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and
_vhost policies_.
+{RouterName} provides the following types of policies:
Global policies::
-Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all vhost policies), and
defines how the router should use vhost policies.
+Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all messaging endpoints), and
defines how the router should use vhost policies.
Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or _vhost_). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
-+
-[NOTE]
-
-A vhost is typically the name of the host to which the client connection
is directed. For example, if a client application opens a connection to the
`amqp://mybroker.example.com:5672/queue01` URL, the vhost would be
`mybroker.example.com`.
-
+Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or vhost). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
The resource limits defined in global and vhost policies are applied to
user connections only. The limits do not affect inter-router connections or
router connections that are outbound to waypoints.
-=== How {RouterName} Applies Policies
+=== How {RouterName} Enforces Connection and Resource Limits
-{RouterName} uses both global and vhost policies to determine whether to
permit a connection, and if it is permitted, to apply the appropriate resource
limits.
+{RouterName} uses policies to determine whether to permit a connection,
and if it is permitted, to apply the appropriate resource limits.
When a client creates a connection to the router, the router first
determines whether to allow or deny the connection. This decision is based on
the following criteria:
-* Whether the connection will exceed the router's global connection limit
(defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
+* Whether the connection will exceed the router’s global connection limit
(defined in the global policy)
-If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user group's resource limits for the lifetime of the connection.
+* Whether the connection will exceed the vhost’s connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
-=== Configuring Global Policies
+If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user group’s resource limits for the lifetime of the connection.
-You can set the incoming connection limit for the router and define how it
should use vhost policies by configuring a global policy.
+=== Setting Global Connection Limits
+
+You can set the incoming connection limit for the router. This limit
defines the total number of concurrent client connections that can be open for
this router.
.Procedure
-* In the router configuration file, add a `policy` section.
+* In the router configuration file, add a `policy` section and set the
`maxConnections`.
+
--
[options="nowrap",subs="+quotes"]
-policy = {
-maxConnections: 1 // <1>
-enableVhostPolicy: true // <2>
-policyDir:
[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...
Github user jenmalloy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203152559
--- Diff: docs/books/user-guide/configuration-security.adoc ---
@@ -442,290 +442,367 @@ For more information about these attributes, see
xref:adding-sasl-authentication
== Authorizing Access to Messaging Resources
-You can restrict the number of user connections, and control access to
AMQP messaging resources by configuring _policies_.
+You can configure _policies_ to secure messaging resources in your
messaging environment. Policies ensure that only authorized users can access
messaging endpoints through the router network, and that the resources on those
endpoints are used in an authorized way.
-=== Types of Policies
-
-You can configure two different types of policies: _global policies_ and
_vhost policies_.
+{RouterName} provides the following types of policies:
Global policies::
-Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all vhost policies), and
defines how the router should use vhost policies.
+Settings for the router. A global policy defines the maximum number of
incoming user connections for the router (across all messaging endpoints), and
defines how the router should use vhost policies.
Vhost policies::
-Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or _vhost_). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
-+
-[NOTE]
-
-A vhost is typically the name of the host to which the client connection
is directed. For example, if a client application opens a connection to the
`amqp://mybroker.example.com:5672/queue01` URL, the vhost would be
`mybroker.example.com`.
-
+Connection and AMQP resource limits for a messaging endpoint (called an
AMQP virtual host, or vhost). A vhost policy defines what a client can access
on a messaging endpoint over a particular connection.
The resource limits defined in global and vhost policies are applied to
user connections only. The limits do not affect inter-router connections or
router connections that are outbound to waypoints.
-=== How {RouterName} Applies Policies
+=== How {RouterName} Enforces Connection and Resource Limits
-{RouterName} uses both global and vhost policies to determine whether to
permit a connection, and if it is permitted, to apply the appropriate resource
limits.
+{RouterName} uses policies to determine whether to permit a connection,
and if it is permitted, to apply the appropriate resource limits.
When a client creates a connection to the router, the router first
determines whether to allow or deny the connection. This decision is based on
the following criteria:
-* Whether the connection will exceed the router's global connection limit
(defined in the global policy)
-* Whether the connection will exceed the vhost's connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
+* Whether the connection will exceed the routerâs global connection
limit (defined in the global policy)
-If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user group's resource limits for the lifetime of the connection.
+* Whether the connection will exceed the vhostâs connection limits
(defined in the vhost policy that matches the host to which the connection is
directed)
-=== Configuring Global Policies
+If the connection is allowed, the router assigns the user (the
authenticated user name from the connection) to a user group, and enforces the
user groupâs resource limits for the lifetime of the connection.
-You can set the incoming connection limit for the router and define how it
should use vhost policies by configuring a global policy.
+=== Setting Global Connection Limits
+
+You can set the incoming connection limit for the router. This limit
defines the total number of concurrent client connections that can be open for
this router.
.Procedure
-* In the router configuration file, add a `policy` section.
+* In the router configuration file, add a `policy` section and set the
`maxConnections`.
+
--
[options="nowrap",subs="+quotes"]
-policy = {
-maxConnections: 1 // <1>
-enableVhostPolicy: true // <2>
-policyDir: /etc/qpid-dispatch/policies/ // <3>
-defaultVhost: $default // <4>
+policy {
+maxConnections: 1
}
-<1> The maximum number of concurrent client connections allowed for this
router. This limit is always
[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...
Github user jenmalloy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r20316
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
--- End diff --
Change "may" to "might"
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #343: DISPATCH-1067 - updates to policy doc (upda...
Github user jenmalloy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/343#discussion_r203164612
--- Diff: docs/books/user-guide/understand-router-configuration.adoc ---
@@ -51,6 +51,133 @@ sectionName {
}
+[id='methods-for-using-pattern-matching']
+== Methods for Using Pattern Matching and Wildcards
+
+The router configuration file supports pattern matching and wildcards to
enable you to match multiple values for certain attributes. However, the syntax
varies based on the type of entity that you are configuring.
+
+[id='router-address-pattern-matching']
+=== Pattern Matching for Addresses
+
+In some router configuration scenarios, you may need to use pattern
matching to match a range of addresses rather than a single, literal address.
Address patterns match any address that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are
delimited by either `.` or `/` characters. They also may contain special
wildcard characters that represent words:
--- End diff --
Change "may" to "might"
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1064) Doc link route reconnect behavior
[ https://issues.apache.org/jira/browse/DISPATCH-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547058#comment-16547058 ] ASF GitHub Bot commented on DISPATCH-1064: -- Github user bhardesty commented on the issue: https://github.com/apache/qpid-dispatch/pull/339 @ganeshmurthy this is ready to merge. > Doc link route reconnect behavior > - > > Key: DISPATCH-1064 > URL: https://issues.apache.org/jira/browse/DISPATCH-1064 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.2.0 >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > When the router is configured with a linkRoute and client connects using > failover, the link will not be reestablished should the router's connection > to the broker fail. If auto-reconnect is required, the router should be > configured with autoLink. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #339: DISPATCH-1064 - Doc link route reconnect behavior
Github user bhardesty commented on the issue: https://github.com/apache/qpid-dispatch/pull/339 @ganeshmurthy this is ready to merge. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1067) Doc improvements for router policies
[ https://issues.apache.org/jira/browse/DISPATCH-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546969#comment-16546969 ] ASF GitHub Bot commented on DISPATCH-1067: -- Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/343 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=h1) Report > :exclamation: No coverage uploaded for pull request base (`master@a3b271e`). [Click here to learn what that means](https://docs.codecov.io/docs/error-reference#section-missing-base-commit). > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=tree) ```diff @@Coverage Diff@@ ## master #343 +/- ## = Coverage ? 84.35% = Files ? 69 Lines ?15624 Branches ?0 = Hits ?13180 Misses? 2444 Partials ?0 ``` -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=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/343?src=pr=footer). Last update [a3b271e...0b8332f](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). > Doc improvements for router policies > > > Key: DISPATCH-1067 > URL: https://issues.apache.org/jira/browse/DISPATCH-1067 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.2.0 >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > The router policy doc needs to be updated to cover the following enhancements: > * Patterns for policy hostnames (DISPATCH-990) > * New policy config attributes (DISPATCH-976) > * Policy username substitution improvements (DISPATCH-1011) > * Allow vhost policies to be configured in the router configuration file > (DISPATCH-1013) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #343: DISPATCH-1067 - updates to policy doc (updated)
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/343 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=h1) Report > :exclamation: No coverage uploaded for pull request base (`master@a3b271e`). [Click here to learn what that means](https://docs.codecov.io/docs/error-reference#section-missing-base-commit). > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=tree) ```diff @@Coverage Diff@@ ## master #343 +/- ## = Coverage ? 84.35% = Files ? 69 Lines ?15624 Branches ?0 = Hits ?13180 Misses? 2444 Partials ?0 ``` -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=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/343?src=pr=footer). Last update [a3b271e...0b8332f](https://codecov.io/gh/apache/qpid-dispatch/pull/343?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1080) system_tests_ssl failing consistently on Travis
[
https://issues.apache.org/jira/browse/DISPATCH-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1080.
-
Resolution: Fixed
> system_tests_ssl failing consistently on Travis
> ---
>
> Key: DISPATCH-1080
> URL: https://issues.apache.org/jira/browse/DISPATCH-1080
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.2.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.3.0
>
>
> system_tests_ssl is consistently failing on Travis
> {noformat}
> Test command: /usr/bin/python
> "/home/travis/build/apache/qpid-dispatch/build/tests/run.py" "-x" "unit2"
> "-v" "system_tests_ssl"
> 47: Test timeout computed to be: 1500
> 47: test_ssl_invalid (system_tests_ssl.RouterTestSslClient) ... ok
> 47: test_ssl_sasl_client_invalid (system_tests_ssl.RouterTestSslClient) ... ok
> 47: test_ssl_sasl_client_valid (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls11_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls11_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_tls11_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls_all (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_connected_tls_sasl_routers
> (system_tests_ssl.RouterTestSslInterRouter) ... ERROR
> 47:
> 47: ==
> 47: ERROR: test_connected_tls_sasl_routers
> (system_tests_ssl.RouterTestSslInterRouter)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 584, in test_connected_tls_sasl_routers
> 47: router_nodes = self.get_router_nodes()
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 572, in get_router_nodes
> 47: node = Node.connect(url)
> 47: File
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch/management/client.py",
> line 111, in connect
> 47: return Node(Node.connection(url, router, timeout, ssl_domain, sasl))
> 47: File
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch/management/client.py",
> line 106, in connection
> 47: password=str(sasl.password) if sasl else None)
> 47: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/utils.py",
> line 237, in __init__
> 47: msg="Opening connection")
> 47: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/utils.py",
> line 314, in wait
> 47: "Connection %s disconnected: %s" % (self.url, self.disconnected))
> 47: ConnectionException: Connection amqp://0.0.0.0:0/$management
> disconnected: Condition('proton:io', 'recv: Connection refused')
> 47:
> 47: ==
> 47: FAIL: test_ssl_sasl_client_valid (system_tests_ssl.RouterTestSslClient)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 374, in test_ssl_sasl_client_valid
> 47: self.assertTrue(self.is_ssl_sasl_client_accepted(self.PORT_TLS_SASL,
> "TLSv1"))
> 47: AssertionError: False is not true
> 47:
> 47: ==
> 47: FAIL: test_tls11_only (system_tests_ssl.RouterTestSslClient)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 325, in test_tls11_only
> 47: self.get_allowed_protocols(self.PORT_TLS11))
> 47: AssertionError: Lists differ: [False, True, False] != [False, False,
> False]
> 47:
> 47: First differing element 1:
> 47: True
> 47: False
> 47:
> 47: - [False, True, False]
> 47: ? ^^^
> 47:
> 47: + [False, False, False]
> 47: ?
> 47:
> 47:
> 47: ==
> 47: FAIL: test_tls11_tls12_only (system_tests_ssl.RouterTestSslClient)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 353, in test_tls11_tls12_only
> 47: self.get_allowed_protocols(self.PORT_TLS11_TLS12))
> 47:
[jira] [Commented] (DISPATCH-1080) system_tests_ssl failing consistently on Travis
[
https://issues.apache.org/jira/browse/DISPATCH-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546746#comment-16546746
]
ASF subversion and git services commented on DISPATCH-1080:
---
Commit 1b39fff04f7d8e15f0762183d1d4b4c3a801739c in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=1b39fff ]
DISPATCH-1080 - Added code to skip tests only if SASL extended is not available
on the executing system
> system_tests_ssl failing consistently on Travis
> ---
>
> Key: DISPATCH-1080
> URL: https://issues.apache.org/jira/browse/DISPATCH-1080
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.2.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.3.0
>
>
> system_tests_ssl is consistently failing on Travis
> {noformat}
> Test command: /usr/bin/python
> "/home/travis/build/apache/qpid-dispatch/build/tests/run.py" "-x" "unit2"
> "-v" "system_tests_ssl"
> 47: Test timeout computed to be: 1500
> 47: test_ssl_invalid (system_tests_ssl.RouterTestSslClient) ... ok
> 47: test_ssl_sasl_client_invalid (system_tests_ssl.RouterTestSslClient) ... ok
> 47: test_ssl_sasl_client_valid (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls11_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls11_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_tls11_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls1_tls12_only (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_tls_all (system_tests_ssl.RouterTestSslClient) ... FAIL
> 47: test_connected_tls_sasl_routers
> (system_tests_ssl.RouterTestSslInterRouter) ... ERROR
> 47:
> 47: ==
> 47: ERROR: test_connected_tls_sasl_routers
> (system_tests_ssl.RouterTestSslInterRouter)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 584, in test_connected_tls_sasl_routers
> 47: router_nodes = self.get_router_nodes()
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 572, in get_router_nodes
> 47: node = Node.connect(url)
> 47: File
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch/management/client.py",
> line 111, in connect
> 47: return Node(Node.connection(url, router, timeout, ssl_domain, sasl))
> 47: File
> "/home/travis/build/apache/qpid-dispatch/python/qpid_dispatch/management/client.py",
> line 106, in connection
> 47: password=str(sasl.password) if sasl else None)
> 47: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/utils.py",
> line 237, in __init__
> 47: msg="Opening connection")
> 47: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/utils.py",
> line 314, in wait
> 47: "Connection %s disconnected: %s" % (self.url, self.disconnected))
> 47: ConnectionException: Connection amqp://0.0.0.0:0/$management
> disconnected: Condition('proton:io', 'recv: Connection refused')
> 47:
> 47: ==
> 47: FAIL: test_ssl_sasl_client_valid (system_tests_ssl.RouterTestSslClient)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 374, in test_ssl_sasl_client_valid
> 47: self.assertTrue(self.is_ssl_sasl_client_accepted(self.PORT_TLS_SASL,
> "TLSv1"))
> 47: AssertionError: False is not true
> 47:
> 47: ==
> 47: FAIL: test_tls11_only (system_tests_ssl.RouterTestSslClient)
> 47: --
> 47: Traceback (most recent call last):
> 47: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_tests_ssl.py", line
> 325, in test_tls11_only
> 47: self.get_allowed_protocols(self.PORT_TLS11))
> 47: AssertionError: Lists differ: [False, True, False] != [False, False,
> False]
> 47:
> 47: First differing element 1:
> 47: True
> 47: False
> 47:
> 47: - [False, True, False]
> 47: ? ^^^
> 47:
> 47: + [False, False, False]
> 47: ?
> 47:
> 47:
> 47: ==
> 47: FAIL: test_tls11_tls12_only
[jira] [Resolved] (DISPATCH-1074) Fix mouseover on an address on console's Chord page
[ https://issues.apache.org/jira/browse/DISPATCH-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1074. Resolution: Fixed Assignee: Ernest Allen Fix Version/s: 1.3.0 Move the mouseover and mouseout event to the containing list item instead of the span. > Fix mouseover on an address on console's Chord page > > > Key: DISPATCH-1074 > URL: https://issues.apache.org/jira/browse/DISPATCH-1074 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.2.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > Fix For: 1.3.0 > > > On the console's Message flow page (chord diagram), when you mouse over the > address section in the legend, the chord diagram does not update unless the > mouse is directly over the address text. > The chord diagram should update when the mouse is in any part of the address > legend line, and not just the text. > -- 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-1074) Fix mouseover on an address on console's Chord page
[ https://issues.apache.org/jira/browse/DISPATCH-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546606#comment-16546606 ] ASF subversion and git services commented on DISPATCH-1074: --- Commit 51cba5cd7e04c5436ded3986986035c9b29b5bc9 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=51cba5c ] DISPATCH-1074 Respond to mouseover an address on Console's message flow page. > Fix mouseover on an address on console's Chord page > > > Key: DISPATCH-1074 > URL: https://issues.apache.org/jira/browse/DISPATCH-1074 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.2.0 >Reporter: Ernest Allen >Priority: Minor > > On the console's Message flow page (chord diagram), when you mouse over the > address section in the legend, the chord diagram does not update unless the > mouse is directly over the address text. > The chord diagram should update when the mouse is in any part of the address > legend line, and not just the text. > -- 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-1078) Tab bar icon changes for topology page
[ https://issues.apache.org/jira/browse/DISPATCH-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1078. Resolution: Fixed Assignee: Ernest Allen Fix Version/s: 1.3.0 > Tab bar icon changes for topology page > -- > > Key: DISPATCH-1078 > URL: https://issues.apache.org/jira/browse/DISPATCH-1078 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.2.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Trivial > Fix For: 1.3.0 > > > The icon displayed next to the topology tab is supposed to be the fontawesome > gears icon. > When the Message traffic page is current, the topology icon changes. > The Topology icon should not change when the message traffic page is > displayed. -- 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-1078) Tab bar icon changes for topology page
[ https://issues.apache.org/jira/browse/DISPATCH-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546600#comment-16546600 ] ASF subversion and git services commented on DISPATCH-1078: --- Commit 6a4d571f6c7cd17cbf2c1df313273e403d689ffc in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6a4d571 ] DISPATCH-1078 Prevent font override on Consoles's message flow page. > Tab bar icon changes for topology page > -- > > Key: DISPATCH-1078 > URL: https://issues.apache.org/jira/browse/DISPATCH-1078 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.2.0 >Reporter: Ernest Allen >Priority: Trivial > Fix For: 1.3.0 > > > The icon displayed next to the topology tab is supposed to be the fontawesome > gears icon. > When the Message traffic page is current, the topology icon changes. > The Topology icon should not change when the message traffic page is > displayed. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 authentication providers per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8219: - Status: Reviewable (was: In Progress) > [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 > authentication providers per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap and OAUTH2 authentication providers were supposed to cache > authentication results per remote host basis. Thus, when connections are made > from the same host using the same credentials, the cached authentication > result should be reused. The current caching approach takes into > consideration an ephemeral port of the connection. As result, a new > connection from the same host with the same credentials cannot reuse previous > authentication result due to a different ephemeral 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] [Assigned] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 authentication providers per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8219: Assignee: Alex Rudyy > [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 > authentication providers per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap and OAUTH2 authentication providers were supposed to cache > authentication results per remote host basis. Thus, when connections are made > from the same host using the same credentials, the cached authentication > result should be reused. The current caching approach takes into > consideration an ephemeral port of the connection. As result, a new > connection from the same host with the same credentials cannot reuse previous > authentication result due to a different ephemeral 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] [Commented] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 authentication providers per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546586#comment-16546586 ] ASF subversion and git services commented on QPID-8219: --- Commit 4e240ba1a9bcdea65002c37101fd1889e16c6955 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=4e240ba ] QPID-8219: [Broker-J] Cache authentication results for the same remote hosts and credentials > [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 > authentication providers per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap and OAUTH2 authentication providers were supposed to cache > authentication results per remote host basis. Thus, when connections are made > from the same host using the same credentials, the cached authentication > result should be reused. The current caching approach takes into > consideration an ephemeral port of the connection. As result, a new > connection from the same host with the same credentials cannot reuse previous > authentication result due to a different ephemeral 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] [Commented] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 authentication providers per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546436#comment-16546436 ] Alex Rudyy commented on QPID-8219: -- Keith, You are right both SimpleLdap and OAUTH2 authentication providers are affected by the defect. I corrected JIRA title and description to reflect that. > [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 > authentication providers per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap and OAUTH2 authentication providers were supposed to cache > authentication results per remote host basis. Thus, when connections are made > from the same host using the same credentials, the cached authentication > result should be reused. The current caching approach takes into > consideration an ephemeral port of the connection. As result, a new > connection from the same host with the same credentials cannot reuse previous > authentication result due to a different ephemeral 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] [Updated] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 authentication providers per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8219: - Description: SimpleLdap and OAUTH2 authentication providers were supposed to cache authentication results per remote host basis. Thus, when connections are made from the same host using the same credentials, the cached authentication result should be reused. The current caching approach takes into consideration an ephemeral port of the connection. As result, a new connection from the same host with the same credentials cannot reuse previous authentication result due to a different ephemeral port. (was: SimpleLdap authentication provider was supposed to cache authentication results per remote host basis. Thus, when connections are made from the same host using the same credentials, the cached authentication results should be reused. The current caching approach takes into consideration an ephemeral port of the connection. As result, a new connection from the same host with the same credentials cannot reuse previous authentication results due to a different ephemeral port.) > [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 > authentication providers per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap and OAUTH2 authentication providers were supposed to cache > authentication results per remote host basis. Thus, when connections are made > from the same host using the same credentials, the cached authentication > result should be reused. The current caching approach takes into > consideration an ephemeral port of the connection. As result, a new > connection from the same host with the same credentials cannot reuse previous > authentication result due to a different ephemeral 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] [Updated] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 authentication providers per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8219: - Summary: [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 authentication providers per connection basis (was: [Broker-J] Authentication results are cached in SimpleLdap Authentication provider per connection basis) > [Broker-J] Authentication results are cached in SimpleLdap and OAUTH2 > authentication providers per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap authentication provider was supposed to cache authentication > results per remote host basis. Thus, when connections are made from the same > host using the same credentials, the cached authentication results should be > reused. The current caching approach takes into consideration an ephemeral > port of the connection. As result, a new connection from the same host with > the same credentials cannot reuse previous authentication results due to a > different ephemeral 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] [Commented] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap Authentication provider per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546328#comment-16546328 ] Keith Wall commented on QPID-8219: -- Wouldn't this problem also affect OAuth2AuthenticationProvider which IIRC uses the same scheme? > [Broker-J] Authentication results are cached in SimpleLdap Authentication > provider per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap authentication provider was supposed to cache authentication > results per remote host basis. Thus, when connections are made from the same > host using the same credentials, the cached authentication results should be > reused. The current caching approach takes into consideration an ephemeral > port of the connection. As result, a new connection from the same host with > the same credentials cannot reuse previous authentication results due to a > different ephemeral 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] [Updated] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap Authentication provider per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8219: - Fix Version/s: qpid-java-broker-7.0.7 qpid-java-broker-7.1.0 qpid-java-6.1.7 > [Broker-J] Authentication results are cached in SimpleLdap Authentication > provider per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap authentication provider was supposed to cache authentication > results per remote host basis. Thus, when connections are made from the same > host using the same credentials, the cached authentication results should be > reused. The current caching approach takes into consideration an ephemeral > port of the connection. As result, a new connection from the same host with > the same credentials cannot reuse previous authentication results due to a > different ephemeral 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] (QPID-8219) [Broker-J] Authentication results are cached in SimpleLdap Authentication provider per connection basis
Alex Rudyy created QPID-8219: Summary: [Broker-J] Authentication results are cached in SimpleLdap Authentication provider per connection basis Key: QPID-8219 URL: https://issues.apache.org/jira/browse/QPID-8219 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.0.6, qpid-java-broker-7.0.5, qpid-java-broker-7.0.4, qpid-java-broker-7.0.1, qpid-java-6.1.5, qpid-java-broker-7.0.0, qpid-java-6.1.4, qpid-java-6.1.3, qpid-java-6.1.2, qpid-java-6.1.1, qpid-java-6.1, qpid-java-broker-7.0.2, qpid-java-broker-7.0.3, qpid-java-6.1.6 Reporter: Alex Rudyy SimpleLdap authentication provider was supposed to cache authentication results per remote host basis. Thus, when connections are made from the same host using the same credentials, the cached authentication results should be reused. The current caching approach takes into consideration an ephemeral port of the connection. As result, a new connection from the same host with the same credentials cannot reuse previous authentication results due to a different ephemeral 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] [Updated] (PROTON-1877) rubygem doc is not multilib-clean for x86_64 vs i686
[
https://issues.apache.org/jira/browse/PROTON-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1877:
---
Fix Version/s: proton-c-0.25.0
Summary: rubygem doc is not multilib-clean for x86_64 vs i686 (was:
[proton 0.23] rubygem doc is not multilib-clean for x86_64 vs i686)
Add missing fix-version.
> rubygem doc is not multilib-clean for x86_64 vs i686
>
>
> Key: PROTON-1877
> URL: https://issues.apache.org/jira/browse/PROTON-1877
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Affects Versions: proton-c-0.23.0, proton-c-0.24.0
>Reporter: Jiri Daněk
>Assignee: Alan Conway
>Priority: Minor
> Fix For: proton-c-0.25.0
>
>
> There is timestamp in headers as well, and there is multiple {{created.rid}}
> files which contain timestamp
> The header:
> {code}
>
> tracker.rb
>
>
> Path:
> lib/core/tracker.rb
>
>
>
> Last Update:
> Wed Jun 06 12:33:53 -0400 2018
>
>
>
>
> {code}
--
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-1679) [c++] local source/target address are not available from sender/receiver objects
[ https://issues.apache.org/jira/browse/PROTON-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1679: --- Fix Version/s: proton-c-0.24.0 Adding missing 0.24.0 fix-version. > [c++] local source/target address are not available from sender/receiver > objects > > > Key: PROTON-1679 > URL: https://issues.apache.org/jira/browse/PROTON-1679 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.24.0 > > > See the two lines marked "// TODO PROTON-1679" in > proton-c/bindings/cpp/src/connection_driver_test.cpp > The assertions should pass, but they don't - the address value from the link > is "" instead of the expected address. -- 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] [Closed] (PROTON-1679) [c++] local source/target address are not available from sender/receiver objects
[ https://issues.apache.org/jira/browse/PROTON-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-1679. -- > [c++] local source/target address are not available from sender/receiver > objects > > > Key: PROTON-1679 > URL: https://issues.apache.org/jira/browse/PROTON-1679 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.1 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.24.0 > > > See the two lines marked "// TODO PROTON-1679" in > proton-c/bindings/cpp/src/connection_driver_test.cpp > The assertions should pass, but they don't - the address value from the link > is "" instead of the expected address. -- 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] [Closed] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-905. - > Long-lived connections leak sessions and links > -- > > Key: PROTON-905 > URL: https://issues.apache.org/jira/browse/PROTON-905 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1, 0.10 >Reporter: Ken Giusti >Assignee: Alan Conway >Priority: Major > Labels: leak > Attachments: link-leak.c, test-send.py > > > I found this issue while debugging a crash dump of qpidd. > Long lived connections do not free its sessions/link. > This only applies when NOT using the event model. The version of qpidd I > tested against (0.30) still uses the iterative model. Point to consider, I > don't know why this is the case. > Details: I have a test script that opens a single connection, then > continually creates sessions/links over that connection, sending one message > before closing and freeing the sessions/links. See attached. > Over time the qpidd run time consumes all memory on the system and is killed > by OOM. To be clear, I'm using drain to remove all sent messages - there is > no message build up. > On debugging this, I'm finding thousands of session objects on the > connections free sessions weakref list. Every one of those sessions has a > refcount of one. > Once the connection is finalized, all session objects are freed. But until > then, freed sessions continue to accumulate indefinitely. -- 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-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-905: -- Alan's comment was made just after the 0.24.0 timeframe. Removing the 0.24.0 fix-version since no change was actually made there for this that we know of. > Long-lived connections leak sessions and links > -- > > Key: PROTON-905 > URL: https://issues.apache.org/jira/browse/PROTON-905 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1, 0.10 >Reporter: Ken Giusti >Assignee: Alan Conway >Priority: Major > Labels: leak > Attachments: link-leak.c, test-send.py > > > I found this issue while debugging a crash dump of qpidd. > Long lived connections do not free its sessions/link. > This only applies when NOT using the event model. The version of qpidd I > tested against (0.30) still uses the iterative model. Point to consider, I > don't know why this is the case. > Details: I have a test script that opens a single connection, then > continually creates sessions/links over that connection, sending one message > before closing and freeing the sessions/links. See attached. > Over time the qpidd run time consumes all memory on the system and is killed > by OOM. To be clear, I'm using drain to remove all sent messages - there is > no message build up. > On debugging this, I'm finding thousands of session objects on the > connections free sessions weakref list. Every one of those sessions has a > refcount of one. > Once the connection is finalized, all session objects are freed. But until > then, freed sessions continue to accumulate indefinitely. -- 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-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-905: -- Fix Version/s: (was: proton-c-0.24.0) > Long-lived connections leak sessions and links > -- > > Key: PROTON-905 > URL: https://issues.apache.org/jira/browse/PROTON-905 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1, 0.10 >Reporter: Ken Giusti >Assignee: Alan Conway >Priority: Major > Labels: leak > Attachments: link-leak.c, test-send.py > > > I found this issue while debugging a crash dump of qpidd. > Long lived connections do not free its sessions/link. > This only applies when NOT using the event model. The version of qpidd I > tested against (0.30) still uses the iterative model. Point to consider, I > don't know why this is the case. > Details: I have a test script that opens a single connection, then > continually creates sessions/links over that connection, sending one message > before closing and freeing the sessions/links. See attached. > Over time the qpidd run time consumes all memory on the system and is killed > by OOM. To be clear, I'm using drain to remove all sent messages - there is > no message build up. > On debugging this, I'm finding thousands of session objects on the > connections free sessions weakref list. Every one of those sessions has a > refcount of one. > Once the connection is finalized, all session objects are freed. But until > then, freed sessions continue to accumulate indefinitely. -- 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
