[jira] [Created] (PROTON-1440) pn_connection_wake to return bool status
Alan Conway created PROTON-1440: --- Summary: pn_connection_wake to return bool status Key: PROTON-1440 URL: https://issues.apache.org/jira/browse/PROTON-1440 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.17.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.18.0 pn_connection_wake() allows any thread to send a PN_CONNECTION_WAKE event to a proactor-managed connection. Currently it does not return any value, and the application must ensure it is not called after the PN_TRANSPORT_CLOSED event is processed for that connection. This is tricky for the application to synchronize and inconsistent with other pn_connection_ functions. If refcounts are used to keep a pn_connection_t in memory after the TRANSPORT_CLOSED, then calling wake() is an error even though the pn_connection_t is valid. Change wake to be safe as long as the pn_connection_t is valid. It returns true if the connection will be woken, false if it is too late. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-730) Coverity scan reported errors in Qpid Dispatch master
Ganesh Murthy created DISPATCH-730:
--
Summary: Coverity scan reported errors in Qpid Dispatch master
Key: DISPATCH-730
URL: https://issues.apache.org/jira/browse/DISPATCH-730
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.8.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Fix For: 0.8.0
5 new defect(s) introduced to Apache Qpid dispatch-router found with Coverity
Scan.
New defect(s) Reported-by: Coverity Scan
Showing 5 of 5 defect(s)
** CID 142339:(USE_AFTER_FREE)
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
*** CID 142339:(USE_AFTER_FREE)
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY &&
link_work->value > 0) {
279 DEQ_INSERT_HEAD(link->work_list, link_work);
280 link_work = 0; // Halt work processing
281 } else {
282 qdr_error_free(link_work->error);
283 free_qdr_link_work_t(link_work);
>>> CID 142339:(USE_AFTER_FREE)
>>> Dereferencing freed pointer "link".
284 link_work = DEQ_HEAD(link->work_list);
285 if (link_work)
286 DEQ_REMOVE_HEAD(link->work_list);
287 }
288 sys_mutex_unlock(conn->work_lock);
289 event_count++;
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY &&
link_work->value > 0) {
279 DEQ_INSERT_HEAD(link->work_list, link_work);
280 link_work = 0; // Halt work processing
281 } else {
282 qdr_error_free(link_work->error);
283 free_qdr_link_work_t(link_work);
>>> CID 142339:(USE_AFTER_FREE)
>>> Dereferencing freed pointer "link".
284 link_work = DEQ_HEAD(link->work_list);
285 if (link_work)
286 DEQ_REMOVE_HEAD(link->work_list);
287 }
288 sys_mutex_unlock(conn->work_lock);
289 event_count++;
** CID 142338: Resource leaks (RESOURCE_LEAK)
/home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in qd_failover_list()
*** CID 142338: Resource leaks (RESOURCE_LEAK)
/home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in qd_failover_list()
97 char *cursor = list->text;
98 char *next;
99 do {
100 next = qd_fol_next(cursor, ",");
101 qd_failover_item_t *item = qd_fol_item(cursor, error);
102 if (item == 0)
>>> CID 142338: Resource leaks (RESOURCE_LEAK)
>>> Variable "list" going out of scope leaks the storage it points to.
103 return 0;
104 DEQ_INSERT_TAIL(list->item_list, item);
105 cursor = next;
106 } while (cursor && *cursor);
107
108 return list;
** CID 142337: Null pointer dereferences (FORWARD_NULL)
/home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
*** CID 142337: Null pointer dereferences (FORWARD_NULL)
/home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
558 if (config && config->inter_router_cost > 1) {
559 pn_data_put_symbol(pn_connection_properties(conn),
560
pn_bytes(strlen(QD_CONNECTION_PROPERTY_COST_KEY),
QD_CONNECTION_PROPERTY_COST_KEY));
561 pn_data_put_int(pn_connection_properties(conn),
config->inter_router_cost);
562 }
563
>>> CID 142337: Null pointer dereferences (FORWARD_NULL)
>>> Dereferencing null pointer "config".
564 qd_failover_list_t *fol = config->failover_list;
565 if (fol) {
566 pn_data_put_symbol(pn_connection_properties(conn),
567
pn_bytes(strlen(QD_CONNECTION_PROPERTY_FAILOVER_LIST_KEY),
QD_CONNECTION_PROPERTY_FAILOVER_LIST_KEY));
568 pn_data_put_list(pn_connection_properties(conn));
569 pn_data_enter(pn_connection_properties(conn));
** CID 142336: API usage errors (CHAR_I
[jira] [Comment Edited] (PROTON-1339) Event_loop injection is very slow to trigger the events
[
https://issues.apache.org/jira/browse/PROTON-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926975#comment-15926975
]
Alan Conway edited comment on PROTON-1339 at 3/15/17 8:53 PM:
--
The new C++ binding based on the C proactor PROTON-1400 will provide a new
implementation of inject .The reproducer for this issue should be checked
against it to ensure it fixes the problem.
was (Author: aconway):
The new C++ binding based on the C proactor will provide a new implementation
of inject .The reproducer for this issue should be checked against it to ensure
it fixes the problem.
> Event_loop injection is very slow to trigger the events
> ---
>
> Key: PROTON-1339
> URL: https://issues.apache.org/jira/browse/PROTON-1339
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: 0.14.0
>Reporter: Adel Boutros
>Assignee: Andrew Stitcher
> Labels: reproducer
> Attachments: main.cpp
>
>
> Full details here:
> http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-0-15-0-Event-loop-injection-is-very-slow-compared-to-timer-schedule-td7652982.html
> The attached test code requires a Broker running.
> Output of attached code:
> {code}
> functor called
> closed connection took 1.155 seconds
> {code}
> ==> 1.155 seconds is too much
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1339) Event_loop injection is very slow to trigger the events
[
https://issues.apache.org/jira/browse/PROTON-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway reassigned PROTON-1339:
---
Assignee: Andrew Stitcher (was: Alan Conway)
> Event_loop injection is very slow to trigger the events
> ---
>
> Key: PROTON-1339
> URL: https://issues.apache.org/jira/browse/PROTON-1339
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: 0.14.0
>Reporter: Adel Boutros
>Assignee: Andrew Stitcher
> Labels: reproducer
> Attachments: main.cpp
>
>
> Full details here:
> http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-0-15-0-Event-loop-injection-is-very-slow-compared-to-timer-schedule-td7652982.html
> The attached test code requires a Broker running.
> Output of attached code:
> {code}
> functor called
> closed connection took 1.155 seconds
> {code}
> ==> 1.155 seconds is too much
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1339) Event_loop injection is very slow to trigger the events
[
https://issues.apache.org/jira/browse/PROTON-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926975#comment-15926975
]
Alan Conway commented on PROTON-1339:
-
The new C++ binding based on the C proactor will provide a new implementation
of inject .The reproducer for this issue should be checked against it to ensure
it fixes the problem.
> Event_loop injection is very slow to trigger the events
> ---
>
> Key: PROTON-1339
> URL: https://issues.apache.org/jira/browse/PROTON-1339
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: 0.14.0
>Reporter: Adel Boutros
>Assignee: Alan Conway
> Labels: reproducer
> Attachments: main.cpp
>
>
> Full details here:
> http://qpid.2158936.n2.nabble.com/Proton-c-0-14-0-0-15-0-Event-loop-injection-is-very-slow-compared-to-timer-schedule-td7652982.html
> The attached test code requires a Broker running.
> Output of attached code:
> {code}
> functor called
> closed connection took 1.155 seconds
> {code}
> ==> 1.155 seconds is too much
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-729) password-file option doesn't work correctly
[ https://issues.apache.org/jira/browse/DISPATCH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926959#comment-15926959 ] ASF subversion and git services commented on DISPATCH-729: -- Commit 8800ab5434499cc54eb2a5a850ddcaafa260caf2 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=8800ab5 ] DISPATCH-729 - Added functionality to read from file specified by passwordFile (cherry picked from commit c46498c893e7e388ed06d859d231d40f663c5112) > password-file option doesn't work correctly > --- > > Key: DISPATCH-729 > URL: https://issues.apache.org/jira/browse/DISPATCH-729 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 > Environment: CentOS 7 >Reporter: Rohan Mars >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.8.0 > > > Using the "password-file" option in a a ssl-profile causes the client not to > be able to connect. The router displays a: > "Enter PEM pass phrase" log message > Using the "password" option directly works. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1421) c proactor to take a connection URL string rather than host, port
[ https://issues.apache.org/jira/browse/PROTON-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1421. - Resolution: Fixed > c proactor to take a connection URL string rather than host, port > - > > Key: PROTON-1421 > URL: https://issues.apache.org/jira/browse/PROTON-1421 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > The pn_proacctor_connect/listen functions currently take a pair of strings > host:port. Instead they should take a single connection string in the form > "host:port" or a proton URL, which is more flexible for possible future > transports. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-729) password-file option doesn't work correctly
[ https://issues.apache.org/jira/browse/DISPATCH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-729. Resolution: Fixed > password-file option doesn't work correctly > --- > > Key: DISPATCH-729 > URL: https://issues.apache.org/jira/browse/DISPATCH-729 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 > Environment: CentOS 7 >Reporter: Rohan Mars >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.8.0 > > > Using the "password-file" option in a a ssl-profile causes the client not to > be able to connect. The router displays a: > "Enter PEM pass phrase" log message > Using the "password" option directly works. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1421) c proactor to take a connection URL string rather than host, port
[ https://issues.apache.org/jira/browse/PROTON-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926958#comment-15926958 ] Alan Conway commented on PROTON-1421: - Note the proactor only parses host and port from the string. Handling the scheme, user/password etc. must be done by the calling application > c proactor to take a connection URL string rather than host, port > - > > Key: PROTON-1421 > URL: https://issues.apache.org/jira/browse/PROTON-1421 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > The pn_proacctor_connect/listen functions currently take a pair of strings > host:port. Instead they should take a single connection string in the form > "host:port" or a proton URL, which is more flexible for possible future > transports. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (PROTON-1421) c proactor to take a connection URL string rather than host, port
[ https://issues.apache.org/jira/browse/PROTON-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1421: Comment: was deleted (was: The previous commit uses the host:port information from the URL, but does not include checking the scheme for SSL (amqp) and setting username/password from the URL onto the connection, that needs to be done.) > c proactor to take a connection URL string rather than host, port > - > > Key: PROTON-1421 > URL: https://issues.apache.org/jira/browse/PROTON-1421 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > The pn_proacctor_connect/listen functions currently take a pair of strings > host:port. Instead they should take a single connection string in the form > "host:port" or a proton URL, which is more flexible for possible future > transports. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1438) c proactor listening behavior
[ https://issues.apache.org/jira/browse/PROTON-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926945#comment-15926945 ] Alan Conway commented on PROTON-1438: - Patch for review https://reviews.apache.org/r/57662/ or https://github.com/alanconway/qpid-proton/tree/ipv4-ipv6 > c proactor listening behavior > - > > Key: PROTON-1438 > URL: https://issues.apache.org/jira/browse/PROTON-1438 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > Improved listening behavior for pn_proactor_listen to allow selective > listening by protocol (ipv4/v6) or portable "listen to everything". > Host can be a host name, IPV4 or IPV6 literal, > or the empty string/NULL (treated the same). The empty string listens on all > local addresses. A host name listens on all addresses associated with the > name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An > IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4. > - pn_proactor_listen may listen on more than one socket for ipv6/v4 or > for DNS names with multiple address records. > - the 'backlog' applies to *each* socket (open for debate - we might > want to divide the backlog among sockets with some minimum if there's > not enough) > - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event > indicates all sockets are closed. > - An error on any socket will close all the sockets of the listener, > PN_LISTERN_CLOSE event indicates all sockets are closed and provides > the error that triggered the close. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1439) messenger tests fail sporadically with interrupt error
[ https://issues.apache.org/jira/browse/PROTON-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1439. - Resolution: Fixed > messenger tests fail sporadically with interrupt error > --- > > Key: PROTON-1439 > URL: https://issues.apache.org/jira/browse/PROTON-1439 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > The python messenger tests sporadically fail with error "Interrupt: [-8]: > None" > The failure occurs in different tests randomly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 57662: PROTON-1438: C proactor listening behavior
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57662/ --- Review request for qpid, Andrew Stitcher and Cliff Jansen. Bugs: PROTON-1438 https://issues.apache.org/jira/browse/PROTON-1438 Repository: qpid-proton-git Description --- (also available on https://github.com/alanconway/qpid-proton/tree/ipv4-ipv6) Improved listening behavior for pn_proactor_listen to allow selective listening by protocol (ipv4/v6) or portable "listen to everything". Host can be a host name, IPV4 or IPV6 literal, or the empty string/NULL (treated the same). The empty string listens on all local addresses. A host name listens on all addresses associated with the name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4. - pn_proactor_listen may listen on more than one socket for ipv6/v4 or for DNS names with multiple address records. - the 'backlog' applies to *each* socket - an error on any socket will close all the sockets of the listener, PN_LISTERN_CLOSE event indicates all sockets are closed and provides the error that triggered the close. PROTON-1438: added pn_event_condition convenience function A convenience function to make it easier to write generic error handling functions for events. /* * If the event context object has a condition and the condition is set * return it, otherwise return NULL. * If the event context object has remote and local conditions, * try the remote condition first, then the local. */ PN_EXTERN struct pn_condition_t *pn_event_condition(pn_event_t *event); PROTON-1438: c libuv proactor - separate pn_connection_t on free Separate pn_connection_t from proactor internal data structures when the proactor frees the connection - in case the application is using refcounting to pin the connection. Diffs - proton-c/include/proton/cid.h 2d688964cbf2cf17850ee2f4f93eb6c85c7eb1a8 proton-c/include/proton/event.h 6f93cd4d33c121d9265649814f7770a99d61cd45 proton-c/include/proton/listener.h 2038c064a8a4fd621f584fd02db93a6e4593b708 proton-c/include/proton/proactor.h 43b8ccb85525631818b8393c5e7f9b07ae0b348d proton-c/src/core/engine.c 8c2aeb0d27a06384b7b1dc3488d9bb122dda7bd7 proton-c/src/proactor/libuv.c 102fcdd8a30d2dd57d9545552bcfd695a251a66d proton-c/src/tests/proactor.c beba46e84c75fb36677576b645fd2f39bb238827 proton-c/src/tests/test_tools.h 9fe679c4ce99f8bd8446343ea180ad10a9a60c7c Diff: https://reviews.apache.org/r/57662/diff/1/ Testing --- Passes proton tests, including new proactor.c tests for ipv4/v6 listening and connecting Thanks, Alan Conway
[jira] [Updated] (PROTON-1408) long-lived connections suffer large performance hit after many messages
[ https://issues.apache.org/jira/browse/PROTON-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish updated PROTON-1408: Attachment: jira_proton_1408_reproducer.tar.gz Everything you need in a tidy little package. I have 10 out of 10 reproductions with this. > long-lived connections suffer large performance hit after many messages > --- > > Key: PROTON-1408 > URL: https://issues.apache.org/jira/browse/PROTON-1408 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: michael goulish >Assignee: Alan Conway > Attachments: jira_proton_1408_reproducer.tar.gz > > > In long-running soak tests, in which connections are never taken down, I am > seeing a sudden & severe performance degradation when the number of messages > over the connection reaches about 6.4 billion. > This is happening in tests with two senders, two receivers & one router > intermediating. > I have tried C libUV clients as well as CPP clients. Behavior is not > identical, but I see sudden performance drop, ie. 8x throughput decrease or > worse, in both cases. > Alan / Ted / Ken see an issue in use of improper comparison logic in > pn_do_disposition(), in transport.c . I am trying to prove this now. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1439) messenger tests fail sporadically with interrupt error
[ https://issues.apache.org/jira/browse/PROTON-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926874#comment-15926874 ] ASF subversion and git services commented on PROTON-1439: - Commit 98676a12cf9acaf896bade79da0bba4bbd933ae4 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=98676a1 ] PROTON-1439: messenger tests fail sporadically with interrupt error Different messenger tests fail randomly with "Interrupt: [-8]: None" Disabled the tests by default as the messenger is no longer being maintained, They can be run with 'proton-tests "*.messenger.*"' > messenger tests fail sporadically with interrupt error > --- > > Key: PROTON-1439 > URL: https://issues.apache.org/jira/browse/PROTON-1439 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > The python messenger tests sporadically fail with error "Interrupt: [-8]: > None" > The failure occurs in different tests randomly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1438) c proactor listening behavior
[ https://issues.apache.org/jira/browse/PROTON-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926873#comment-15926873 ] ASF subversion and git services commented on PROTON-1438: - Commit 03ca9bec52d4a7a918a694c64929291edee58824 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=03ca9be ] PROTON-1438: C url parser allows unbracketed IPv6 For example the following are considered equivalent: ::1:amqp [::1]:amqp amqp://::1 amqp://::1:amqp > c proactor listening behavior > - > > Key: PROTON-1438 > URL: https://issues.apache.org/jira/browse/PROTON-1438 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > Improved listening behavior for pn_proactor_listen to allow selective > listening by protocol (ipv4/v6) or portable "listen to everything". > Host can be a host name, IPV4 or IPV6 literal, > or the empty string/NULL (treated the same). The empty string listens on all > local addresses. A host name listens on all addresses associated with the > name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An > IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4. > - pn_proactor_listen may listen on more than one socket for ipv6/v4 or > for DNS names with multiple address records. > - the 'backlog' applies to *each* socket (open for debate - we might > want to divide the backlog among sockets with some minimum if there's > not enough) > - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event > indicates all sockets are closed. > - An error on any socket will close all the sockets of the listener, > PN_LISTERN_CLOSE event indicates all sockets are closed and provides > the error that triggered the close. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1408) long-lived connections suffer large performance hit after many messages
[ https://issues.apache.org/jira/browse/PROTON-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926821#comment-15926821 ] michael goulish commented on PROTON-1408: - I can now reproduce the problem 100%, and after just a couple minutes instead of 9 hours or 27 hours as it was initially. This is done by: 1. storing deliveries in the receiver and only acking when I get 100,000 2. Altering proton code so that the first outgoing ID it uses is already close to 2^31 - 1 I am now packaging up all my stuff for the reproducer. > long-lived connections suffer large performance hit after many messages > --- > > Key: PROTON-1408 > URL: https://issues.apache.org/jira/browse/PROTON-1408 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: michael goulish >Assignee: Alan Conway > > In long-running soak tests, in which connections are never taken down, I am > seeing a sudden & severe performance degradation when the number of messages > over the connection reaches about 6.4 billion. > This is happening in tests with two senders, two receivers & one router > intermediating. > I have tried C libUV clients as well as CPP clients. Behavior is not > identical, but I see sudden performance drop, ie. 8x throughput decrease or > worse, in both cases. > Alan / Ted / Ken see an issue in use of improper comparison logic in > pn_do_disposition(), in transport.c . I am trying to prove this now. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1439) messenger tests fail sporadically with interrupt error
Alan Conway created PROTON-1439: --- Summary: messenger tests fail sporadically with interrupt error Key: PROTON-1439 URL: https://issues.apache.org/jira/browse/PROTON-1439 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.17.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.18.0 The python messenger tests sporadically fail with error "Interrupt: [-8]: None" The failure occurs in different tests randomly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-725) Use Patternfly styles for console
[ https://issues.apache.org/jira/browse/DISPATCH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926721#comment-15926721 ] ASF subversion and git services commented on DISPATCH-725: -- Commit cac44dc1fe509e002334225db802c2a4af0f8b5c in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=cac44dc ] DISPATCH-725 Adding css for slider > Use Patternfly styles for console > - > > Key: DISPATCH-725 > URL: https://issues.apache.org/jira/browse/DISPATCH-725 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > For the stand-alone console, use the patternfly.org styles. > This does not include the hawtio console since hawtio has it's own styles > that are not consistant with patternfly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-729) password-file option doesn't work correctly
[ https://issues.apache.org/jira/browse/DISPATCH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-729: -- Assignee: Ganesh Murthy > password-file option doesn't work correctly > --- > > Key: DISPATCH-729 > URL: https://issues.apache.org/jira/browse/DISPATCH-729 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 > Environment: CentOS 7 >Reporter: Rohan Mars >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.8.0 > > > Using the "password-file" option in a a ssl-profile causes the client not to > be able to connect. The router displays a: > "Enter PEM pass phrase" log message > Using the "password" option directly works. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-729) password-file option doesn't work correctly
[ https://issues.apache.org/jira/browse/DISPATCH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-729: Priority: Minor (was: Major) > password-file option doesn't work correctly > --- > > Key: DISPATCH-729 > URL: https://issues.apache.org/jira/browse/DISPATCH-729 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 > Environment: CentOS 7 >Reporter: Rohan Mars >Priority: Minor > Fix For: 0.8.0 > > > Using the "password-file" option in a a ssl-profile causes the client not to > be able to connect. The router displays a: > "Enter PEM pass phrase" log message > Using the "password" option directly works. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-725) Use Patternfly styles for console
[ https://issues.apache.org/jira/browse/DISPATCH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926699#comment-15926699 ] ASF subversion and git services commented on DISPATCH-725: -- Commit 7b743b23cba983db70da859ad7543fcac8daddba in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7b743b2 ] DISPATCH-725 Fix layout of connect page > Use Patternfly styles for console > - > > Key: DISPATCH-725 > URL: https://issues.apache.org/jira/browse/DISPATCH-725 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > For the stand-alone console, use the patternfly.org styles. > This does not include the hawtio console since hawtio has it's own styles > that are not consistant with patternfly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-729) password-file option doesn't work correctly
Rohan Mars created DISPATCH-729: --- Summary: password-file option doesn't work correctly Key: DISPATCH-729 URL: https://issues.apache.org/jira/browse/DISPATCH-729 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 0.7.0 Environment: CentOS 7 Reporter: Rohan Mars Fix For: 0.8.0 Using the "password-file" option in a a ssl-profile causes the client not to be able to connect. The router displays a: "Enter PEM pass phrase" log message Using the "password" option directly works. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-728) crash on shutdown with connector
[ https://issues.apache.org/jira/browse/DISPATCH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-728: Attachment: qdrouterd2.conf qdrouterd1.conf > crash on shutdown with connector > > > Key: DISPATCH-728 > URL: https://issues.apache.org/jira/browse/DISPATCH-728 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 > Environment: CentosOS 7 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: qdrouterd1.conf, qdrouterd2.conf > > > Running two routers connected via a "connector" causes the router to crash on > shutdown (control-c). > qdrouterd: /home/centos/qpid-dispatch/src/posix/driver.c:451: > qdpn_driver_remove_connector: Assertion `(d->connectors).size > 0' failed. > Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-728) crash on shutdown with connector
Rohan Mars created DISPATCH-728: --- Summary: crash on shutdown with connector Key: DISPATCH-728 URL: https://issues.apache.org/jira/browse/DISPATCH-728 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 0.7.0 Environment: CentosOS 7 Reporter: Rohan Mars Fix For: 0.8.0 Running two routers connected via a "connector" causes the router to crash on shutdown (control-c). qdrouterd: /home/centos/qpid-dispatch/src/posix/driver.c:451: qdpn_driver_remove_connector: Assertion `(d->connectors).size > 0' failed. Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-725) Use Patternfly styles for console
[ https://issues.apache.org/jira/browse/DISPATCH-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926633#comment-15926633 ] ASF subversion and git services commented on DISPATCH-725: -- Commit 0d825b15f3bee84c4f9d2a05febf13024eb69108 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0d825b1 ] DISPATCH-725 Adding missing files from patternfly checkin > Use Patternfly styles for console > - > > Key: DISPATCH-725 > URL: https://issues.apache.org/jira/browse/DISPATCH-725 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > For the stand-alone console, use the patternfly.org styles. > This does not include the hawtio console since hawtio has it's own styles > that are not consistant with patternfly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1437) c proactor address info and listen hints
[ https://issues.apache.org/jira/browse/PROTON-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1437: Description: The C proactor should provide access to the remote network address for incoming connections. The standard BSD `struct addrinfo` will be used to represent the address, this is portable to any platform that supports BSD sockets and is (in principle) extensible to cover new types of address by adding new values for ai_family. (The original JIRA also mentioned listeners, that has moved to a separate issue PROTON-1438) was:The C proactor should provide access to the remote network address for incoming connections and allow listener hints to be set to control protocols etc. The standard BSD `struct addrinfo` will be used to represent the address, this is portable to any platform that supports BSD sockets and is (in principle) extensible to cover new types of address by adding new values for ai_family > c proactor address info and listen hints > - > > Key: PROTON-1437 > URL: https://issues.apache.org/jira/browse/PROTON-1437 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.17.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18.0 > > > The C proactor should provide access to the remote network address for > incoming connections. The standard BSD `struct addrinfo` will be used to > represent the address, this is portable to any platform that supports BSD > sockets and is (in principle) extensible to cover new types of address by > adding new values for ai_family. > (The original JIRA also mentioned listeners, that has moved to a separate > issue PROTON-1438) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1438) c proactor listening behavior
Alan Conway created PROTON-1438: --- Summary: c proactor listening behavior Key: PROTON-1438 URL: https://issues.apache.org/jira/browse/PROTON-1438 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.17.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.18.0 Improved listening behavior for pn_proactor_listen to allow selective listening by protocol (ipv4/v6) or portable "listen to everything". Host can be a host name, IPV4 or IPV6 literal, or the empty string/NULL (treated the same). The empty string listens on all local addresses. A host name listens on all addresses associated with the name. An IPV6 literal address (or wildcard '[::]') listens only for IPV6. An IPV4 literal address (or wildcard '0.0.0.0') listens only for IPV4. - pn_proactor_listen may listen on more than one socket for ipv6/v4 or for DNS names with multiple address records. - the 'backlog' applies to *each* socket (open for debate - we might want to divide the backlog among sockets with some minimum if there's not enough) - pn_listener_close() closes all sockets, PN_LISTENER_CLOSE event indicates all sockets are closed. - An error on any socket will close all the sockets of the listener, PN_LISTERN_CLOSE event indicates all sockets are closed and provides the error that triggered the close. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7683) Remove knowledge of 0-x encoders from the AMQP 1.0 protocol layers
[
https://issues.apache.org/jira/browse/QPID-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926395#comment-15926395
]
Lorenz Quack commented on QPID-7683:
* Some local variables in {{ListToAmqpListConverter}} are called {{map}}
instead of {{list}}
* In the {{MimeContentConverterRegistry}} we should throw an exception or at
least print a warning if two converters try to occupy the same slot.
i.e., two {{MimeContentToObjectConverter}} with the same mime type or two
{{ObjectToMimeContentConverter}} with the same object class and rank.
I think this is especially dangerous in a plugin architecture where the
implementations are largely independent.
Maybe we should even allow plugins to occupy the same slot and just put them
into an arbitrary order ([guava
multimap|https://github.com/google/guava/wiki/NewCollectionTypesExplained#multimap]).
* Was giving {{SerializableToJavaObjectStream}} the lowest rank intentional?
... hold your horses ... reviewing
{{MimeContentConverterRegistry#getBestFitObjectToMimeContentConverter}} it
looks like the converter with the *highest* rank gets picked. I found this
surprising. You maintained everything in a nicely ordered list and then tricked
me by picking the last entry instead of the first.
* The inner loop in
{{MimeContentConverterRegistry#getBestFitObjectToMimeContentConverter}} seems a
bit convoluted. Why do you go through the pain of making a copy and using an
iterator? I think this would be a simpler approach that would work: {code}
for (Map.Entry entry :
_classToRankedMimeContentConverter.get(i).entrySet())
{
if (entry.getValue().isAcceptable(object))
{
potentialConverters.put(entry.getKey(),
entry.getValue());
}
}{code}
> Remove knowledge of 0-x encoders from the AMQP 1.0 protocol layers
> --
>
> Key: QPID-7683
> URL: https://issues.apache.org/jira/browse/QPID-7683
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7683-Refactor-AMQP-1.0-module-to-avoid-knowledg.patch
>
>
> Currently the AMQP 1.0 protocol layer makes direct use of BBEncoder (0-10)
> and TypedBytesEncoder (supported by the Qpid Client for the encoding of
> list/map message content for 0-8..0-10). This prevents the 0-x encoders from
> being moved to their respective module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7701) [BDB HA] Cursor#getNext API misuse
[
https://issues.apache.org/jira/browse/QPID-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7701.
--
Resolution: Fixed
> [BDB HA] Cursor#getNext API misuse
> --
>
> Key: QPID-7701
> URL: https://issues.apache.org/jira/browse/QPID-7701
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
>
> The documentation for methods {{com.sleepycat.je.Cursor#getNext}} and
> {{com.sleepycat.je.Cursor#getSearchKeyRange}} notes the following:
> {quote}
> In a replicated environment, an explicit transaction must have been
> specified when opening the cursor, unless read-uncommitted isolation is
> specified via the {{CursorConfig}} or {{LockMode}}
> parameter.
> {quote}
> Currently methods such as
> {{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.BDBMessageStoreReader#visitDistributedTransactions}}
> do not do this.
> The documentation does not state the implications of not following this
> advice.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7707. -- Resolution: Fixed > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. > This is a UI issue only. The underlying REST API operation is reporting the > failure correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-726) Connection Property for Failover Servers
[ https://issues.apache.org/jira/browse/DISPATCH-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-726. --- Resolution: Fixed > Connection Property for Failover Servers > > > Key: DISPATCH-726 > URL: https://issues.apache.org/jira/browse/DISPATCH-726 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.8.0 > > > Qpid Dispatch Router should be configurable to supply a failover list in the > connection properties such that clients (like the Qpid JMS client) can have a > list of alternate hosts and ports to connect to should the router connection > fail. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-726) Connection Property for Failover Servers
[ https://issues.apache.org/jira/browse/DISPATCH-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926310#comment-15926310 ] ASF subversion and git services commented on DISPATCH-726: -- Commit 06d1c9e36b805c8cccfb6c377ad93c6e5d35f01d in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=06d1c9e ] DISPATCH-726 - Added failover-list annotation for listeners. > Connection Property for Failover Servers > > > Key: DISPATCH-726 > URL: https://issues.apache.org/jira/browse/DISPATCH-726 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.8.0 > > > Qpid Dispatch Router should be configurable to supply a failover list in the > connection properties such that clients (like the Qpid JMS client) can have a > list of alternate hosts and ports to connect to should the router connection > fail. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-726) Connection Property for Failover Servers
[ https://issues.apache.org/jira/browse/DISPATCH-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926309#comment-15926309 ] ASF subversion and git services commented on DISPATCH-726: -- Commit 0226992ebc1379e18aec85830d3be930ee1e425d in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0226992 ] DISPATCH-726 - Added module for parsing and using failover lists. > Connection Property for Failover Servers > > > Key: DISPATCH-726 > URL: https://issues.apache.org/jira/browse/DISPATCH-726 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.8.0 > > > Qpid Dispatch Router should be configurable to supply a failover list in the > connection properties such that clients (like the Qpid JMS client) can have a > list of alternate hosts and ports to connect to should the router connection > fail. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7710) [Java Broker] Json configuration store can only save one binding with the same routing key per queue
[ https://issues.apache.org/jira/browse/QPID-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7710: - Summary: [Java Broker] Json configuration store can only save one binding with the same routing key per queue (was: Java Broker] Json configuration store can only save one binding with the same routing key per queue) > [Java Broker] Json configuration store can only save one binding with the > same routing key per queue > > > Key: QPID-7710 > URL: https://issues.apache.org/jira/browse/QPID-7710 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2 >Reporter: Alex Rudyy > > Creating two queue bindings with the same routing key to different exchanges > results in saving only one of them in json configuration store -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7710) Java Broker] Json configuration store can only save one binding with the same routing key per queue
[ https://issues.apache.org/jira/browse/QPID-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7710: - Summary: Java Broker] Json configuration store can only save one binding with the same routing key per queue (was: Java Broker] Json configuration store can only save one binding with the same rooting key per queue) > Java Broker] Json configuration store can only save one binding with the same > routing key per queue > --- > > Key: QPID-7710 > URL: https://issues.apache.org/jira/browse/QPID-7710 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2 >Reporter: Alex Rudyy > > Creating two queue bindings with the same routing key to different exchanges > results in saving only one of them in json configuration store -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7701) [BDB HA] Cursor#getNext API misuse
[
https://issues.apache.org/jira/browse/QPID-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7701:
-
Affects Version/s: qpid-java-broker-7.0.0
qpid-java-6.0
qpid-java-6.1
> [BDB HA] Cursor#getNext API misuse
> --
>
> Key: QPID-7701
> URL: https://issues.apache.org/jira/browse/QPID-7701
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
>
> The documentation for methods {{com.sleepycat.je.Cursor#getNext}} and
> {{com.sleepycat.je.Cursor#getSearchKeyRange}} notes the following:
> {quote}
> In a replicated environment, an explicit transaction must have been
> specified when opening the cursor, unless read-uncommitted isolation is
> specified via the {{CursorConfig}} or {{LockMode}}
> parameter.
> {quote}
> Currently methods such as
> {{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.BDBMessageStoreReader#visitDistributedTransactions}}
> do not do this.
> The documentation does not state the implications of not following this
> advice.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7701) [BDB HA] Cursor#getNext API misuse
[
https://issues.apache.org/jira/browse/QPID-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7701:
-
Fix Version/s: (was: qpid-java-6.1)
(was: qpid-java-6.0)
(was: 0.32)
(was: 0.30)
qpid-java-broker-7.0.0
qpid-java-6.1.2
qpid-java-6.0.7
> [BDB HA] Cursor#getNext API misuse
> --
>
> Key: QPID-7701
> URL: https://issues.apache.org/jira/browse/QPID-7701
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
>
> The documentation for methods {{com.sleepycat.je.Cursor#getNext}} and
> {{com.sleepycat.je.Cursor#getSearchKeyRange}} notes the following:
> {quote}
> In a replicated environment, an explicit transaction must have been
> specified when opening the cursor, unless read-uncommitted isolation is
> specified via the {{CursorConfig}} or {{LockMode}}
> parameter.
> {quote}
> Currently methods such as
> {{org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.BDBMessageStoreReader#visitDistributedTransactions}}
> do not do this.
> The documentation does not state the implications of not following this
> advice.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926293#comment-15926293 ] ASF subversion and git services commented on QPID-7707: --- Commit 1787057 from [~k-wall] in branch 'java/branches/6.1.x' [ https://svn.apache.org/r1787057 ] QPID-7707: [Web Management Console] Ensure that failure of the ACL reload or ManagedCertificate deletion is directed to the XHR error handler Merged from trunk with command: svn merge -c 1787052 ^/qpid/java/trunk > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. > This is a UI issue only. The underlying REST API operation is reporting the > failure correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7692) [0-8..0-91] Message sent to fanout exchange with no routing key is not delivered to application
[
https://issues.apache.org/jira/browse/QPID-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926278#comment-15926278
]
ASF subversion and git services commented on QPID-7692:
---
Commit 1787056 from oru...@apache.org in branch 'java/branches/6.1.x'
[ https://svn.apache.org/r1787056 ]
QPID-7692: [Java Client] Allow routingKey/subject to be null in addresses
merged changes from client trunk using
svn merge -c 1785989 ^/qpid/qpid-jms-amqp-0-x/trunk
merged tests from broker trunk using
svn merge -c 1785988 ^/qpid/java/trunk
> [0-8..0-91] Message sent to fanout exchange with no routing key is not
> delivered to application
>
>
> Key: QPID-7692
> URL: https://issues.apache.org/jira/browse/QPID-7692
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1.2, qpid-java-client-0-x-6.3.0
>
>
> If I publish a message to the fanout exchange with no routing key, then
> receive the same message, the client logs an error and the application fails
> to receive the message both otherwise continues. The problem only occurs on
> the 0-8..0-91 code path and then only if the client is in BURL default
> address syntax.
> Example publish address that causes the problem:
> {noformat}
> destination.pub = ADDR: myfanout; {create :always, node: {type: topic,
> x-declare: { type: fanout}}}
> {noformat}
> The problem does not occur if a subject is used e.g. myfanout/myfanout; ...
> or if the address does not include the _options_ part.
> {noformat}
> 12:37:40.195 [Dispatcher-2-Conn-2] ERROR o.a.qpid.client.BasicMessageConsumer
> - Caught exception (dump follows) - ignoring...
> java.lang.IllegalArgumentException: routing/binding key must not be null
> at
> org.apache.qpid.client.AMQDestination.(AMQDestination.java:379)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQDestination.(AMQDestination.java:369)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQDestination.(AMQDestination.java:363)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at org.apache.qpid.client.AMQTopic.(AMQTopic.java:66)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession_0_8$TopicDestinationCache.newDestination(AMQSession_0_8.java:1528)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession_0_8$TopicDestinationCache.newDestination(AMQSession_0_8.java:1524)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession_0_8$DestinationCache.getDestination(AMQSession_0_8.java:1515)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.AMQMessageDelegate_0_8.(AMQMessageDelegate_0_8.java:127)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.AbstractJMSMessageFactory.create08MessageWithBody(AbstractJMSMessageFactory.java:122)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.AbstractJMSMessageFactory.createMessage(AbstractJMSMessageFactory.java:188)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.MessageFactoryRegistry.createMessage(MessageFactoryRegistry.java:126)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:156)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:47)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:726)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3662)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3594)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.access$1300(AMQSession.java:3362)
> [qpid-client-6.1.1.jar:6.1.1]
> at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3355)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3504)
> [qpid-client-6.1.1.jar:6.1.1]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apach
[jira] [Updated] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7707: - Priority: Minor (was: Major) > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. > This is a UI issue only. The underlying REST API operation is reporting the > failure correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operat
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926253#comment-15926253 ] Alex Rudyy edited comment on QPID-7707 at 3/15/17 2:30 PM: --- The changes look reasonable to me. Please merge them into 6.x branches was (Author: alex.rufous): The changes look reasonable to me > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. > This is a UI issue only. The underlying REST API operation is reporting the > failure correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7707: - Status: Reviewable (was: In Progress) > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7680) Isolate 0-10 Xid to the 0-10 protocol layer
[
https://issues.apache.org/jira/browse/QPID-7680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7680.
Resolution: Fixed
> Isolate 0-10 Xid to the 0-10 protocol layer
> ---
>
> Key: QPID-7680
> URL: https://issues.apache.org/jira/browse/QPID-7680
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently the {{Xid}} class of the 0-10 protocol layer leaks into the
> {{DtxRegistry}} and associated classes in the Broker's core. This prevents
> the 0-10 protocol classes being moved out to the plugin.
> Refactor DTX so that Xid used is protocol neutral.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-7707: Assignee: Keith Wall > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926253#comment-15926253 ] Alex Rudyy commented on QPID-7707: -- The changes look reasonable to me > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. > This is a UI issue only. The underlying REST API operation is reporting the > failure correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7707: - Description: Error to reload ACL should be reported back to the user invoking the operation. Otherwise, the user can be misled and assume that operation was completed successful. The broker logs need to be examined in order to verify that operation was successful. This is a UI issue only. The underlying REST API operation is reporting the failure correctly. was:Error to reload ACL should be reported back to the user invoking the operation. Otherwise, the user can be misled and assume that operation was completed successful. The broker logs need to be examined in order to verify that operation was successful. > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. > This is a UI issue only. The underlying REST API operation is reporting the > failure correctly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7707: - Fix Version/s: qpid-java-broker-7.0.0 qpid-java-6.1.2 > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy > Fix For: qpid-java-6.1.2, qpid-java-broker-7.0.0 > > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926243#comment-15926243 ] ASF subversion and git services commented on QPID-7707: --- Commit 1787052 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1787052 ] QPID-7707: [Web Management Console] Ensure that failure of the ACL reload or ManagedCertificate deletion is directed to the XHR error handler > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7692) [0-8..0-91] Message sent to fanout exchange with no routing key is not delivered to application
[
https://issues.apache.org/jira/browse/QPID-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7692.
--
Resolution: Fixed
The changes look reasonable to me. We need to merge them into 6.1.x
> [0-8..0-91] Message sent to fanout exchange with no routing key is not
> delivered to application
>
>
> Key: QPID-7692
> URL: https://issues.apache.org/jira/browse/QPID-7692
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1.2, qpid-java-client-0-x-6.3.0
>
>
> If I publish a message to the fanout exchange with no routing key, then
> receive the same message, the client logs an error and the application fails
> to receive the message both otherwise continues. The problem only occurs on
> the 0-8..0-91 code path and then only if the client is in BURL default
> address syntax.
> Example publish address that causes the problem:
> {noformat}
> destination.pub = ADDR: myfanout; {create :always, node: {type: topic,
> x-declare: { type: fanout}}}
> {noformat}
> The problem does not occur if a subject is used e.g. myfanout/myfanout; ...
> or if the address does not include the _options_ part.
> {noformat}
> 12:37:40.195 [Dispatcher-2-Conn-2] ERROR o.a.qpid.client.BasicMessageConsumer
> - Caught exception (dump follows) - ignoring...
> java.lang.IllegalArgumentException: routing/binding key must not be null
> at
> org.apache.qpid.client.AMQDestination.(AMQDestination.java:379)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQDestination.(AMQDestination.java:369)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQDestination.(AMQDestination.java:363)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at org.apache.qpid.client.AMQTopic.(AMQTopic.java:66)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession_0_8$TopicDestinationCache.newDestination(AMQSession_0_8.java:1528)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession_0_8$TopicDestinationCache.newDestination(AMQSession_0_8.java:1524)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession_0_8$DestinationCache.getDestination(AMQSession_0_8.java:1515)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.AMQMessageDelegate_0_8.(AMQMessageDelegate_0_8.java:127)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.AbstractJMSMessageFactory.create08MessageWithBody(AbstractJMSMessageFactory.java:122)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.AbstractJMSMessageFactory.createMessage(AbstractJMSMessageFactory.java:188)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.MessageFactoryRegistry.createMessage(MessageFactoryRegistry.java:126)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:156)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:47)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:726)
> ~[qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3662)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3594)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.access$1300(AMQSession.java:3362)
> [qpid-client-6.1.1.jar:6.1.1]
> at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3355)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
> [qpid-client-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3504)
> [qpid-client-6.1.1.jar:6.1.1]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-727) qdmanage identity reporting and lookup are broken
[
https://issues.apache.org/jira/browse/DISPATCH-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-727.
Resolution: Duplicate
Fix Version/s: 0.8.0
> qdmanage identity reporting and lookup are broken
> -
>
> Key: DISPATCH-727
> URL: https://issues.apache.org/jira/browse/DISPATCH-727
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 0.8.0
>
>
> This may be a duplicate, but I want to make sure it doesn't get lost.
> On master commit=81eee44, some entities (I tried router) cannot be looked up
> by their identity.
> {code}
> [aconway@wallace dispatch2 (master=)]$ qdmanage query --type=router
> [
> {
> "connectionCount": 3,
> "autoLinkCount": 0,
> "name": "Router.A",
> "area": "0",
> "linkCount": 4,
> "linkRouteCount": 0,
> "addrCount": 5,
> "routerId": "Router.A",
> "version": "0.8.0",
> "mode": "standalone",
> "nodeCount": 0,
> "type": "org.apache.qpid.dispatch.router",
> "id": "Router.A",
> "identity": "1"
> }
> ]
> [aconway@wallace dispatch2 (master=)]$ qdmanage read --identity=1
> NotFoundStatus: No entity with identity='1'
> [aconway@wallace dispatch2 (master=)]$ git log -1
> 81eee44 DISPATCH-622 - Use -lpthread compile option for Solaris
> {code}
> Some identity lookups do work e.g. `qdmanage read
> --identity=allocator/qdr_general_work_t` - I think it is the numerical
> identities generated by C that are not working.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid JMS 0.21.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid JMS 0.21.0. This is the latest release of our newer JMS client supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org), based around the Apache Qpid Proton protocol engine and implementing the AMQP JMS Mapping as it evolves at OASIS. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-jms-0.21.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-270) update to proton-j 0.18.0
[ https://issues.apache.org/jira/browse/QPIDJMS-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-270. Resolution: Fixed > update to proton-j 0.18.0 > - > > Key: QPIDJMS-270 > URL: https://issues.apache.org/jira/browse/QPIDJMS-270 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.21.0 > > > update to proton-j 0.18.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7685) [Java Broker, BDB] AsyncRecovery and Queue#enqueue can contend for a BDB Lock potentially bringing down the broker
[
https://issues.apache.org/jira/browse/QPID-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7685.
--
Resolution: Fixed
The changes look good to me
> [Java Broker, BDB] AsyncRecovery and Queue#enqueue can contend for a BDB Lock
> potentially bringing down the broker
> --
>
> Key: QPID-7685
> URL: https://issues.apache.org/jira/browse/QPID-7685
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0.6, qpid-java-6.1.1,
> qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Critical
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
>
> This is the scenario:
> BDB message store.
> AsyncRecovery completes recovery of queue Q1. Queue Q2 is still being
> recovered.
> An transacted application sends a message to Q1 but does not commit the
> transaction. This ends up creating an entry in the {{DeliveryDb}} through the
> following call chain:
> > AMQChannel#deliverCurrentMessageIfComplete
> --> AbstractExchange#send
> > LocalTransaction#enqueue(List, EnqueueableMessage,
> ServerTransaction.Action)
> --> AbstractBDBMessageStore.BDBTransaction#enqueueMessage
> > AbstractBDBMessageStore#enqueueMessage
> --> getDeliveryDb().put
> The transaction will hold a write lock on this new DB entry until the
> transaction is committed.
> If it now happens that this entry appears immediately after the last entry of
> Q2 in the database the recovery code will try to read that entry in
> {{AbstractBDBMessageStore#visitMessageInstances(TransactionLogResource,
> MessageInstanceHandler)}}:
> {{cursor.getNext(key, value, LockMode.DEFAULT)}}
> Acquisition of the read lock will timeout after {{je.lock.timeout}} (default:
> 500ms) and after exhaustion of the retries (hard coded to 5) a
> {{StoreException}} will be thrown bringing down the broker with the following
> stack trace (from a broker derived from 0.32):
> {noformat}
>
> #
> # Unhandled Exception
> com.google.common.util.concurrent.UncheckedExecutionException:
> org.apache.qpid.server.store.StoreException: Cannot visit messages in Thread
> pool-2-thread-1
> #
> # Exiting
> #
>
> com.google.common.util.concurrent.UncheckedExecutionException:
> org.apache.qpid.server.store.StoreException: Cannot visit messages
> at
> com.google.common.util.concurrent.Futures.wrapAndThrowUnchecked(Futures.java:1358)
> at
> com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1344)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$4.run(AbstractVirtualHost.java:1619)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.qpid.server.store.StoreException: Cannot visit messages
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.handleDatabaseException(StandardEnvironmentFacade.java:369)
> at
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.sleepOrThrowOnLockConflict(AbstractBDBMessageStore.java:665)
> at
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.visitMessageInstances(AbstractBDBMessageStore.java:233)
> at
> org.apache.qpid.server.virtualhost.AsynchronousMessageStoreRecoverer$AsynchronousRecoverer.recoverQueue(AsynchronousMessageStoreRecoverer.java:163)
> at
> org.apache.qpid.server.virtualhost.AsynchronousMessageStoreRecoverer$AsynchronousRecoverer.access$900(AsynchronousMessageStoreRecoverer.java:86)
> at
> org.apache.qpid.server.virtualhost.AsynchronousMessageStoreRecoverer$AsynchronousRecoverer$QueueRecoveringTask.run(AsynchronousMessageStoreRecoverer.java:436)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ... 3 more
> Caused by: com.sleepycat.je.LockTimeoutException: (JE 5.0.104) Lock expired.
> Locker 2109822146 -1_Queue Recoverer : Q2 (vh: def
[jira] [Resolved] (QPID-7675) [Java Broker] Runtime exception can be thrown by REST API on failure to create BDB HA Virtual Host Node
[
https://issues.apache.org/jira/browse/QPID-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7675.
--
Resolution: Fixed
The changes look good to me
> [Java Broker] Runtime exception can be thrown by REST API on failure to
> create BDB HA Virtual Host Node
> ---
>
> Key: QPID-7675
> URL: https://issues.apache.org/jira/browse/QPID-7675
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.0.6,
> qpid-java-6.1, qpid-java-6.1.1
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7675-Java-Broker-Improve-handling-and-reporting.patch
>
>
> RuntimeException is occasionally thrown on creation of BDB HA Virtual Host
> using REST API when validation of existing node in group fails. The stack
> trace is provided below:
> {noformat}
> java.lang.RuntimeException: Cannot retrieve state for node 'myNode'
> (localhost:5000) from group 'myGroup'
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.connectToHelperNodeAndCheckPermittedHosts(ReplicatedEnvironmentFacade.java:1858)
> ~[qpid-bdbstore-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.getPermittedNodesFromHelper(BDBHAVirtualHostNodeImpl.java:564)
> ~[qpid-bdbstore-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.validateOnCreate(BDBHAVirtualHostNodeImpl.java:544)
> ~[qpid-bdbstore-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:847)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:834)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:625)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:145)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:624)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.createAsync(AbstractConfiguredObject.java:833)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.createAsync(AbstractConfiguredObjectTypeFactory.java:76)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.createAsync(ConfiguredObjectFactoryImpl.java:125)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.BrokerImpl.createVirtualHostNodeAsync(BrokerImpl.java:601)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.BrokerImpl.addChildAsync(BrokerImpl.java:655)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2066)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2061)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:625)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
> ~[qpid-broker-core-6.1.1.jar:6.1.1]
> at java.security.AccessController.doPrivileged(Native
[jira] [Resolved] (QPID-7684) [Java Broker, BDB] Close Cursor when LockConflictException is thrown
[
https://issues.apache.org/jira/browse/QPID-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7684.
--
Resolution: Fixed
The changes look good to me
> [Java Broker, BDB] Close Cursor when LockConflictException is thrown
>
>
> Key: QPID-7684
> URL: https://issues.apache.org/jira/browse/QPID-7684
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.32, qpid-java-6.0.6, qpid-java-6.1.1,
> qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
>
> Currently, when a LockConflictException is thrown we retry the operation.
> However the retry logic does not adhere to the rules outlined in the BDB JE
> documentation, specifically we do not close and recreate the Cursor.
> To quote the
> [documentation|https://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/LockConflictException.html]:
> {quote}If a lock conflict occurs during a transaction, the transaction may be
> retried by performing the following steps. \[...\]:
> # Close all cursors opened under the transaction.
> # Abort the transaction.
> # Begin a new transaction and repeat the operations.
> {quote}
> The impact of not doing this is unclear.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7695) [HA] Indefinite hang when new node joins existing group but existing node is unresponsive
[
https://issues.apache.org/jira/browse/QPID-7695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7695.
--
Resolution: Fixed
The changes look good to me
> [HA] Indefinite hang when new node joins existing group but existing node is
> unresponsive
> -
>
> Key: QPID-7695
> URL: https://issues.apache.org/jira/browse/QPID-7695
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2, qpid-java-broker-7.0.0
>
>
> When adding a new node to an existing group, internally Qpid uses
> com.sleepycat.je.rep.util.DbPing#DbPing() to establish initial contact with
> the node and perform some preliminary checks. If this node is somehow
> unresponsive, Qpid (the Broker's Confif Thread) hangs indefinitely and is
> unrecoverable. BDB JE 5.0.104 is in use.
> The Broker Config thread stack trace looks like this:
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.read0(FileDispatcherImpl.java:-1)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> - locked <0x168d> (a java.lang.Object)
> at
> com.sleepycat.je.rep.utilint.ServiceDispatcher.doServiceHandshake(ServiceDispatcher.java:325)
> at com.sleepycat.je.rep.util.DbPing.getNodeState(DbPing.java:194)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.getRemoteNodeState(ReplicatedEnvironmentFacade.java:1807)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.connectToHelperNodeAndCheckPermittedHosts(ReplicatedEnvironmentFacade.java:1846)
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.getPermittedNodesFromHelper(BDBHAVirtualHostNodeImpl.java:566)
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.validateOnCreate(BDBHAVirtualHostNodeImpl.java:546)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:878)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:865)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:636)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:629)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:145)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.createAsync(AbstractConfiguredObject.java:864)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.createAsync(AbstractConfiguredObjectTypeFactory.java:75)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.createAsync(ConfiguredObjectFactoryImpl.java:145)
> at
> org.apache.qpid.server.model.BrokerImpl.createVirtualHostNodeAsync(BrokerImpl.java:605)
> at
> org.apache.qpid.server.model.BrokerImpl.addChildAsync(BrokerImpl.java:660)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2094)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2089)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:636)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:629)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
> at
> java.security.AccessController.doPrivileged(AccessController.java:-1)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapp
[jira] [Resolved] (QPID-7696) [Java Broker] Deletion of a temporary queue can crash the broker with certain ACLs
[
https://issues.apache.org/jira/browse/QPID-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7696.
--
Resolution: Fixed
Fix Version/s: qpid-java-6.0.7
> [Java Broker] Deletion of a temporary queue can crash the broker with certain
> ACLs
> --
>
> Key: QPID-7696
> URL: https://issues.apache.org/jira/browse/QPID-7696
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.1.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.0.7, qpid-java-6.1.2
>
> Attachments:
> QPID-7696-remove-queue-bindings-on-queue-deletion-regardless-availability-unbind-acl-rule.diff
>
>
> ACL:
> {noformat}
> ACL ALLOW-LOG testUser CREATE QUEUE temporary="true"
> ACL ALLOW-LOG testUser DELETE QUEUE temporary="true"
> ACL ALLOW-LOG testUser ACCESS ALL
> ACL ALLOW-LOG admin ALL ALL
> ACL DENY-LOG ALL ALL
> {noformat}
> client code:
> {code}
> /* create connection */
> Session session = connection.createSession(true,
> Session.SESSION_TRANSACTED);
> TemporaryQueue temporaryQueue = session.createTemporaryQueue();
> temporaryQueue.delete();
>/* cleanup */
> {code}
> This crashes the broker v6.1.1
> {noformat}
>
> #
> # Unhandled Exception java.security.AccessControlException: Permission DELETE
> is denied for : Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on
> Queue 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct'
> in Thread IO-/127.0.0.1:53477
> #
> # Exiting
> #
>
> java.security.AccessControlException: Permission DELETE is denied for :
> Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on Queue
> 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct'
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2959)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2891)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authoriseSetAttributes(AbstractConfiguredObject.java:2970)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1659)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:625)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:305)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Process finished with exit code 1
> {noformat}
> I have not tested with other versions of the broker, yet.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-1641) python tools need porting to native windows environment
[ https://issues.apache.org/jira/browse/QPID-1641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned QPID-1641: - Assignee: Justin Ross > python tools need porting to native windows environment > --- > > Key: QPID-1641 > URL: https://issues.apache.org/jira/browse/QPID-1641 > Project: Qpid > Issue Type: Wish > Components: C++ Tools >Affects Versions: M4 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Justin Ross >Priority: Minor > Attachments: qpid1641-1.diff > > Original Estimate: 48h > Remaining Estimate: 48h > > The commands in the python directory such as qpid-tool do not work on Windows > using Python 2.6.1 from python.org. > A workaround is to use python included in cygwin. > Some basic porting work is required, > i.e. "os.uname", socket.SSLType do not exist in the Windows version of Python > There appear to be other connection issues, but they could just be user error > on my part. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-1443) Merge updated Ruby client
[ https://issues.apache.org/jira/browse/QPID-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-1443. - Resolution: Won't Do This 0-10 impl has been superceded by our work in Qpid Proton on an AMQP 1.0 Ruby binding. > Merge updated Ruby client > - > > Key: QPID-1443 > URL: https://issues.apache.org/jira/browse/QPID-1443 > Project: Qpid > Issue Type: Improvement > Components: Ruby Client >Affects Versions: M4 > Environment: Tested with ruby-1.8.6.287-2.fc9.x86_64, should work > with older versions of Ruby, too >Reporter: David Lutterkort > Attachments: ruby-qpid.tar.gz > > > Please replace the existing Ruby client in > https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/ruby with the > updated client at http://people.redhat.com/dlutter/ruby-qpid.tar.gz [1] > The new client provides full support for AMQP 0.10 and the Qpid management > framework. If there is interest, I can also provide the git repository that > was used in the process and contains more details on how the client came > about. > The client is largely a reimplementation of the Python client. > The sources also contain a Rakefile to ease testing and packaging. To run all > tests, run a broker locally and then do 'rake test' > To package as a rubygem and/or an RPM, run 'rake package' and 'rake rpm' > This work was done by myself and Ian Main with a lot of > help from Rafael Schloming and Ted Ross > . Please include them on any communication about merging > the client - especially, since I will be on vacation next week ;) > [1] The detached GPG signature is at > http://people.redhat.com/dlutter/ruby-qpid.tar.gz.sig; signing key is > FC6E8A22, you can import that with gpg --keyserver keys.gnupg.net --recv-keys > FC6E8A22 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6946) Implement Federation for Java Broker
[ https://issues.apache.org/jira/browse/QPID-6946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-6946: -- Fix Version/s: Future > Implement Federation for Java Broker > > > Key: QPID-6946 > URL: https://issues.apache.org/jira/browse/QPID-6946 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Reporter: Karl Andersson > Fix For: Future > > > C++ Version has Federation support but as far as I know, the Java Broker > doesn't. There is a Design Proposal from 2008: > https://cwiki.apache.org/confluence/display/qpid/Java+Federation+Design+Proposal -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-946) Implement Message Federation
[ https://issues.apache.org/jira/browse/QPID-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-946. Resolution: Duplicate > Implement Message Federation > - > > Key: QPID-946 > URL: https://issues.apache.org/jira/browse/QPID-946 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Affects Versions: M2.1 >Reporter: Marnie McCormack > > Implement message federation for Java brokers. > RG to add details & a design proposal here please. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-1939) Accept user:password in python client URL
[
https://issues.apache.org/jira/browse/QPID-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned QPID-1939:
-
Assignee: Justin Ross
> Accept user:password in python client URL
> -
>
> Key: QPID-1939
> URL: https://issues.apache.org/jira/browse/QPID-1939
> Project: Qpid
> Issue Type: Improvement
> Components: Python Client
> Environment: any.
>Reporter: mARK bLOORE
>Assignee: Justin Ross
>Priority: Minor
>
> in python/qpid/util.py, lines 84-87 are
> RE = re.compile(r"""
> # [ :// ] [ [ /] @]
> [ : ]
> ^ (?: ([^:/@]+)://)? (?: ([^:/@]+) (?: / ([^:/@]+) )? @)? ([^@:/]+)
> (?: :([0-9]+))?$
> """, re.X)
> this matches user/password in a (partial) URL. it should be user:password.
> qpid.util.URL('scheme://user:pass@host:12')
> raises a ValueError.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7696) [Java Broker] Deletion of a temporary queue can crash the broker with certain ACLs
[
https://issues.apache.org/jira/browse/QPID-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926047#comment-15926047
]
ASF subversion and git services commented on QPID-7696:
---
Commit 1787039 from oru...@apache.org in branch 'java/branches/6.0.x'
[ https://svn.apache.org/r1787039 ]
QPID-7696: [Java Broker] Do not require 'unbind' permission to delete queue or
exchange
merged from 6.1.x branch using
svn merge -c 1786743 ^/qpid/java/branches/6.1.x
svn merge -c 1787035 ^/qpid/java/branches/6.1.x
merge conficts are resoved manually
> [Java Broker] Deletion of a temporary queue can crash the broker with certain
> ACLs
> --
>
> Key: QPID-7696
> URL: https://issues.apache.org/jira/browse/QPID-7696
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.1.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1.2
>
> Attachments:
> QPID-7696-remove-queue-bindings-on-queue-deletion-regardless-availability-unbind-acl-rule.diff
>
>
> ACL:
> {noformat}
> ACL ALLOW-LOG testUser CREATE QUEUE temporary="true"
> ACL ALLOW-LOG testUser DELETE QUEUE temporary="true"
> ACL ALLOW-LOG testUser ACCESS ALL
> ACL ALLOW-LOG admin ALL ALL
> ACL DENY-LOG ALL ALL
> {noformat}
> client code:
> {code}
> /* create connection */
> Session session = connection.createSession(true,
> Session.SESSION_TRANSACTED);
> TemporaryQueue temporaryQueue = session.createTemporaryQueue();
> temporaryQueue.delete();
>/* cleanup */
> {code}
> This crashes the broker v6.1.1
> {noformat}
>
> #
> # Unhandled Exception java.security.AccessControlException: Permission DELETE
> is denied for : Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on
> Queue 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct'
> in Thread IO-/127.0.0.1:53477
> #
> # Exiting
> #
>
> java.security.AccessControlException: Permission DELETE is denied for :
> Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on Queue
> 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct'
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2959)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2891)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authoriseSetAttributes(AbstractConfiguredObject.java:2970)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1659)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:625)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:305)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Process finished with exit code 1
> {noformat}
> I have not tested with other versions of the broker, yet.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7705) [Java Broker] Inconsistent ACL behaviour between various versions of Qpid Brokers when 'Unbind' privilege is required for removal of queue bindings on temporary queue
[
https://issues.apache.org/jira/browse/QPID-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-7705.
--
Resolution: Fixed
Fixed as part of QPID-7696
> [Java Broker] Inconsistent ACL behaviour between various versions of Qpid
> Brokers when 'Unbind' privilege is required for removal of queue bindings on
> temporary queue deletion
> --
>
> Key: QPID-7705
> URL: https://issues.apache.org/jira/browse/QPID-7705
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.0.6,
> qpid-java-6.1, qpid-java-6.1.1
>Reporter: Alex Rudyy
>
> With 0.32 Java Broker ACL implementation a temporary queue is allowed to be
> deleted by the owner (for example using JMS {{Session#deleteQueue()}})
> without the need for explicit grant of UNBIND privilege to the user. In Qpid
> Broker versions 6.0 and 6.1 the UNBIND privilege is required for queue
> deletion because as part of queue deletions all existing bindings are removed
> and if UNBIND is not granter the binding deletion fails causing queue
> deletion failure. In the trunk version (7.0) the UNBIND is not required ( See
> QPID-7703) for temporary queue deletion. We need to fix this ACL
> inconsistency.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7705) [Java Broker] Inconsistent ACL behaviour between various versions of Qpid Brokers when 'Unbind' privilege is required for removal of queue bindings on temporary queue d
[
https://issues.apache.org/jira/browse/QPID-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7705:
-
Affects Version/s: (was: qpid-java-broker-7.0.0)
(was: 0.32)
qpid-java-6.0.1
qpid-java-6.0.2
qpid-java-6.0.3
qpid-java-6.0.4
qpid-java-6.0.5
qpid-java-6.0.6
qpid-java-6.1.1
> [Java Broker] Inconsistent ACL behaviour between various versions of Qpid
> Brokers when 'Unbind' privilege is required for removal of queue bindings on
> temporary queue deletion
> --
>
> Key: QPID-7705
> URL: https://issues.apache.org/jira/browse/QPID-7705
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.0.6,
> qpid-java-6.1, qpid-java-6.1.1
>Reporter: Alex Rudyy
>
> With 0.32 Java Broker ACL implementation a temporary queue is allowed to be
> deleted by the owner (for example using JMS {{Session#deleteQueue()}})
> without the need for explicit grant of UNBIND privilege to the user. In Qpid
> Broker versions 6.0 and 6.1 the UNBIND privilege is required for queue
> deletion because as part of queue deletions all existing bindings are removed
> and if UNBIND is not granter the binding deletion fails causing queue
> deletion failure. In the trunk version (7.0) the UNBIND is not required ( See
> QPID-7703) for temporary queue deletion. We need to fix this ACL
> inconsistency.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7703) [Java Broker] 'Unbind' privilege is not checked for removal of queue bindings on queue deletion
[ https://issues.apache.org/jira/browse/QPID-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7703. -- Resolution: Invalid The unbind permission should not be required for queue deletion if queue delete permission is granted. The trunk already exhibits this behaviour and the changes made against QPID-7696 fixed 6.1.x and 6.0.x branches to stop requiring 'unbind' privilege for queue and exchange deletion > [Java Broker] 'Unbind' privilege is not checked for removal of queue > bindings on queue deletion > > > Key: QPID-7703 > URL: https://issues.apache.org/jira/browse/QPID-7703 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Alex Rudyy > > As part of changes in QPID-6028 the queue binding implementation was changed > and responsibilities to create and remove bindings were moved into Exchange > operations 'bind' and 'unbind' accordingly. The exchanges are now > responsible for performing authorization checks for 'bind' and 'unbind' > operations. However, on queue deletion, the queue bindings are removed > without performing 'unbind' authorization checks which is a change in > behaviour comparing with previous 6.x releases. We need to decide whether we > need to restore previous behaviour and enforce 'unbind' ACL check on queue > deletion or keep existing functionality. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7703) [Java Broker] 'Unbind' privilege is not checked for removal of queue bindings on queue deletion
[ https://issues.apache.org/jira/browse/QPID-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7703: - Affects Version/s: (was: qpid-java-broker-7.0.0) > [Java Broker] 'Unbind' privilege is not checked for removal of queue > bindings on queue deletion > > > Key: QPID-7703 > URL: https://issues.apache.org/jira/browse/QPID-7703 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Alex Rudyy > > As part of changes in QPID-6028 the queue binding implementation was changed > and responsibilities to create and remove bindings were moved into Exchange > operations 'bind' and 'unbind' accordingly. The exchanges are now > responsible for performing authorization checks for 'bind' and 'unbind' > operations. However, on queue deletion, the queue bindings are removed > without performing 'unbind' authorization checks which is a change in > behaviour comparing with previous 6.x releases. We need to decide whether we > need to restore previous behaviour and enforce 'unbind' ACL check on queue > deletion or keep existing functionality. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7696) [Java Broker] Deletion of a temporary queue can crash the broker with certain ACLs
[
https://issues.apache.org/jira/browse/QPID-7696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925959#comment-15925959
]
ASF subversion and git services commented on QPID-7696:
---
Commit 1787035 from oru...@apache.org in branch 'java/branches/6.1.x'
[ https://svn.apache.org/r1787035 ]
QPID-7696: [Java Broker] Do not require 'unbind' permission to delete queue or
exchange
> [Java Broker] Deletion of a temporary queue can crash the broker with certain
> ACLs
> --
>
> Key: QPID-7696
> URL: https://issues.apache.org/jira/browse/QPID-7696
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.1.1
>Reporter: Lorenz Quack
> Fix For: qpid-java-6.1.2
>
> Attachments:
> QPID-7696-remove-queue-bindings-on-queue-deletion-regardless-availability-unbind-acl-rule.diff
>
>
> ACL:
> {noformat}
> ACL ALLOW-LOG testUser CREATE QUEUE temporary="true"
> ACL ALLOW-LOG testUser DELETE QUEUE temporary="true"
> ACL ALLOW-LOG testUser ACCESS ALL
> ACL ALLOW-LOG admin ALL ALL
> ACL DENY-LOG ALL ALL
> {noformat}
> client code:
> {code}
> /* create connection */
> Session session = connection.createSession(true,
> Session.SESSION_TRANSACTED);
> TemporaryQueue temporaryQueue = session.createTemporaryQueue();
> temporaryQueue.delete();
>/* cleanup */
> {code}
> This crashes the broker v6.1.1
> {noformat}
>
> #
> # Unhandled Exception java.security.AccessControlException: Permission DELETE
> is denied for : Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on
> Queue 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct'
> in Thread IO-/127.0.0.1:53477
> #
> # Exiting
> #
>
> java.security.AccessControlException: Permission DELETE is denied for :
> Binding 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' on Queue
> 'TempQueuec64ba00d-9b7c-44f2-9217-80c954234ce4' Exchange 'amq.direct'
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2959)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authorise(AbstractConfiguredObject.java:2891)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.authoriseSetAttributes(AbstractConfiguredObject.java:2970)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1659)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:625)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:305)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Process finished with exit code 1
> {noformat}
> I have not tested with other versions of the broker, yet.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7710) Java Broker] Json configuration store can only save one binding with the same rooting key per queue
[ https://issues.apache.org/jira/browse/QPID-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7710: - Affects Version/s: (was: qpid-java-6.0.6) (was: qpid-java-6.0.5) (was: qpid-java-6.0.4) (was: qpid-java-6.0.3) (was: qpid-java-6.0.1) (was: qpid-java-6.0) qpid-java-6.1.2 > Java Broker] Json configuration store can only save one binding with the same > rooting key per queue > --- > > Key: QPID-7710 > URL: https://issues.apache.org/jira/browse/QPID-7710 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2 >Reporter: Alex Rudyy > > Creating two queue bindings with the same routing key to different exchanges > results in saving only one of them in json configuration store -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7710) Java Broker] Json configuration store can only save one binding with the same rooting key per queue
[ https://issues.apache.org/jira/browse/QPID-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7710: - Affects Version/s: (was: qpid-java-broker-7.0.0) > Java Broker] Json configuration store can only save one binding with the same > rooting key per queue > --- > > Key: QPID-7710 > URL: https://issues.apache.org/jira/browse/QPID-7710 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.3, > qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.0.6, qpid-java-6.1, > qpid-java-6.1.1 >Reporter: Alex Rudyy > > Creating two queue bindings with the same routing key to different exchanges > results in saving only one of them in json configuration store -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7710) Java Broker] Json configuration store can only save one binding with the same rooting key per queue
[ https://issues.apache.org/jira/browse/QPID-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925938#comment-15925938 ] Rob Godfrey commented on QPID-7710: --- Does this really affect trunk and 6.x? Bindings on trunk are stored completely differently (since they are no longer a configured object). > Java Broker] Json configuration store can only save one binding with the same > rooting key per queue > --- > > Key: QPID-7710 > URL: https://issues.apache.org/jira/browse/QPID-7710 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.3, > qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.0.6, qpid-java-6.1, > qpid-java-6.1.1 >Reporter: Alex Rudyy > > Creating two queue bindings with the same routing key to different exchanges > results in saving only one of them in json configuration store -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7710) Java Broker] Json configuration store can only save one binding with the same rooting key per queue
Alex Rudyy created QPID-7710: Summary: Java Broker] Json configuration store can only save one binding with the same rooting key per queue Key: QPID-7710 URL: https://issues.apache.org/jira/browse/QPID-7710 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-6.1.1, qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.0.5, qpid-java-6.0.4, qpid-java-6.0.3, qpid-java-6.0.1, qpid-java-6.0, qpid-java-broker-7.0.0 Reporter: Alex Rudyy Creating two queue bindings with the same routing key to different exchanges results in saving only one of them in json configuration store -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7707) [Java Broker, Web Management Console] If ACL reload operation fails due to malformed ACL rules, etc, the error is not reported back to the user invoking the operation
[ https://issues.apache.org/jira/browse/QPID-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7707: - Description: Error to reload ACL should be reported back to the user invoking the operation. Otherwise, the user can be misled and assume that operation was completed successful. The broker logs need to be examined in order to verify that operation was successful. (was: Error to reload ACL should be reported back to the user invoking the operation. Otherwise, the user can be misleaded and assume that operation was completed successful. The broker logs need to be examined in order to verify that operation was successful.) > [Java Broker, Web Management Console] If ACL reload operation fails due to > malformed ACL rules, etc, the error is not reported back to the user invoking > the operation > --- > > Key: QPID-7707 > URL: https://issues.apache.org/jira/browse/QPID-7707 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0 >Reporter: Alex Rudyy > > Error to reload ACL should be reported back to the user invoking the > operation. Otherwise, the user can be misled and assume that operation was > completed successful. The broker logs need to be examined in order to verify > that operation was successful. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4087) Add payload compression to qpid client libraries
[ https://issues.apache.org/jira/browse/QPID-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925874#comment-15925874 ] Rob Godfrey commented on QPID-4087: --- For the Java client message compression was added in QPID-6000 (although it will only be used if the server advertises support for it) - support for message compression is only available in the AMQP 0-8/9/9-1/10 protocols, and not AMQP 1.0 > Add payload compression to qpid client libraries > > > Key: QPID-4087 > URL: https://issues.apache.org/jira/browse/QPID-4087 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Reporter: Noel O'Connor > > Add a configurable compression option to the AMQP binding URL which would > turn on compression on the client for both producers and receivers. A > configurable threshold value could also be added to ensure that compression > is only done on a certain payload size or greater. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4087) Add payload compression to qpid client libraries
[ https://issues.apache.org/jira/browse/QPID-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-4087: -- Component/s: (was: Java Client) > Add payload compression to qpid client libraries > > > Key: QPID-4087 > URL: https://issues.apache.org/jira/browse/QPID-4087 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Reporter: Noel O'Connor > > Add a configurable compression option to the AMQP binding URL which would > turn on compression on the client for both producers and receivers. A > configurable threshold value could also be added to ensure that compression > is only done on a certain payload size or greater. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7459) ProducerFlowControlTest#testSendTimeout test fails sprodically on 0-10 profiles
[
https://issues.apache.org/jira/browse/QPID-7459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15925843#comment-15925843
]
Keith Wall commented on QPID-7459:
--
And a repeat ..
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-BrokerForJava-Test-IBMJDK1.8/2004/testReport/junit/org.apache.qpid.server.queue/ProducerFlowControlTest/testCapacityExceededCausesBlock/
> ProducerFlowControlTest#testSendTimeout test fails sprodically on 0-10
> profiles
> ---
>
> Key: QPID-7459
> URL: https://issues.apache.org/jira/browse/QPID-7459
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Keith Wall
>Priority: Minor
> Attachments:
> TEST-org.apache.qpid.server.queue.ProducerFlowControlTest.testSendTimeout.txt
>
>
> ProducerFlowControlTest#testSendTimeout test fails sprodically on 0-10
> profiles.
> The test is racey. The test relies on message n-1 causing flow control to be
> imposed before the test can try to send message n. If flow control is not
> imposed before the client tries to send message n, the test will fail. In
> the failing case the client has not processed the incoming MessageStop before
> it sends message n. The test tries tries to prevent this by sync'ing twice.
> This approach is ineffective for 0-10 as the send sync to optimised out and
> does not caused an ExecutionSync.
> The test issue does not affect the usefulness of the feature itself.
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-Test-JDK1.8/1801/artifact/trunk/systests/target/surefire-reports/java-mms.0-10/
> {noformat}
> junit.framework.AssertionFailedError: No timeout exception on sending
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertNotNull(Assert.java:256)
> at junit.framework.TestCase.assertNotNull(TestCase.java:426)
> at
> org.apache.qpid.server.queue.ProducerFlowControlTest.testSendTimeout(ProducerFlowControlTest.java:284)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7458) ProducerFlowControlTest#testSendTimeout test fails sprodically on 0-10 profiles
[
https://issues.apache.org/jira/browse/QPID-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-7458.
--
Resolution: Duplicate
> ProducerFlowControlTest#testSendTimeout test fails sprodically on 0-10
> profiles
> ---
>
> Key: QPID-7458
> URL: https://issues.apache.org/jira/browse/QPID-7458
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Keith Wall
>Priority: Minor
>
> ProducerFlowControlTest#testSendTimeout test fails sprodically on 0-10
> profiles.
> The test is racey. The test relies on message n-1 causing flow control to be
> imposed before the test can try to send message n. If flow control is not
> imposed before the client tries to send message n, the test will fail. In
> the failing case the client has not processed the incoming MessageStop before
> it sends message n. The test tries tries to prevent this by sync'ing twice.
> This approach is ineffective for 0-10 as the send sync to optimised out and
> does not caused an ExecutionSync.
> The test issue does not affect the usefulness of the feature itself.
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-Test-JDK1.8/1801/artifact/trunk/systests/target/surefire-reports/java-mms.0-10/
> {noformat}
> junit.framework.AssertionFailedError: No timeout exception on sending
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertNotNull(Assert.java:256)
> at junit.framework.TestCase.assertNotNull(TestCase.java:426)
> at
> org.apache.qpid.server.queue.ProducerFlowControlTest.testSendTimeout(ProducerFlowControlTest.java:284)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
