Dear Robbie, Thank you very much again for your detailed reply. As I mentioned in the other thread ( http://qpid.2158936.n2.nabble.com/Qpid-Proton-Python-waiting-for-data-from-external-process-td7692955.html), I also ended up in trying another solution with BlockingConnection(), after finding out that, for some reason (I wasn't actually able to understand why this is happening), using a Container loop with an EventInjector, under quite high load, seem to cause some relatively high producer-to-consumer delays.
I followed your suggestion of using a wait() with a condition always returning "False" and with a very low timeout, as a "trick" to force the processing of the container every x seconds. I posted a code snippet with this solution, I'm currently testing, here: https://pastebin.com/NLSvY09W I'm currently testing if everything works fine, but so far I did not get any "local-idle-timeout expired" error anymore. Thank you very much, Francesco Il giorno ven 17 lug 2020 alle ore 13:35 Robbie Gemmell < robbie.gemm...@gmail.com> ha scritto: > I've never really used BlockingConnection and Python isn't really my > thing, but peeking at the impl it makes use of a 'wait' method that > does the processing of its Container until e.g a message is done being > sent, is received, etc. > > Possibly you could run your own 'wait' call rather than sleeping, e.g > with a low timeout and condition that returns false, causing the > underlying container to be processed while you 'wait' and do stuff > like heart beating when needed. > > It's still single threaded though so note you can't use another thread > to do so, you would have to use your single thread for everything you > do with it. > > Might be best to just stick to the more regular, documented, > maintained path and use the Container along with the EventInjector etc > though. > > Robbie > > On Fri, 17 Jul 2020 at 10:47, Francesco Raviglione > <francescorav.es...@gmail.com> wrote: > > > > Dear Robbie, > > Thank you very much for the clarification. > > Now it is clear why I was actually getting the "local-idle-timeout > expired" > > errors. > > > > Is there a way in which I can implement myself a separate thread to send > > heartbeat packets using a BlockingConnection, so that I can, for > instance, > > sleep inside the while loop and have, in any case, a working heartbeat > > mechanism? > > > > What I am currently missing is if there is a method or function to send > an > > "(empty)" heartbeat packet over a blocking connection, without the need > of > > sending it to some topic or queue through a sender. > > > > Thank you very much, > > Francesco > > > > > > Il giorno ven 17 lug 2020 alle ore 11:32 Robbie Gemmell < > > robbie.gemm...@gmail.com> ha scritto: > > > > > I expect this will be directly because of your sleeping for 1 second, > > > using a low 'heartbeat' value of 1 second (which isn't necessarily > > > doing exactly what you think, see later), coupled directly with your > > > use of BlockingConnection. > > > > > > The BlockingConnection is a simplistic wrapper of sorts, it can't > > > process anything at all if you aren't currently using its methods as > > > it has no thread of its own to do so. This means it can't process the > > > sending or receiving of heartbeats (or actual data instead of > > > heartbeats). By sleeping for 1 second, you are ensuring that it did > > > nothing for that second, and so by the point you use it and it can > > > process any data, the peer will have seemingly exceeded the allowed > > > timeout of 1 second without the connection getting data, whether it > > > sent any or not. > > > > > > The 'heartbeat' setting controls the advertised idle-timeout. The > > > value here appears to control the actual timeout at which the > > > connection is considered broken, whilst the number advertised to the > > > server will be half of this actual timeout to avoid spurious timeouts, > > > i.e 1/2 sec in this case. If it's a proton[-j] based server it will > > > also half the received value in case the sending peer had not done so, > > > and so expect to send data or a heartbeat at 1/4 second period. > > > > > > > > > Robbie > > > > > > On Fri, 17 Jul 2020 at 09:51, Francesco Raviglione > > > <francescorav.es...@gmail.com> wrote: > > > > > > > > Dear all, > > > > I'm trying to use a Blocking Connection in the python version of Qpid > > > > Proton, in order to try to solve the problem of getting data from an > > > > external source and sending it inside AMQP messages only when it is > > > > available. > > > > However, even if I explicitly set a low heartbeat value when > creating a > > > new > > > > BlockingConnection(), I often get the following error: > > > > > > > > Traceback (most recent call last): > > > > File "ConnectionExceptionIssue.py", line 29, in <module> > > > > AMQPsend("192.168.1.2:5672/topic://test.activemq.topic.001") > > > > File "ConnectionExceptionIssue.py", line 27, in AMQPsend > > > > sender.send(req); > > > > File > > > > > > > > "/home/fullsuper/anaconda3/envs/tornado-qpid/lib/python3.8/site-packages/proton/_utils.py", > > > > line 119, in send > > > > self.connection.wait(lambda: _is_settled(delivery), msg="Sending > on > > > > sender %s" % self.link.name, > > > > File > > > > > > > > "/home/fullsuper/anaconda3/envs/tornado-qpid/lib/python3.8/site-packages/proton/_utils.py", > > > > line 486, in wait > > > > raise ConnectionException( > > > > proton._exceptions.ConnectionException: Connection amqp:// > > > 192.168.1.2:5672 > > > > disconnected: Condition('amqp:resource-limit-exceeded', > > > 'local-idle-timeout > > > > expired') > > > > > > > > To better analyze the problem, I tried writing this sample code: > > > > https://pastebin.com/R8uJALAQ > > > > The code should ideally send an "Hello World!" message every second > to an > > > > external broker. > > > > I noticed that for higher heartbeat values (e.g. 7.5 seconds), the > error > > > > does not occur, while if I set a lower value (e.g. 1 second), I > always > > > get > > > > this error. > > > > > > > > Do you know why? Is it some sort of bug or is there something wrong > in my > > > > sample code? > > > > > > > > Thank you very much, > > > > Francesco Raviglione > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > For additional commands, e-mail: users-h...@qpid.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
