Yes, its are persistent messages. As these messages in a huge transaction, without compression property set the broker will run out of memory.
At 2011-10-20 15:42:28,"Torsten Mielke" <tors...@fusesource.com> wrote: >Are these persistent messages? > >From my own performance tests I know that enqueuing a persistent message takes >longer than dequeuing it, which is the opposite behavior from what you're >seeing. Persistent msgs need to be persisted to the brokers store. > >Do you encounter the same behavior when turning off compression? >Are producer/broker/consumer on the same machine? >Also, I presume there are no transactions used? > > > >Torsten Mielke >tors...@fusesource.com >tmie...@blogspot.com > >On Oct 20, 2011, at 9:32 AM, lzr wrote: > >> Hi all, >> >> >> In my cases, I produces and consumes messages with big data: 40K per >> message, 10000 messages produced and consumed for each exchange. For better >> performance I used jms.useCompression in my connection and it did work well: >> 10000 messages sent in 5 seconds; >> But my consumer takes about 70 seconds to receive these messages from queue >> (Just received, no process to message). >> How is the consumer so lower than producer? Is there any optimization to the >> consumer? >> >> >> It's much appreciated if any suggestions! >> >> >> Best regards, >> Zhuran Li > > > > >
