[GitHub] qpid-proton issue #154: Replace user-defined macro WIN32 by compiler-defined...
Github user matlo607 commented on the issue: https://github.com/apache/qpid-proton/pull/154 Actually everything looks correct in the C code. Here below is the result of `git grep WIN32`. ``` CMakeLists.txt:382: if(WIN32) c/CMakeLists.txt:22:if(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:25:endif(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:380: if(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:387: endif(WIN32 AND NOT CYGWIN) c/examples/CMakeLists.txt:40:if(WIN32) c/examples/broker.c:38:#if defined(_WIN32) c/examples/send-ssl.c:54:#if defined(_WIN32) CMakeLists.txt:382: if(WIN32) c/CMakeLists.txt:22:if(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:25:endif(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:380: if(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:387: endif(WIN32 AND NOT CYGWIN) c/examples/CMakeLists.txt:40:if(WIN32) c/examples/broker.c:38:#if defined(_WIN32) c/examples/send-ssl.c:54:#if defined(_WIN32) CMakeLists.txt:382: if(WIN32) c/CMakeLists.txt:22:if(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:25:endif(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:380: if(WIN32 AND NOT CYGWIN) c/CMakeLists.txt:387: endif(WIN32 AND NOT CYGWIN) c/examples/CMakeLists.txt:40:if(WIN32) c/examples/broker.c:38:#if defined(_WIN32) c/examples/send-ssl.c:54:#if defined(_WIN32) c/examples/thread.h:24:#ifdef _WIN32 c/include/proton/import_export.h:36:#if defined(_WIN32) && !defined(PROTON_DECLARE_STATIC) c/include/proton/import_export.h:69:# if defined(_WIN32) c/include/proton/selectable.h:59:#if defined(_WIN32) && ! defined(__CYGWIN__) c/src/reactor/io/windows/io.c:23:#ifndef _WIN32_WINNT c/src/reactor/io/windows/io.c:24:#define _WIN32_WINNT 0x0501 c/src/reactor/io/windows/io.c:26:#if _WIN32_WINNT < 0x0501 c/src/reactor/io/windows/iocp.c:22:#ifndef _WIN32_WINNT c/src/reactor/io/windows/iocp.c:23:#define _WIN32_WINNT 0x0501 c/src/reactor/io/windows/iocp.c:25:#if _WIN32_WINNT < 0x0501 c/src/reactor/io/windows/selector.c:22:#ifndef _WIN32_WINNT c/src/reactor/io/windows/selector.c:23:#define _WIN32_WINNT 0x0501 c/src/reactor/io/windows/selector.c:25:#if _WIN32_WINNT < 0x0501 c/src/reactor/io/windows/write_pipeline.c:30:#ifndef _WIN32_WINNT c/src/reactor/io/windows/write_pipeline.c:31:#define _WIN32_WINNT 0x0501 c/src/reactor/io/windows/write_pipeline.c:33:#if _WIN32_WINNT < 0x0501 c/src/ssl/openssl.c:33:#ifndef _WIN32_WINNT c/src/ssl/openssl.c:34:#define _WIN32_WINNT 0x0501 c/src/ssl/openssl.c:36:#if _WIN32_WINNT < 0x0501 c/src/ssl/openssl.c:1531:#ifdef _WIN32 c/src/ssl/schannel.c:46:#define SECURITY_WIN32 c/src/ssl/schannel.c:50:#undef SECURITY_WIN32 c/tests/CMakeLists.txt:76: if(WIN32) c/tests/CMakeLists.txt:78: else(WIN32) c/tests/CMakeLists.txt:80: endif(WIN32) c/tests/proactor.c:700:#if defined(_WIN32) c/tests/proactor.c:1095:#if !defined(_WIN32) c/tests/ssl.c:67:#if !defined(_WIN32) c/tests/thread.h:24:#ifdef _WIN32 c/tools/include/pncompat/misc_defs.h:42:#elif !defined(_WIN32) || defined (__CYGWIN__) c/tools/include/pncompat/misc_funcs.inc:41:#if defined(_WIN32) && ! defined(__CYGWIN__) c/tools/include/pncompat/misc_funcs.inc:45:#if defined(_WIN32) && ! defined(__CYGWIN__) cpp/examples/CMakeLists.txt:108: if(WIN32) cpp/examples/CMakeLists.txt:110: else(WIN32) cpp/examples/CMakeLists.txt:112: endif(WIN32) ``` --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1106) Interrouter link name collisions when routers started in same second
[ https://issues.apache.org/jira/browse/DISPATCH-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590776#comment-16590776 ] ASF subversion and git services commented on DISPATCH-1106: --- Commit 8a8b6376cbcf2e04e4dddcfd18bb5a683e837964 in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=8a8b637 ] DISPATCH-1106: Reduce chance of routers using same link name random seed > Interrouter link name collisions when routers started in same second > > > Key: DISPATCH-1106 > URL: https://issues.apache.org/jira/browse/DISPATCH-1106 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.3.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.4.0 > > > If two routers are started in the same second then they use the same time(0) > random seed. Then the routers will use an identical sequence of generated > link names. > This is not necessarily illegal from an AMQP point of view but it is > confusing and not the intended behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590741#comment-16590741
]
Rob Godfrey commented on PROTON-1917:
-
Hmmm... that's a different error - it's reporting you are requesting a hostname
that isn't known, rather than a host which resolves to a virtual host which is
still recovering after restart. Do you have a virtual host that should resolve
to 'lahad01'?
-- Rob
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional command
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: apache-qpid-broker-j-7.0.3-bin.zip > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6 >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: (was: apache-qpid-broker-j-7.0.3-bin.zip) > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6 >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #154: Replace user-defined macro WIN32 by compiler-defined...
Github user astitcher commented on the issue: https://github.com/apache/qpid-proton/pull/154 This looks fine, but you have ignored the c code in the tree - is there a reason for that? --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #363: Dispatch 1103
Github user ted-ross commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/363#discussion_r212398966
--- Diff: tests/system_tests_autolinks.py ---
@@ -35,6 +36,124 @@
CONNECTION_PROPERTIES = {u'connection': u'properties', u'int_property':
6451}
--- End diff --
Please also provide a test which receives attaches for pre-configured
auto-links. Have the test reject the auto-links and see that they retry.
Also, have the test accept the auto-link and then detach it to see the retry.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #363: Dispatch 1103
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/363#discussion_r212397739 --- Diff: src/router_core/connections.c --- @@ -34,6 +34,9 @@ static void qdr_link_delete_CT(qdr_core_t *core, qdr_action_t *action, bool disc ALLOC_DEFINE(qdr_connection_t); ALLOC_DEFINE(qdr_connection_work_t); +const int AUTO_LINK_FIRST_RETRY_INTERVAL = 2; --- End diff -- All of this auto-link-retry logic should be in the route_control module, not the connections module. One hint that this is the case is the fact that you moved qdr_route_log_CT from static to non-static. qdr_route_log_CT is a static helper function for route_control logic. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590468#comment-16590468
]
Jeremy commented on PROTON-1917:
Hello [~rgodfrey] and [~gemmellr]
I tested with the patched broker-j from QPID-8233. I had the same error. I
tested the broker on anther host too (in order not to take cached data).
{code:java}
receive_with_retry on_message msg
receive_with_retry on_message msg
[00435C70]:(PN_PROACTOR_TIMEOUT)
[00435C70]:(PN_PROACTOR_TIMEOUT)
[00435C70]:(PN_PROACTOR_TIMEOUT)
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Unknown hostname in connection
open: 'lahad01'
[00435C70]:(PN_PROACTOR_INACTIVE)
[00435C70]:(PN_PROACTOR_INTERRUPT)
main: end
Press any key to continue . . .{code}
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5
[jira] [Created] (DISPATCH-1106) Interrouter link name collisions when routers started in same second
Chuck Rolke created DISPATCH-1106: - Summary: Interrouter link name collisions when routers started in same second Key: DISPATCH-1106 URL: https://issues.apache.org/jira/browse/DISPATCH-1106 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.3.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Fix For: 1.4.0 If two routers are started in the same second then they use the same time(0) random seed. Then the routers will use an identical sequence of generated link names. This is not necessarily illegal from an AMQP point of view but it is confusing and not the intended behavior. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8233: - Affects Version/s: qpid-java-broker-7.0.3 qpid-java-broker-7.0.2 qpid-java-broker-7.0.0 qpid-java-broker-7.0.1 qpid-java-broker-7.0.4 qpid-java-broker-7.0.5 qpid-java-broker-7.0.6 > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6 >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8234) [Broker-J] Return amqp error "amqp:connection:forced" on opening connections to non-existing or not-active virtual hosts
[
https://issues.apache.org/jira/browse/QPID-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy closed QPID-8234.
Resolution: Duplicate
Closed as duplicate of QPID-8233
> [Broker-J] Return amqp error "amqp:connection:forced" on opening connections
> to non-existing or not-active virtual hosts
>
>
> Key: QPID-8234
> URL: https://issues.apache.org/jira/browse/QPID-8234
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.7
>
>
> On attempt to open connection to non-existing or not available virtual host,
> it would be better to use {{amqp:connection:forced}} error conditions rather
> than {{amqp:not-found}}
> As per spec {{amqp:connection:forced}} is defined as {quote} An operator
> intervened to close the connection for some reason. The client could retry at
> some later date.{quote}. It allows retrying whilst {{amqp:not-found}} can be
> interpreted on the client to stop reconnecting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8233: - Fix Version/s: qpid-java-broker-7.0.7 > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8234) [Broker-J] Return amqp error "amqp:connection:forced" on opening connections to non-existing or not-active virtual hosts
[
https://issues.apache.org/jira/browse/QPID-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8234:
-
Affects Version/s: qpid-java-broker-7.0.3
qpid-java-broker-7.0.2
qpid-java-broker-7.0.0
qpid-java-broker-7.0.1
qpid-java-broker-7.0.4
qpid-java-broker-7.0.5
Fix Version/s: qpid-java-broker-7.0.7
Component/s: Broker-J
> [Broker-J] Return amqp error "amqp:connection:forced" on opening connections
> to non-existing or not-active virtual hosts
>
>
> Key: QPID-8234
> URL: https://issues.apache.org/jira/browse/QPID-8234
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.7
>
>
> On attempt to open connection to non-existing or not available virtual host,
> it would be better to use {{amqp:connection:forced}} error conditions rather
> than {{amqp:not-found}}
> As per spec {{amqp:connection:forced}} is defined as {quote} An operator
> intervened to close the connection for some reason. The client could retry at
> some later date.{quote}. It allows retrying whilst {{amqp:not-found}} can be
> interpreted on the client to stop reconnecting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8234) [Broker-J] Return amqp error "amqp:connection:forced" on opening connections to non-existing or not-active virtual hosts
[
https://issues.apache.org/jira/browse/QPID-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590059#comment-16590059
]
Rob Godfrey commented on QPID-8234:
---
I think this duplicates QPID-8233 :)
> [Broker-J] Return amqp error "amqp:connection:forced" on opening connections
> to non-existing or not-active virtual hosts
>
>
> Key: QPID-8234
> URL: https://issues.apache.org/jira/browse/QPID-8234
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
>
> On attempt to open connection to non-existing or not available virtual host,
> it would be better to use {{amqp:connection:forced}} error conditions rather
> than {{amqp:not-found}}
> As per spec {{amqp:connection:forced}} is defined as {quote} An operator
> intervened to close the connection for some reason. The client could retry at
> some later date.{quote}. It allows retrying whilst {{amqp:not-found}} can be
> interpreted on the client to stop reconnecting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8235) [Broker-J] Broker should delay opening/closing connections to virtual hosts which are still activating
Rob Godfrey created QPID-8235: - Summary: [Broker-J] Broker should delay opening/closing connections to virtual hosts which are still activating Key: QPID-8235 URL: https://issues.apache.org/jira/browse/QPID-8235 Project: Qpid Issue Type: Bug Reporter: Rob Godfrey Currently when a client attempts to connect to a virtual host which is still activating then the connection is immediately closed. Instead the broker should distinguish between hosts which are in the process of activating, and those that are in a more long term non-active state. Where the virtualhost is still activating, the broker should not immediately respond, but instead defer any further action until the activation has completed. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8234) [Broker-J] Return amqp error "amqp:connection:forced" on opening connections to non-existing or not-active virtual hosts
Alex Rudyy created QPID-8234:
Summary: [Broker-J] Return amqp error "amqp:connection:forced" on
opening connections to non-existing or not-active virtual hosts
Key: QPID-8234
URL: https://issues.apache.org/jira/browse/QPID-8234
Project: Qpid
Issue Type: Bug
Affects Versions: qpid-java-broker-7.0.6
Reporter: Alex Rudyy
On attempt to open connection to non-existing or not available virtual host, it
would be better to use {{amqp:connection:forced}} error conditions rather than
{{amqp:not-found}}
As per spec {{amqp:connection:forced}} is defined as {quote} An operator
intervened to close the connection for some reason. The client could retry at
some later date.{quote}. It allows retrying whilst {{amqp:not-found}} can be
interpreted on the client to stop reconnecting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590049#comment-16590049 ] Rob Godfrey commented on QPID-8233: --- Attached are a patch and a full build of Broker-J 7.0.3 with this patch applied to see if this approach solves the problem detailed in PROTON-1917 > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey >Priority: Major > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: apache-qpid-broker-j-7.0.3-bin.zip > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey >Priority: Major > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: QPID-8233.diff > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Rob Godfrey >Priority: Major > Attachments: QPID-8233.diff > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590045#comment-16590045
]
Rob Godfrey commented on PROTON-1917:
-
I have created QPID-8233 for the Broker-J change, and I will post on that a
proposed fix which [~jeremy.aouad] may wish to try
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
Rob Godfrey created QPID-8233: - Summary: [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error Key: QPID-8233 URL: https://issues.apache.org/jira/browse/QPID-8233 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Rob Godfrey Currently if a connection is made to a broker where a virtual host is in the process of activating, the client received a "not-found" error with a description "virtual host is not active". A client receiving this would not expect that simply retrying is likely to lead to success. Instead of sending "not-found" the broker should send "connection-forced" which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590031#comment-16590031
]
Jeremy commented on PROTON-1917:
I am using broker-j version 7.0.3.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590026#comment-16590026
]
Rob Godfrey commented on PROTON-1917:
-
[~jeremy.aouad] Which version of Broker-J are you using? I think the most
pragmatic change would be to have Broker-J return "connection-forced" rather
than "not-found", this would be a one line change in Broker-J and maybe
[~alex.rufous] can bundle that change into a patch release if you are using a
relatively recent version.
Ultimately I would like to change the behaviour of Broker-J so that it waits
until it has attempted to activate the virtual host before it responds to the
open request, but that is a bigger change
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.w
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16590022#comment-16590022
]
Robbie Gemmell commented on PROTON-1917:
Assuming use of a failover URI, it will consider it a failed attempt and
continue to try reconnecting if config allows.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589996#comment-16589996
]
Rob Godfrey commented on PROTON-1917:
-
[~gemmellr] Do you know how the JMS client will behave in this situation?
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589995#comment-16589995
]
Jeremy commented on PROTON-1917:
Ok, so how do you propose we proceed? it is also worth seeing if qpid jms has
the same behavior as proton.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589977#comment-16589977
]
Rob Godfrey edited comment on PROTON-1917 at 8/23/18 9:48 AM:
--
I'm still not totally convinced that this is really Proton's fault, other than
via a knowledge of the description string which is specific to Broker-J it
can't know that it should retry on this error.
I think Broker-J would be better using a different error condition. Rather
than amqp:not-found, it would perhaps be better for it to use
amqp:connection:forced which is defined as "An operator intervened to close the
connection for some reason. The client could retry at some later date." which
explicitly allows for retrying, even though it's not quite what is happening.
I don't know if proton would continue retrying in this case.
was (Author: rgodfrey):
I'm still not totally convinced that this is really Proton's fault, other than
via a knowledge of the description string which is specific to Broker-J it
can't know that it should retry on this error.
I think Broker-J would be better using a different error condition. Rather
than amqp:not-found, it would perhaps be better for it to use
amqp:connection:forced which is defined as "An operator intervened to close the
connection for some reason. The client could retry at some later date." which
explicit allows for retrying, even though it's not quite what is happening. I
don't know if proton would continue retrying in this case.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589977#comment-16589977
]
Rob Godfrey commented on PROTON-1917:
-
I'm still not totally convinced that this is really Proton's fault, other than
via a knowledge of the description string which is specific to Broker-J it
can't know that it should retry on this error.
I think Broker-J would be better using a different error condition. Rather
than amqp:not-found, it would perhaps be better for it to use
amqp:connection:forced which is defined as "An operator intervened to close the
connection for some reason. The client could retry at some later date." which
explicit allows for retrying, even though it's not quite what is happening. I
don't know if proton would continue retrying in this case.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhos
[jira] [Comment Edited] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589943#comment-16589943
]
Jeremy edited comment on PROTON-1917 at 8/23/18 9:29 AM:
-
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, the problem from proton's side is that it is breaking the infinite
retry loop, and is exiting with an error immediately, regardless of the
configured retry.
Activating proton's logger along with my logs gives the following:
{code:java}
receive_with_retry on_message msg
[00405C70]:(PN_PROACTOR_TIMEOUT)
[00405C70]:(PN_PROACTOR_TIMEOUT)
[00405C70]:(PN_PROACTOR_TIMEOUT)
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
active
[00405C70]:(PN_PROACTOR_INACTIVE)
[00405C70]:(PN_PROACTOR_INTERRUPT)
main: end
Press any key to continue . . .{code}
Upon starting the killed broker, I get the PN_PROACTOR_INACTIVE and
PN_PROACTOR_INTERRUPT, and then proton exits an error.
was (Author: jeremy.aouad):
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, the problem from proton's side is that it is breaking the infinite
retry loop, and is exiting with an error immediately, regardless of the
configured retry.
Activating proton's logger along with my logs gives the following:
{code:java}
receive_with_retry on_message msg
receive_with_retry on_message msg
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_INACTIVE)
[0034D210]:(PN_PROACTOR_INTERRUPT)
unknown file: error: C++ exception with description "Handler [00310FD0]
received error of type 1: amqp:not-found: Virtual host 'localhost' is not active
" thrown in the test body.{code}
Upon starting the killed broker, I get the PN_PROACTOR_INACTIVE and
PN_PROACTOR_INTERRUPT, and then proton exits an error.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>
[jira] [Comment Edited] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589943#comment-16589943
]
Jeremy edited comment on PROTON-1917 at 8/23/18 9:25 AM:
-
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, the problem from proton's side is that it is breaking the infinite
retry loop, and is exiting with an error immediately, regardless of the
configured retry.
Activating proton's logger along with my logs gives the following:
{code:java}
receive_with_retry on_message msg
receive_with_retry on_message msg
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_INACTIVE)
[0034D210]:(PN_PROACTOR_INTERRUPT)
unknown file: error: C++ exception with description "Handler [00310FD0]
received error of type 1: amqp:not-found: Virtual host 'localhost' is not active
" thrown in the test body.{code}
Upon starting the killed broker, I get the PN_PROACTOR_INACTIVE and
PN_PROACTOR_INTERRUPT, and then proton exits an error.
was (Author: jeremy.aouad):
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, the problem from proton's side is that it is breaking the infinite
retry loop, and is exiting with an error immediately, regardless of the
configured retry.
Activating proton's logger along with my logs gives the following:
{code:java}
Received msg = msg
Received msg = msg
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_INACTIVE)
[0034D210]:(PN_PROACTOR_INTERRUPT)
unknown file: error: C++ exception with description "Handler [00310FD0]
received error of type 1: amqp:not-found: Virtual host 'localhost' is not active
" thrown in the test body.{code}
Upon starting the killed broker, I get the PN_PROACTOR_INACTIVE and
PN_PROACTOR_INTERRUPT, and then proton exits an error.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_re
[jira] [Comment Edited] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589943#comment-16589943
]
Jeremy edited comment on PROTON-1917 at 8/23/18 9:24 AM:
-
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, the problem from proton's side is that it is breaking the infinite
retry loop, and is exiting with an error immediately, regardless of the
configured retry.
Activating proton's logger along with my logs gives the following:
{code:java}
Received msg = msg
Received msg = msg
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_TIMEOUT)
[0034D210]:(PN_PROACTOR_INACTIVE)
[0034D210]:(PN_PROACTOR_INTERRUPT)
unknown file: error: C++ exception with description "Handler [00310FD0]
received error of type 1: amqp:not-found: Virtual host 'localhost' is not active
" thrown in the test body.{code}
Upon starting the killed broker, I get the PN_PROACTOR_INACTIVE and
PN_PROACTOR_INTERRUPT, and then proton exits an error.
was (Author: jeremy.aouad):
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, the problem from proton's side is that it is breaking the infinite
retry loop, and is exiting with an error immediately, regardless of the
configured retry.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().
[jira] [Updated] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy updated PROTON-1917:
---
Description:
I have a running broker, and a configured queue containing messages.
I also have a consumer, where I configured the max number of attempts to 0
(infinite retry).
I kill the broker (ctrl-c) and start it on the same port.
Upon reconnection, I get the following error message randomly:
{code:java}
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
active
main: end{code}
In the case where the consumer is able to connect, the consumer continues to
consume the messages normally.
However, in the broker web interface, I see upon each re-connection, an extra
connection (same ip and port) to the queue. As if, the old connection is not
killed. I wasn't expecting this behavior. This might be a separate issue.
I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
{code:java}
class receive_with_retry : public proton::messaging_handler {
private:
std::string url;
std::string queueName;
public:
receive_with_retry(const std::string &u, const std::string& q) : url(u),
queueName(q) {}
void on_container_start(proton::container &c) override {
std::cout << "receive_with_retry on_container_start" << std::endl;
c.connect(
url,
proton::connection_options()
.idle_timeout(proton::duration(2000))
.reconnect(proton::reconnect_options()
.max_attempts(0)
.delay(proton::duration(3000))
.delay_multiplier(1)
.max_delay(proton::duration(3001;
}
void on_connection_open(proton::connection& c) override {
std::cout << "receive_with_retry on_connection_open " << std::endl;
c.open_receiver(queueName, proton::receiver_options().auto_accept(false));
}
void on_session_open(proton::session& session) override {
std::cout << "receive_with_retry on_session_open " << std::endl;
}
void on_receiver_open(proton::receiver& receiver) override {
std::cout << "receive_with_retry on_receiver_open " << std::endl;
receiver.open();
}
void on_message(proton::delivery& delivery, proton::message &message)
override {
std::cout << "receive_with_retry on_message " << message.body() <<
std::endl;
// Can be used for throttling
// std::this_thread::sleep_for(std::chrono::milliseconds(100));
// commented out in order not to exit immediately, but continue on
consuming the messages.
// delivery.receiver().close();
// delivery.receiver().connection().close();
}
void on_transport_error(proton::transport& error) override {
std::cout << "receive_with_retry: on_transport_error: " <<
error.error().what() << std::endl;
error.connection().close();
}
void on_error(const proton::error_condition& error) override {
std::cout << "receive_with_retry: on_error: " << error.what() <<
std::endl;
}
};
void receiveWithRetry(const std::string& url, const std::string& queueName){
try {
std::cout << "main: start" << std::endl;
receive_with_retry receiveWithRetry(url, queueName);
proton::container(receiveWithRetry).run();
std::cout << "main: end" << std::endl;
}
catch (const std::exception& cause) {
std::cout << "main: caught exception: " << cause.what() << std::endl;
}
}
int main() {
try {
receiveWithRetry("amqp://localhost:5673", "test_queue");
return 0;
}
catch (const std::exception& e) {
std::cerr << e.what() << std::endl;
}
return 1;
}
{code}
was:
I have a running broker, and a configured queue containing messages.
I also have a consumer, where I configured the max number of attempts to 0
(infinite retry).
I kill the broker (ctrl-c) and start it on the same port.
Upon reconnection, I get the following error message randomly:
{code:java}
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
active
main: end{code}
In the case where the consumer is able to connect, the consumer continues to
consume the messages normally.
However, in the broker web interface, I see upon each re-connection, an extra
connection (same ip and port) to the queue. As if, the old connection is not
killed. I wasn't expecting this behavior. This might be a separate issue.
I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
{code:java}
class receive_with_retry : public proton::messaging_handler {
private:
std::string url;
std::string queueName;
public:
receive_with_retry(const std::string &u, const std::string& q) : url(u),
queueName(q) {}
void on_container_start(proton::container &c) override {
std::cout << "receive_with_retry on_c
[jira] [Comment Edited] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589943#comment-16589943
]
Jeremy edited comment on PROTON-1917 at 8/23/18 9:14 AM:
-
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, the problem from proton's side is that it is breaking the infinite
retry loop, and is exiting with an error immediately, regardless of the
configured retry.
was (Author: jeremy.aouad):
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, from proton's side is that it is breaking the infinite retry loop, and
is exiting with an error, regardless of the configured retry.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std:
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589943#comment-16589943
]
Jeremy commented on PROTON-1917:
Indeed, it is a broker-j.
I agree that the problem is that the broker is not fully started, but is
accepting connections.
However, from proton's side is that it is breaking the infinite retry loop, and
is exiting with an error, regardless of the configured retry.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated PROTON-1917:
Summary: [proton-c] the c++ proton consumer with retry should continue to
retry if virtual host not active (was: [proton-c] When qpid broker is killed
and started, the c++ proton consumer (with retry) is randomly exiting with an
error)
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589937#comment-16589937
]
Rob Godfrey edited comment on PROTON-1917 at 8/23/18 9:09 AM:
--
>From the error message I'm assuming you are using Qpid Broker-J as your
>broker. When Qpid Broker-J starts up, the individual virtualhosts within the
>broker do not all start up immediately, so there is a brief period of time
>where the TCP/IP port for the broker is accepting connections but the
>individual virtual hosts may not yet be available. This behaviour makes more
>sense when you consider the case of HA vritualhosts where the virtual host on
>this particular broker may not be the "active" node cluster and so will not
>become immediately active. As such the "error" is nothing to worry about and
>it should simply continue to retry.
was (Author: rgodfrey):
This is not really a proton issue. From the error message I'm assuming you are
using Qpid Broker-J as your broker. When Qpid Broker-J starts up, the
individual virtualhosts within the broker do not all start up immediately, so
there is a brief period of time where the TCP/IP port for the broker is
accepting connections but the individual virtual hosts may not yet be
available. This behaviour makes more sense when you consider the case of HA
vritualhosts where the virtual host on this particular broker may not be the
"active" node cluster and so will not become immediately active. As such the
"error" is nothing to worry about and you should simply continue to retry.
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
[GitHub] qpid-proton pull request #154: Replace user-defined macro WIN32 by compiler-...
GitHub user matlo607 opened a pull request: https://github.com/apache/qpid-proton/pull/154 Replace user-defined macro WIN32 by compiler-defined _WIN32 On Windows, if qpid-proton is used by another build system (still compiling with VC) than a Visual Studio project, `/D WIN32` is not automatically set on the command line. Today both `WIN32` and `_WIN32` can be found in the source code. The idea here are: * removing this uncertainty by using `_WIN32` that is automatically set by the compiler * having a better uniformity across the source code. You can merge this pull request into a Git repository by running: $ git pull https://github.com/matlo607/qpid-proton replace-WIN32-by-_WIN32 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/154.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 #154 commit ee3484bc506e098932de7963426d71837b98b8a7 Author: Matthieu Longo Date: 2018-08-22T13:53:01Z Replace user-defined macro WIN32 by compiler-defined _WIN32 More information are available at https://stackoverflow.com/questions/662084/whats-the-difference-between-the-win32-and-win32-defines-in-c --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey resolved PROTON-1917.
-
Resolution: Not A Problem
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey reopened PROTON-1917:
-
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589937#comment-16589937
]
Rob Godfrey commented on PROTON-1917:
-
This is not really a proton issue. From the error message I'm assuming you are
using Qpid Broker-J as your broker. When Qpid Broker-J starts up, the
individual virtualhosts within the broker do not all start up immediately, so
there is a brief period of time where the TCP/IP port for the broker is
accepting connections but the individual virtual hosts may not yet be
available. This behaviour makes more sense when you consider the case of HA
vritualhosts where the virtual host on this particular broker may not be the
"active" node cluster and so will not become immediately active. As such the
"error" is nothing to worry about and you should simply continue to retry.
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string &u, const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container &c) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message &message)
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue"
[jira] [Updated] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy updated PROTON-1917:
---
Description:
I have a running broker, and a configured queue containing messages.
I also have a consumer, where I configured the max number of attempts to 0
(infinite retry).
I kill the broker (ctrl-c) and start it on the same port.
Upon reconnection, I get the following error message randomly:
{code:java}
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
active
main: end{code}
In the case where the consumer is able to connect, the consumer continues to
consume the messages normally.
However, in the broker web interface, I see upon each re-connection, an extra
connection (same ip and port) to the queue. As if, the old connection is not
killed. I wasn't expecting this behavior. This might be a separate issue.
I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
{code:java}
class receive_with_retry : public proton::messaging_handler {
private:
std::string url;
std::string queueName;
public:
receive_with_retry(const std::string &u, const std::string& q) : url(u),
queueName(q) {}
void on_container_start(proton::container &c) override {
std::cout << "receive_with_retry on_container_start" << std::endl;
c.connect(
url,
proton::connection_options()
.idle_timeout(proton::duration(2000))
.reconnect(proton::reconnect_options()
.max_attempts(0)
.delay(proton::duration(3000))
.delay_multiplier(1)
.max_delay(proton::duration(3001;
}
void on_connection_open(proton::connection& c) override {
std::cout << "receive_with_retry on_connection_open " << std::endl;
c.open_receiver(queueName, proton::receiver_options().auto_accept(false));
}
void on_session_open(proton::session& session) override {
std::cout << "receive_with_retry on_session_open " << std::endl;
}
void on_receiver_open(proton::receiver& receiver) override {
std::cout << "receive_with_retry on_receiver_open " << std::endl;
receiver.open();
}
void on_message(proton::delivery& delivery, proton::message &message)
override {
std::cout << "receive_with_retry on_message " << message.body() <<
std::endl;
// commented out in order not to exit immediately, but continue on
consuming the messages.
// delivery.receiver().close();
// delivery.receiver().connection().close();
}
void on_transport_error(proton::transport& error) override {
std::cout << "receive_with_retry: on_transport_error: " <<
error.error().what() << std::endl;
error.connection().close();
}
void on_error(const proton::error_condition& error) override {
std::cout << "receive_with_retry: on_error: " << error.what() <<
std::endl;
}
};
void receiveWithRetry(const std::string& url, const std::string& queueName){
try {
std::cout << "main: start" << std::endl;
receive_with_retry receiveWithRetry(url, queueName);
proton::container(receiveWithRetry).run();
std::cout << "main: end" << std::endl;
}
catch (const std::exception& cause) {
std::cout << "main: caught exception: " << cause.what() << std::endl;
}
}
int main() {
try {
receiveWithRetry("amqp://localhost:5673", "test_queue");
return 0;
}
catch (const std::exception& e) {
std::cerr << e.what() << std::endl;
}
return 1;
}
{code}
was:
I have a running broker, and a configured queue containing messages.
I also have a consumer, where I configured the max delay to 0 (infinite retry).
I kill the broker (ctrl-c) and start it on the same port.
Upon reconnection, I get the following error message randomly:
{code:java}
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
active
main: end{code}
In the case where the consumer is able to connect, the consumer continues to
consume the messages normally.
However, in the broker web interface, I see upon each re-connection, an extra
connection (same ip and port) to the queue. As if, the old connection is not
killed. I wasn't expecting this behavior. This might be a separate issue.
I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
{code:java}
class receive_with_retry : public proton::messaging_handler {
private:
std::string url;
std::string queueName;
public:
receive_with_retry(const std::string &u, const std::string& q) : url(u),
queueName(q) {}
void on_container_start(proton::container &c) override {
std::cout << "receive_with_retry on_container_start" << std::endl;
c.connect(
url,
proton::connection_options()
.idle_tim
[jira] [Updated] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy updated PROTON-1917:
---
Description:
I have a running broker, and a configured queue containing messages.
I also have a consumer, where I configured the max delay to 0 (infinite retry).
I kill the broker (ctrl-c) and start it on the same port.
Upon reconnection, I get the following error message randomly:
{code:java}
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
active
main: end{code}
In the case where the consumer is able to connect, the consumer continues to
consume the messages normally.
However, in the broker web interface, I see upon each re-connection, an extra
connection (same ip and port) to the queue. As if, the old connection is not
killed. I wasn't expecting this behavior. This might be a separate issue.
I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
{code:java}
class receive_with_retry : public proton::messaging_handler {
private:
std::string url;
std::string queueName;
public:
receive_with_retry(const std::string &u, const std::string& q) : url(u),
queueName(q) {}
void on_container_start(proton::container &c) override {
std::cout << "receive_with_retry on_container_start" << std::endl;
c.connect(
url,
proton::connection_options()
.idle_timeout(proton::duration(2000))
.reconnect(proton::reconnect_options()
.max_attempts(0)
.delay(proton::duration(3000))
.delay_multiplier(1)
.max_delay(proton::duration(3001;
}
void on_connection_open(proton::connection& c) override {
std::cout << "receive_with_retry on_connection_open " << std::endl;
c.open_receiver(queueName, proton::receiver_options().auto_accept(false));
}
void on_session_open(proton::session& session) override {
std::cout << "receive_with_retry on_session_open " << std::endl;
}
void on_receiver_open(proton::receiver& receiver) override {
std::cout << "receive_with_retry on_receiver_open " << std::endl;
receiver.open();
}
void on_message(proton::delivery& delivery, proton::message &message)
override {
std::cout << "receive_with_retry on_message " << message.body() <<
std::endl;
// commented out in order not to exit immediately, but continue on
consuming the messages.
// delivery.receiver().close();
// delivery.receiver().connection().close();
}
void on_transport_error(proton::transport& error) override {
std::cout << "receive_with_retry: on_transport_error: " <<
error.error().what() << std::endl;
error.connection().close();
}
void on_error(const proton::error_condition& error) override {
std::cout << "receive_with_retry: on_error: " << error.what() <<
std::endl;
}
};
void receiveWithRetry(const std::string& url, const std::string& queueName){
try {
std::cout << "main: start" << std::endl;
receive_with_retry receiveWithRetry(url, queueName);
proton::container(receiveWithRetry).run();
std::cout << "main: end" << std::endl;
}
catch (const std::exception& cause) {
std::cout << "main: caught exception: " << cause.what() << std::endl;
}
}
int main() {
try {
receiveWithRetry("amqp://localhost:5673", "test_queue");
return 0;
}
catch (const std::exception& e) {
std::cerr << e.what() << std::endl;
}
return 1;
}
{code}
was:
I have a running broker, and a configured queue and containing messages.
I also have a consumer, where I configured the max delay to 0 (infinite retry).
I kill the broker (ctrl-c) and start it on the same port.
Upon reconnection, I get the following error message randomly:
{code:java}
receive_with_retry on_connection_open
receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
active
main: end{code}
In the case where the consumer is able to connect, the consumer continues to
consume the messages normally.
However, in the broker web interface, I see upon each re-connection, an extra
connection (same ip and port) to the queue. As if, the old connection is not
killed. I wasn't expecting this behavior. This might be a separate issue.
I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
{code:java}
class receive_with_retry : public proton::messaging_handler {
private:
std::string url;
std::string queueName;
public:
receive_with_retry(const std::string &u, const std::string& q) : url(u),
queueName(q) {}
void on_container_start(proton::container &c) override {
std::cout << "receive_with_retry on_container_start" << std::endl;
c.connect(
url,
proton::connection_options()
.idle_timeout(proto
