Re: Bad allocation error

2010-01-12 Thread denny86
Gordon Sim wrote: > > > So the crash was happening when you were manually accepting. Was autoAck > set to 0 or left as the default value? > > Yes crash occur, when calling messageAccept() Left autoAck as default value. Or non-zero. doesn't matter > Really? I would have expected that to

Re: Bad allocation error

2010-01-11 Thread denny86
Gordon Sim wrote: > > If not can you try the attached test program? It will listen for a > configurable number of messages on queues a, b and c (all bound to > amq.fanout for convenience). I can consume 10 million messages from each > queue without seeing any issue (neither crashes nor memor

Re: Bad allocation error

2010-01-11 Thread denny86
i will try it out now. thanks -- View this message in context: http://n2.nabble.com/Bad-allocation-error-tp4265473p4289738.html Sent from the Apache Qpid users mailing list archive at Nabble.com. - Apache Qpid - AMQP Messagin

Re: Bad allocation error

2010-01-10 Thread denny86
Gordon Sim wrote: > > > The simplest way (in my view) is to pass in an instance of > SubscriptionSettings to each SubscriptionManager::subscribe() call. > > However if the default settings work for you (and it sounds like they > might?) then you don't even need to do that. Just call subscrib

Re: Bad allocation error

2010-01-08 Thread denny86
Gordon Sim wrote: > > In your first mail you stated you were using ACQUIRE_MODE_NOT_ACQUIRED. > Are you in fact using ACQUIRE_MODE_PRE_ACQUIRED? If so that is what I > was suggesting. In that case you do not need to manually acquire at all. > Initially, i set to ACQUIRE_MODE_NOT_ACQUIRED and

Re: Bad allocation error

2010-01-08 Thread denny86
Gordon Sim wrote: > > > Maybe worth asking as an aside at this point why it is you want to > subscribe in unacquired mode? Do you want to acquire every message you > receive? If so the pre-acquired mode will do that more simply and > efficiently. > > All i need is to confirm each message

Re: Bad allocation error

2010-01-08 Thread denny86
denny86 wrote: > > I have a similar solution [not tried yet] to my problem. > > http://n2.nabble.com/ATL-Project-td2944757.html > > But that is referring to an ATL project. mine is not ATL. anyways will try > out what Steve says. > > didnt work out -- V

Re: Bad allocation error

2010-01-08 Thread denny86
I have a similar solution [not tried yet] to my problem. http://n2.nabble.com/ATL-Project-td2944757.html But that is referring to an ATL project. mine is not ATL. anyways will try out what Steve says. hope i'm not spamming here. =^D Regards, Denny -- View this message in context: http://n2.na

Re: Bad allocation error

2010-01-07 Thread denny86
Further research, i found that queue with min queue depth will dequeue the message even if i dont acquire and accept those messages in that queue. How is that possible? I didnt turn on auto delete. To verify that if have not gone wrong somewhere, I checked the instances of subscription class fo

Re: Bad allocation error

2010-01-07 Thread denny86
Gordon Sim wrote: > > On 01/07/2010 01:19 PM, denny86 wrote: >> >> >> >> Gordon Sim wrote: >>> >>> >>> Each subscription will have its own Subscription instance. You will need >>> to acquire and accept messages rec

Re: Bad allocation error

2010-01-07 Thread denny86
Gordon Sim wrote: > > > Each subscription will have its own Subscription instance. You will need > to acquire and accept messages received from each queue through the > relevant Subscription object. > Yes... i am working on that already Is session.sync(); required after sending Compl

Re: Bad allocation error

2010-01-07 Thread denny86
denny86 wrote: > > > > Yes, got it.. Using session to acquire and accept messages would fail > after sometime. But using Subscription Instance, i face no problem. > > Now enqueue/dequeue operations are working smooth.. No issues so far, > 200,000 message

Re: Bad allocation error

2010-01-07 Thread denny86
Gordon Sim wrote: > > Yes, got it.. Using session to acquire and accept messages would fail after sometime. But using Subscription Instance, i face no problem. Now enqueue/dequeue operations are working smooth.. No issues so far, 200,000 messages processed without fail. ;) Thank you Gordon

Re: Bad allocation error

2010-01-07 Thread denny86
Gordon Sim wrote: > > > They are on the Subscription class, you get one of those returned from > SubscriptionManager::subscribe(). > > Yes i found it.. i misread ur early post. i looked upon SubscriptionManager and not Subscription class... Going to try that now.. tnx & regards, Denny --

Re: Bad allocation error

2010-01-07 Thread denny86
Gordon Sim wrote: > > Try changing this to use the acquire() and accept() messages on the > Subscription class (you get an instance of this returned when you call > subscribe() on SubscriptionManager. > Sorry i can't find acquire() and accept() member functions within the SubscriptionManag

Re: Bad allocation error

2010-01-07 Thread denny86
Gordon Sim wrote: > > Sounds like your client process is running out of memory(?). This is > using the 0.5 code, right? > Yes. I'm using 0.5 version. I didnt figure out any memory leaks initially. Gordon Sim wrote: > > Try changing this to use the acquire() and accept() messages on the >

Bad allocation error

2010-01-07 Thread denny86
Hi, I stumbled upon following error while listening to messages Listening for messages [Press Ctrl+C to Quit]...2010-jan-07 13:45:13 error FAIL [2737 192.168.99.44:5672]: bad allocation (.\qpid\client\Connector.cpp:396) 2010-jan-07 13:45:13 warning Connection closed Connection closed I'm usin

Re: Qpid persistent storage using Berkeley DB/SQL

2010-01-06 Thread denny86
Hi, I found it.. Thanks. Will go through the code. Regards, Denny Gordon Sim wrote: > > On 01/06/2010 11:12 AM, denny86 wrote: >> Couldn't find it in the qpid truck [ >> https://svn.apache.org/repos/asf/qpid/trunk/qpid/ ]. > > Its within the cpp tree: &

Re: Qpid persistent storage using Berkeley DB

2010-01-06 Thread denny86
o and it seems to be working > fine. > > Michel > > - Original Message - > From: "denny86" > To: users@qpid.apache.org > Sent: Wednesday, January 6, 2010 11:24:08 AM > Subject: Re: Qpid persistent storage using Berkeley DB > > > H

Re: Qpid persistent storage using Berkeley DB

2010-01-06 Thread denny86
Hi, Thanks for your reply. Well in fact, SQL will do. I'm not sticking to BDB only. If you [or anyone here] could shed some light regarding this SQL implementation, I would be grateful. :) Thanks & Regards, Denny Robert Godfrey wrote: > > Hi Denny, > > 2010/1/6

Qpid persistent storage using Berkeley DB

2010-01-05 Thread denny86
Hi, I'm using C++ Broker along with C++ Clients, both running in win32 platforms. I would like to implement Berkeley DB persistent storage. I have seen an example of persistence library at http://qpidcomponents.org/download.html#persistence QpidComponents . But the same is implemented for li