i do know that output response shown by ./qpid-tool is slow, hence i tried many times but still the msgDepth had 1 msg in it. please do let me know is this any bug or am i going wrong anywhere. thanks
ft420 wrote: > > i had edited the post and deleted this sentence "I have tried same test > case with client and broker on linux combination which worked > successfully.." as i again tested same on linux but same problem persists > on linux also. > code snippet is : > : > : > connection.open(host, port); > Session session = connection.newSession(); > SubscriptionManager SubMgr(session); > SubscriptionSettings settings; > settings.acquireMode = ACQUIRE_MODE_NOT_ACQUIRED; > QueueQueryResult QueryResult = session.queueQuery(arg::queue="abc"); > uint qMsgCnt = QueryResult.getMessageCount(); > LocalQueue local_queue; > cout << "Before purge" << qMsgCnt << endl; > SubMgr.subscribe(local_queue, "abc", settings); > session.queuePurge(arg::queue="abc"); > qMsgCnt = QueryResult.getMessageCount(); > cout << "After purge" << qMsgCnt << endl; > : > : > > Gordon Sim wrote: >> >> On 10/09/2009 05:28 AM, ft420 wrote: >>> >>> Hi >>> Client running on windows, broker on Linux >>> sequence of statements: >>> 1. writing n messages to the queue. >>> 2. getMessageCount on the queue. >>> 3. call to queuePurge >>> 4. getMessageCount on the queue. >>> In above case step 4 returns 0 but on linux when i check the queue >>> status >>> with python command ./qpid-tool it shows 1 in msgDepth?? >> >> qpid-tool does not immediately reflect changes to the enqueue and >> dequeue count (from which the depth is computed). That gets updated >> periodically. Does qpid-tool eventually show the correct counts? Or does >> it remain at 1? If the latter can you retrieve the message from the >> queue? >> >>> i am not able to find the bug.. please let me know if i m going wrong >>> any >>> where.. >>> I have tried same test case with client and broker on linux combination >>> which worked successfully.. >> >> I can see no reason why or how the windows client could result in this >> difference from just the steps above. Is it possible that the client >> subscribes to the queue and gets a message that is not acknowledged that >> then goes back on the queue? >> >> Maybe worth turning on logging for the broker for the steps above to see >> if that shows anything. >> >>> qpid 0.5 on windows qpid 0.5 on linux and qpid-python 0.4 commands on >>> linux. >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:users-subscr...@qpid.apache.org >> >> >> > > -- View this message in context: http://n2.nabble.com/queuePurge-call-purges-all-messages-except-1-tp3792392p3793700.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscr...@qpid.apache.org
