2009/10/6 Gordon Sim <[email protected]>: > On 10/06/2009 12:34 PM, Martin Ritchie wrote: >> >> 2009/10/6 Gordon Sim<[email protected]>: >>> >>> I noticed the following hang in an automated build&test run. I believe it >>> is >>> using the java broker(?). Almost everything appears to be idle, but the >>> test >>> is blocked waiting for a latch. >>> >>> Anyone else seeing this? Could this be a result of recent changes? >> >> Sorry about that Gordon, when the test fails to receive all the >> messages it becomes stuck. I fixed it this morning, r822170. I'd never >> seen the test fail locally but our automated test boxes had also hung. >> Strange thing is that the tests haven't failed since the fix went in. >> If the same situation occured that caused the tests to hang >> >> One thing I haven't figured out is why the new >> AcknowledgeAfterFailoverTest when run against the CPP broker fails to >> have the right number of messagse on the queue. >> >> The test fails broker 1 then sends messages to, the now only active, >> broker 2. When it then queries the broker for the >> queue count it returns 0 rather than the messages just published. Any >> thoughts? > > Are the brokers part of a cluster? Are there any consumers on the queue in > question?
Gordon, I have not configured the brokers to be part of a cluster. I use the QpidTestCase startBroker to start two brokers one on the standard test port and one on 'getFailingPort()'. When running the Java profile this results in two standalone brokers. The test consumer uses failover to cycle between the brokers. So what the test does is fail the first broker and then create a new connection on which to send messages and then validate they are there before continuing with the test. When connecting to the new broker, to send, the test creates and closes a consumer on the destination queue to ensure that the queue exists prior to publication. The main test has a single connection that should failover between the brokers. However, the test does not get as far as testing that original connection as the test is unable to verify that the messages have been correctly published to the queue. Now, it could be that the messages are being prefetched to the main test consumer and the Java broker is just that bit slower at performing the prefetch hence why it doesn't fail. I did try adding a connection.stop/start to control the main test's consumer while the new broker was being prepared however, this did not have any affect. Any insights with your knowledge of how the CPP broker, 0-10 java client would be appreciated. Cheers Martin > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Martin Ritchie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
