[jira] [Created] (DISPATCH-1026) Router crashing when using sourcePattern/targetPattern with multiple patterns and one of them being user token when trying to open an unauthorized address
Fernando Giorgetti created DISPATCH-1026:
Summary: Router crashing when using sourcePattern/targetPattern
with multiple patterns and one of them being user token when trying to open an
unauthorized address
Key: DISPATCH-1026
URL: https://issues.apache.org/jira/browse/DISPATCH-1026
Project: Qpid Dispatch
Issue Type: Bug
Reporter: Fernando Giorgetti
When you define a vhost policy with a targetPattern or a sourcePattern using
multiple addresses and one of them being the ${user} (user token), and if you
try to connect to an unauthorized address, the router crashes.
Example:
targetPattern: queue/${user}, sample, address
If you try to connect a sender to an address, like, "notauthorized" then the
router crashes with:
qdrouterd: /tmp/qpid-dispatch/src/policy.c:848:
_qd_policy_approve_link_name_tree: Assertion `0' failed.
Aborted (core dumped)
--
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-389) JMS 2.0 Async CompletionListener can be notified in error
[ https://issues.apache.org/jira/browse/QPIDJMS-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-389. -- Resolution: Fixed > JMS 2.0 Async CompletionListener can be notified in error > - > > Key: QPIDJMS-389 > URL: https://issues.apache.org/jira/browse/QPIDJMS-389 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.33.0 > > > If two producers are created for a single session and one producer is used to > send a message using an CompletionListener and the other producer happens to > be remotely closed the sent message CompletionListener will be notified of > completion in error if it hadn't already completed. -- 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-389) JMS 2.0 Async CompletionListener can be notified in error
[ https://issues.apache.org/jira/browse/QPIDJMS-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505417#comment-16505417 ] ASF subversion and git services commented on QPIDJMS-389: - Commit 816773722df3abb23d1bca81aa64f353e57c0a02 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=8167737 ] QPIDJMS-389 Signal the correct producer completion only Ensure that if more than one producer exists on a session that the remote close of one producer does not trigger completions for the other producer that is waiting for its send to complete. > JMS 2.0 Async CompletionListener can be notified in error > - > > Key: QPIDJMS-389 > URL: https://issues.apache.org/jira/browse/QPIDJMS-389 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.33.0 > > > If two producers are created for a single session and one producer is used to > send a message using an CompletionListener and the other producer happens to > be remotely closed the sent message CompletionListener will be notified of > completion in error if it hadn't already completed. -- 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-389) JMS 2.0 Async CompletionListener can be notified in error
Timothy Bish created QPIDJMS-389: Summary: JMS 2.0 Async CompletionListener can be notified in error Key: QPIDJMS-389 URL: https://issues.apache.org/jira/browse/QPIDJMS-389 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.32.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.33.0 If two producers are created for a single session and one producer is used to send a message using an CompletionListener and the other producer happens to be remotely closed the sent message CompletionListener will be notified of completion in error if it hadn't already completed. -- 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-1025) User token not being replaced properly on a vhost policy when defined in the prefix or suffix
[
https://issues.apache.org/jira/browse/DISPATCH-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505384#comment-16505384
]
ASF GitHub Bot commented on DISPATCH-1025:
--
GitHub user fgiorgetti opened a pull request:
https://github.com/apache/qpid-dispatch/pull/319
DISPATCH-1025 - Fixes user token replacement used in prefix or suffix
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/fgiorgetti/qpid-dispatch
fgiorgetti-DISPATCH-1025
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/319.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 #319
commit 812fd0014f69c31a1f9e76be48c273e52fa91fb2
Author: Fernando Giorgetti
Date: 2018-06-07T22:16:19Z
DISPATCH-1025 - Fixes user token replacement used in prefix or suffix
> User token not being replaced properly on a vhost policy when defined in the
> prefix or suffix
> -
>
> Key: DISPATCH-1025
> URL: https://issues.apache.org/jira/browse/DISPATCH-1025
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Policy Engine
>Reporter: Fernando Giorgetti
>Priority: Major
>
> When a vhost policy is defined with a sources/sourcePattern and/or
> targets/targetPattern containing a user token (${user}), the token is just
> being replaced properly when using: sources/targets and only if it is
> embedded (not being in prefix or suffix).
> This causes policy validation to reject link attachment to the related
> address.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #319: DISPATCH-1025 - Fixes user token replacemen...
GitHub user fgiorgetti opened a pull request: https://github.com/apache/qpid-dispatch/pull/319 DISPATCH-1025 - Fixes user token replacement used in prefix or suffix You can merge this pull request into a Git repository by running: $ git pull https://github.com/fgiorgetti/qpid-dispatch fgiorgetti-DISPATCH-1025 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/319.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 #319 commit 812fd0014f69c31a1f9e76be48c273e52fa91fb2 Author: Fernando Giorgetti Date: 2018-06-07T22:16:19Z DISPATCH-1025 - Fixes user token replacement used in prefix or suffix --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1025) User token not being replaced properly on a vhost policy when defined in the prefix or suffix
Fernando Giorgetti created DISPATCH-1025:
Summary: User token not being replaced properly on a vhost policy
when defined in the prefix or suffix
Key: DISPATCH-1025
URL: https://issues.apache.org/jira/browse/DISPATCH-1025
Project: Qpid Dispatch
Issue Type: Bug
Components: Policy Engine
Reporter: Fernando Giorgetti
When a vhost policy is defined with a sources/sourcePattern and/or
targets/targetPattern containing a user token (${user}), the token is just
being replaced properly when using: sources/targets and only if it is embedded
(not being in prefix or suffix).
This causes policy validation to reject link attachment to the related address.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1857) [cpp] no access to AMQP connection offered/desired capabilities
Alan Conway created PROTON-1857: --- Summary: [cpp] no access to AMQP connection offered/desired capabilities Key: PROTON-1857 URL: https://issues.apache.org/jira/browse/PROTON-1857 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.23.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.24.0 The C++ binding does not provide access to the offered-capabilities and desired-capabilities of a connection, [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open] This looks like an oversight - link capabilities are supported. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1856) [ruby] auto-accept over-writing user transfer state
Alan Conway created PROTON-1856: --- Summary: [ruby] auto-accept over-writing user transfer state Key: PROTON-1856 URL: https://issues.apache.org/jira/browse/PROTON-1856 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: proton-c-0.23.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.24.0 The auto-accept functionality of the MessagingAdapter is incorrectly setting the transfer state even if the user had already set it. It is checking for "settled?" to decide if it should set state, but this is incorrect since the message may be locally but not remotely settled at this point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1855) [ruby] copy link terminus state for incoming links
Alan Conway created PROTON-1855: --- Summary: [ruby] copy link terminus state for incoming links Key: PROTON-1855 URL: https://issues.apache.org/jira/browse/PROTON-1855 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: proton-c-0.23.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: proton-c-0.24.0 For incoming links, the remote terminus state should be copied to the local state automatically before the application handlers see the link object. This way all relevant link state can be accessed using the simple get/set methods. Other bindings do this, it is an oversight that ruby does not. -- 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-941) Router is returning incorrect files from http get requests.
[ https://issues.apache.org/jira/browse/DISPATCH-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505202#comment-16505202 ] ASF subversion and git services commented on DISPATCH-941: -- Commit 3dbbafc2dc0e2dbd4aa90c1f1509da966360327e in qpid-dispatch's branch refs/heads/1.1.x from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=3dbbafc ] DISPATCH-941: Router is returning incorrect files from http get Bug in http-libwebsockets code. A partial HTTP handler such as we have needs to call lws_callback_http_dummy() to fill in default HTTP behaviours. Without that the LWS library was not properly informed of termination of HTTP transactions causing confusion if a connection was re-used. (cherry picked from commit c728d7f41c78ccc8db127b87c11470a5b9bc8c82) > Router is returning incorrect files from http get requests. > --- > > Key: DISPATCH-941 > URL: https://issues.apache.org/jira/browse/DISPATCH-941 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.0.1 >Reporter: Ernest Allen >Assignee: Alan Conway >Priority: Major > Fix For: 1.1.0 > > Attachments: CaptureApache_angular.PNG, CaptureApache_angular.PNG, > CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, CaptureApache_woff2.PNG, > CaptureDispatch_angular.PNG, CaptureDispatch_angular.PNG, > CaptureDispatch_woff2.PNG > > > When http requests are made from a Windows machine, the http response headers > appear to be mixed up or for a different request. For example, when the > browser requests the file OpenSans-Regular-webfont.woff2, the response has a > content-type of text/javascript and an incorrect content-length. Here is the > bad response: !CaptureDispatch_woff2.PNG! > When the same browser on the same machine requests the same file from Apache > tomcat, the response is correct: > !CaptureApache_woff2.PNG! > Another example: This time the request is for the javascript file angular.js. > Here is the bad response from the router: > !CaptureDispatch_angular.PNG! > > And here is the correct response from tomcat for the same file: > !CaptureApache_angular.PNG! > The incorrect content-types and content-lengths returned by the router lead > me to believe that the responses are getting mixed up. > Possibly important note: Which requests are mixed up varies each time I > reload the page. Sometimes files that failed on a previous page load will > come down just fine. It doesn't always happen on the same files. > This happens for all browsers I've tried on Windows. It does not happen for > any browser when the request comes from my linux box. > -- 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-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:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1023. - Resolution: Fixed > 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
[jira] [Updated] (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:all-tabpanel ] Ganesh Murthy updated DISPATCH-1021: Fix Version/s: 1.1.0 > 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 > Fix For: 1.1.0 > > 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
[jira] [Resolved] (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:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1021. - Resolution: Fixed > 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 > Fix For: 1.1.0 > > 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
[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&focusedCommentId=16505061#comment-16505061 ] ASF subversion and git services commented on DISPATCH-1023: --- Commit 478a98688afbaa1c62abbc7a53775e1fae0dfb15 in qpid-dispatch's branch refs/heads/1.1.x from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=478a986 ] DISPATCH-1023 - Added a multicast bit on the qdr_delivery_t object to use in places where owning_addr is not available. Also added code to free multi frame non-multicast presettled messages. This closes #318 (cherry picked from commit e96c7ed5083d4563f8b82b852d3367d59da9) > 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
[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&focusedCommentId=16505060#comment-16505060 ] ASF subversion and git services commented on DISPATCH-1021: --- Commit edfa1ccc5859ea3567b641e1ced8fabda9055d65 in qpid-dispatch's branch refs/heads/1.1.x from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=edfa1cc ] 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. This closes #316. (cherry picked from commit c1e0ceeecc9348c7633022681a7ac19e6fd0f1b8) > 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
[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&focusedCommentId=16505054#comment-16505054 ] ASF GitHub Bot commented on DISPATCH-1023: -- Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/318 > 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
[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&focusedCommentId=16505053#comment-16505053 ] ASF subversion and git services commented on DISPATCH-1023: --- Commit e96c7ed5083d4563f8b82b852d3367d59da9 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e96c7ed ] DISPATCH-1023 - Added a multicast bit on the qdr_delivery_t object to use in places where owning_addr is not available. Also added code to free multi frame non-multicast presettled messages. This closes #318 > 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 #318: DISPATCH-1023 - Added a multicast bit on th...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/318 --- - 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&focusedCommentId=16505035#comment-16505035 ] ASF subversion and git services commented on DISPATCH-1021: --- Commit c1e0ceeecc9348c7633022681a7ac19e6fd0f1b8 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=c1e0cee ] 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. This closes #316. > 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
[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&focusedCommentId=16505036#comment-16505036 ] ASF GitHub Bot commented on DISPATCH-1021: -- Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/316 > 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 #316: DISPATCH-1021 - Introduced a more flag in t...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/316 --- - 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&focusedCommentId=16505011#comment-16505011
]
ASF GitHub Bot commented on DISPATCH-1021:
--
Github user ganeshmurthy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/316#discussion_r193836829
--- Diff: src/router_core/transfer.c ---
@@ -1237,7 +1246,7 @@ void qdr_drain_inbound_undelivered_CT(qdr_core_t
*core, qdr_link_t *link, qdr_ad
qdr_delivery_t *dlv = DEQ_HEAD(deliveries);
while (dlv) {
DEQ_REMOVE_HEAD(deliveries);
-qdr_link_forward_CT(core, link, dlv, addr);
+qdr_link_forward_CT(core, link, dlv, addr, 0);
--- End diff --
will do. thanks.
> 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 #316: DISPATCH-1021 - Introduced a more flag in t...
Github user ganeshmurthy commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/316#discussion_r193836829
--- Diff: src/router_core/transfer.c ---
@@ -1237,7 +1246,7 @@ void qdr_drain_inbound_undelivered_CT(qdr_core_t
*core, qdr_link_t *link, qdr_ad
qdr_delivery_t *dlv = DEQ_HEAD(deliveries);
while (dlv) {
DEQ_REMOVE_HEAD(deliveries);
-qdr_link_forward_CT(core, link, dlv, addr);
+qdr_link_forward_CT(core, link, dlv, addr, 0);
--- End diff --
will do. thanks.
---
-
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&focusedCommentId=16505009#comment-16505009
]
ASF GitHub Bot commented on DISPATCH-1021:
--
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/316#discussion_r193835316
--- Diff: src/router_core/transfer.c ---
@@ -1237,7 +1246,7 @@ void qdr_drain_inbound_undelivered_CT(qdr_core_t
*core, qdr_link_t *link, qdr_ad
qdr_delivery_t *dlv = DEQ_HEAD(deliveries);
while (dlv) {
DEQ_REMOVE_HEAD(deliveries);
-qdr_link_forward_CT(core, link, dlv, addr);
+qdr_link_forward_CT(core, link, dlv, addr, 0);
--- End diff --
You should use false for a boolean literal, not 0.
> 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 #316: DISPATCH-1021 - Introduced a more flag in t...
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/316#discussion_r193835316
--- Diff: src/router_core/transfer.c ---
@@ -1237,7 +1246,7 @@ void qdr_drain_inbound_undelivered_CT(qdr_core_t
*core, qdr_link_t *link, qdr_ad
qdr_delivery_t *dlv = DEQ_HEAD(deliveries);
while (dlv) {
DEQ_REMOVE_HEAD(deliveries);
-qdr_link_forward_CT(core, link, dlv, addr);
+qdr_link_forward_CT(core, link, dlv, addr, 0);
--- End diff --
You should use false for a boolean literal, not 0.
---
-
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&focusedCommentId=16505004#comment-16505004
]
ASF GitHub Bot commented on DISPATCH-1023:
--
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/318#discussion_r193834441
--- Diff: src/router_core/transfer.c ---
@@ -1162,7 +1164,7 @@ static void qdr_deliver_continue_CT(qdr_core_t *core,
qdr_action_t *action, bool
}
// This is a multicast delivery
-if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr)) {
+if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr) ||
in_dlv->multicast || in_dlv->settled) {
--- End diff --
If the latter is handling for multi-frame unicasts, then the comment above
is no longer accurate.
> 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
[jira] [Commented] (QPID-8206) [linearstore] Deadlock possible in InactivityFireEvent if fire() is called at the same time as cancel()
[
https://issues.apache.org/jira/browse/QPID-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16505005#comment-16505005
]
Kim van der Riet commented on QPID-8206:
I cannot reproduce using this reproducer on my hardware.
*But* if I add a sleep of 10ms into {{InactivityFireEvent::cancel()}} just
after taking the lock, then the deadlock occurs quite quickly for me - after a
minute or so of running Pavel's reproducer.
{noformat}
diff --git a/src/qpid/linearstore/JournalImpl.cpp
b/src/qpid/linearstore/JournalImpl.cpp
index fe919fbd3..e512e9a05 100644
--- a/src/qpid/linearstore/JournalImpl.cpp
+++ b/src/qpid/linearstore/JournalImpl.cpp
@@ -82,6 +82,7 @@ void InactivityFireEvent::fire() {
void InactivityFireEvent::cancel() {
::qpid::sys::Mutex::ScopedLock sl(_ifeStateLock);
+::usleep(10 * 1000); // <-- *** DEBUG ***
::qpid::sys::TimerTask::cancel();
_state = CANCELLED;
}
{noformat}
After making the following fix, but leaving the sleep in place:
{noformat}
diff --git a/src/qpid/linearstore/JournalImpl.cpp
b/src/qpid/linearstore/JournalImpl.cpp
index fe919fbd3..55f33bb80 100644
--- a/src/qpid/linearstore/JournalImpl.cpp
+++ b/src/qpid/linearstore/JournalImpl.cpp
@@ -81,9 +81,12 @@ void InactivityFireEvent::fire() {
}
void InactivityFireEvent::cancel() {
-::qpid::sys::Mutex::ScopedLock sl(_ifeStateLock);
::qpid::sys::TimerTask::cancel();
-_state = CANCELLED;
+{
+::qpid::sys::Mutex::ScopedLock sl(_ifeStateLock);
+::usleep(10 * 1000); // <-- *** DEBUG ***
+_state = CANCELLED;
+}
}
GetEventsFireEvent::GetEventsFireEvent(JournalImpl* p,
{noformat}
I cannot get the reproducer to fail. I am hopeful that this will make a valid
fix. I will continue to test for a while.
In essence, the fix allows the underlying timer to *first* cancel (which
includes waiting for any flush fires that may have occurred on another thread)
before taking the lock to change the local state to CANCELLED.
To be sure we are not introducing a regression, we should probably also check
the reproducers for QPID-7975.
> [linearstore] Deadlock possible in InactivityFireEvent if fire() is called at
> the same time as cancel()
> ---
>
> Key: QPID-8206
> URL: https://issues.apache.org/jira/browse/QPID-8206
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> A deadlock has been observed in InactivityFireEvent if
> {{InactivityFireEvent::fire()}} triggered by the timer occurs at almost the
> same time as {{InactivityFireEvent::cancel()}} on another thread, and which
> occurs if the queue is deleted.
> The mutex {{InactivityFireEvent::_ifeStateLock}} becomes deadlocked if the
> thread calling {{cancel()}} obtains the lock, but a fire event is imminent.
> The {{fire()}} call will then be blocked on this mutex. However, cancel
> cannot complete until fire competes owing to the sys::Time Monitor which
> waits for all fires to complete before allowing the cancel to occur.
--
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 #318: DISPATCH-1023 - Added a multicast bit on th...
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/318#discussion_r193834441
--- Diff: src/router_core/transfer.c ---
@@ -1162,7 +1164,7 @@ static void qdr_deliver_continue_CT(qdr_core_t *core,
qdr_action_t *action, bool
}
// This is a multicast delivery
-if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr)) {
+if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr) ||
in_dlv->multicast || in_dlv->settled) {
--- End diff --
If the latter is handling for multi-frame unicasts, then the comment above
is no longer accurate.
---
-
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&focusedCommentId=16505003#comment-16505003
]
ASF GitHub Bot commented on DISPATCH-1023:
--
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/318#discussion_r193833973
--- Diff: src/router_core/transfer.c ---
@@ -1162,7 +1164,7 @@ static void qdr_deliver_continue_CT(qdr_core_t *core,
qdr_action_t *action, bool
}
// This is a multicast delivery
-if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr)) {
+if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr) ||
in_dlv->multicast || in_dlv->settled) {
--- End diff --
Why did you keep the call to qdr_is_addr_treatment_multicast here? Isn't
it always true that the in_dlv->multicast flag will be initialized
appropriately in qdr_link_forward_CT?
Also, why did you add the in_dlv->settled condition? That is new/changed
functionality.
> 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 #318: DISPATCH-1023 - Added a multicast bit on th...
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/318#discussion_r193833973
--- Diff: src/router_core/transfer.c ---
@@ -1162,7 +1164,7 @@ static void qdr_deliver_continue_CT(qdr_core_t *core,
qdr_action_t *action, bool
}
// This is a multicast delivery
-if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr)) {
+if (qdr_is_addr_treatment_multicast(in_dlv->link->owning_addr) ||
in_dlv->multicast || in_dlv->settled) {
--- End diff --
Why did you keep the call to qdr_is_addr_treatment_multicast here? Isn't
it always true that the in_dlv->multicast flag will be initialized
appropriately in qdr_link_forward_CT?
Also, why did you add the in_dlv->settled condition? That is new/changed
functionality.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8206) [linearstore] Deadlock possible in InactivityFireEvent if fire() is called at the same time as cancel()
[
https://issues.apache.org/jira/browse/QPID-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504958#comment-16504958
]
Kim van der Riet commented on QPID-8206:
Pavel Moravec has found a reproducer:
0) {{rm -rf /var/lib/qpidd/.qpidd # just to start with absolutely clean table}}
1) set
{{journal-flush-timeout=50ms}}
to qpidd.conf - the lower the better. I reproduce the deadlock always within a
minute or two with this value, but it took ~10 minutes with default 500ms (I
think).
2) run this script that sporadically sends and receives a durable message to a
queue that is time to time deleted - and it does so concurrently for 50 queues:
{noformat}
for i in $(seq 1 50); do
while true; do
echo "$(date): loop $i"
qpid-send -a "DurableTest-${i}; {create:always, node:{type:queue,
durable:true}}" -m 1 --content-size=1100 --durable=yes
qpid-receive -a DurableTest-${i} --print-content=no 2> /dev/null
sleep 0.2
done &
done
for i in $(seq 1 50); do
while true; do
echo "$(date): deleting queue $i"
qpid-config del queue DurableTest-${i} --force
sleep $((RANDOM%5)).$((RANDOM%10))
done &
done
{noformat}
3) check if qpidd responds, via e.g.:
{{while true; do date; qpid-stat -g; sleep 5; done}}
4) within a minute or so, deadlock comes to you and your broker.
> [linearstore] Deadlock possible in InactivityFireEvent if fire() is called at
> the same time as cancel()
> ---
>
> Key: QPID-8206
> URL: https://issues.apache.org/jira/browse/QPID-8206
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> A deadlock has been observed in InactivityFireEvent if
> {{InactivityFireEvent::fire()}} triggered by the timer occurs at almost the
> same time as {{InactivityFireEvent::cancel()}} on another thread, and which
> occurs if the queue is deleted.
> The mutex {{InactivityFireEvent::_ifeStateLock}} becomes deadlocked if the
> thread calling {{cancel()}} obtains the lock, but a fire event is imminent.
> The {{fire()}} call will then be blocked on this mutex. However, cancel
> cannot complete until fire competes owing to the sys::Time Monitor which
> waits for all fires to complete before allowing the cancel to occur.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8206) [linearstore] Deadlock possible in InactivityFireEvent if fire() is called at the same time as cancel()
Kim van der Riet created QPID-8206:
--
Summary: [linearstore] Deadlock possible in InactivityFireEvent if
fire() is called at the same time as cancel()
Key: QPID-8206
URL: https://issues.apache.org/jira/browse/QPID-8206
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Reporter: Kim van der Riet
Assignee: Kim van der Riet
A deadlock has been observed in InactivityFireEvent if
{{InactivityFireEvent::fire()}} triggered by the timer occurs at almost the
same time as {{InactivityFireEvent::cancel()}} on another thread, and which
occurs if the queue is deleted.
The mutex {{InactivityFireEvent::_ifeStateLock}} becomes deadlocked if the
thread calling {{cancel()}} obtains the lock, but a fire event is imminent. The
{{fire()}} call will then be blocked on this mutex. However, cancel cannot
complete until fire competes owing to the sys::Time Monitor which waits for all
fires to complete before allowing the cancel to occur.
--
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-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&focusedCommentId=16504867#comment-16504867 ] ASF subversion and git services commented on QPIDJMS-386: - Commit fe4aa6ed9f9be25ac74c34f07c87859d64b3c73d in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=fe4aa6e ] QPIDJMS-386: add some tweaks for the tests > 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: Timothy Bish >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] [Updated] (QPID-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[ https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8204: - Priority: Minor (was: Major) > [Broker-J] Add statistics to report the maximum size of incoming messages > - > > Key: QPID-8204 > URL: https://issues.apache.org/jira/browse/QPID-8204 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch > > > Add statistics to report the maximum size of incoming messages on Broker and > Virtual Hosts. Add a switch to enable/disable collection of statistics for > message maximum size . By default, collection of maximum size statistics > should be disabled -- 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-8202) [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8202. -- Resolution: Fixed Resolving JIRA as changes have been reviewed and merged into 7.0.x branch > [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded > from store for every content chunk sent to the client > --- > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple frames. > Currently, the flowed to disk message is repeatedly loaded from store and > evicted from memory on sending every content chunk. As result, the message > consumption performance is very slow. Only AMQP protocols 0-8..0-91 are > affected by the issue -- 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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[ https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8204. -- Resolution: Fixed Resolving JIRA as changes have been reviewed and merged into 7.0.x branch > [Broker-J] Add statistics to report the maximum size of incoming messages > - > > Key: QPID-8204 > URL: https://issues.apache.org/jira/browse/QPID-8204 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch > > > Add statistics to report the maximum size of incoming messages on Broker and > Virtual Hosts. Add a switch to enable/disable collection of statistics for > message maximum size . By default, collection of maximum size statistics > should be disabled -- 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-8202) [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504679#comment-16504679 ] ASF subversion and git services commented on QPID-8202: --- Commit daf346efcd5ca2652f49077c622a3ffccab03049 in qpid-broker-j's branch refs/heads/7.0.x from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=daf346e ] QPID-8202: [Broker-J] Address review comments from Keith Wall (cherry picked from commit 9d08c765155f4d70e53f972f1a63b4a7326f) > [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded > from store for every content chunk sent to the client > --- > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple frames. > Currently, the flowed to disk message is repeatedly loaded from store and > evicted from memory on sending every content chunk. As result, the message > consumption performance is very slow. Only AMQP protocols 0-8..0-91 are > affected by the issue -- 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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[ https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504678#comment-16504678 ] ASF subversion and git services commented on QPID-8204: --- Commit 0df1680d9d008d306c5f5e6319e1c5f618f4b5cb in qpid-broker-j's branch refs/heads/7.0.x from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0df1680 ] QPID-8204: [Broker-J] Rename new statistics into 'inboundMessageHighWatermark' and remove extra switch enabling the statistics evaluation (cherry picked from commit 0b63b074e0e61e026caab0122aa4fa404aec25ff) > [Broker-J] Add statistics to report the maximum size of incoming messages > - > > Key: QPID-8204 > URL: https://issues.apache.org/jira/browse/QPID-8204 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch > > > Add statistics to report the maximum size of incoming messages on Broker and > Virtual Hosts. Add a switch to enable/disable collection of statistics for > message maximum size . By default, collection of maximum size statistics > should be disabled -- 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-8202) [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504619#comment-16504619 ] Keith Wall commented on QPID-8202: -- Changes look reasonable to me. > [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded > from store for every content chunk sent to the client > --- > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple frames. > Currently, the flowed to disk message is repeatedly loaded from store and > evicted from memory on sending every content chunk. As result, the message > consumption performance is very slow. Only AMQP protocols 0-8..0-91 are > affected by the issue -- 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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[ https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504610#comment-16504610 ] Keith Wall commented on QPID-8204: -- Changes look reasonable to me. > [Broker-J] Add statistics to report the maximum size of incoming messages > - > > Key: QPID-8204 > URL: https://issues.apache.org/jira/browse/QPID-8204 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch > > > Add statistics to report the maximum size of incoming messages on Broker and > Virtual Hosts. Add a switch to enable/disable collection of statistics for > message maximum size . By default, collection of maximum size statistics > should be disabled -- 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-8203) [Broker-J][AMQP 0-8...0-91] Improve maximum message size check
[ https://issues.apache.org/jira/browse/QPID-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8203: - Summary: [Broker-J][AMQP 0-8...0-91] Improve maximum message size check (was: [Broker-J][AMQP 0-9] Improve maximum message size check) > [Broker-J][AMQP 0-8...0-91] Improve maximum message size check > -- > > Key: QPID-8203 > URL: https://issues.apache.org/jira/browse/QPID-8203 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > Maximum message size check needs to be improved -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8205) [Broker-J] Release Qpid Broker-J 7.0.5
Alex Rudyy created QPID-8205: Summary: [Broker-J] Release Qpid Broker-J 7.0.5 Key: QPID-8205 URL: https://issues.apache.org/jira/browse/QPID-8205 Project: Qpid Issue Type: Task Components: Broker-J Reporter: Alex Rudyy Fix For: qpid-java-broker-7.0.5 Release Qpid Broker-J following instructions provided at [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8205) [Broker-J] Release Qpid Broker-J 7.0.5
[ https://issues.apache.org/jira/browse/QPID-8205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8205: Assignee: Alex Rudyy > [Broker-J] Release Qpid Broker-J 7.0.5 > -- > > Key: QPID-8205 > URL: https://issues.apache.org/jira/browse/QPID-8205 > Project: Qpid > Issue Type: Task > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.5 > > > Release Qpid Broker-J following instructions provided at > [https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+Broker-J] -- 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-8202) [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8202: - Summary: [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client (was: [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client) > [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded > from store for every content chunk sent to the client > --- > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple frames. > Currently, the flowed to disk message is repeatedly loaded from store and > evicted from memory on sending every content chunk. As result, the message > consumption performance is very slow. Only AMQP protocols 0-8..0-91 are > affected by the issue -- 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-8202) [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8202: - Description: When large message cannot fit in one frame it is sent in multiple frames. Currently, the flowed to disk message is repeatedly loaded from store and evicted from memory on sending every content chunk. As result, the message consumption performance is very slow. Only AMQP protocols 0-8..0-91 are affected by the issue (was: When large message cannot fit in one frame it is sent in multiple blocks. Currently, the flowed to disk message is reloaded from store and evicted from memory on sending every block. As result, the message consumption performance is very slow. Only AMQP protocols 0-8..0-91 are affected by the issue) > [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store > for every content chunk sent to the client > > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple frames. > Currently, the flowed to disk message is repeatedly loaded from store and > evicted from memory on sending every content chunk. As result, the message > consumption performance is very slow. Only AMQP protocols 0-8..0-91 are > affected by the issue -- 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-8202) [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8202: - Affects Version/s: qpid-java-6.1.6 qpid-java-6.1 qpid-java-6.1.1 qpid-java-6.1.2 qpid-java-6.1.3 qpid-java-6.1.4 qpid-java-6.1.5 > [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store > for every content chunk sent to the client > > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple blocks. > Currently, the flowed to disk message is reloaded from store and evicted from > memory on sending every block. As result, the message consumption performance > is very slow. Only AMQP protocols 0-8..0-91 are affected by the issue -- 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-8202) [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504538#comment-16504538 ] Alex Rudyy commented on QPID-8202: -- Keith, I committed changes [9d08c765155f4d70e53f972f1a63b4a7326f|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=9d08c76] addressing your review comments. I decided to continue using MessageContentSourceBody as ContentBody duplicates the buffer before sending. You are right, 6.1 is affected as well. > [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store > for every content chunk sent to the client > > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple blocks. > Currently, the flowed to disk message is reloaded from store and evicted from > memory on sending every block. As result, the message consumption performance > is very slow. Only AMQP protocols 0-8..0-91 are affected by the issue -- 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-8202) [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504527#comment-16504527 ] ASF subversion and git services commented on QPID-8202: --- Commit 9d08c765155f4d70e53f972f1a63b4a7326f in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=9d08c76 ] QPID-8202: [Broker-J] Address review comments from Keith Wall > [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store > for every content chunk sent to the client > > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple blocks. > Currently, the flowed to disk message is reloaded from store and evicted from > memory on sending every block. As result, the message consumption performance > is very slow. Only AMQP protocols 0-8..0-91 are affected by the issue -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1846) [proton-c] Message decode fails with PN_OUT_OF_MEMORY if there are large lists in the message
[
https://issues.apache.org/jira/browse/PROTON-1846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504462#comment-16504462
]
Marcel Meulemans commented on PROTON-1846:
--
I tried the diff above and and the {{uint32_t}} seems to introduce some
unwanted side effects due to the with the singed/unsigned "magic" in
{{pn_data_point/pn_data_restore}} (did look into the details, just that this
branch,
[https://github.com/apache/qpid-proton/blob/master/c/src/core/codec.c#L1177]
isn't hit when it should be). Using {{typedef int32_t pni_nid_t;}} and fixing
PNI_NID_MAX accordingly did worked for me.
> [proton-c] Message decode fails with PN_OUT_OF_MEMORY if there are large
> lists in the message
> --
>
> Key: PROTON-1846
> URL: https://issues.apache.org/jira/browse/PROTON-1846
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Ganesh Murthy
>Priority: Major
> Attachments: send_large_structured_body.js
>
>
> Steps to reproduce -
>
> # Start the Qpid Dispatch router
> # Run the following script that creates a bunch of addresses
> # for i in `seq 1 6546`; do echo
> "\{\"prefix\":\"address-$i\",\"distribution\":\"balanced\"}" | qdmanage
> CREATE --type=org.apache.qpid.dispatch.router.config.address --name
> address-$i --stdin; done
> # now run qdmanage QUERY --type=address
> # You will receive a Data error (-10)
> The following diff seems to fix the issue
> diff --git a/c/src/core/data.h b/c/src/core/data.h
> index 94dc7d67..f4320e2a 100644
> --- a/c/src/core/data.h
> +++ b/c/src/core/data.h
> @@ -27,7 +27,7 @@
> #include "decoder.h"
> #include "encoder.h"
>
> -typedef uint16_t pni_nid_t;
> +typedef uint32_t pni_nid_t;
> #define PNI_NID_MAX ((pni_nid_t)-1)
--
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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[ https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504446#comment-16504446 ] Alex Rudyy commented on QPID-8204: -- Kieth, I addressed you review comments in commit [0b63b074e0e61e026caab0122aa4fa404aec25ff|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0b63b07]. > [Broker-J] Add statistics to report the maximum size of incoming messages > - > > Key: QPID-8204 > URL: https://issues.apache.org/jira/browse/QPID-8204 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch > > > Add statistics to report the maximum size of incoming messages on Broker and > Virtual Hosts. Add a switch to enable/disable collection of statistics for > message maximum size . By default, collection of maximum size statistics > should be disabled -- 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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[ https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504441#comment-16504441 ] ASF subversion and git services commented on QPID-8204: --- Commit 0b63b074e0e61e026caab0122aa4fa404aec25ff in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0b63b07 ] QPID-8204: [Broker-J] Rename new statistics into 'inboundMessageHighWatermark' and remove extra switch enabling the statistics evaluation > [Broker-J] Add statistics to report the maximum size of incoming messages > - > > Key: QPID-8204 > URL: https://issues.apache.org/jira/browse/QPID-8204 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch > > > Add statistics to report the maximum size of incoming messages on Broker and > Virtual Hosts. Add a switch to enable/disable collection of statistics for > message maximum size . By default, collection of maximum size statistics > should be disabled -- 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] (QPID-8203) [Broker-J][AMQP 0-9] Improve maximum message size check
[ https://issues.apache.org/jira/browse/QPID-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503972#comment-16503972 ] Keith Wall edited comment on QPID-8203 at 6/7/18 7:43 AM: -- Production code change (master.7.0.x) looked reasonable. The new protocol test file didn't follow the naming conventions demanded by the configuration of the maven-surefire-plugin, so wasn't being run when invoked from Maven. I fixed that and added a 0-10 protocol test. I noted that an equivalent AMQP 1.0 test already existed. was (Author: k-wall): Production code change (master.7.0.x) looked reasonable. The new protocol test file didn't follow the naming conventions demanded by the configuration of the maven-surefire-plugin, so wasn't being run when invoked from Maven. I fixed that and added a 0-10 protocol test. I noted that a AMQP 1.0 already existed. > [Broker-J][AMQP 0-9] Improve maximum message size check > --- > > Key: QPID-8203 > URL: https://issues.apache.org/jira/browse/QPID-8203 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > Maximum message size check needs to be improved -- 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] (QPID-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[
https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504040#comment-16504040
]
Keith Wall edited comment on QPID-8204 at 6/7/18 7:42 AM:
--
Is the {{maxMessageSizeStatisticsEnabled}} switch really justifiable? I prefer
to avoid a proliferation of switches because they just bewilder. My guess
would be the additional CAS would have no noticeable effect on performance.
was (Author: k-wall):
Is the {{maxMessageSizeStatisticsEnabled}} switch really justifiable? I prefer
to avoid a proliferation of switches because they just bewilder. I guess would
be the additional CAS would have no noticeable effect on performance.
> [Broker-J] Add statistics to report the maximum size of incoming messages
> -
>
> Key: QPID-8204
> URL: https://issues.apache.org/jira/browse/QPID-8204
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5
>
> Attachments:
> 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch
>
>
> Add statistics to report the maximum size of incoming messages on Broker and
> Virtual Hosts. Add a switch to enable/disable collection of statistics for
> message maximum size . By default, collection of maximum size statistics
> should be disabled
--
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-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&focusedCommentId=16504354#comment-16504354 ] Daniel Maier commented on QPIDJMS-386: -- I tested the last fix with the scenario described in QPIDJMS-376. Failover works smooth for me now. Tanks a lot. Great work! > 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: Timothy Bish >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
