Re: AMQP 1.0 Qpid JMS and an Issue with Failover/Reconnect
On 03/22/2016 12:51 PM, Aleks Balaban wrote: Thank you for writing back. My client quite minimalistic JMS client application with usual JMS stuff such as Connection, Session objects and "onMessage" listeners, which does nothing but connect to an AMQP server and waits to receive notifications/messages. It works just fine, only it isn't capable to re-establish the underlying SSL connection when something went wrong and that happens almost every day. I'm running it in a debug mode and the log I posted earlier is all I have. Obviously, the connection failure has been detected properly (for testing purposes I caused it by shooting down the internet connection) and the FailoverProvider makes two attempts to re-establish the connection. Both of them fails because the internet is off and suddenly some thread executor takes over and terminates everything. I'm just wondering is there any example in the web or anybody was trying to achieve the same. The documentation seems to be insufficient to find out what was wrong. What I've been thinking about, do I need to take care about configuration attributes at different communication levels? For example, do I have to take care manually that TCP, AMQP and JMS configuration parameters harmonize with each other? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org I wrote a small test using your provided failover options and my test sits for as long as I let it trying to reconnect. I would take a look at your code and see where you might be closing the connection as there should be no issue with these options. -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: [c++] Proposal for application function injection.
hello all
I have to say I am far from being fluent in c++ but one thing we really
like about proton is that it has no dependency and can be used in legacy
code
I do not know if the boost::function option will drive a dependency to
boost but this is maybe something to take into account.
Again, I may be wrong
Cheers
Olivier
On Monday, 21 March 2016, Alan Conway wrote:
> On Thu, 2016-03-17 at 17:19 -0400, Andrew Stitcher wrote:
> > On Thu, 2016-03-17 at 17:09 -0400, Alan Conway wrote:
> > >
> > > The proton::container is single threaded, once you call run() you
> > > can't
> > > interact with it from other threads.
> > >
> > > I'd like to propose a "function injection" interface. I think the
> > > analogous thing could be done for all the languages. The Go binding
> > > already has this mechanism.
> > >
> > > The idea is to provide a thread safe call that injects a simple
> > > "callable" object with no parameters and no return value.
> > >
> > > In C++11 this is easy to do:
> > >
> > > class container {
> > > void inject(std::function)
> > > }
> > >
> > > Semantics: calling inject() will queue the injected function to be
> > > called as soon as is reasonable in the run() thread.
> > This is definitely the interface I was thinking of.
> >
> > I'm not clear exactly how the context carrying through the event
> > queue
> > works though to be honest.
>
> So there are two issues:
>
> 1. which event loop are you injecting into. I think once we have
> connections in more than one thread we'll need to inject into a
> specific connection, not just into the container. Something like
>
> myconnection.driver().inject(...)
>
> In a single-threaded container, each connection could return the same
> (container level) driver but in a multi-threaded container each
> connection would potentially have its own driver. In fact we could
> provide a driver() on each endpoint and walk up the containment
> hierarchy, so link::driver() would return its connection's driver etc.
>
> 2. how to supply context to the function being called. That can be done
> by binding arguments, so for example:
>
> sender s =
> myconnection.driver().inject(std::bind(connection::open_sender,
> myconnection, "foo", ...)
> s.driver().inject(std::bind(sender::send, s, mymsg...)
>
> After only a few lines of this you want something like Gordon's
> BlockingConnection interface, I would see this as the enabler for
> implementing that.
>
> > > In C++03 we can support the functionality in a clunky way that is
> > > not
> > > very efficient or easy to use, but works:
> > It's actually exactly as efficient in principle as it does the same
> > thing without the decent syntax!
>
> Not unless we re-implement boost::function or std::function. We need a
> copyable, non-template type for functors that we can store where it can
> be picked up by another thread, which is hard. There is an easy, ugly
> way using pointers to base classes with virtual functions but it
> involves allocations for every inject, refcounting or some other
> tricksy memory mnagement.
>
> >
> > My objection to this is that I don't think this precise proposal
> > would
> > allow you to use a boost::function<> and tbh that's the only way I
> > would do this sort of thing in '03.
>
> I think we have 3 options and we need to decide which/how many to
> offer:
>
> - std::function
> - boost::function
> - clunky base-class pointers
>
> Less is better for us :) I think you're right that boost::function
> might be a better second choice than base class pointers since that's
> very widely available.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
Re: Support of Proton in Qpid C++ Broker
Thank you guys for your responses! Regards, Adel On Tue, Mar 22, 2016 at 5:18 PM, Andrew Stitcher wrote: > On Tue, 2016-03-22 at 15:56 +0100, Adel Boutros wrote: > > Hello, > > > > In the file amqp.cmake ( > > https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/amqp.cmake), > > there > > is a warning indicating the maximum supported version of Proton is > > 0.9. > > > > Knowing the current Proton release version is 0.12.0, I have the > > following > > questions: > > > >1. Is there a plan to update the maximum version of Proton to > > 0.12.0? > >2. What could go wrong if I use Proton 0.12.0 with the Qpid C++ > > Broker > >0.34? > > This warning is left over from when proton was undergoing more serious > changes, and we were unsure whether qpid would continue to work > correctly with future versions of proton. > > Proton changes have slowed down considerably and proton has stabilised > so the warning should probably just be removed now. > > Andrew > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: Re: AMQP 1.0 Qpid JMS and an Issue with Failover/Reconnect
Thank you for writing back. My client quite minimalistic JMS client application with usual JMS stuff such as Connection, Session objects and "onMessage" listeners, which does nothing but connect to an AMQP server and waits to receive notifications/messages. It works just fine, only it isn't capable to re-establish the underlying SSL connection when something went wrong and that happens almost every day. I'm running it in a debug mode and the log I posted earlier is all I have. Obviously, the connection failure has been detected properly (for testing purposes I caused it by shooting down the internet connection) and the FailoverProvider makes two attempts to re-establish the connection. Both of them fails because the internet is off and suddenly some thread executor takes over and terminates everything. I'm just wondering is there any example in the web or anybody was trying to achieve the same. The documentation seems to be insufficient to find out what was wrong. What I've been thinking about, do I need to take care about configuration attributes at different communication levels? For example, do I have to take care manually that TCP, AMQP and JMS configuration parameters harmonize with each other? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Support of Proton in Qpid C++ Broker
On Tue, 2016-03-22 at 15:56 +0100, Adel Boutros wrote: > Hello, > > In the file amqp.cmake ( > https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/amqp.cmake), > there > is a warning indicating the maximum supported version of Proton is > 0.9. > > Knowing the current Proton release version is 0.12.0, I have the > following > questions: > > 1. Is there a plan to update the maximum version of Proton to > 0.12.0? > 2. What could go wrong if I use Proton 0.12.0 with the Qpid C++ > Broker > 0.34? This warning is left over from when proton was undergoing more serious changes, and we were unsure whether qpid would continue to work correctly with future versions of proton. Proton changes have slowed down considerably and proton has stabilised so the warning should probably just be removed now. Andrew - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: AMQP 1.0 Qpid JMS and an Issue with Failover/Reconnect
I'd recommend that you post some code to show what your client is doing. The logs really don't provide enough information to diagnose what might be going on. On 03/22/2016 11:07 AM, Aleks Balaban wrote: Hi, Im using Qpid JMS 0.8.0 library in order to implement a standalone Java AMQP client. Because the underlying transport connection tends to break every couple of hours I was trying to configure the reconnection attempts (like failover but to the same server) using following configuration: failover:(amqps://someurl:5671)?failover.reconnectDelay=2000&failover.warnAfterReconnectAttempts=1 In accordance with Qpid failover configuration explanation I expect my client to keep trying to reconnect increasing the attempt delays for factor 2 (starting with 2 seconds). Instead, according to the log file, only two attempts to reconnect have been performed when a connection failure was detected and at the end the whole client application has been terminated, what I definitively would like to avoid! Here is the log file: 2016-03-22 14:29:40 INFO AmqpProvider:1190 - IdleTimeoutCheck closed the transport due to the peer exceeding our requested idle-timeout. 2016-03-22 14:29:40 DEBUG FailoverProvider:761 - Failover: the provider reports failure: Transport closed due to the peer exceeding our requested idle-timeout 2016-03-22 14:29:40 DEBUG FailoverProvider:519 - handling Provider failure: Transport closed due to the peer exceeding our requested idle-timeout 2016-03-22 14:29:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to: amqps://publish.preops.nm.eurocontrol.int:5671 in-progress 2016-03-22 14:29:40 INFO FailoverProvider:659 - Connection attempt:[1] to: amqps://publish.preops.nm.eurocontrol.int:5671 failed 2016-03-22 14:29:40 WARN FailoverProvider:686 - Failed to connect after: 1 attempt(s) continuing to retry. 2016-03-22 14:29:42 DEBUG FailoverProvider:653 - Connection attempt:[2] to: amqps://publish.preops.nm.eurocontrol.int:5671 in-progress 2016-03-22 14:29:42 INFO FailoverProvider:659 - Connection attempt:[2] to: amqps://publish.preops.nm.eurocontrol.int:5671 failed 2016-03-22 14:29:42 WARN FailoverProvider:686 - Failed to connect after: 2 attempt(s) continuing to retry. 2016-03-22 14:29:43 DEBUG ThreadPoolUtils:156 - Shutdown of ExecutorService: java.util.concurrent.ThreadPoolExecutor@778970af[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] is shutdown: true and terminated: true took: 0.000 seconds. 2016-03-22 14:29:45 DEBUG ThreadPoolUtils:192 - Waited 2.004 seconds for ExecutorService: java.util.concurrent.ScheduledThreadPoolExecutor@877a470[Shutting down, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 3] to terminate... 2016-03-22 14:29:46 DEBUG ThreadPoolUtils:156 - Shutdown of ExecutorService: java.util.concurrent.ScheduledThreadPoolExecutor@877a470[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 4] is shutdown: true and terminated: true took: 2.889 seconds. Any idea, what I’m doing wrong here? Basically, what I'm looking for to achieve is a client which is capable to detect transport connection failure and try to reconnect every 5-10 seconds. Many thanks! -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/ - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Support of Proton in Qpid C++ Broker
The trunk version of the C++ broker should work fine with Proton 0.12. The 0.34 version might need some workarounds, the Proton release notes ( http://qpid.apache.org/releases/qpid-proton-0.12.0/release-notes.html) mention that "Qpid C++ 0.34 builds will fail against this version of Proton unless you set -DCMAKE_CXX_FLAGS=-Wno-error=switch. A new release of Qpid C++ will resolve this problem.". As for the warning message, I think there is already a JIRA to update it - QPID-6837 (https://issues.apache.org/jira/browse/QPID-6837). Regards Jakub On Tue, Mar 22, 2016 at 3:56 PM, Adel Boutros wrote: > Hello, > > In the file amqp.cmake ( > https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/amqp.cmake), there > is a warning indicating the maximum supported version of Proton is 0.9. > > Knowing the current Proton release version is 0.12.0, I have the following > questions: > >1. Is there a plan to update the maximum version of Proton to 0.12.0? >2. What could go wrong if I use Proton 0.12.0 with the Qpid C++ Broker >0.34? > > > Regards, > > Adel Boutros > Murex SAS > www.murex.com >
AMQP 1.0 Qpid JMS and an Issue with Failover/Reconnect
Hi, Im using Qpid JMS 0.8.0 library in order to implement a standalone Java AMQP client. Because the underlying transport connection tends to break every couple of hours I was trying to configure the reconnection attempts (like failover but to the same server) using following configuration: failover:(amqps://someurl:5671)?failover.reconnectDelay=2000&failover.warnAfterReconnectAttempts=1 In accordance with Qpid failover configuration explanation I expect my client to keep trying to reconnect increasing the attempt delays for factor 2 (starting with 2 seconds). Instead, according to the log file, only two attempts to reconnect have been performed when a connection failure was detected and at the end the whole client application has been terminated, what I definitively would like to avoid! Here is the log file: 2016-03-22 14:29:40 INFO AmqpProvider:1190 - IdleTimeoutCheck closed the transport due to the peer exceeding our requested idle-timeout. 2016-03-22 14:29:40 DEBUG FailoverProvider:761 - Failover: the provider reports failure: Transport closed due to the peer exceeding our requested idle-timeout 2016-03-22 14:29:40 DEBUG FailoverProvider:519 - handling Provider failure: Transport closed due to the peer exceeding our requested idle-timeout 2016-03-22 14:29:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to: amqps://publish.preops.nm.eurocontrol.int:5671 in-progress 2016-03-22 14:29:40 INFO FailoverProvider:659 - Connection attempt:[1] to: amqps://publish.preops.nm.eurocontrol.int:5671 failed 2016-03-22 14:29:40 WARN FailoverProvider:686 - Failed to connect after: 1 attempt(s) continuing to retry. 2016-03-22 14:29:42 DEBUG FailoverProvider:653 - Connection attempt:[2] to: amqps://publish.preops.nm.eurocontrol.int:5671 in-progress 2016-03-22 14:29:42 INFO FailoverProvider:659 - Connection attempt:[2] to: amqps://publish.preops.nm.eurocontrol.int:5671 failed 2016-03-22 14:29:42 WARN FailoverProvider:686 - Failed to connect after: 2 attempt(s) continuing to retry. 2016-03-22 14:29:43 DEBUG ThreadPoolUtils:156 - Shutdown of ExecutorService: java.util.concurrent.ThreadPoolExecutor@778970af[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] is shutdown: true and terminated: true took: 0.000 seconds. 2016-03-22 14:29:45 DEBUG ThreadPoolUtils:192 - Waited 2.004 seconds for ExecutorService: java.util.concurrent.ScheduledThreadPoolExecutor@877a470[Shutting down, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 3] to terminate... 2016-03-22 14:29:46 DEBUG ThreadPoolUtils:156 - Shutdown of ExecutorService: java.util.concurrent.ScheduledThreadPoolExecutor@877a470[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 4] is shutdown: true and terminated: true took: 2.889 seconds. Any idea, what I’m doing wrong here? Basically, what I'm looking for to achieve is a client which is capable to detect transport connection failure and try to reconnect every 5-10 seconds. Many thanks!
Support of Proton in Qpid C++ Broker
Hello, In the file amqp.cmake ( https://github.com/apache/qpid/blob/trunk/qpid/cpp/src/amqp.cmake), there is a warning indicating the maximum supported version of Proton is 0.9. Knowing the current Proton release version is 0.12.0, I have the following questions: 1. Is there a plan to update the maximum version of Proton to 0.12.0? 2. What could go wrong if I use Proton 0.12.0 with the Qpid C++ Broker 0.34? Regards, Adel Boutros Murex SAS www.murex.com
