Review Request 44805: PROTON-1138: c++: get<>/convert<> for proton::value
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44805/ --- Review request for qpid, Andrew Stitcher, Cliff Jansen, and Justin Ross. Repository: qpid-proton-git Description --- Provide free get<> and convert<> template functions to get the exact type from a proton::value or to convert from the contained type if allowed. Retained get members for backwards compatibility but marked deprecated. Note, scalar is not done yet but will follow the same pattern, get your comments in now. Diffs - examples/cpp/direct_recv.cpp ffb2f03cf4df9517158f6b0e5d8e3ad387a6 examples/cpp/encode_decode.cpp 12fc1ed1ace5af84dbf67995ad7059d3df04350e examples/cpp/engine/server.cpp 4641c4cb20b3c4bff4246649c2ee0929d14f3c35 examples/cpp/server.cpp 8ac34ccb65bd90ee81c3271c633d34f828b067f2 examples/cpp/server_direct.cpp 9d3b79c9531762a4a84c47dc9c9ede9cc32e09fd proton-c/bindings/cpp/include/proton/data.hpp 3d391541a849b4cc203145eba279daa07a3638f8 proton-c/bindings/cpp/include/proton/decoder.hpp 9a835c09c64f03cb07aaf66ff29b78ecf95f496d proton-c/bindings/cpp/include/proton/value.hpp e0b73176507b4ddca1fdf8b3e6f72c7ea37a933a proton-c/bindings/cpp/src/decoder.cpp 890fac5eae9a4bad38223e1811fc17c2a1db6cff proton-c/bindings/cpp/src/interop_test.cpp b05c098f4944f88b4a893c3d38451e6eebaf22d7 proton-c/bindings/cpp/src/message_test.cpp 8c1e585d42fe757b953a8ffb1a9ffe2b7567f9f5 proton-c/bindings/cpp/src/scalar_test.cpp 9b2df1f6c8f8debd6bbee203fce8e9342f539dac proton-c/bindings/cpp/src/value.cpp bece42c66c8b7394d29a2212a1b021ccfb552eb7 proton-c/bindings/cpp/src/value_test.cpp be24da430cf76ac698e89fc57442c4cff30beae2 tests/tools/apps/cpp/reactor_send.cpp 3ba26e8aa608b6b218ec94d300b4dfd7da173eb8 Diff: https://reviews.apache.org/r/44805/diff/ Testing --- ctest -R cpp Thanks, Alan Conway
[jira] [Commented] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194151#comment-15194151
]
Timothy Bish commented on QPIDJMS-154:
--
You should be able to build your own snapshot now and it should retry against
the alternate host.
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
>Assignee: Timothy Bish
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
> ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
> amqp://localhost:5672
> 2016-03-11 11:04:42 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsSessionInfo {} (2)
> {code}
> *_Test code:_*
> {code:java}
> @Test
[jira] [Commented] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194146#comment-15194146
]
ASF subversion and git services commented on QPIDJMS-154:
-
Commit 15f6446ac0bda96230c9dbe0f54b7495911363b6 in qpid-jms's branch
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=15f6446 ]
QPIDJMS-154 Don't pass along a JMSException on connect so that attempts
to connect can continue until stopped by user or by configuration.
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
>Assignee: Timothy Bish
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
>
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[ https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194136#comment-15194136 ] ASF GitHub Bot commented on DISPATCH-179: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/60 DISPATCH-179 - Added code to update router.link type You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch tross-DISPATCH-179-1-LINK-UPDATE-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/60.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #60 commit b07e9f54aeaeeab85048319e524b4828c620cce7 Author: Ganesh Murthy Date: 2016-03-14T19:47:05Z DISPATCH-179 - Added code to update router.link type > Refactor Router Core > > > Key: DISPATCH-179 > URL: https://issues.apache.org/jira/browse/DISPATCH-179 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6 > > > Refactor the core router function to clean up the architecture and to fix the > significant lock contention issue that exists in 0.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-179 - Added code to update ro...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/60 DISPATCH-179 - Added code to update router.link type You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch tross-DISPATCH-179-1-LINK-UPDATE-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/60.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #60 commit b07e9f54aeaeeab85048319e524b4828c620cce7 Author: Ganesh Murthy Date: 2016-03-14T19:47:05Z DISPATCH-179 - Added code to update router.link type --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[ https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194130#comment-15194130 ] ASF GitHub Bot commented on DISPATCH-179: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/59 > Refactor Router Core > > > Key: DISPATCH-179 > URL: https://issues.apache.org/jira/browse/DISPATCH-179 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6 > > > Refactor the core router function to clean up the architecture and to fix the > significant lock contention issue that exists in 0.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-179 - Added code to update ro...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/59 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[
https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194076#comment-15194076
]
ASF GitHub Bot commented on DISPATCH-179:
-
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/59#discussion_r56071049
--- Diff: src/router_core/agent_link.c ---
@@ -229,3 +242,185 @@ void qdra_link_get_next_CT(qdr_core_t *core,
qdr_query_t *query)
//
qdr_agent_enqueue_response_CT(core, query);
}
+
+
+static void qdr_manage_write_response_map_CT(qd_composed_field_t *body,
qdr_link_t *link)
+{
+qd_compose_start_map(body);
+
+for(int i = 0; i < QDR_LINK_COLUMN_COUNT; i++) {
+qd_compose_insert_string(body, qdr_link_columns[i]);
+qdr_agent_write_column_CT(body, i, link);
+}
+
+qd_compose_end_map(body);
+}
+
+
+static qdr_link_t *qdr_link_find_by_identity(qdr_core_t *core,
qd_field_iterator_t *identity)
+{
+if (!identity)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+char id[100];
+if (link->identifier) {
+snprintf(id, 100, "%ld", link->identifier);
+if (qd_field_iterator_equal(identity, (const unsigned char
*)id))
+break;
+}
+link = DEQ_NEXT(link);
+}
+
+return link;
+
+}
+
+
+static qdr_link_t *qdr_link_find_by_name(qdr_core_t *core,
qd_field_iterator_t *name)
+{
+if(!name)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+if (link->name && qd_field_iterator_equal(name, (const unsigned
char *)link->name))
+break;
+link = DEQ_NEXT(link);
+}
+
+return link;
+}
+
+
+/**
+ * The body map containing any attributes that are not applicable for the
entity being updated
+ * MUST result in a failure response with a statusCode of 400 (Bad
Request).
+ * TODO - Generalize this function so that all update functions can use it.
+ */
+static qd_error_t qd_is_update_request_valid(qd_router_entity_type_t
entity_type,
+ qd_parsed_field_t *in_body)
+{
+qd_error_clear();
+if(in_body != 0 && qd_parse_is_map(in_body)) {
+int j=0;
+qd_parsed_field_t *field = qd_parse_sub_key(in_body, j);
+
+while (field) {
+bool found = false;
+
+qd_field_iterator_t *iter = qd_parse_raw(field);
+
+for(int i = 1; i < QDR_LINK_COLUMN_COUNT; i++) {
+if (qd_field_iterator_equal(iter, (unsigned
char*)qdr_link_columns[i])) {
+found = true;
+break;
+}
+}
+if (!found) {// Some bad field was specified in the body map.
Reject this request
+int field_len = qd_field_iterator_length(iter);
+// lenth of "Invalid Column Name :" + '\0' is 22
+char error_message[22 + field_len];
+snprintf(error_message, 22, "Invalid Column Name: ");
+char octet = qd_field_iterator_octet(iter);
+int i = 0;
+while (octet) {
+char *spot = &error_message[21+i];
+snprintf(spot, 2, &octet);
+octet = qd_field_iterator_octet(iter);
+i++;
+}
+return qd_error(QD_ERROR_MESSAGE, "%s", error_message);
+}
+
+j++;
+
+//Get the next field in the body
+field = qd_parse_sub_key(in_body, j);
+}
+}
+else
+return qd_error(QD_ERROR_MESSAGE, "%s", "Message body is not a
map"); // The body is either empty or the body is not a map, return false
+
+return QD_ERROR_NONE;
+}
+
+
+static void qdra_link_update_set_status(qdr_core_t *core, qdr_query_t
*query, qdr_link_t *link)
+{
+if (link) {
+//link->admin_state = qd_field_iterator_copy(adm_state);
+qdr_manage_write_response_map_CT(query->body, link);
+query->status = QD_AMQP_OK;
+}
+else {
+query->status = QD_AMQP_NOT_FOUND;
+qd_compose_start_map(query->body);
+qd_compose_end_map(query->body);
+}
+}
+
+static void qdra_link_set_bad_request(qdr_query_t *query)
+{
+query->status = QD_AMQP_BAD_REQUEST;
+qd_compose_start_map(query->body);
[GitHub] qpid-dispatch pull request: DISPATCH-179 - Added code to update ro...
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/59#discussion_r56071049
--- Diff: src/router_core/agent_link.c ---
@@ -229,3 +242,185 @@ void qdra_link_get_next_CT(qdr_core_t *core,
qdr_query_t *query)
//
qdr_agent_enqueue_response_CT(core, query);
}
+
+
+static void qdr_manage_write_response_map_CT(qd_composed_field_t *body,
qdr_link_t *link)
+{
+qd_compose_start_map(body);
+
+for(int i = 0; i < QDR_LINK_COLUMN_COUNT; i++) {
+qd_compose_insert_string(body, qdr_link_columns[i]);
+qdr_agent_write_column_CT(body, i, link);
+}
+
+qd_compose_end_map(body);
+}
+
+
+static qdr_link_t *qdr_link_find_by_identity(qdr_core_t *core,
qd_field_iterator_t *identity)
+{
+if (!identity)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+char id[100];
+if (link->identifier) {
+snprintf(id, 100, "%ld", link->identifier);
+if (qd_field_iterator_equal(identity, (const unsigned char
*)id))
+break;
+}
+link = DEQ_NEXT(link);
+}
+
+return link;
+
+}
+
+
+static qdr_link_t *qdr_link_find_by_name(qdr_core_t *core,
qd_field_iterator_t *name)
+{
+if(!name)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+if (link->name && qd_field_iterator_equal(name, (const unsigned
char *)link->name))
+break;
+link = DEQ_NEXT(link);
+}
+
+return link;
+}
+
+
+/**
+ * The body map containing any attributes that are not applicable for the
entity being updated
+ * MUST result in a failure response with a statusCode of 400 (Bad
Request).
+ * TODO - Generalize this function so that all update functions can use it.
+ */
+static qd_error_t qd_is_update_request_valid(qd_router_entity_type_t
entity_type,
+ qd_parsed_field_t *in_body)
+{
+qd_error_clear();
+if(in_body != 0 && qd_parse_is_map(in_body)) {
+int j=0;
+qd_parsed_field_t *field = qd_parse_sub_key(in_body, j);
+
+while (field) {
+bool found = false;
+
+qd_field_iterator_t *iter = qd_parse_raw(field);
+
+for(int i = 1; i < QDR_LINK_COLUMN_COUNT; i++) {
+if (qd_field_iterator_equal(iter, (unsigned
char*)qdr_link_columns[i])) {
+found = true;
+break;
+}
+}
+if (!found) {// Some bad field was specified in the body map.
Reject this request
+int field_len = qd_field_iterator_length(iter);
+// lenth of "Invalid Column Name :" + '\0' is 22
+char error_message[22 + field_len];
+snprintf(error_message, 22, "Invalid Column Name: ");
+char octet = qd_field_iterator_octet(iter);
+int i = 0;
+while (octet) {
+char *spot = &error_message[21+i];
+snprintf(spot, 2, &octet);
+octet = qd_field_iterator_octet(iter);
+i++;
+}
+return qd_error(QD_ERROR_MESSAGE, "%s", error_message);
+}
+
+j++;
+
+//Get the next field in the body
+field = qd_parse_sub_key(in_body, j);
+}
+}
+else
+return qd_error(QD_ERROR_MESSAGE, "%s", "Message body is not a
map"); // The body is either empty or the body is not a map, return false
+
+return QD_ERROR_NONE;
+}
+
+
+static void qdra_link_update_set_status(qdr_core_t *core, qdr_query_t
*query, qdr_link_t *link)
+{
+if (link) {
+//link->admin_state = qd_field_iterator_copy(adm_state);
+qdr_manage_write_response_map_CT(query->body, link);
+query->status = QD_AMQP_OK;
+}
+else {
+query->status = QD_AMQP_NOT_FOUND;
+qd_compose_start_map(query->body);
+qd_compose_end_map(query->body);
+}
+}
+
+static void qdra_link_set_bad_request(qdr_query_t *query)
+{
+query->status = QD_AMQP_BAD_REQUEST;
+qd_compose_start_map(query->body);
+qd_compose_end_map(query->body);
+}
+
+void qdra_link_update_CT(qdr_core_t *core,
+ qd_field_iterator_t *name,
+ qd_field_iterator_t *identity,
+
[GitHub] qpid-dispatch pull request: DISPATCH-179 - Added code to update ro...
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/59#discussion_r56070842
--- Diff: src/router_core/agent_link.c ---
@@ -229,3 +242,185 @@ void qdra_link_get_next_CT(qdr_core_t *core,
qdr_query_t *query)
//
qdr_agent_enqueue_response_CT(core, query);
}
+
+
+static void qdr_manage_write_response_map_CT(qd_composed_field_t *body,
qdr_link_t *link)
+{
+qd_compose_start_map(body);
+
+for(int i = 0; i < QDR_LINK_COLUMN_COUNT; i++) {
+qd_compose_insert_string(body, qdr_link_columns[i]);
+qdr_agent_write_column_CT(body, i, link);
+}
+
+qd_compose_end_map(body);
+}
+
+
+static qdr_link_t *qdr_link_find_by_identity(qdr_core_t *core,
qd_field_iterator_t *identity)
+{
+if (!identity)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+char id[100];
+if (link->identifier) {
+snprintf(id, 100, "%ld", link->identifier);
+if (qd_field_iterator_equal(identity, (const unsigned char
*)id))
+break;
+}
+link = DEQ_NEXT(link);
+}
+
+return link;
+
+}
+
+
+static qdr_link_t *qdr_link_find_by_name(qdr_core_t *core,
qd_field_iterator_t *name)
+{
+if(!name)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+if (link->name && qd_field_iterator_equal(name, (const unsigned
char *)link->name))
+break;
+link = DEQ_NEXT(link);
+}
+
+return link;
+}
+
+
+/**
+ * The body map containing any attributes that are not applicable for the
entity being updated
+ * MUST result in a failure response with a statusCode of 400 (Bad
Request).
+ * TODO - Generalize this function so that all update functions can use it.
+ */
+static qd_error_t qd_is_update_request_valid(qd_router_entity_type_t
entity_type,
--- End diff --
This seems a bit of overkill. There's only one column that's updatable in
this entity type. Why allow all the non-updatable columns?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[
https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194074#comment-15194074
]
ASF GitHub Bot commented on DISPATCH-179:
-
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/59#discussion_r56070842
--- Diff: src/router_core/agent_link.c ---
@@ -229,3 +242,185 @@ void qdra_link_get_next_CT(qdr_core_t *core,
qdr_query_t *query)
//
qdr_agent_enqueue_response_CT(core, query);
}
+
+
+static void qdr_manage_write_response_map_CT(qd_composed_field_t *body,
qdr_link_t *link)
+{
+qd_compose_start_map(body);
+
+for(int i = 0; i < QDR_LINK_COLUMN_COUNT; i++) {
+qd_compose_insert_string(body, qdr_link_columns[i]);
+qdr_agent_write_column_CT(body, i, link);
+}
+
+qd_compose_end_map(body);
+}
+
+
+static qdr_link_t *qdr_link_find_by_identity(qdr_core_t *core,
qd_field_iterator_t *identity)
+{
+if (!identity)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+char id[100];
+if (link->identifier) {
+snprintf(id, 100, "%ld", link->identifier);
+if (qd_field_iterator_equal(identity, (const unsigned char
*)id))
+break;
+}
+link = DEQ_NEXT(link);
+}
+
+return link;
+
+}
+
+
+static qdr_link_t *qdr_link_find_by_name(qdr_core_t *core,
qd_field_iterator_t *name)
+{
+if(!name)
+return 0;
+
+qdr_link_t *link = DEQ_HEAD(core->open_links);
+
+while(link) {
+if (link->name && qd_field_iterator_equal(name, (const unsigned
char *)link->name))
+break;
+link = DEQ_NEXT(link);
+}
+
+return link;
+}
+
+
+/**
+ * The body map containing any attributes that are not applicable for the
entity being updated
+ * MUST result in a failure response with a statusCode of 400 (Bad
Request).
+ * TODO - Generalize this function so that all update functions can use it.
+ */
+static qd_error_t qd_is_update_request_valid(qd_router_entity_type_t
entity_type,
--- End diff --
This seems a bit of overkill. There's only one column that's updatable in
this entity type. Why allow all the non-updatable columns?
> Refactor Router Core
>
>
> Key: DISPATCH-179
> URL: https://issues.apache.org/jira/browse/DISPATCH-179
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6
>
>
> Refactor the core router function to clean up the architecture and to fix the
> significant lock contention issue that exists in 0.5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-22) Add ability to run on Jenkins CI
[ https://issues.apache.org/jira/browse/QPIDIT-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194033#comment-15194033 ] ASF subversion and git services commented on QPIDIT-22: --- Commit ab84b0eee90b33912ccad8e9a0ee8b5660f413a0 in qpid-interop-test's branch refs/heads/cpp-api-changes from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=ab84b0e ] QPIDIT-22: Updated c++ shims for latest changes to Proton c++ API. WIP - JMS shims not working, issues with AMQP types > Add ability to run on Jenkins CI > > > Key: QPIDIT-22 > URL: https://issues.apache.org/jira/browse/QPIDIT-22 > Project: Apache QPID IT > Issue Type: Improvement >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Run the tests on Jenkins continuous integration system. For this to be > realized, the location of dependent components needs to be parameterized, as > they can no longer be in the usual installed locations. This includes: > * qpid-proton > * qpid-jms -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[ https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194016#comment-15194016 ] ASF GitHub Bot commented on DISPATCH-179: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/59 DISPATCH-179 - Added code to update router.link type You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch tross-DISPATCH-179-1-LINK-UPDATE Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/59.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #59 commit 87fca826b76f775d3345208122de22ef0e37 Author: Ganesh Murthy Date: 2016-03-14T19:47:05Z DISPATCH-179 - Added code to update router.link type > Refactor Router Core > > > Key: DISPATCH-179 > URL: https://issues.apache.org/jira/browse/DISPATCH-179 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6 > > > Refactor the core router function to clean up the architecture and to fix the > significant lock contention issue that exists in 0.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-179 - Added code to update ro...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/59 DISPATCH-179 - Added code to update router.link type You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch tross-DISPATCH-179-1-LINK-UPDATE Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/59.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #59 commit 87fca826b76f775d3345208122de22ef0e37 Author: Ganesh Murthy Date: 2016-03-14T19:47:05Z DISPATCH-179 - Added code to update router.link type --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6370) Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI
[ https://issues.apache.org/jira/browse/QPID-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193945#comment-15193945 ] Irina Boverman commented on QPID-6370: -- I just updated qpid-python 0.32 pypi package to 0.32.1 and included these patches: QPID-6445-Revert-the-error-checking-code-to-not-clos.patch NO-JIRA-Fix-for-python-client-ValueError-exception.-.patch QPID-6839-python-qpid-Log-the-failure-of-the-Selecto.patch QPID-7053-Add-a-callback-that-is-invoked-when-asynch.patch > Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI > -- > > Key: QPID-6370 > URL: https://issues.apache.org/jira/browse/QPID-6370 > Project: Qpid > Issue Type: Bug > Components: Python Client >Reporter: Brian Bouterse > > I can test it whenever this is done. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6370) Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI
[ https://issues.apache.org/jira/browse/QPID-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193842#comment-15193842 ] Justin Ross commented on QPID-6370: --- [~bmbouter], I asked Irina, and she says she'll use the Z field for new PyPI builds going forward. > Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI > -- > > Key: QPID-6370 > URL: https://issues.apache.org/jira/browse/QPID-6370 > Project: Qpid > Issue Type: Bug > Components: Python Client >Reporter: Brian Bouterse > > I can test it whenever this is done. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-6370) Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI
[ https://issues.apache.org/jira/browse/QPID-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-6370. --- Resolution: Done > Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI > -- > > Key: QPID-6370 > URL: https://issues.apache.org/jira/browse/QPID-6370 > Project: Qpid > Issue Type: Bug > Components: Python Client >Reporter: Brian Bouterse > > I can test it whenever this is done. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7066) [Java Broker] Add a validValuePattern attribute to ManagedAttribute
[ https://issues.apache.org/jira/browse/QPID-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193744#comment-15193744 ] Lorenz Quack commented on QPID-7066: regarding 3. I agree it would be preferable to catch this at compile time but catching it at runtime is surely preferable to not catching it at all, right? You could argue that you do not want to make the code more complicated to handle programming errors but the cases are already handled and the problem is silently ignored. Namely on line [469|https://svn.apache.org/viewvc/qpid/java/trunk/broker-core/src/main/java/org/apache/qpid/server/model/AbstractConfiguredObject.java?view=markup&pathrev=1734964#l469] and [474|https://svn.apache.org/viewvc/qpid/java/trunk/broker-core/src/main/java/org/apache/qpid/server/model/AbstractConfiguredObject.java?view=markup&pathrev=1734964#l474] of ACO. > [Java Broker] Add a validValuePattern attribute to ManagedAttribute > --- > > Key: QPID-7066 > URL: https://issues.apache.org/jira/browse/QPID-7066 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Minor > Fix For: qpid-java-6.1 > > > Currently there is no way to convey through meta data that an attribute value > must conform to a particular pattern (for instance in the case of a hostname > or ip address). > Where a managed attribute is of type String, the regex can be used both > client and server side to validate the input. Client side validation will > also always need to take into account that it is always legal to insert a > context variable reference into the value... and where such a context > injection is present is is effectively impossible to correctly validate on > the client side. > For attributes which are of type Collection, List or > Set the validValuePattern can be taken to be referring to the > validation applied to each element of the collection. > The annotation information should also be conveyed through the metadataservlet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6370) Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI
[ https://issues.apache.org/jira/browse/QPID-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193755#comment-15193755 ] Irina Boverman commented on QPID-6370: -- Both QPID-5799 and QPID-6197 fixes were already included 0.32 version (see https://pypi.python.org/pypi?name=qpid-python&version=0.32&:action=display). > Backporting QPID-5799 and QPID-6197 to qpid-python on PyPI > -- > > Key: QPID-6370 > URL: https://issues.apache.org/jira/browse/QPID-6370 > Project: Qpid > Issue Type: Bug > Components: Python Client >Reporter: Brian Bouterse > > I can test it whenever this is done. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[ https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-6969. Resolution: Fixed > [Java Broker] Provide SQL-like querying functionality through the HTTP > Management API > - > > Key: QPID-6969 > URL: https://issues.apache.org/jira/browse/QPID-6969 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > > > For reporting and monitoring it is sometimes more convenient to provide more > complex querying features than are currently supported by the REST API, and > to limit the results brought back to be only certain attributes of the > queried object. > We should add mechanisms to query configured objects across the whole broker, > or only those within a given virtual host (the latter including connections > which are associated with a virtual host even though not directly children of > that host - since connections are children of ports). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[ https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193683#comment-15193683 ] ASF subversion and git services commented on QPID-6969: --- Commit 1734973 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734973 ] QPID-6969 : Address some review comments from [~lorenz.quack] > [Java Broker] Provide SQL-like querying functionality through the HTTP > Management API > - > > Key: QPID-6969 > URL: https://issues.apache.org/jira/browse/QPID-6969 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > > > For reporting and monitoring it is sometimes more convenient to provide more > complex querying features than are currently supported by the REST API, and > to limit the results brought back to be only certain attributes of the > queried object. > We should add mechanisms to query configured objects across the whole broker, > or only those within a given virtual host (the latter including connections > which are associated with a virtual host even though not directly children of > that host - since connections are children of ports). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[
https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193674#comment-15193674
]
Lorenz Quack commented on QPID-6969:
* If you do not provide a where clause a NullPointerException is thrown.
* An uncaught SelectionParsingException may be thrown. Example query:
{{/queue?where=name>'foo'}}
> [Java Broker] Provide SQL-like querying functionality through the HTTP
> Management API
> -
>
> Key: QPID-6969
> URL: https://issues.apache.org/jira/browse/QPID-6969
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch
>
>
> For reporting and monitoring it is sometimes more convenient to provide more
> complex querying features than are currently supported by the REST API, and
> to limit the results brought back to be only certain attributes of the
> queried object.
> We should add mechanisms to query configured objects across the whole broker,
> or only those within a given virtual host (the latter including connections
> which are associated with a virtual host even though not directly children of
> that host - since connections are children of ports).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[
https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193674#comment-15193674
]
Lorenz Quack edited comment on QPID-6969 at 3/14/16 5:22 PM:
-
* -If you do not provide a where clause a NullPointerException is thrown.-
* An uncaught SelectionParsingException may be thrown. Example query:
{{/queue?where=name>'foo'}}
was (Author: lorenz.quack):
* If you do not provide a where clause a NullPointerException is thrown.
* An uncaught SelectionParsingException may be thrown. Example query:
{{/queue?where=name>'foo'}}
> [Java Broker] Provide SQL-like querying functionality through the HTTP
> Management API
> -
>
> Key: QPID-6969
> URL: https://issues.apache.org/jira/browse/QPID-6969
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch
>
>
> For reporting and monitoring it is sometimes more convenient to provide more
> complex querying features than are currently supported by the REST API, and
> to limit the results brought back to be only certain attributes of the
> queried object.
> We should add mechanisms to query configured objects across the whole broker,
> or only those within a given virtual host (the latter including connections
> which are associated with a virtual host even though not directly children of
> that host - since connections are children of ports).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[ https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193646#comment-15193646 ] ASF subversion and git services commented on QPID-6969: --- Commit 1734965 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734965 ] QPID-6969 : Address some review comments from [~lorenz.quack] > [Java Broker] Provide SQL-like querying functionality through the HTTP > Management API > - > > Key: QPID-6969 > URL: https://issues.apache.org/jira/browse/QPID-6969 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > > > For reporting and monitoring it is sometimes more convenient to provide more > complex querying features than are currently supported by the REST API, and > to limit the results brought back to be only certain attributes of the > queried object. > We should add mechanisms to query configured objects across the whole broker, > or only those within a given virtual host (the latter including connections > which are associated with a virtual host even though not directly children of > that host - since connections are children of ports). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7066) [Java Broker] Add a validValuePattern attribute to ManagedAttribute
[ https://issues.apache.org/jira/browse/QPID-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193643#comment-15193643 ] ASF subversion and git services commented on QPID-7066: --- Commit 1734964 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734964 ] QPID-7066 : Address review comments by [~lorenz.quack] > [Java Broker] Add a validValuePattern attribute to ManagedAttribute > --- > > Key: QPID-7066 > URL: https://issues.apache.org/jira/browse/QPID-7066 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Minor > Fix For: qpid-java-6.1 > > > Currently there is no way to convey through meta data that an attribute value > must conform to a particular pattern (for instance in the case of a hostname > or ip address). > Where a managed attribute is of type String, the regex can be used both > client and server side to validate the input. Client side validation will > also always need to take into account that it is always legal to insert a > context variable reference into the value... and where such a context > injection is present is is effectively impossible to correctly validate on > the client side. > For attributes which are of type Collection, List or > Set the validValuePattern can be taken to be referring to the > validation applied to each element of the collection. > The annotation information should also be conveyed through the metadataservlet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7066) [Java Broker] Add a validValuePattern attribute to ManagedAttribute
[ https://issues.apache.org/jira/browse/QPID-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193630#comment-15193630 ] Rob Godfrey commented on QPID-7066: --- # is a bug - will fix # is consistent with the other valid value style errors, so I am minded not to change # So this would require checking in the annotation processor I think - it's be weird only to throw an error on startup. I considered adding a check but decided it would be of low value - the error is the programmer attempting to add invalid meta data. I'll have a look at how hard it would be to add to the annotation processor # As discussed offline, you've raised QPID-7141 for this issue > [Java Broker] Add a validValuePattern attribute to ManagedAttribute > --- > > Key: QPID-7066 > URL: https://issues.apache.org/jira/browse/QPID-7066 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Minor > Fix For: qpid-java-6.1 > > > Currently there is no way to convey through meta data that an attribute value > must conform to a particular pattern (for instance in the case of a hostname > or ip address). > Where a managed attribute is of type String, the regex can be used both > client and server side to validate the input. Client side validation will > also always need to take into account that it is always legal to insert a > context variable reference into the value... and where such a context > injection is present is is effectively impossible to correctly validate on > the client side. > For attributes which are of type Collection, List or > Set the validValuePattern can be taken to be referring to the > validation applied to each element of the collection. > The annotation information should also be conveyed through the metadataservlet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[ https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193604#comment-15193604 ] ASF subversion and git services commented on QPID-6969: --- Commit 1734956 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734956 ] QPID-6969 : Address some review comments from [~lorenz.quack] > [Java Broker] Provide SQL-like querying functionality through the HTTP > Management API > - > > Key: QPID-6969 > URL: https://issues.apache.org/jira/browse/QPID-6969 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > > > For reporting and monitoring it is sometimes more convenient to provide more > complex querying features than are currently supported by the REST API, and > to limit the results brought back to be only certain attributes of the > queried object. > We should add mechanisms to query configured objects across the whole broker, > or only those within a given virtual host (the latter including connections > which are associated with a virtual host even though not directly children of > that host - since connections are children of ports). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-238) Need more documentation for qdstat output
[ https://issues.apache.org/jira/browse/DISPATCH-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated DISPATCH-238: - Assignee: Ted Ross > Need more documentation for qdstat output > - > > Key: DISPATCH-238 > URL: https://issues.apache.org/jira/browse/DISPATCH-238 > Project: Qpid Dispatch > Issue Type: Bug > Components: Documentation >Affects Versions: 0.5 >Reporter: Alan Conway >Assignee: Ted Ross > Fix For: 0.6 > > > The qdstat tool produces output in columns. There is no clear explanation in > the documentation (at least not in the man pages or --help text) on what the > columns mean, and they are not obvious to a newcomer. Need to add this to the > help output if it is suffuciently compact or the man page template if it gets > too long for --help output. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-238) Need more documentation for qdstat output
[
https://issues.apache.org/jira/browse/DISPATCH-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193589#comment-15193589
]
Alan Conway commented on DISPATCH-238:
--
The following is a summary of the qdstat column meanings, some of it is from
the management schema, some from memory. Needs review & filling in of blanks,
then it nees to be transcribed to the qdstat.rst man page. Probably a little
long to put into the qdstat --help output.
{code}
--connections:
"host": IP address (host:port) of remote end of connection.
"container": remote AMQP container-ID if given
"role":
"normal": normal client connection
"inter-router": connection to another router
"on-demand": waypoint connection created as needed to external broker.
"deer": "in" means connection initiated from remote end, "out" means initiated
by the router.
security: ??? security settings
authentication: authenticated user ID
--addresses:
"class":
"mobile" address can be subscribed/sent from any router.
"router" ???
"area" ???
"local" address is managed by this router (e.g. local $management address)
"link-incoming" ???
"link-outgoing" ???
"address": the AMQP address string.
"phase": waypoint phase of address
"in-proc": ??? how is this different from class=local?
Following are counters of messages this router has handled for the address,
need some detail.
"local": local subscribers
"remote": remote subscribers
"in": messages received by router for this address
"out": messages sent by router for this address
"thru": messages that transited through this router for this address.
"to-proc": Messages that terminated at this router for this address.
"from-proc": Messages that originated at this router for this address.
--links:
"type": "endpoint", "waypoint", "inter-router", "inter-area"
"dir": "in" opened by remote, "out" opened by router.
"rindex": inter-router links, the identity of the remote router.
"address" AMQP address
"phase": waypoint phase
"event-fifo", "msg-fifo": depth of local router buffers for this link.
--nodes:
"router-id": id of remote node.
"next-hop": Neighbour ID of next hop to remote node from here.
"link": Local link to remote node if there is one.
"neighbors": List of remote node's neighbours.
"valid-origins": List of valid origin nodes for messages arriving via the re
mote node, used for duplicate elimination in redundant networks.",
{code}
> Need more documentation for qdstat output
> -
>
> Key: DISPATCH-238
> URL: https://issues.apache.org/jira/browse/DISPATCH-238
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.5
>Reporter: Alan Conway
> Fix For: 0.6
>
>
> The qdstat tool produces output in columns. There is no clear explanation in
> the documentation (at least not in the man pages or --help text) on what the
> columns mean, and they are not obvious to a newcomer. Need to add this to the
> help output if it is suffuciently compact or the man page template if it gets
> too long for --help output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[ https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-6969: --- Status: Open (was: Reviewable) > [Java Broker] Provide SQL-like querying functionality through the HTTP > Management API > - > > Key: QPID-6969 > URL: https://issues.apache.org/jira/browse/QPID-6969 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > > > For reporting and monitoring it is sometimes more convenient to provide more > complex querying features than are currently supported by the REST API, and > to limit the results brought back to be only certain attributes of the > queried object. > We should add mechanisms to query configured objects across the whole broker, > or only those within a given virtual host (the latter including connections > which are associated with a virtual host even though not directly children of > that host - since connections are children of ports). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7066) [Java Broker] Add a validValuePattern attribute to ManagedAttribute
[ https://issues.apache.org/jira/browse/QPID-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7066: --- Assignee: Rob Godfrey Status: Open (was: Reviewable) > [Java Broker] Add a validValuePattern attribute to ManagedAttribute > --- > > Key: QPID-7066 > URL: https://issues.apache.org/jira/browse/QPID-7066 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Minor > Fix For: qpid-java-6.1 > > > Currently there is no way to convey through meta data that an attribute value > must conform to a particular pattern (for instance in the case of a hostname > or ip address). > Where a managed attribute is of type String, the regex can be used both > client and server side to validate the input. Client side validation will > also always need to take into account that it is always legal to insert a > context variable reference into the value... and where such a context > injection is present is is effectively impossible to correctly validate on > the client side. > For attributes which are of type Collection, List or > Set the validValuePattern can be taken to be referring to the > validation applied to each element of the collection. > The annotation information should also be conveyed through the metadataservlet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-238) Need more documentation for qdstat output
Alan Conway created DISPATCH-238: Summary: Need more documentation for qdstat output Key: DISPATCH-238 URL: https://issues.apache.org/jira/browse/DISPATCH-238 Project: Qpid Dispatch Issue Type: Bug Components: Documentation Affects Versions: 0.5 Reporter: Alan Conway Fix For: 0.6 The qdstat tool produces output in columns. There is no clear explanation in the documentation (at least not in the man pages or --help text) on what the columns mean, and they are not obvious to a newcomer. Need to add this to the help output if it is suffuciently compact or the man page template if it gets too long for --help output. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7141) [Java Broker] Make sure all data in the ApiDocs are correctly escaped/encoded
[ https://issues.apache.org/jira/browse/QPID-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7141: --- Summary: [Java Broker] Make sure all data in the ApiDocs are correctly escaped/encoded (was: [Java Broker] Make sure all data in the ApiDocs are correctly encoded) > [Java Broker] Make sure all data in the ApiDocs are correctly escaped/encoded > - > > Key: QPID-7141 > URL: https://issues.apache.org/jira/browse/QPID-7141 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > > The content of the /apidocs html page is derived from the broker which is not > aware of html semantics. > We have to make sure the strings coming from the broker are correctly encoded > before putting them in the HTML DOM. > OWASP has some information about correct escaping/encoding for different > scenarios: > https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7141) [Java Broker] Make sure all data in the ApiDocs are correctly encoded
Lorenz Quack created QPID-7141: -- Summary: [Java Broker] Make sure all data in the ApiDocs are correctly encoded Key: QPID-7141 URL: https://issues.apache.org/jira/browse/QPID-7141 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Lorenz Quack The content of the /apidocs html page is derived from the broker which is not aware of html semantics. We have to make sure the strings coming from the broker are correctly encoded before putting them in the HTML DOM. OWASP has some information about correct escaping/encoding for different scenarios: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-155) Throw a more correct exception from connect attempts that receive the amqp:not-found error
[ https://issues.apache.org/jira/browse/QPIDJMS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-155. -- Resolution: Fixed > Throw a more correct exception from connect attempts that receive the > amqp:not-found error > -- > > Key: QPIDJMS-155 > URL: https://issues.apache.org/jira/browse/QPIDJMS-155 > Project: Qpid JMS > Issue Type: Sub-task > Components: qpid-jms-client >Affects Versions: 0.8.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.9.0 > > > Currently the code will throw an InvalidDestinationException which is not > correct for this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7066) [Java Broker] Add a validValuePattern attribute to ManagedAttribute
[
https://issues.apache.org/jira/browse/QPID-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193502#comment-15193502
]
Lorenz Quack commented on QPID-7066:
* {{ConfiguredSettableAttribute}} and its subclasses have a typo in the method
name {{vaidValuePattern}}
* The error messages in {{ACO#onValidate}} are worded quite awkwardly. But they
are consistent.
* Currently setting the validValuePattern "foo" on a List of Integers means
they are all accepted. Would it not be more prudent to either throw an
exception if validValuePattern is not applicable or reject all values?
* Should the TODO in {{ApiDocsServlet.java}} be addressed? It's not a trivial
problem and we control the values but it feels like we should handle this
nevertheless.
> [Java Broker] Add a validValuePattern attribute to ManagedAttribute
> ---
>
> Key: QPID-7066
> URL: https://issues.apache.org/jira/browse/QPID-7066
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> Currently there is no way to convey through meta data that an attribute value
> must conform to a particular pattern (for instance in the case of a hostname
> or ip address).
> Where a managed attribute is of type String, the regex can be used both
> client and server side to validate the input. Client side validation will
> also always need to take into account that it is always legal to insert a
> context variable reference into the value... and where such a context
> injection is present is is effectively impossible to correctly validate on
> the client side.
> For attributes which are of type Collection, List or
> Set the validValuePattern can be taken to be referring to the
> validation applied to each element of the collection.
> The annotation information should also be conveyed through the metadataservlet
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-155) Throw a more correct exception from connect attempts that receive the amqp:not-found error
[ https://issues.apache.org/jira/browse/QPIDJMS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193508#comment-15193508 ] ASF subversion and git services commented on QPIDJMS-155: - Commit 7ff4920483c011824b9ad71930c081916d07b6b2 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=7ff4920 ] https://issues.apache.org/jira/browse/QPIDJMS-155 Allow for more information to be present when creating the exception from a given error condition. Throw a JMSException when the connection sees that amqp:not-found error during an open attempt. > Throw a more correct exception from connect attempts that receive the > amqp:not-found error > -- > > Key: QPIDJMS-155 > URL: https://issues.apache.org/jira/browse/QPIDJMS-155 > Project: Qpid JMS > Issue Type: Sub-task > Components: qpid-jms-client >Affects Versions: 0.8.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.9.0 > > > Currently the code will throw an InvalidDestinationException which is not > correct for this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-155) Throw a more correct exception from connect attempts that receive the amqp:not-found error
Timothy Bish created QPIDJMS-155: Summary: Throw a more correct exception from connect attempts that receive the amqp:not-found error Key: QPIDJMS-155 URL: https://issues.apache.org/jira/browse/QPIDJMS-155 Project: Qpid JMS Issue Type: Sub-task Components: qpid-jms-client Affects Versions: 0.8.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 0.9.0 Currently the code will throw an InvalidDestinationException which is not correct for this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-6764) Message age alerting is inappropriate on the enqueue path
[ https://issues.apache.org/jira/browse/QPID-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-6764. Resolution: Fixed > Message age alerting is inappropriate on the enqueue path > - > > Key: QPID-6764 > URL: https://issues.apache.org/jira/browse/QPID-6764 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > The Java Broker supports number of configurable message/queue alerts such as > message size alert (overly large messages), queue depth alert (queues with an > unexpected number of message on them), or message age alert (a queue > containing a message which is older than a threshold). These checks are > performed in two places: periodically by housekeeping and when a message is > enqueued. > The message age alert check is performed on by housekeeping and on enqueue of > a new message. The latter check is inappropriate and is a waste of > resources. Unlike the other checks, enqueuing a message can't affect the > outcome. It should be performed only be housekeeping. > The message age check involves taking a lock on the oldest message - so may > have a significant computation overhead. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6764) Message age alerting is inappropriate on the enqueue path
[ https://issues.apache.org/jira/browse/QPID-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193457#comment-15193457 ] ASF subversion and git services commented on QPID-6764: --- Commit 1734946 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734946 ] QPID-6764 : Address review comments from [~lorenz.quack] > Message age alerting is inappropriate on the enqueue path > - > > Key: QPID-6764 > URL: https://issues.apache.org/jira/browse/QPID-6764 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > The Java Broker supports number of configurable message/queue alerts such as > message size alert (overly large messages), queue depth alert (queues with an > unexpected number of message on them), or message age alert (a queue > containing a message which is older than a threshold). These checks are > performed in two places: periodically by housekeeping and when a message is > enqueued. > The message age alert check is performed on by housekeeping and on enqueue of > a new message. The latter check is inappropriate and is a waste of > resources. Unlike the other checks, enqueuing a message can't affect the > outcome. It should be performed only be housekeeping. > The message age check involves taking a lock on the oldest message - so may > have a significant computation overhead. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6764) Message age alerting is inappropriate on the enqueue path
[
https://issues.apache.org/jira/browse/QPID-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193446#comment-15193446
]
Lorenz Quack commented on QPID-6764:
I think the boolean flags are still wrong. I think it should be {{(false,
false)}}. BTW, does anybody remember my position on boolean flags? ;)
> Message age alerting is inappropriate on the enqueue path
> -
>
> Key: QPID-6764
> URL: https://issues.apache.org/jira/browse/QPID-6764
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> The Java Broker supports number of configurable message/queue alerts such as
> message size alert (overly large messages), queue depth alert (queues with an
> unexpected number of message on them), or message age alert (a queue
> containing a message which is older than a threshold). These checks are
> performed in two places: periodically by housekeeping and when a message is
> enqueued.
> The message age alert check is performed on by housekeeping and on enqueue of
> a new message. The latter check is inappropriate and is a waste of
> resources. Unlike the other checks, enqueuing a message can't affect the
> outcome. It should be performed only be housekeeping.
> The message age check involves taking a lock on the oldest message - so may
> have a significant computation overhead.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6764) Message age alerting is inappropriate on the enqueue path
[ https://issues.apache.org/jira/browse/QPID-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193409#comment-15193409 ] ASF subversion and git services commented on QPID-6764: --- Commit 1734942 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734942 ] QPID-6764 : Address review comments from [~lorenz.quack] > Message age alerting is inappropriate on the enqueue path > - > > Key: QPID-6764 > URL: https://issues.apache.org/jira/browse/QPID-6764 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > The Java Broker supports number of configurable message/queue alerts such as > message size alert (overly large messages), queue depth alert (queues with an > unexpected number of message on them), or message age alert (a queue > containing a message which is older than a threshold). These checks are > performed in two places: periodically by housekeeping and when a message is > enqueued. > The message age alert check is performed on by housekeeping and on enqueue of > a new message. The latter check is inappropriate and is a waste of > resources. Unlike the other checks, enqueuing a message can't affect the > outcome. It should be performed only be housekeeping. > The message age check involves taking a lock on the oldest message - so may > have a significant computation overhead. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-6764) Message age alerting is inappropriate on the enqueue path
[
https://issues.apache.org/jira/browse/QPID-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193356#comment-15193356
]
Lorenz Quack edited comment on QPID-6764 at 3/14/16 3:00 PM:
-
* It seems that in the {{NotificationCheck#MESSAGE_AGE_ALERT}}) has the wrong
boolean flags in the constructor (have I mentioned that I do not like boolean
flags?)
* On {{AbstractQueue}} there is {{checkForNotification}} and
{{performNotificationCheck}}. That is not a useful distinction. However, it
seems like {{checkForNotification}} is unused and could be removed.
* {{checkForNotificationOnNewMessage}} and {{performNotificationCheck}} seem to
be closely related so we might want to consider naming them similar
was (Author: lorenz.quack):
* It seems that in the {{NotificationCheck#MESSAGE_AGE_ALERT) has the wrong
boolean flags in the constructor (have I mentioned that I do not like boolean
flags?)
* On {{AbstractQueue}} there is {{checkForNotification}} and
{{performNotificationCheck}}. That is not a useful distinction. However, it
seems like {{checkForNotification}} is unused and could be removed.
* {{checkForNotificationOnNewMessage}} and {{performNotificationCheck}} seem to
be closely related so we might want to consider naming them similar
> Message age alerting is inappropriate on the enqueue path
> -
>
> Key: QPID-6764
> URL: https://issues.apache.org/jira/browse/QPID-6764
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> The Java Broker supports number of configurable message/queue alerts such as
> message size alert (overly large messages), queue depth alert (queues with an
> unexpected number of message on them), or message age alert (a queue
> containing a message which is older than a threshold). These checks are
> performed in two places: periodically by housekeeping and when a message is
> enqueued.
> The message age alert check is performed on by housekeeping and on enqueue of
> a new message. The latter check is inappropriate and is a waste of
> resources. Unlike the other checks, enqueuing a message can't affect the
> outcome. It should be performed only be housekeeping.
> The message age check involves taking a lock on the oldest message - so may
> have a significant computation overhead.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6764) Message age alerting is inappropriate on the enqueue path
[ https://issues.apache.org/jira/browse/QPID-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-6764: --- Assignee: Rob Godfrey (was: Keith Wall) Status: Open (was: Reviewable) > Message age alerting is inappropriate on the enqueue path > - > > Key: QPID-6764 > URL: https://issues.apache.org/jira/browse/QPID-6764 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > The Java Broker supports number of configurable message/queue alerts such as > message size alert (overly large messages), queue depth alert (queues with an > unexpected number of message on them), or message age alert (a queue > containing a message which is older than a threshold). These checks are > performed in two places: periodically by housekeeping and when a message is > enqueued. > The message age alert check is performed on by housekeeping and on enqueue of > a new message. The latter check is inappropriate and is a waste of > resources. Unlike the other checks, enqueuing a message can't affect the > outcome. It should be performed only be housekeeping. > The message age check involves taking a lock on the oldest message - so may > have a significant computation overhead. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-237) Dispatch Router overwrites delivery tag for link-routed deliveries
Ted Ross created DISPATCH-237: - Summary: Dispatch Router overwrites delivery tag for link-routed deliveries Key: DISPATCH-237 URL: https://issues.apache.org/jira/browse/DISPATCH-237 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 0.5 Reporter: Ted Ross Fix For: 0.6 Dispatch Router overwrites the delivery tags for messages that flow along routed links. The original delivery tags need to be preserved for link routes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6764) Message age alerting is inappropriate on the enqueue path
[
https://issues.apache.org/jira/browse/QPID-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193356#comment-15193356
]
Lorenz Quack commented on QPID-6764:
* It seems that in the {{NotificationCheck#MESSAGE_AGE_ALERT) has the wrong
boolean flags in the constructor (have I mentioned that I do not like boolean
flags?)
* On {{AbstractQueue}} there is {{checkForNotification}} and
{{performNotificationCheck}}. That is not a useful distinction. However, it
seems like {{checkForNotification}} is unused and could be removed.
* {{checkForNotificationOnNewMessage}} and {{performNotificationCheck}} seem to
be closely related so we might want to consider naming them similar
> Message age alerting is inappropriate on the enqueue path
> -
>
> Key: QPID-6764
> URL: https://issues.apache.org/jira/browse/QPID-6764
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> The Java Broker supports number of configurable message/queue alerts such as
> message size alert (overly large messages), queue depth alert (queues with an
> unexpected number of message on them), or message age alert (a queue
> containing a message which is older than a threshold). These checks are
> performed in two places: periodically by housekeeping and when a message is
> enqueued.
> The message age alert check is performed on by housekeeping and on enqueue of
> a new message. The latter check is inappropriate and is a waste of
> resources. Unlike the other checks, enqueuing a message can't affect the
> outcome. It should be performed only be housekeeping.
> The message age check involves taking a lock on the oldest message - so may
> have a significant computation overhead.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[ https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193256#comment-15193256 ] Rob Godfrey commented on QPID-6969: --- * As discussed offline, I think documentation should be added into the code as metadata for all API methods, so I think we should do QPID-7140 and then add the appropriate documentation inline. * For testing, I'd favour refactoring to separate out the object querying / results building code from anything to do with Http / Servlet we can then test the core functionality without requiring mocking a servlet framework (or alternatively only writing system tests). * For the general auto-generated code issues, we previously made the decision to not regenerate code on every build as the extra overhead on a per-build basis seemed unnecessary when the grammar changed so infrequently (practically never) similarly we've managed to avoid hand editing generated code for a number of years already. Unfortunately I don't think it's necessarily easy to have the parser generate comments into the other generated classes. I agree that the general syntax of JavaCC is horrible and makes the entire thing very difficult to reason about. For the most part the code in this change is only a slightly modified copy of the JMS selector code - pretty much all comments here apply equally well to that code. * TokenMgrError - yeah that should be fixed (quite why JavaCC makes this a freaking Error and not a ParseException I have no idea :-( ) > [Java Broker] Provide SQL-like querying functionality through the HTTP > Management API > - > > Key: QPID-6969 > URL: https://issues.apache.org/jira/browse/QPID-6969 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > > > For reporting and monitoring it is sometimes more convenient to provide more > complex querying features than are currently supported by the REST API, and > to limit the results brought back to be only certain attributes of the > queried object. > We should add mechanisms to query configured objects across the whole broker, > or only those within a given virtual host (the latter including connections > which are associated with a virtual host even though not directly children of > that host - since connections are children of ports). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[ https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-6969: --- Attachment: 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > [Java Broker] Provide SQL-like querying functionality through the HTTP > Management API > - > > Key: QPID-6969 > URL: https://issues.apache.org/jira/browse/QPID-6969 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > Attachments: > 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch > > > For reporting and monitoring it is sometimes more convenient to provide more > complex querying features than are currently supported by the REST API, and > to limit the results brought back to be only certain attributes of the > queried object. > We should add mechanisms to query configured objects across the whole broker, > or only those within a given virtual host (the latter including connections > which are associated with a virtual host even though not directly children of > that host - since connections are children of ports). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6969) [Java Broker] Provide SQL-like querying functionality through the HTTP Management API
[
https://issues.apache.org/jira/browse/QPID-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193178#comment-15193178
]
Lorenz Quack commented on QPID-6969:
Review comments:
* no tests, no documentation, no examples :(
* {{QueryServlet#performQuery()}} is relatively long, deeply nested and
consists of several distinct tasks. I would propose to break it up (patch
attached)
* {{ConfiguredObjectFilterParser.java}} claims it was autogenerated from
{{SelectorParser.jj}} which seems unlikely.
* It would be nice to clearly separate (auto?)generated code from hand written
code. It even seems that not all generated files (e.g.
{{ConfiguredObjectFilterParser.java}}) contain a comment to not edit them which
seems like a minimal requirement.
* Are these files really *auto*-generated? If so I would expect a {{mvn clean
install}} to pick up any changes to a *.jj file which does not seem to be the
case. I would call them generated (and maybe include instructions on how to
regenerate them) or truly autogenerate them as part of the build process.
* The mix of grammar rules and code in the *.jj files make it very hard to
reason about.
* I find it worrying that our grammars (SelectorParser.jj and
ConfiguredObjectFilterParser.jj) are longer than the [grammar for the entire
C-language|https://java.net/downloads/javacc/contrib/grammars/C.jj]
* {{TokenMgrError}} is not caught crashing the broker (e.g.
{{/querybroker/broker?select="}})
> [Java Broker] Provide SQL-like querying functionality through the HTTP
> Management API
> -
>
> Key: QPID-6969
> URL: https://issues.apache.org/jira/browse/QPID-6969
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
> Attachments:
> 0001-QPID-6969-Java-Broker-Refactor-QueryServlet-performQ.patch
>
>
> For reporting and monitoring it is sometimes more convenient to provide more
> complex querying features than are currently supported by the REST API, and
> to limit the results brought back to be only certain attributes of the
> queried object.
> We should add mechanisms to query configured objects across the whole broker,
> or only those within a given virtual host (the latter including connections
> which are associated with a virtual host even though not directly children of
> that host - since connections are children of ports).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7140) [Java Broker] Add the ability to auto generate documentation from metadata for REST services other than operations on configured objects
Rob Godfrey created QPID-7140: - Summary: [Java Broker] Add the ability to auto generate documentation from metadata for REST services other than operations on configured objects Key: QPID-7140 URL: https://issues.apache.org/jira/browse/QPID-7140 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Currently we generate documentation from the meta data associated with configured objects - however the broker also offers other services (such as the query servlet) which should include documentation. We need to introduce a way to add documentation for these services into the the code and to present this through our API docs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7139) [Java Broker] Broker should be able to find virtual hosts with duplicate IDs and automatically replace duplicate IDs with unique ones on startup
[ https://issues.apache.org/jira/browse/QPID-7139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy closed QPID-7139. Resolution: Invalid There is no need to treat virtual hosts as being "special" and perform duplicate ID fix automatically > [Java Broker] Broker should be able to find virtual hosts with duplicate IDs > and automatically replace duplicate IDs with unique ones on startup > - > > Key: QPID-7139 > URL: https://issues.apache.org/jira/browse/QPID-7139 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1 >Reporter: Alex Rudyy > > Broker should be able to find virtual hosts with duplicate IDs and > automatically replace duplicate IDs with unique ones on startup -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7139) [Java Broker] Broker should be able to find virtual hosts with duplicate IDs and automatically replace duplicate IDs with unique ones on startup
Alex Rudyy created QPID-7139: Summary: [Java Broker] Broker should be able to find virtual hosts with duplicate IDs and automatically replace duplicate IDs with unique ones on startup Key: QPID-7139 URL: https://issues.apache.org/jira/browse/QPID-7139 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: qpid-java-6.0.1, qpid-java-6.0, 0.32, 0.30, 0.28 Reporter: Alex Rudyy Broker should be able to find virtual hosts with duplicate IDs and automatically replace duplicate IDs with unique ones on startup -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7138) [Java Broker] Broker should detect duplicate IDs in configured objects
[ https://issues.apache.org/jira/browse/QPID-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7138: - Issue Type: Improvement (was: Bug) > [Java Broker] Broker should detect duplicate IDs in configured objects > -- > > Key: QPID-7138 > URL: https://issues.apache.org/jira/browse/QPID-7138 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1 >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > Currently duplicate IDs are only checked on configuration store levels, i.e. > broker configuration store, virtual host configuration stores. However, if > duplicate IDs are used in different virtual host configuration stores that > will be unnoticed by the broker. Configured object names are used to refer > configured objects from each other at the moment but IDs can be used for > object referencing as well, for example, in result of manual editing of > configuration files. We need to enforce ID integrity check and detect any > duplicate IDs on broker on startup . -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7138) [Java Broker] Broker should detect duplicate IDs in configured objects
Alex Rudyy created QPID-7138: Summary: [Java Broker] Broker should detect duplicate IDs in configured objects Key: QPID-7138 URL: https://issues.apache.org/jira/browse/QPID-7138 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-6.0.1, qpid-java-6.0, 0.32, 0.30, 0.28 Reporter: Alex Rudyy Fix For: qpid-java-6.1 Currently duplicate IDs are only checked on configuration store levels, i.e. broker configuration store, virtual host configuration stores. However, if duplicate IDs are used in different virtual host configuration stores that will be unnoticed by the broker. Configured object names are used to refer configured objects from each other at the moment but IDs can be used for object referencing as well, for example, in result of manual editing of configuration files. We need to enforce ID integrity check and detect any duplicate IDs on broker on startup . -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
