We're using v0.20, with a couple of patches I've applied to cross-compile for our ARM target and to use monotonic rather than the realtime clock (we sync the clock to a GPS receiver, and leap seconds applied around midnight caused all the connections to time out).
I've gone back to the earliest crash logs I had for this, and actually they were asserts not throws, including an assert from the poller thread. I build the qpid libraries with NDEBUG now so it'll throw exceptions instead. The asserts were: 1) In qpid::framing::FrameSet::getMethod() from a Session::nextReceiver call 2) In qpid::sys::PollerPrivate::resetMode from the poller thread 3) In qpid::client::SessionImpl::hasError() from a Connection::close 4) In qpid::client::SessionImpl::markCompleted from a Receiver::fetch 5) In qpid::client::SessionImpl::sendCommand from a Sender::send 6) In qpid::client::SessionImpl::isComplete from a Sender::send Though I think most of these are due to bugs in my code where, e.g. I was trying to use orphaned sessions when I had recreated the connection. I'm not seeing these issues now. I only have warning level logging enabled in the qpid daemon right now. I might be worth increasing the verbosity of this so I get more information when things go wrong. I did a full search in all the syslogs I have on my slave target and whilst 99% of the broker entries are connection timeouts, I do also have a few examples of the following: [System] warning CLOSING [<REPEATER IP>:5672-<MASTER IP>:40652] unsent data (probably due to client disconnect)_ [System] error Connection <REPEATER IP>:5672-<MASTER IP>:57577 No protocol received closing_ -- View this message in context: http://qpid.2158936.n2.nabble.com/Newbie-problem-with-long-term-use-of-C-broker-client-code-tp7591679p7591714.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
