A few questions: 1. What versions of the store and qpid are you using?
2. Are your messages persistent? Flow-to-disk will force transient messages to disk, but will discard them on recovery; persistent messages are written to disk anyway, but have their message content discarded when the policy limit is reached. I guess the latter is the case here. This behavior should be checked out... it looks suspicious. On Thu, 2010-03-11 at 11:01 -0800, Charles Woerner wrote: > A bit more information, at about the time Journal recovery phase 1 is > complete I see one of the two qpidd processes begin to acquire vast > amounts of memory (I assume this is the phase where it begins reading > up to max-queue-size of persistent queue data into memory). Once the > process acquires about 97% of available memory the system usually dies > with the "critical Broker start-up failed: Cannot read from child > process.". > > I'm not surprised that the system dies when it runs out of memory. > But I hope someone can help me understand why qpidd is using so much > memory and whether I have my max-queue-size and store geometry > configured in a reasonable manner. I would hope that there isn't some > inherent limitation where one can't recover more data from a > persistent journal than one has available memory. > > On Mar 10, 2010, at 10:55 PM, Charles Woerner wrote: > > > To follow up, it always fails at startup with this large queue, but I > > don't always see the "Broker startup failed: cannot read from child > > process" error. Sometimes it just dies. > > > > __ > > Charles Woerner | [email protected] | demandbase --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
