It's the latter, unfortunately. I set self.expected to zero and self.timeout to something big so that poll_for_messages() runs basically indefinitely - and new messages are not seen.
With PN_TRACE_FRM set to true, I see empty frames being sent one way every ~15 seconds, but not the other way: [0x7f98cfb002e0]:0 -> (EMPTY FRAME) In contrast, with my java-equivalent poller, when it's idly waiting for more messages, I see 2 empty frames in one direction and one in the other direction every ~15 seconds: [1584536876:0] -> Empty Frame [1584536876:0] -> Empty Frame [1584536876:0] <- Empty Frame This makes me suspect that the connection is being dropped in the python version, though I'm not sure how to prevent that. On Mon, Nov 18, 2019 at 4:45 AM Gordon Sim <[email protected]> wrote: > On 16/11/2019 11:34 pm, Mike Longfritz wrote: > > I have a receiver that is connecting to an apache qpid queue > (java-based, I > > believe, though that's probably not relevant). The issue I'm finding is > > that the receiver gets messages that are currently in the queue when it > > connects (there are often many), but that any new messages in the queue > are > > not getting to the receiver. If I start a new receiver, it sees the > missed > > messages just fine - but again, any more that come into the queue after > the > > connection is established are not seen. > > Is it that messages that arrive after your poll_for_messages() call > returns the first time are not received? Or is the call to that method > long enough that messages arriving during the first poll attempt are not > being received? > > If the former, it may be that you are actually being disconnected, e.g. > if the broker is expecting heartbeats. When not in the run() method of > the container, proton is doing nothing. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
