> > Have you looked at the process sizes? I'm wondering if there's some issue > with the overhead of storing messages on the client and/or broker that is > making them grow large enough to cause things to slow down. I can't think of > anything that would explain a 3 second delay that you describe but >
The process size doesn't grow appreciably when receiving the data frames. Which makes sense in that it's only dealing with a frame at a time. The trace always hangs up the same way. It ping/pongs between amqp_0_10::Connection::decode and SessionState::receiverRecord until it gets to frame 79, at which point the delay kicks in. 2010-09-23 15:39:59 trace virtual bool qpid::SessionState::receiverRecord(const qpid::framing::AMQFrame&): anonymous.9f27f634-b486-42a4-bdb0-915036119395: recv cmd 2: content (65523 bytes) @\x164\xA6\x8AU6\xBA\x01\xC0\x8B\x92NL\xAD\xA4\x98%\x1Ec=\x85\xF39\xAD*,\xAB?]\xED/... ??? 2010-09-23 15:40:03 trace virtual size_t qpid::amqp_0_10::Connection::decode(const char*, size_t): RECV [127.0.0.1:39014]: Frame[E; channel=1; content (65523 bytes) \xdc\xec\xcf\x14\x1a\xa2\xb4\xb1\xaau\xd6\x86-\xa0\xac\\xb5\xd4\x00y\x...@q\x05\xa4\xae\x19\x96\x8b\xc34...] (What's interesting is the client logging has no delay -- as far as it's concerned, it sends all frames immediately, one after the other. The delay appears to only be on the broker.) What I'm trying to figure it out is what actually occurs between the above two steps. Is there a handshake between broker and client that's getting munged? (I don't see it in the logs on client or server.) Thanks, Joe --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
