Yes, I run the both consumer and producer in Eclipse. When the sent done, start consumer to receive the messages from queue.
At 2011-10-20 16:20:09,lzr <jsw...@163.com> wrote: >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 >> >> >> >> >>