[jira] [Resolved] (DISPATCH-1012) Release undeliverable deliveries, don't hold them
[ https://issues.apache.org/jira/browse/DISPATCH-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1012. - Resolution: Fixed > Release undeliverable deliveries, don't hold them > - > > Key: DISPATCH-1012 > URL: https://issues.apache.org/jira/browse/DISPATCH-1012 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.1.0 > > > In 1.1.0, deliveries that are produced into the router network that are > undeliverable (i.e. the last consumer for the address has detached) are held > in the ingress link's undelivered list. There is no limit to the amount of > time that a delivery can remain in this list. > Rather than hold undeliverable messages in the undelivered list, the router > should return them to the sender with RELEASED disposition. Furthermore, > once released, credit should not be replenished to the sender until there is > a consumer attached to receive the deliveries. -- 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-1012) Release undeliverable deliveries, don't hold them
[ https://issues.apache.org/jira/browse/DISPATCH-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501121#comment-16501121 ] ASF subversion and git services commented on DISPATCH-1012: --- Commit ee29b2a553579ee2ce32a780740b4e3a8247cfb1 in qpid-dispatch's branch refs/heads/1.1.x from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ee29b2a ] DISPATCH-1012 - For anycast addresses, deliveries to an address that has no attached destinations shall be released by the router network and credit not replenished to the sender. Once a destination becomes reachable, the sender's credit shall be topped back up to the original capacity. (cherry picked from commit ab4421db6b1371e5ba902bc441ccc332352e7516) > Release undeliverable deliveries, don't hold them > - > > Key: DISPATCH-1012 > URL: https://issues.apache.org/jira/browse/DISPATCH-1012 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.1.0 > > > In 1.1.0, deliveries that are produced into the router network that are > undeliverable (i.e. the last consumer for the address has detached) are held > in the ingress link's undelivered list. There is no limit to the amount of > time that a delivery can remain in this list. > Rather than hold undeliverable messages in the undelivered list, the router > should return them to the sender with RELEASED disposition. Furthermore, > once released, credit should not be replenished to the sender until there is > a consumer attached to receive the deliveries. -- 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] (DISPATCH-1012) Release undeliverable deliveries, don't hold them
[ https://issues.apache.org/jira/browse/DISPATCH-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened DISPATCH-1012: -- Reopening as fix-version changed to 1.1.0 but the commit hasnt been merged to 1.1.x as yet. > Release undeliverable deliveries, don't hold them > - > > Key: DISPATCH-1012 > URL: https://issues.apache.org/jira/browse/DISPATCH-1012 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.1.0 > > > In 1.1.0, deliveries that are produced into the router network that are > undeliverable (i.e. the last consumer for the address has detached) are held > in the ingress link's undelivered list. There is no limit to the amount of > time that a delivery can remain in this list. > Rather than hold undeliverable messages in the undelivered list, the router > should return them to the sender with RELEASED disposition. Furthermore, > once released, credit should not be replenished to the sender until there is > a consumer attached to receive the deliveries. -- 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-1017) Use a javascript build system for the console
[ https://issues.apache.org/jira/browse/DISPATCH-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500921#comment-16500921 ] ASF subversion and git services commented on DISPATCH-1017: --- Commit 0310ac224a61e9ee2aca447fe6fdf9d75ec5de11 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0310ac2 ] DISPATCH-1017 Added console build. > Use a javascript build system for the console > - > > Key: DISPATCH-1017 > URL: https://issues.apache.org/jira/browse/DISPATCH-1017 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Attachments: CMakeLists.txt > > > It's time to use a javascript build system such as gulp for the console. > A build system would run during the router's 'make install' and do the > following: > * npm install all 3rd party libraries > * compile any typescript and scss files to .js and .css respectively > * package all .css files (3rd party and homegrown) into a single .css file > * package all .js files (again 3rd party and homegrown) into a single .js > file > * minify the css and js files > * run a javascript linter > After the gulp build, only a few files would need to be copied to the console > install directory. > To ensure the downstream package builds are consistent, the package_lock.json > file should specify which version of the 3rd party libraries to use. -- 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-1017) Use a javascript build system for the console
[ https://issues.apache.org/jira/browse/DISPATCH-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500901#comment-16500901 ] ASF GitHub Bot commented on DISPATCH-1017: -- Github user ErnieAllen closed the pull request at: https://github.com/apache/qpid-dispatch/pull/312 > Use a javascript build system for the console > - > > Key: DISPATCH-1017 > URL: https://issues.apache.org/jira/browse/DISPATCH-1017 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Attachments: CMakeLists.txt > > > It's time to use a javascript build system such as gulp for the console. > A build system would run during the router's 'make install' and do the > following: > * npm install all 3rd party libraries > * compile any typescript and scss files to .js and .css respectively > * package all .css files (3rd party and homegrown) into a single .css file > * package all .js files (again 3rd party and homegrown) into a single .js > file > * minify the css and js files > * run a javascript linter > After the gulp build, only a few files would need to be copied to the console > install directory. > To ensure the downstream package builds are consistent, the package_lock.json > file should specify which version of the 3rd party libraries to use. -- 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 #312: DISPATCH-1017 Add console to build
Github user ErnieAllen closed the pull request at: https://github.com/apache/qpid-dispatch/pull/312 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1012) Release undeliverable deliveries, don't hold them
[ https://issues.apache.org/jira/browse/DISPATCH-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-1012: Fix Version/s: (was: 1.2.0) 1.1.0 > Release undeliverable deliveries, don't hold them > - > > Key: DISPATCH-1012 > URL: https://issues.apache.org/jira/browse/DISPATCH-1012 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Major > Fix For: 1.1.0 > > > In 1.1.0, deliveries that are produced into the router network that are > undeliverable (i.e. the last consumer for the address has detached) are held > in the ingress link's undelivered list. There is no limit to the amount of > time that a delivery can remain in this list. > Rather than hold undeliverable messages in the undelivered list, the router > should return them to the sender with RELEASED disposition. Furthermore, > once released, credit should not be replenished to the sender until there is > a consumer attached to receive the deliveries. -- 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-1023) qdr_deliovery_t objects leak in two router presettled case
[ https://issues.apache.org/jira/browse/DISPATCH-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500785#comment-16500785 ] ASF GitHub Bot commented on DISPATCH-1023: -- GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/314 DISPATCH-1023 - Added a multicast bit on the qdr_delivery_t object to… … use in places where owning_addr is not available You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1023 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/314.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #314 commit 5fe7e53c4e026f4dab662a79fe572e6ad674be9f Author: Ganesh Murthy Date: 2018-06-04T20:02:10Z DISPATCH-1023 - Added a multicast bit on the qdr_delivery_t object to use in places where owning_addr is not available > qdr_deliovery_t objects leak in two router presettled case > -- > > Key: DISPATCH-1023 > URL: https://issues.apache.org/jira/browse/DISPATCH-1023 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: router1-qdrouterd.conf, router2-qdrouterd.conf, > simple_send_large.py > > > Start routers with the attached config files. > Put a receiver on one router and a receiver on the other > Send/receive about 10,000 large presettled messages > Notice that the count of qdr_delivery_t objects in the output of qdstat -m > keeps steadily increasing > -- 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 #314: DISPATCH-1023 - Added a multicast bit on th...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/314 DISPATCH-1023 - Added a multicast bit on the qdr_delivery_t object to⦠⦠use in places where owning_addr is not available You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1023 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/314.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #314 commit 5fe7e53c4e026f4dab662a79fe572e6ad674be9f Author: Ganesh Murthy Date: 2018-06-04T20:02:10Z DISPATCH-1023 - Added a multicast bit on the qdr_delivery_t object to use in places where owning_addr is not available --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1021) Router core dumps when 3 senders and 3 receivers are sending/receiving very large presettled messages to a multicast address
[ https://issues.apache.org/jira/browse/DISPATCH-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500761#comment-16500761 ] ASF GitHub Bot commented on DISPATCH-1021: -- GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/313 DISPATCH-1021 - Introduced a more flag in the action so every action … …can accurately know if there is more data to come in the message You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1021 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/313.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #313 commit 32a0b1e2965b4373306f8557f9afbd295d565f4c Author: Ganesh Murthy Date: 2018-06-04T19:36:56Z DISPATCH-1021 - Introduced a more flag in the action so every action can accurately know if there is more data to come in the message > Router core dumps when 3 senders and 3 receivers are sending/receiving very > large presettled messages to a multicast address > - > > Key: DISPATCH-1021 > URL: https://issues.apache.org/jira/browse/DISPATCH-1021 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Attachments: router1-qdrouterd.conf, router2-qdrouterd.conf, > simple_send_large.py > > > Steps to reproduce > * Modify simple_send.py to send large messages (see attachment) > * Start 2 routers with attached config files > * Attach all senders to one router and all receivers to the other router > * The router will crash on the line - assert(in_dlv->where == > QDR_DELIVERY_IN_SETTLED; -- 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 #313: DISPATCH-1021 - Introduced a more flag in t...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/313 DISPATCH-1021 - Introduced a more flag in the action so every action ⦠â¦can accurately know if there is more data to come in the message You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-1021 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/313.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #313 commit 32a0b1e2965b4373306f8557f9afbd295d565f4c Author: Ganesh Murthy Date: 2018-06-04T19:36:56Z DISPATCH-1021 - Introduced a more flag in the action so every action can accurately know if there is more data to come in the message --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1020) Detach expiring links with closed=true when peer connectivity lost
[
https://issues.apache.org/jira/browse/DISPATCH-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-1020:
Fix Version/s: 1.2.0
> Detach expiring links with closed=true when peer connectivity lost
> --
>
> Key: DISPATCH-1020
> URL: https://issues.apache.org/jira/browse/DISPATCH-1020
> Project: Qpid Dispatch
> Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
>
> Currently, Dispatch responds to the loss of an underlying connection to a
> peer by detaching the links established over that connection in the following
> way.
> {noformat}
> @detach(22) [handle=0, closed=false, error=@error(29)
> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
> container was lost”]]
> {noformat}
> As is makes no sense for link defined to expire to attached again, it would
> be an improvement to the dispatch's behaviour if those links were detached
> with {{closed=true}}. This would aid the timely clean-up of resources
> elsewhere in the AMQP network.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1020) Detach expiring links with closed=true when peer connectivity lost
[
https://issues.apache.org/jira/browse/DISPATCH-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-1020:
---
Assignee: Ganesh Murthy
> Detach expiring links with closed=true when peer connectivity lost
> --
>
> Key: DISPATCH-1020
> URL: https://issues.apache.org/jira/browse/DISPATCH-1020
> Project: Qpid Dispatch
> Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
>
> Currently, Dispatch responds to the loss of an underlying connection to a
> peer by detaching the links established over that connection in the following
> way.
> {noformat}
> @detach(22) [handle=0, closed=false, error=@error(29)
> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
> container was lost”]]
> {noformat}
> As is makes no sense for link defined to expire to attached again, it would
> be an improvement to the dispatch's behaviour if those links were detached
> with {{closed=true}}. This would aid the timely clean-up of resources
> elsewhere in the AMQP network.
--
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-1022) Router crashes when a client sends an end immediately following a detach in a link routed case
[ https://issues.apache.org/jira/browse/DISPATCH-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1022. - Resolution: Fixed > Router crashes when a client sends an end immediately following a detach in a > link routed case > -- > > Key: DISPATCH-1022 > URL: https://issues.apache.org/jira/browse/DISPATCH-1022 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: local.conf > > > Steps to reproduce - > > # Start a router with an attached config file. The config file configures a > link route to the broker > # Create an appropriate queues in the broker > # Create a sender that opens a connection to the router and creates a sender > to a link routed address and close the sender and close the session > associated with the sender. Do this repeatedly. > # The router will crash -- 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-1022) Router crashes when a client sends an end immediately following a detach in a link routed case
[ https://issues.apache.org/jira/browse/DISPATCH-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500735#comment-16500735 ] ASF subversion and git services commented on DISPATCH-1022: --- Commit 43b3b2e03c182e4bffd33a96daa3a911dd4132ea in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=43b3b2e ] DISPATCH-1022 - Zeroed out pn_link references on qd_links before closing session locally so no activities can happen on those links > Router crashes when a client sends an end immediately following a detach in a > link routed case > -- > > Key: DISPATCH-1022 > URL: https://issues.apache.org/jira/browse/DISPATCH-1022 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > Attachments: local.conf > > > Steps to reproduce - > > # Start a router with an attached config file. The config file configures a > link route to the broker > # Create an appropriate queues in the broker > # Create a sender that opens a connection to the router and creates a sender > to a link routed address and close the sender and close the session > associated with the sender. Do this repeatedly. > # The router will crash -- 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] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
[ https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-388: --- Attachment: QpidJms388_RuntimeExectionInOnMessageTest.java > Unhandled RuntimeException in MessageListener#onMessage does not increment > AMQP delivery count in AUTO_ACK > -- > > Key: QPIDJMS-388 > URL: https://issues.apache.org/jira/browse/QPIDJMS-388 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java > > > The JMS spec states: "The result of a listener throwing a RuntimeException > depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or > DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The > 'JMSRedelivered' message header field will be set, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > Currently qpid-jms however is not incrementing the deliveryCount or setting > the redelivered message header to true when a listener throws a > runtimeexception while in AUTO_ACK. > This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and > endless redelivery attempts. -- 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] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
[ https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-388: --- Attachment: (was: QpidJms388_RuntimeExectionInOnMessageTest.java) > Unhandled RuntimeException in MessageListener#onMessage does not increment > AMQP delivery count in AUTO_ACK > -- > > Key: QPIDJMS-388 > URL: https://issues.apache.org/jira/browse/QPIDJMS-388 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java > > > The JMS spec states: "The result of a listener throwing a RuntimeException > depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or > DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The > 'JMSRedelivered' message header field will be set, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > Currently qpid-jms however is not incrementing the deliveryCount or setting > the redelivered message header to true when a listener throws a > runtimeexception while in AUTO_ACK. > This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and > endless redelivery attempts. -- 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] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
[ https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-388: - Priority: Minor (was: Major) > Unhandled RuntimeException in MessageListener#onMessage does not increment > AMQP delivery count in AUTO_ACK > -- > > Key: QPIDJMS-388 > URL: https://issues.apache.org/jira/browse/QPIDJMS-388 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Johan Stenberg >Priority: Minor > Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java > > > The JMS spec states: "The result of a listener throwing a RuntimeException > depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or > DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The > 'JMSRedelivered' message header field will be set, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > Currently qpid-jms however is not incrementing the deliveryCount or setting > the redelivered message header to true when a listener throws a > runtimeexception while in AUTO_ACK. > This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and > endless redelivery attempts. -- 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] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
[ https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-388: --- Attachment: QpidJms388_RuntimeExectionInOnMessageTest.java > Unhandled RuntimeException in MessageListener#onMessage does not increment > AMQP delivery count in AUTO_ACK > -- > > Key: QPIDJMS-388 > URL: https://issues.apache.org/jira/browse/QPIDJMS-388 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java > > > The JMS spec states: "The result of a listener throwing a RuntimeException > depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or > DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The > 'JMSRedelivered' message header field will be set, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > Currently qpid-jms however is not incrementing the deliveryCount or setting > the redelivered message header to true when a listener throws a > runtimeexception while in AUTO_ACK. > This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and > endless redelivery attempts. -- 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-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
Johan Stenberg created QPIDJMS-388: -- Summary: Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK Key: QPIDJMS-388 URL: https://issues.apache.org/jira/browse/QPIDJMS-388 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.32.0 Reporter: Johan Stenberg The JMS spec states: "The result of a listener throwing a RuntimeException depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The 'JMSRedelivered' message header field will be set, and the 'JMSXDeliveryCount' message property incremented, for a message redelivered under these circumstances." Currently qpid-jms however is not incrementing the deliveryCount or setting the redelivered message header to true when a listener throws a runtimeexception while in AUTO_ACK. This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and endless redelivery attempts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1010) Intermittent test failure with system_tests_disallow_link_resumable_link_route
[
https://issues.apache.org/jira/browse/DISPATCH-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500618#comment-16500618
]
Chuck Rolke edited comment on DISPATCH-1010 at 6/4/18 6:08 PM:
---
Even with the removal of sleep(2) and the addition of port waits the test still
fails to attach to the link route.
LinkDetached: sender ac54f518-94ed-4a0e-9797-776bc7f63c86-org.apache to
org.apache closed due to: Condition('qd:no-route-to-dest', 'No route to the
destination node')
This test and any other that wants to test a link route needs to find a way to
wait for the router to create the link route.
was (Author: chug):
Even with the removal of sleep(2) and the addition of port waits the test still
times out.
LinkDetached: sender ac54f518-94ed-4a0e-9797-776bc7f63c86-org.apache to
org.apache closed due to: Condition('qd:no-route-to-dest', 'No route to the
destination node')
This test and any other that wants to test a link route needs to find a way to
wait for the router to create the link route.
> Intermittent test failure with system_tests_disallow_link_resumable_link_route
> --
>
> Key: DISPATCH-1010
> URL: https://issues.apache.org/jira/browse/DISPATCH-1010
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.0.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> The test starts the routers with
> {{wait=False and sleep(2)}}
> Sometimes the sleep is not enough and the tests all fail with connection
> errors because the routers are not up yet.
>
--
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-1010) Intermittent test failure with system_tests_disallow_link_resumable_link_route
[
https://issues.apache.org/jira/browse/DISPATCH-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500618#comment-16500618
]
Chuck Rolke commented on DISPATCH-1010:
---
Even with the removal of sleep(2) and the addition of port waits the test still
times out.
LinkDetached: sender ac54f518-94ed-4a0e-9797-776bc7f63c86-org.apache to
org.apache closed due to: Condition('qd:no-route-to-dest', 'No route to the
destination node')
This test and any other that wants to test a link route needs to find a way to
wait for the router to create the link route.
> Intermittent test failure with system_tests_disallow_link_resumable_link_route
> --
>
> Key: DISPATCH-1010
> URL: https://issues.apache.org/jira/browse/DISPATCH-1010
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.0.0
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
>
> The test starts the routers with
> {{wait=False and sleep(2)}}
> Sometimes the sleep is not enough and the tests all fail with connection
> errors because the routers are not up yet.
>
--
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-proton pull request #147: NO-JIRA: [cpp] add constants for standard AMQ...
Github user alanconway closed the pull request at: https://github.com/apache/qpid-proton/pull/147 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1011) Policy username substitution fails to match certain user names
[
https://issues.apache.org/jira/browse/DISPATCH-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved DISPATCH-1011.
---
Resolution: Fixed
Fix Version/s: 1.2.0
> Policy username substitution fails to match certain user names
> --
>
> Key: DISPATCH-1011
> URL: https://issues.apache.org/jira/browse/DISPATCH-1011
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Affects Versions: 1.0.1
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>Priority: Major
> Fix For: 1.2.0
>
>
> If a username is a substring of a policy rule's static text then the username
> substitution fails. For example:
> {{ if (!_qd_policy_approve_link_name("em", "temp-${user}", "temp-em"))}}
> {{ return "proposed link 'temp-em' should match allowed links with
> ${user} but does not";}}
> Since the username *em* is found in the fixed text of *temp-* then the
> substitution logic goes awry and the match fails. Thanks to aconway for
> making this observation.
--
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-376) notify the ExceptionListener when a consumer with a MessageListener remotely closes
[ https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500448#comment-16500448 ] Robbie Gemmell commented on QPIDJMS-376: I've made a change via https://issues.apache.org/jira/browse/QPIDJMS-386. You can either build from master (e.g https://github.com/apache/qpid-jms) or use a build from the snapshots repo ([https://repository.apache.org/content/repositories/snapshots/)] to give it a test if you'd like. To be clear, the client wont try to re-establish the consumer links outside of a failover attempt. Robbie > notify the ExceptionListener when a consumer with a MessageListener remotely > closes > --- > > Key: QPIDJMS-376 > URL: https://issues.apache.org/jira/browse/QPIDJMS-376 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 > Environment: AMQP Server: Enmasse 0.17.1 > Enmasse Address Type: anycast >Reporter: Daniel Maier >Priority: Major > Fix For: 0.32.0 > > Attachments: clientlogs.txt > > > When I create a consumer to an address that just does not exist, I expected > to get some exception or that the client retries the operation. But there > seems not even to be a log message which indicates a failure. > Is this intended behavior or is this a bug? A more general description is: If > AMQP server closes the receiver link, qpid jms client does not notify the > user anyhow or does not re-establish the link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-386) failover provider prevents handling of remote resource closure from completing correctly
[ https://issues.apache.org/jira/browse/QPIDJMS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-386. Resolution: Fixed > failover provider prevents handling of remote resource closure from > completing correctly > > > Key: QPIDJMS-386 > URL: https://issues.apache.org/jira/browse/QPIDJMS-386 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 > Environment: >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.33.0 > > > QPIDJMS-376 added functionality to fire the connection ExceptionListener if a > MessageConsumer with a MessageListener is remotely closed, since the lack of > future message deliveries would mean the application has no further > interaction with the consumer to observe the issue. It has since been > identified that this doesn't occur when using the built in failover provider, > which is preventing the process of handling the remote consumer resource > closure from completing fully. -- 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] (QPIDJMS-387) Update Netty to 4-1-25-Final and ActiveMQ 5.15.4
[ https://issues.apache.org/jira/browse/QPIDJMS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-387. -- Resolution: Fixed > Update Netty to 4-1-25-Final and ActiveMQ 5.15.4 > - > > Key: QPIDJMS-387 > URL: https://issues.apache.org/jira/browse/QPIDJMS-387 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.33.0 > > > Update Netty to latest release 4.1.25.Final and update ActiveMQ 5.15.4 > release in the test suite. -- 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-387) Update Netty to 4-1-25-Final and ActiveMQ 5.15.4
[ https://issues.apache.org/jira/browse/QPIDJMS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500427#comment-16500427 ] ASF subversion and git services commented on QPIDJMS-387: - Commit b661207980ba33a6469b608ef71d73bd02110edf in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=b661207 ] QPIDJMS-387 Update Netty and ActiveMQ to latest releasses Update to Netty 4.1.25.Final and ActiveMQ 5.15.4 > Update Netty to 4-1-25-Final and ActiveMQ 5.15.4 > - > > Key: QPIDJMS-387 > URL: https://issues.apache.org/jira/browse/QPIDJMS-387 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.33.0 > > > Update Netty to latest release 4.1.25.Final and update ActiveMQ 5.15.4 > release in the test suite. -- 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-387) Update Netty to 4-1-25-Final and ActiveMQ 5.15.4
Timothy Bish created QPIDJMS-387: Summary: Update Netty to 4-1-25-Final and ActiveMQ 5.15.4 Key: QPIDJMS-387 URL: https://issues.apache.org/jira/browse/QPIDJMS-387 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.32.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.33.0 Update Netty to latest release 4.1.25.Final and update ActiveMQ 5.15.4 release in the test suite. -- 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-proton pull request #147: NO-JIRA: [cpp] add constants for standard AMQ...
GitHub user alanconway opened a pull request: https://github.com/apache/qpid-proton/pull/147 NO-JIRA: [cpp] add constants for standard AMQP condition names You can merge this pull request into a Git repository by running: $ git pull https://github.com/alanconway/qpid-proton cpp-error-constants Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/147.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #147 commit 3bd7f7683e3bded074739dce2fd6615743de88ce Author: Alan Conway Date: 2018-06-04T15:18:16Z NO-JIRA: [cpp] add constants for standard AMQP condition names --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-386) failover provider prevents handling of remote resource closure from completing correctly
[ https://issues.apache.org/jira/browse/QPIDJMS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500372#comment-16500372 ] ASF subversion and git services commented on QPIDJMS-386: - Commit 78892af25b2271c5c4d2f2d19019c12d2d1a755a in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=78892af ] QPIDJMS-386: fix failover provider to ensure handling of remote resource closure process can complete > failover provider prevents handling of remote resource closure from > completing correctly > > > Key: QPIDJMS-386 > URL: https://issues.apache.org/jira/browse/QPIDJMS-386 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 > Environment: >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.33.0 > > > QPIDJMS-376 added functionality to fire the connection ExceptionListener if a > MessageConsumer with a MessageListener is remotely closed, since the lack of > future message deliveries would mean the application has no further > interaction with the consumer to observe the issue. It has since been > identified that this doesn't occur when using the built in failover provider, > which is preventing the process of handling the remote consumer resource > closure from completing fully. -- 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-386) failover provider prevents handling of remote resource closure from completing correctly
Robbie Gemmell created QPIDJMS-386: -- Summary: failover provider prevents handling of remote resource closure from completing correctly Key: QPIDJMS-386 URL: https://issues.apache.org/jira/browse/QPIDJMS-386 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.32.0 Environment: Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.33.0 QPIDJMS-376 added functionality to fire the connection ExceptionListener if a MessageConsumer with a MessageListener is remotely closed, since the lack of future message deliveries would mean the application has no further interaction with the consumer to observe the issue. It has since been identified that this doesn't occur when using the built in failover provider, which is preventing the process of handling the remote consumer resource closure from completing fully. -- 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-376) notify the ExceptionListener when a consumer with a MessageListener remotely closes
[ https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500339#comment-16500339 ] Daniel Maier commented on QPIDJMS-376: -- Hi [~gemmellr] no problem you missed my comment. My described behavior was already with fixed DISPATCH-962. Indeed the issue on the mailing list sounds the same as mine, i.e. failover does not retry when link gets closed remotely nor exception listener gets called. Did you already create an issue for this? > notify the ExceptionListener when a consumer with a MessageListener remotely > closes > --- > > Key: QPIDJMS-376 > URL: https://issues.apache.org/jira/browse/QPIDJMS-376 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 > Environment: AMQP Server: Enmasse 0.17.1 > Enmasse Address Type: anycast >Reporter: Daniel Maier >Priority: Major > Fix For: 0.32.0 > > Attachments: clientlogs.txt > > > When I create a consumer to an address that just does not exist, I expected > to get some exception or that the client retries the operation. But there > seems not even to be a log message which indicates a failure. > Is this intended behavior or is this a bug? A more general description is: If > AMQP server closes the receiver link, qpid jms client does not notify the > user anyhow or does not re-establish the link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDJMS-376) notify the ExceptionListener when a consumer with a MessageListener remotely closes
[ https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPIDJMS-376. -- Resolution: Fixed As I assume you are still using a router with the DISPATCH-962 bug in place, I believe you are probably hitting effectively the same issue I've just identified for someone else on the users list about a related-but-different situation, due to an issue in the failover layers handling of it. Its worth noting that I wouldn't expect the clients failover handling to be able to handle the situation you describe very pleasantly. I would typically expect it to class the inability to restore the existing consumer as a failed failover attempt and keep trying, but the DISPATCH-962 router bug making it seem like its succeeded in creating the consumer will likely make it act differently currently. Yes, as this JIRA's changes have been released already, a new JIRA would be needed for further change if made, though commenting on here to establish whats needed first would be fine. Your earlier comment was just missed due to a deluge of updates at the time and being busy with other things. > notify the ExceptionListener when a consumer with a MessageListener remotely > closes > --- > > Key: QPIDJMS-376 > URL: https://issues.apache.org/jira/browse/QPIDJMS-376 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 > Environment: AMQP Server: Enmasse 0.17.1 > Enmasse Address Type: anycast >Reporter: Daniel Maier >Priority: Major > Fix For: 0.32.0 > > Attachments: clientlogs.txt > > > When I create a consumer to an address that just does not exist, I expected > to get some exception or that the client retries the operation. But there > seems not even to be a log message which indicates a failure. > Is this intended behavior or is this a bug? A more general description is: If > AMQP server closes the receiver link, qpid jms client does not notify the > user anyhow or does not re-establish the link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8191) [Broker-J][WMC] Memory logger logs are not displayed in the log viewer UI
[ https://issues.apache.org/jira/browse/QPID-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8191: - Fix Version/s: qpid-java-broker-7.1.0 > [Broker-J][WMC] Memory logger logs are not displayed in the log viewer UI > - > > Key: QPID-8191 > URL: https://issues.apache.org/jira/browse/QPID-8191 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Memory logger logs are not rendered in log viewer table. -- 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-8011) [Broker-J][WMC] Auto-refresh functionality is broken for grids of type EnhancedGrid when pagination plugin and Observable/Memory store are used
[ https://issues.apache.org/jira/browse/QPID-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8011: - Summary: [Broker-J][WMC] Auto-refresh functionality is broken for grids of type EnhancedGrid when pagination plugin and Observable/Memory store are used (was: [Broker-J[WMC] Auto-refresh functionality is broken for grids of type EnhancedGrid when pagination plugin and Observable/Memory store are used) > [Broker-J][WMC] Auto-refresh functionality is broken for grids of type > EnhancedGrid when pagination plugin and Observable/Memory store are used > --- > > Key: QPID-8011 > URL: https://issues.apache.org/jira/browse/QPID-8011 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.4, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Trivial > Fix For: qpid-java-broker-7.1.0 > > > All EnhancedGrid grids with pagination and Observable/Memory store do not > update the rows properly. The following issues are seen: > * pagination is not updated after number of rows reaches page size. Total > number of items is displayed incorrectly (equals to page size) and the links > to next pages are not displayed. The pagination can be updated by > increasing/reducing page number. > * After navigation to next page, on grid update the updated items from the > previous page can be displayed unexpectedly on currently displayed page. The > displayed total number of items is increased by number of updated rows. > Sorting on navigation back and forward can temporary restore the page but > after grid update the updated items from previous pages can reappear again > The following grids are affected: > * Ports grid on Broker tab (Virtual host grids invokes explicitly _refresh() > on update which works around the issues ) > * Log Files grid on FileLogger tab > * Groups grid for group managing group providers (FileGroupProvider, > ManagedGroupProvider) > * Group Memebers grid on Group tab > * Certificates grid on ManagedCertificateStore > * Users grid on user managing auth providers > * -- 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-7170) Make LDAP Authentication Provider populate the AuthenticatedPrincipal's displayable name
[
https://issues.apache.org/jira/browse/QPID-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500060#comment-16500060
]
Alex Rudyy commented on QPID-7170:
--
The work is de-scoped from 7.1.0
> Make LDAP Authentication Provider populate the AuthenticatedPrincipal's
> displayable name
>
>
> Key: QPID-7170
> URL: https://issues.apache.org/jira/browse/QPID-7170
> Project: Qpid
> Issue Type: Sub-task
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> On authentication, the LDAP Authentication Provider needs to be populate the
> displayableName. For this purpose, the provider needs a new optional
> attribute {{displayableNameAttribute}} which specifies which directory
> attribute that contains the displayable name.
> If the displayableNameAttribute is populated, the attribute's value should be
> used as the name when creating the AuthenticatedPrincipal. If the
> {{displayableNameAttribute}} is null, or the attribute has no value in the
> Directory, the name should be null.
--
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-7242) Make existing authentication/group providers produce realm qualified principals
[
https://issues.apache.org/jira/browse/QPID-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500054#comment-16500054
]
Alex Rudyy commented on QPID-7242:
--
The work is de-scoped from 7.1.0
> Make existing authentication/group providers produce realm qualified
> principals
>
>
> Key: QPID-7242
> URL: https://issues.apache.org/jira/browse/QPID-7242
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Change all existing authentication and group providers to produce realm
> qualified principals.
> Each authentication and group provider will have a {{realm}} attribute.
> Validation ({{#onValidate}}) must ensure that the realm name used by each
> provider is unique.
> For some providers, the realm name may be default-able: authentication/group
> backends can default to the domain name (the host portion of a URI) of the
> authentication/group server e.g. directory.example.com in the case of an
> Directory (LDAP). For non-server backed providers, an realm can be
> constructed using the other realm suggested by RFC-4120 (e.g.
> {{qpid:SCRAM-SHA256/myscramprovider}}). For some providers, such as
> Kerberos, the realm must be supplied by the user.
> The Principals produced by the authentication and group providers must carry
> the realm. The serialised form of the Principal will be a string where the
> {{uriEscape(name) + '@' + domain}}. Principal equality must include the
> realm too.
> For this change. ConfiguredObject#createdBy/lastUpdatedBy remain Strings (for
> now).
> Existing ACL rules consider only a principal's name, so existing ACL
> behaviour should be unchanged by this change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7092) User identity must be unique
[ https://issues.apache.org/jira/browse/QPID-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500050#comment-16500050 ] Alex Rudyy commented on QPID-7092: -- The work is de-scoped from 7.1.0 > User identity must be unique > > > Key: QPID-7092 > URL: https://issues.apache.org/jira/browse/QPID-7092 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Labels: Broker-J-Identity > Fix For: Future > > > The Java Broker's model has an authentication provider associated with each > port. This means that a single Broker may be configured to use more than > authentication provider at once. For instance, it would be possible to use > LDAP authentication for messaging connections and use OAUTH2 for management. > Currently a user's identity within the Broker represented by a simple name > (string). This approach gives rise to the possibility of a conflict: a user > 'fred' from an authentication provider A may not be the same person as user > 'fred' from authentication system B. At the moment the group provider > implementations and access control can not distinguish. > Authentication providers need to have the ability to produce a unique stable > identifier for each user.Group providers and access control providers > need a mechanism ability to act for only identities from a particular > authentication provider source(s). -- 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-7244) Expose realm qualified authenticate name to messaging clients
[
https://issues.apache.org/jira/browse/QPID-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500053#comment-16500053
]
Alex Rudyy commented on QPID-7244:
--
The work is de-scoped from 7.1.0
> Expose realm qualified authenticate name to messaging clients
> -
>
> Key: QPID-7244
> URL: https://issues.apache.org/jira/browse/QPID-7244
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> We want messaging clients to be capable of publishing messages with the
> {{JMSXUserId}} populated with a realm qualified authenticated name.
> To enable this for 0-8..0-10 change message source {{$virtualhostproperties}}
> to have an extra header {{authenticatedUser}} which will contain the
> serialised form of the principal. For 1.0, a non-normative (probably qpid
> specific) connection property could be used by the open performative
> (discussion required).
> The Java Broker messageAuthorizationRequired feature must be relaxed to allow
> either the the realm qualified form, or bare form. The latter is required for
> compatibility with clients which don't support the feature.
--
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-7093) Make the display of createdBy/lastUpdatedBy user information human readable
[ https://issues.apache.org/jira/browse/QPID-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500051#comment-16500051 ] Alex Rudyy commented on QPID-7093: -- The work is de-scoped from 7.1.0 > Make the display of createdBy/lastUpdatedBy user information human readable > --- > > Key: QPID-7093 > URL: https://issues.apache.org/jira/browse/QPID-7093 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Labels: Broker-J-Identity > Fix For: Future > > > For some authentication providers, the id that represents a person is not > human readable. For instance, when using the Google OAuth2, the identities > are 16 digit numbers. This present a usability problem in the web management > console when viewing audit trail information createdBy/lastUpdateBy as the > operator will have no reasonable way to find out the name of the user that > created or updated an object. > Authentication Providers will have the ability to resolve a userid into a > displayable name (QPID-7168). -- 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-7245) Configuration upgrader for realm qualified identities
[
https://issues.apache.org/jira/browse/QPID-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500049#comment-16500049
]
Alex Rudyy commented on QPID-7245:
--
The work is de-scoped from 7.1.0
> Configuration upgrader for realm qualified identities
> -
>
> Key: QPID-7245
> URL: https://issues.apache.org/jira/browse/QPID-7245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Produce an automated configuration upgrader that acts on authentication and
> group provider records. The upgrader must populate the realm attribute
> applying the same rules as the defaulting rules used by the providers
> themselves, ensuring a unique name is produced.
> The configuration upgrader must upgrade the {{createdBy}} and
> {{lastUpdatedBy}} attributes to be realm qualified. This can only be done if
> there is exactly one authentication provider.
> Automatic upgrade of the ACL rules and JMSXUserId within sent messages are
> out of scope.
--
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-7166) Make user/group names produced by authentication and group providers realm qualified
[
https://issues.apache.org/jira/browse/QPID-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500042#comment-16500042
]
Alex Rudyy commented on QPID-7166:
--
The work is de-scoped from 7.1.0 for later
> Make user/group names produced by authentication and group providers realm
> qualified
>
>
> Key: QPID-7166
> URL: https://issues.apache.org/jira/browse/QPID-7166
> Project: Qpid
> Issue Type: New Feature
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Change the existing authentication providers/group providers to produce
> principals contain a realm qualified names.
> The realm qualified name will be in the form:
> {noformat}{identity}@{realm}{noformat} The identity and realm will need to
> be encoded (how?).
> The formation of the realm name will follow Section 6 RFC-4120. Ultimately
> all authentication and group providers will have an {{realmName}}. The
> Broker will enforce a business rule that all realm names are unique.
> Some authentication provides will capable of defaulting the realm name. For
> instance, an LDAP authentication provider might default its realm name to be
> the full qualified domain name of the LDAP server itself. If the provider
> has a default, this must be overridable, to allow duplicate realm names to be
> avoided.
> https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker
--
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-7246) Make ACL module realm aware
[
https://issues.apache.org/jira/browse/QPID-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500046#comment-16500046
]
Alex Rudyy commented on QPID-7246:
--
The work is de-scoped from 7.1.0
> Make ACL module realm aware
> ---
>
> Key: QPID-7246
> URL: https://issues.apache.org/jira/browse/QPID-7246
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Make the existing ACL module realm aware.
> The parser will need to be adapted to accept realm qualified user/group
> names. Currently some symbols, such as the {{=}} and {{/}} within X500
> realms will choke the parser. Perhaps insisting that the name is quoted will
> help?
> Change RuleSet#isRelevant() so that applicability of the rule is considers
> realm in addition to the Principal's name.
> In order to ease upgrade, to allow existing ACL rules files to contain to
> work without change, it may be better to allow an instance of AccessControl
> to be associated with a default authentication provider and default group
> provider. If the ACL rule is written in term of of the identity without
> realm, the authorisation engine would fallback to either of the two
> associated providers, thus a rule {{ACL ALLOW 'fred'...}} would be treated
> as if it were {{ACL ALLOW 'f...@ldap.example.com'}}. At configuration
> upgrade time, if there is a singleton authentication provider and singleton
> group provider, these would be associated with the Access Control Provider
> automatically.
--
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-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified
[
https://issues.apache.org/jira/browse/QPID-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500043#comment-16500043
]
Alex Rudyy commented on QPID-7167:
--
The work is de-scoped from 7.1.0 for later
> Make user/group names produced by LDAP authentication and group provider be
> realm qualified
> ---
>
> Key: QPID-7167
> URL: https://issues.apache.org/jira/browse/QPID-7167
> Project: Qpid
> Issue Type: Sub-task
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> For the LDAP provider, identities (users/groups) produced should be in the
> form:
> {noformat}{identity}@{realm}{noformat}
> where identity is the distinguished name of the user which has been encoded
> (how?). The realm should be any valid realm defined by Section 6 RFC-4120.
> For the LDAP Provider, the realm could be defaulted, perhaps to be the full
> qualified host name of the LDAP server itself.
--
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-7169) Make AuthenticatedPrincipal carry displayable (common) name
[
https://issues.apache.org/jira/browse/QPID-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500044#comment-16500044
]
Alex Rudyy commented on QPID-7169:
--
The work is de-scoped from 7.1.0 for later
> Make AuthenticatedPrincipal carry displayable (common) name
> ---
>
> Key: QPID-7169
> URL: https://issues.apache.org/jira/browse/QPID-7169
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Change {{AuthenticatedPrincipal}} to carry a {{displayableName}}. This will
> typically carry the given name of the human user. It will be legal for an
> AuthenticatedPrincipal not to have a such a name, so this field may be null.
> AuthenticationProviders will be responsible for populating the name from the
> authentication backend as the user authenticates. The precise details of
> this step will vary from provider to provider.
> The Web Management Console needs the givenName for presentation purposes (so
> the Console can display who is logged in in a friendly manner). Change the
> {{SaslServlet}} to pass the displayable name from the Authenticated
> Principal. Change the menu bar of the Web Management Console to include the
> name if it is available.
--
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-8026) [Java Broker] [AMQP 1.0] Add support for max-message-size on consumer attach
[ https://issues.apache.org/jira/browse/QPID-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500036#comment-16500036 ] Alex Rudyy commented on QPID-8026: -- The work is de-scoped from 7.1.0 for later > [Java Broker] [AMQP 1.0] Add support for max-message-size on consumer attach > > > Key: QPID-8026 > URL: https://issues.apache.org/jira/browse/QPID-8026 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Rob Godfrey >Priority: Major > Fix For: Future > > > QPID-7957 added support for sending the max-message-size on producer attaches > *sent* to the broker, but there is currently no support in the broker for the > case where a consumer attaches a link which asserts that the consumer is > unable to receive messages above a certain size on that link. > In this case the consumer should, I think, behave as if a filter had been > applied which simply excludes from the possibility of delivery any message > which (when converted into an AMQP 1.0 payload) would be above the given size. -- 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-6907) Add ability to restrict read in ACLs
[ https://issues.apache.org/jira/browse/QPID-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500035#comment-16500035 ] Alex Rudyy commented on QPID-6907: -- The work is descoped from 7.1.0 for later > Add ability to restrict read in ACLs > > > Key: QPID-6907 > URL: https://issues.apache.org/jira/browse/QPID-6907 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: Future > > > Currently the ACL mechanism has no way to restrict what a management user can > see. If the user can authenticate, then they are entitled to see all the > objects beneath Broker. There is no way to express user A should have > management permission to read below virtual host X. > ACLs do have an ACCESS permission, be this is used to govern connections to > virtual hosts for messaging. -- 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-7168) Allow authentication providers to resolve a realm qualified user identity into a displayable name
[ https://issues.apache.org/jira/browse/QPID-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500034#comment-16500034 ] Alex Rudyy commented on QPID-7168: -- The work is de-scoped from 7.1.0 for later > Allow authentication providers to resolve a realm qualified user identity > into a displayable name > - > > Key: QPID-7168 > URL: https://issues.apache.org/jira/browse/QPID-7168 > Project: Qpid > Issue Type: New Feature > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Labels: Broker-J-Identity > Fix For: Future > > > Extend the Authentication Provider interface to allow implementations to > resolve a realm qualified user identity into a human readable name. If the > authentication provider does not recognise the realm, it is not capable of > resolving names or the name is not known, the provider must return null. > Callers must be prepared to handle null. > Internally, providers may implement this method by calling out to the > authentication backend. Alternatively, the provider may maintain a cache of > names, populated as users authenticate. The provider should be prepared to > be queried many times for a user's name during the lifetime of Broker's > execution, so should take steps to avoid expensive processing, if necessary. -- 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-7885) [Java Broker] Support Java 9
[ https://issues.apache.org/jira/browse/QPID-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7885: - Fix Version/s: qpid-java-broker-7.1.0 > [Java Broker] Support Java 9 > > > Key: QPID-7885 > URL: https://issues.apache.org/jira/browse/QPID-7885 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Lorenz Quack >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > With the Java 9 on the horizon it is time to get Qpid's Java components ready. > * make sure component compile with JDK9 > * make sure components run with JRE9 > * take advantage of the new Java Module System -- 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-7242) Make existing authentication/group providers produce realm qualified principals
[
https://issues.apache.org/jira/browse/QPID-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7242:
-
Labels: Broker-J-Identity (was: )
> Make existing authentication/group providers produce realm qualified
> principals
>
>
> Key: QPID-7242
> URL: https://issues.apache.org/jira/browse/QPID-7242
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Change all existing authentication and group providers to produce realm
> qualified principals.
> Each authentication and group provider will have a {{realm}} attribute.
> Validation ({{#onValidate}}) must ensure that the realm name used by each
> provider is unique.
> For some providers, the realm name may be default-able: authentication/group
> backends can default to the domain name (the host portion of a URI) of the
> authentication/group server e.g. directory.example.com in the case of an
> Directory (LDAP). For non-server backed providers, an realm can be
> constructed using the other realm suggested by RFC-4120 (e.g.
> {{qpid:SCRAM-SHA256/myscramprovider}}). For some providers, such as
> Kerberos, the realm must be supplied by the user.
> The Principals produced by the authentication and group providers must carry
> the realm. The serialised form of the Principal will be a string where the
> {{uriEscape(name) + '@' + domain}}. Principal equality must include the
> realm too.
> For this change. ConfiguredObject#createdBy/lastUpdatedBy remain Strings (for
> now).
> Existing ACL rules consider only a principal's name, so existing ACL
> behaviour should be unchanged by this change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7170) Make LDAP Authentication Provider populate the AuthenticatedPrincipal's displayable name
[
https://issues.apache.org/jira/browse/QPID-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7170:
-
Labels: Broker-J-Identity (was: )
> Make LDAP Authentication Provider populate the AuthenticatedPrincipal's
> displayable name
>
>
> Key: QPID-7170
> URL: https://issues.apache.org/jira/browse/QPID-7170
> Project: Qpid
> Issue Type: Sub-task
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> On authentication, the LDAP Authentication Provider needs to be populate the
> displayableName. For this purpose, the provider needs a new optional
> attribute {{displayableNameAttribute}} which specifies which directory
> attribute that contains the displayable name.
> If the displayableNameAttribute is populated, the attribute's value should be
> used as the name when creating the AuthenticatedPrincipal. If the
> {{displayableNameAttribute}} is null, or the attribute has no value in the
> Directory, the name should be null.
--
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-7244) Expose realm qualified authenticate name to messaging clients
[
https://issues.apache.org/jira/browse/QPID-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7244:
-
Labels: Broker-J-Identity (was: )
> Expose realm qualified authenticate name to messaging clients
> -
>
> Key: QPID-7244
> URL: https://issues.apache.org/jira/browse/QPID-7244
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> We want messaging clients to be capable of publishing messages with the
> {{JMSXUserId}} populated with a realm qualified authenticated name.
> To enable this for 0-8..0-10 change message source {{$virtualhostproperties}}
> to have an extra header {{authenticatedUser}} which will contain the
> serialised form of the principal. For 1.0, a non-normative (probably qpid
> specific) connection property could be used by the open performative
> (discussion required).
> The Java Broker messageAuthorizationRequired feature must be relaxed to allow
> either the the realm qualified form, or bare form. The latter is required for
> compatibility with clients which don't support the feature.
--
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-7245) Configuration upgrader for realm qualified identities
[
https://issues.apache.org/jira/browse/QPID-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7245:
-
Labels: Broker-J-Identity (was: )
> Configuration upgrader for realm qualified identities
> -
>
> Key: QPID-7245
> URL: https://issues.apache.org/jira/browse/QPID-7245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Produce an automated configuration upgrader that acts on authentication and
> group provider records. The upgrader must populate the realm attribute
> applying the same rules as the defaulting rules used by the providers
> themselves, ensuring a unique name is produced.
> The configuration upgrader must upgrade the {{createdBy}} and
> {{lastUpdatedBy}} attributes to be realm qualified. This can only be done if
> there is exactly one authentication provider.
> Automatic upgrade of the ACL rules and JMSXUserId within sent messages are
> out of scope.
--
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-7092) User identity must be unique
[ https://issues.apache.org/jira/browse/QPID-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7092: - Labels: Broker-J-Identity (was: ) > User identity must be unique > > > Key: QPID-7092 > URL: https://issues.apache.org/jira/browse/QPID-7092 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Labels: Broker-J-Identity > Fix For: Future > > > The Java Broker's model has an authentication provider associated with each > port. This means that a single Broker may be configured to use more than > authentication provider at once. For instance, it would be possible to use > LDAP authentication for messaging connections and use OAUTH2 for management. > Currently a user's identity within the Broker represented by a simple name > (string). This approach gives rise to the possibility of a conflict: a user > 'fred' from an authentication provider A may not be the same person as user > 'fred' from authentication system B. At the moment the group provider > implementations and access control can not distinguish. > Authentication providers need to have the ability to produce a unique stable > identifier for each user.Group providers and access control providers > need a mechanism ability to act for only identities from a particular > authentication provider source(s). -- 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-7246) Make ACL module realm aware
[
https://issues.apache.org/jira/browse/QPID-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7246:
-
Labels: Broker-J-Identity (was: )
> Make ACL module realm aware
> ---
>
> Key: QPID-7246
> URL: https://issues.apache.org/jira/browse/QPID-7246
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Make the existing ACL module realm aware.
> The parser will need to be adapted to accept realm qualified user/group
> names. Currently some symbols, such as the {{=}} and {{/}} within X500
> realms will choke the parser. Perhaps insisting that the name is quoted will
> help?
> Change RuleSet#isRelevant() so that applicability of the rule is considers
> realm in addition to the Principal's name.
> In order to ease upgrade, to allow existing ACL rules files to contain to
> work without change, it may be better to allow an instance of AccessControl
> to be associated with a default authentication provider and default group
> provider. If the ACL rule is written in term of of the identity without
> realm, the authorisation engine would fallback to either of the two
> associated providers, thus a rule {{ACL ALLOW 'fred'...}} would be treated
> as if it were {{ACL ALLOW 'f...@ldap.example.com'}}. At configuration
> upgrade time, if there is a singleton authentication provider and singleton
> group provider, these would be associated with the Access Control Provider
> automatically.
--
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-7093) Make the display of createdBy/lastUpdatedBy user information human readable
[ https://issues.apache.org/jira/browse/QPID-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7093: - Labels: Broker-J-Identity (was: ) > Make the display of createdBy/lastUpdatedBy user information human readable > --- > > Key: QPID-7093 > URL: https://issues.apache.org/jira/browse/QPID-7093 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Labels: Broker-J-Identity > Fix For: Future > > > For some authentication providers, the id that represents a person is not > human readable. For instance, when using the Google OAuth2, the identities > are 16 digit numbers. This present a usability problem in the web management > console when viewing audit trail information createdBy/lastUpdateBy as the > operator will have no reasonable way to find out the name of the user that > created or updated an object. > Authentication Providers will have the ability to resolve a userid into a > displayable name (QPID-7168). -- 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-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified
[
https://issues.apache.org/jira/browse/QPID-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7167:
-
Labels: Broker-J-Identity (was: )
> Make user/group names produced by LDAP authentication and group provider be
> realm qualified
> ---
>
> Key: QPID-7167
> URL: https://issues.apache.org/jira/browse/QPID-7167
> Project: Qpid
> Issue Type: Sub-task
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> For the LDAP provider, identities (users/groups) produced should be in the
> form:
> {noformat}{identity}@{realm}{noformat}
> where identity is the distinguished name of the user which has been encoded
> (how?). The realm should be any valid realm defined by Section 6 RFC-4120.
> For the LDAP Provider, the realm could be defaulted, perhaps to be the full
> qualified host name of the LDAP server itself.
--
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-7169) Make AuthenticatedPrincipal carry displayable (common) name
[
https://issues.apache.org/jira/browse/QPID-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7169:
-
Labels: Broker-J-Identity (was: )
> Make AuthenticatedPrincipal carry displayable (common) name
> ---
>
> Key: QPID-7169
> URL: https://issues.apache.org/jira/browse/QPID-7169
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Change {{AuthenticatedPrincipal}} to carry a {{displayableName}}. This will
> typically carry the given name of the human user. It will be legal for an
> AuthenticatedPrincipal not to have a such a name, so this field may be null.
> AuthenticationProviders will be responsible for populating the name from the
> authentication backend as the user authenticates. The precise details of
> this step will vary from provider to provider.
> The Web Management Console needs the givenName for presentation purposes (so
> the Console can display who is logged in in a friendly manner). Change the
> {{SaslServlet}} to pass the displayable name from the Authenticated
> Principal. Change the menu bar of the Web Management Console to include the
> name if it is available.
--
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-7168) Allow authentication providers to resolve a realm qualified user identity into a displayable name
[ https://issues.apache.org/jira/browse/QPID-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7168: - Labels: Broker-J-Identity (was: ) > Allow authentication providers to resolve a realm qualified user identity > into a displayable name > - > > Key: QPID-7168 > URL: https://issues.apache.org/jira/browse/QPID-7168 > Project: Qpid > Issue Type: New Feature > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Labels: Broker-J-Identity > Fix For: Future > > > Extend the Authentication Provider interface to allow implementations to > resolve a realm qualified user identity into a human readable name. If the > authentication provider does not recognise the realm, it is not capable of > resolving names or the name is not known, the provider must return null. > Callers must be prepared to handle null. > Internally, providers may implement this method by calling out to the > authentication backend. Alternatively, the provider may maintain a cache of > names, populated as users authenticate. The provider should be prepared to > be queried many times for a user's name during the lifetime of Broker's > execution, so should take steps to avoid expensive processing, if necessary. -- 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-7166) Make user/group names produced by authentication and group providers realm qualified
[
https://issues.apache.org/jira/browse/QPID-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7166:
-
Labels: Broker-J-Identity (was: )
> Make user/group names produced by authentication and group providers realm
> qualified
>
>
> Key: QPID-7166
> URL: https://issues.apache.org/jira/browse/QPID-7166
> Project: Qpid
> Issue Type: New Feature
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Labels: Broker-J-Identity
> Fix For: Future
>
>
> Change the existing authentication providers/group providers to produce
> principals contain a realm qualified names.
> The realm qualified name will be in the form:
> {noformat}{identity}@{realm}{noformat} The identity and realm will need to
> be encoded (how?).
> The formation of the realm name will follow Section 6 RFC-4120. Ultimately
> all authentication and group providers will have an {{realmName}}. The
> Broker will enforce a business rule that all realm names are unique.
> Some authentication provides will capable of defaulting the realm name. For
> instance, an LDAP authentication provider might default its realm name to be
> the full qualified domain name of the LDAP server itself. If the provider
> has a default, this must be overridable, to allow duplicate realm names to be
> avoided.
> https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker
--
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-6948) Introduce REST API compatibility layer
[ https://issues.apache.org/jira/browse/QPID-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-6948: - Fix Version/s: qpid-java-broker-7.1.0 > Introduce REST API compatibility layer > -- > > Key: QPID-6948 > URL: https://issues.apache.org/jira/browse/QPID-6948 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Make the REST API backwardly compatibility with model as used by 0.32. > In general the compatibility layer should: > For GET: > * attributes that are removed should be simulated (e.g. defaultVirtualHost) > * new attributes/new types don't need to be hidden > For POST/PUT: > * on creation, new mandatory attributes should be given sensible defaults > * removed operations should be supported perhaps by rewriting the request in > terms of new operations. > When the model changes structurally, the compatibility layer should present > the old model. -- 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-7662) [Java Broker] Broker should mark system queues (like durable subscription queues) in special way in order to allow operators to distnguish those queues from normal queues
[ https://issues.apache.org/jira/browse/QPID-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7662: - Fix Version/s: (was: qpid-java-broker-7.1.0) Future > [Java Broker] Broker should mark system queues (like durable subscription > queues) in special way in order to allow operators to distnguish those > queues from normal queues created by the users > > > Key: QPID-7662 > URL: https://issues.apache.org/jira/browse/QPID-7662 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: Future > > > Currently special system queues (like queues created for the durable > subscriptions) are accessible via management interfaces and can be modified > by the operators like normal queues without any restriction. Broker should > have an ability to mark those queues as special system queues in order to > allow operators to distinguish them from normal queues created by the users. > Potentially, an operator access can be restricted to those queues to allow > only limited set of operations like deletion, configuring alternate, max > delivery count, etc. -- 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-7092) User identity must be unique
[ https://issues.apache.org/jira/browse/QPID-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7092: - Fix Version/s: (was: qpid-java-broker-7.1.0) Future > User identity must be unique > > > Key: QPID-7092 > URL: https://issues.apache.org/jira/browse/QPID-7092 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: Future > > > The Java Broker's model has an authentication provider associated with each > port. This means that a single Broker may be configured to use more than > authentication provider at once. For instance, it would be possible to use > LDAP authentication for messaging connections and use OAUTH2 for management. > Currently a user's identity within the Broker represented by a simple name > (string). This approach gives rise to the possibility of a conflict: a user > 'fred' from an authentication provider A may not be the same person as user > 'fred' from authentication system B. At the moment the group provider > implementations and access control can not distinguish. > Authentication providers need to have the ability to produce a unique stable > identifier for each user.Group providers and access control providers > need a mechanism ability to act for only identities from a particular > authentication provider source(s). -- 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-7170) Make LDAP Authentication Provider populate the AuthenticatedPrincipal's displayable name
[
https://issues.apache.org/jira/browse/QPID-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7170:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Make LDAP Authentication Provider populate the AuthenticatedPrincipal's
> displayable name
>
>
> Key: QPID-7170
> URL: https://issues.apache.org/jira/browse/QPID-7170
> Project: Qpid
> Issue Type: Sub-task
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> On authentication, the LDAP Authentication Provider needs to be populate the
> displayableName. For this purpose, the provider needs a new optional
> attribute {{displayableNameAttribute}} which specifies which directory
> attribute that contains the displayable name.
> If the displayableNameAttribute is populated, the attribute's value should be
> used as the name when creating the AuthenticatedPrincipal. If the
> {{displayableNameAttribute}} is null, or the attribute has no value in the
> Directory, the name should be null.
--
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-7242) Make existing authentication/group providers produce realm qualified principals
[
https://issues.apache.org/jira/browse/QPID-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7242:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Make existing authentication/group providers produce realm qualified
> principals
>
>
> Key: QPID-7242
> URL: https://issues.apache.org/jira/browse/QPID-7242
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> Change all existing authentication and group providers to produce realm
> qualified principals.
> Each authentication and group provider will have a {{realm}} attribute.
> Validation ({{#onValidate}}) must ensure that the realm name used by each
> provider is unique.
> For some providers, the realm name may be default-able: authentication/group
> backends can default to the domain name (the host portion of a URI) of the
> authentication/group server e.g. directory.example.com in the case of an
> Directory (LDAP). For non-server backed providers, an realm can be
> constructed using the other realm suggested by RFC-4120 (e.g.
> {{qpid:SCRAM-SHA256/myscramprovider}}). For some providers, such as
> Kerberos, the realm must be supplied by the user.
> The Principals produced by the authentication and group providers must carry
> the realm. The serialised form of the Principal will be a string where the
> {{uriEscape(name) + '@' + domain}}. Principal equality must include the
> realm too.
> For this change. ConfiguredObject#createdBy/lastUpdatedBy remain Strings (for
> now).
> Existing ACL rules consider only a principal's name, so existing ACL
> behaviour should be unchanged by this change.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7244) Expose realm qualified authenticate name to messaging clients
[
https://issues.apache.org/jira/browse/QPID-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7244:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Expose realm qualified authenticate name to messaging clients
> -
>
> Key: QPID-7244
> URL: https://issues.apache.org/jira/browse/QPID-7244
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> We want messaging clients to be capable of publishing messages with the
> {{JMSXUserId}} populated with a realm qualified authenticated name.
> To enable this for 0-8..0-10 change message source {{$virtualhostproperties}}
> to have an extra header {{authenticatedUser}} which will contain the
> serialised form of the principal. For 1.0, a non-normative (probably qpid
> specific) connection property could be used by the open performative
> (discussion required).
> The Java Broker messageAuthorizationRequired feature must be relaxed to allow
> either the the realm qualified form, or bare form. The latter is required for
> compatibility with clients which don't support the feature.
--
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-7093) Make the display of createdBy/lastUpdatedBy user information human readable
[ https://issues.apache.org/jira/browse/QPID-7093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7093: - Fix Version/s: (was: qpid-java-broker-7.1.0) Future > Make the display of createdBy/lastUpdatedBy user information human readable > --- > > Key: QPID-7093 > URL: https://issues.apache.org/jira/browse/QPID-7093 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: Future > > > For some authentication providers, the id that represents a person is not > human readable. For instance, when using the Google OAuth2, the identities > are 16 digit numbers. This present a usability problem in the web management > console when viewing audit trail information createdBy/lastUpdateBy as the > operator will have no reasonable way to find out the name of the user that > created or updated an object. > Authentication Providers will have the ability to resolve a userid into a > displayable name (QPID-7168). -- 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-7245) Configuration upgrader for realm qualified identities
[
https://issues.apache.org/jira/browse/QPID-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7245:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Configuration upgrader for realm qualified identities
> -
>
> Key: QPID-7245
> URL: https://issues.apache.org/jira/browse/QPID-7245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> Produce an automated configuration upgrader that acts on authentication and
> group provider records. The upgrader must populate the realm attribute
> applying the same rules as the defaulting rules used by the providers
> themselves, ensuring a unique name is produced.
> The configuration upgrader must upgrade the {{createdBy}} and
> {{lastUpdatedBy}} attributes to be realm qualified. This can only be done if
> there is exactly one authentication provider.
> Automatic upgrade of the ACL rules and JMSXUserId within sent messages are
> out of scope.
--
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-7246) Make ACL module realm aware
[
https://issues.apache.org/jira/browse/QPID-7246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7246:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Make ACL module realm aware
> ---
>
> Key: QPID-7246
> URL: https://issues.apache.org/jira/browse/QPID-7246
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> Make the existing ACL module realm aware.
> The parser will need to be adapted to accept realm qualified user/group
> names. Currently some symbols, such as the {{=}} and {{/}} within X500
> realms will choke the parser. Perhaps insisting that the name is quoted will
> help?
> Change RuleSet#isRelevant() so that applicability of the rule is considers
> realm in addition to the Principal's name.
> In order to ease upgrade, to allow existing ACL rules files to contain to
> work without change, it may be better to allow an instance of AccessControl
> to be associated with a default authentication provider and default group
> provider. If the ACL rule is written in term of of the identity without
> realm, the authorisation engine would fallback to either of the two
> associated providers, thus a rule {{ACL ALLOW 'fred'...}} would be treated
> as if it were {{ACL ALLOW 'f...@ldap.example.com'}}. At configuration
> upgrade time, if there is a singleton authentication provider and singleton
> group provider, these would be associated with the Access Control Provider
> automatically.
--
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-7169) Make AuthenticatedPrincipal carry displayable (common) name
[
https://issues.apache.org/jira/browse/QPID-7169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7169:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Make AuthenticatedPrincipal carry displayable (common) name
> ---
>
> Key: QPID-7169
> URL: https://issues.apache.org/jira/browse/QPID-7169
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> Change {{AuthenticatedPrincipal}} to carry a {{displayableName}}. This will
> typically carry the given name of the human user. It will be legal for an
> AuthenticatedPrincipal not to have a such a name, so this field may be null.
> AuthenticationProviders will be responsible for populating the name from the
> authentication backend as the user authenticates. The precise details of
> this step will vary from provider to provider.
> The Web Management Console needs the givenName for presentation purposes (so
> the Console can display who is logged in in a friendly manner). Change the
> {{SaslServlet}} to pass the displayable name from the Authenticated
> Principal. Change the menu bar of the Web Management Console to include the
> name if it is available.
--
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-7166) Make user/group names produced by authentication and group providers realm qualified
[
https://issues.apache.org/jira/browse/QPID-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7166:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Make user/group names produced by authentication and group providers realm
> qualified
>
>
> Key: QPID-7166
> URL: https://issues.apache.org/jira/browse/QPID-7166
> Project: Qpid
> Issue Type: New Feature
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> Change the existing authentication providers/group providers to produce
> principals contain a realm qualified names.
> The realm qualified name will be in the form:
> {noformat}{identity}@{realm}{noformat} The identity and realm will need to
> be encoded (how?).
> The formation of the realm name will follow Section 6 RFC-4120. Ultimately
> all authentication and group providers will have an {{realmName}}. The
> Broker will enforce a business rule that all realm names are unique.
> Some authentication provides will capable of defaulting the realm name. For
> instance, an LDAP authentication provider might default its realm name to be
> the full qualified domain name of the LDAP server itself. If the provider
> has a default, this must be overridable, to allow duplicate realm names to be
> avoided.
> https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker
--
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-7167) Make user/group names produced by LDAP authentication and group provider be realm qualified
[
https://issues.apache.org/jira/browse/QPID-7167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7167:
-
Fix Version/s: (was: qpid-java-broker-7.1.0)
Future
> Make user/group names produced by LDAP authentication and group provider be
> realm qualified
> ---
>
> Key: QPID-7167
> URL: https://issues.apache.org/jira/browse/QPID-7167
> Project: Qpid
> Issue Type: Sub-task
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> For the LDAP provider, identities (users/groups) produced should be in the
> form:
> {noformat}{identity}@{realm}{noformat}
> where identity is the distinguished name of the user which has been encoded
> (how?). The realm should be any valid realm defined by Section 6 RFC-4120.
> For the LDAP Provider, the realm could be defaulted, perhaps to be the full
> qualified host name of the LDAP server itself.
--
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-7168) Allow authentication providers to resolve a realm qualified user identity into a displayable name
[ https://issues.apache.org/jira/browse/QPID-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7168: - Fix Version/s: (was: qpid-java-broker-7.1.0) Future > Allow authentication providers to resolve a realm qualified user identity > into a displayable name > - > > Key: QPID-7168 > URL: https://issues.apache.org/jira/browse/QPID-7168 > Project: Qpid > Issue Type: New Feature > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: Future > > > Extend the Authentication Provider interface to allow implementations to > resolve a realm qualified user identity into a human readable name. If the > authentication provider does not recognise the realm, it is not capable of > resolving names or the name is not known, the provider must return null. > Callers must be prepared to handle null. > Internally, providers may implement this method by calling out to the > authentication backend. Alternatively, the provider may maintain a cache of > names, populated as users authenticate. The provider should be prepared to > be queried many times for a user's name during the lifetime of Broker's > execution, so should take steps to avoid expensive processing, if necessary. -- 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-6907) Add ability to restrict read in ACLs
[ https://issues.apache.org/jira/browse/QPID-6907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-6907: - Fix Version/s: (was: qpid-java-broker-7.1.0) Future > Add ability to restrict read in ACLs > > > Key: QPID-6907 > URL: https://issues.apache.org/jira/browse/QPID-6907 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: Future > > > Currently the ACL mechanism has no way to restrict what a management user can > see. If the user can authenticate, then they are entitled to see all the > objects beneath Broker. There is no way to express user A should have > management permission to read below virtual host X. > ACLs do have an ACCESS permission, be this is used to govern connections to > virtual hosts for messaging. -- 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-8026) [Java Broker] [AMQP 1.0] Add support for max-message-size on consumer attach
[ https://issues.apache.org/jira/browse/QPID-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8026: - Fix Version/s: (was: qpid-java-broker-7.1.0) Future > [Java Broker] [AMQP 1.0] Add support for max-message-size on consumer attach > > > Key: QPID-8026 > URL: https://issues.apache.org/jira/browse/QPID-8026 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Rob Godfrey >Priority: Major > Fix For: Future > > > QPID-7957 added support for sending the max-message-size on producer attaches > *sent* to the broker, but there is currently no support in the broker for the > case where a consumer attaches a link which asserts that the consumer is > unable to receive messages above a certain size on that link. > In this case the consumer should, I think, behave as if a filter had been > applied which simply excludes from the possibility of delivery any message > which (when converted into an AMQP 1.0 payload) would be above the given size. -- 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-8132) Refresh Apache BCEL dependency to 6.2
[ https://issues.apache.org/jira/browse/QPID-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8132: - Fix Version/s: qpid-java-broker-7.1.0 > Refresh Apache BCEL dependency to 6.2 > - > > Key: QPID-8132 > URL: https://issues.apache.org/jira/browse/QPID-8132 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.1.0 > > > The Apache BCEL dependency used by Broker-J is getting stale (5.2). 6.2 is > the latest release. -- 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-7918) [Java Broker] Respond to low heap memory condition by throttling producers.
[ https://issues.apache.org/jira/browse/QPID-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7918: - Fix Version/s: qpid-java-broker-7.1.0 > [Java Broker] Respond to low heap memory condition by throttling producers. > --- > > Key: QPID-7918 > URL: https://issues.apache.org/jira/browse/QPID-7918 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Currently, if the cumulative size of messages headers/contents cached in > direct memory exceeds a threshold, the Java Broker responds by flowing the > messages to disk and evicting them from memory. This guards the condition of > excessive *message payload* causing an out-of-memory situation. > However the Broker also maintains a linked list representing every queues in > the JVMs heap memory. Each message is represented by a small node in the > linked list. The Broker's design currently means that the entire linked list > must reside in (heap) memory (even if the message's content has been paged > out by the flow to disk mechanism). This gives rise to the the possibility > that the linked lists backing the queue could exhaust all heap and the Broker > could fail with an OOM (heap) condition. > The long term aim is to allow sections linked list to be paged out to > eliminate this problem, but this would necessitate a deep redesign. > As a interim measure, it appears that the the JVM's Memory bean > (MemoryPoolMXBean) could be used to notify the Broker when after a garbage > collection cycle heap memory usage is above a threshold. The Broker could > respond to this event by throttling producer, thus allow consumes to catch up > and hopefully avoiding the failure. The Broker would need to relinquish flow > control once memory usage had fallen again. > Consideration would need to be given for different JVMs and different GC > implementations. Consideration must also be given for use cases where the > Broker is embedded. > -- 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-8011) [Broker-J[WMC] Auto-refresh functionality is broken for grids of type EnhancedGrid when pagination plugin and Observable/Memory store are used
[ https://issues.apache.org/jira/browse/QPID-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8011: - Fix Version/s: qpid-java-broker-7.1.0 > [Broker-J[WMC] Auto-refresh functionality is broken for grids of type > EnhancedGrid when pagination plugin and Observable/Memory store are used > -- > > Key: QPID-8011 > URL: https://issues.apache.org/jira/browse/QPID-8011 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.4, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Trivial > Fix For: qpid-java-broker-7.1.0 > > > All EnhancedGrid grids with pagination and Observable/Memory store do not > update the rows properly. The following issues are seen: > * pagination is not updated after number of rows reaches page size. Total > number of items is displayed incorrectly (equals to page size) and the links > to next pages are not displayed. The pagination can be updated by > increasing/reducing page number. > * After navigation to next page, on grid update the updated items from the > previous page can be displayed unexpectedly on currently displayed page. The > displayed total number of items is increased by number of updated rows. > Sorting on navigation back and forward can temporary restore the page but > after grid update the updated items from previous pages can reappear again > The following grids are affected: > * Ports grid on Broker tab (Virtual host grids invokes explicitly _refresh() > on update which works around the issues ) > * Log Files grid on FileLogger tab > * Groups grid for group managing group providers (FileGroupProvider, > ManagedGroupProvider) > * Group Memebers grid on Group tab > * Certificates grid on ManagedCertificateStore > * Users grid on user managing auth providers > * -- 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-8157) [Broker-J] Deletion of Virtual Host Node fails to clean-up properly all Virtual Host/Virtual Host Node resources
[
https://issues.apache.org/jira/browse/QPID-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8157:
-
Fix Version/s: qpid-java-broker-7.1.0
> [Broker-J] Deletion of Virtual Host Node fails to clean-up properly all
> Virtual Host/Virtual Host Node resources
>
>
> Key: QPID-8157
> URL: https://issues.apache.org/jira/browse/QPID-8157
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> Deletion of BDB HA Virtual Host Node ends up in left behind configuration and
> coalescing committer threads, open amqp connections, etc
> Steps to reproduce
> * Create BDB HA Virtual Host Node using management
> * Delete BDB HA Virtual Host Node using management (preferably amqp
> management)
> * Collect heap dump and check references to deleted virtual host node
> {noformat}
> select * from
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImplWithAccessChecking
> {noformat}
> Only master sources are affected by the issue. It seems one of recent
> refactoring of delete functionality introduced the regression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8195) [Broker-J] Improve AmqpErrorException#toString
[
https://issues.apache.org/jira/browse/QPID-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8195.
--
Resolution: Fixed
Assignee: (was: Keith Wall)
The change looks good to me
> [Broker-J] Improve AmqpErrorException#toString
> --
>
> Key: QPID-8195
> URL: https://issues.apache.org/jira/browse/QPID-8195
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> The {{AmqpErrorException#toString}} does not include the details of the
> underlying {{Error}} which impedes problem resolution.
--
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-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7153: - Fix Version/s: qpid-java-broker-7.1.0 > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- 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] (QPIDJMS-376) notify the ExceptionListener when a consumer with a MessageListener remotely closes
[ https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Maier reopened QPIDJMS-376: -- As I am not sure if someone reads my last comment when this issue is closed, I re-open it. If you prefer a new issue let me know. > notify the ExceptionListener when a consumer with a MessageListener remotely > closes > --- > > Key: QPIDJMS-376 > URL: https://issues.apache.org/jira/browse/QPIDJMS-376 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 > Environment: AMQP Server: Enmasse 0.17.1 > Enmasse Address Type: anycast >Reporter: Daniel Maier >Priority: Major > Fix For: 0.32.0 > > Attachments: clientlogs.txt > > > When I create a consumer to an address that just does not exist, I expected > to get some exception or that the client retries the operation. But there > seems not even to be a log message which indicates a failure. > Is this intended behavior or is this a bug? A more general description is: If > AMQP server closes the receiver link, qpid jms client does not notify the > user anyhow or does not re-establish the link. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
