2010/1/20, Jon Watte <[email protected]>:

> Would you expect the behavior of calling getObjects() when you haven't
> provided your own outlet to be to wait until there are some objects to
> return?


Well, when you run the broker there are some default objects created on it:
the default amqp exchanges, management queue, bindings, ....
So there are always "objects" on a running broker. So even if it's some kind
of polling it should return a non empty-list I guess. But I am not very
clear about what an object is really.
Anyway, I am a Qpid newbie too and  for the moment I am just trying to
understand how it is supposed to work rather than expecting things :)
The fact that the console application in the qmf-console C++ example
provided with Qpid returns 0 objects to me on a Linux configuration, but not
on Windows, makes me think that maybe something's wrong with my
configuration. I haven't found any bug report on this example so I guess
it's supposed to work properly.

I would be glad if someone could run the C ++ console program on a C++
broker (Linux version) and compare its output with mine.
You can find console on :
http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/examples/qmf-console/
Details on my output are in my previous post on this thread.

Thanks,

Edlira


Actually, as I said in my previous mail, the console application that is in
the qmf-console C++ example (that comes with the
C++ Qpid client + broker in order to demonstrate teh QMF console use)
returns no objects to me.
This application is supposed to
I didn't find any bug reported on this example,




On Wed, Jan 20, 2010 at 3:21 AM, Edlira Nano <[email protected]> wrote:
>
> > Hi again,
> >
> > I have the same problem of getObjects() returning an empty list when I
> run
> > the ./console program in the C++ qmf-console example from trunk.
> > I always get as output :
> > " Creating SessionManager
> > Adding broker
> > Package List:
> > getting exchanges...
> >   returned 0 elements
> > getting queues...
> >   returned 0 elements "
> >
> > Now I tried adding a sleep(1) right before the getObjects(list, "queue").
> > My
> > output now is :
> > " Creating SessionManager
> > Adding broker
> > Package List:
> > getting exchanges...
> >   returned 0 elements
> > getting queues...
> >   returned 2 elements
> > queue: org.apache.qpid.broker:queue[0-218-1-0-3]
> > 0-0-1-0-1152921504606846979:message_queue
> >   bindingCount=2
> >  arguments={}
> > queue: org.apache.qpid.broker:queue[0-218-1-0-555]
> > 0-0-1-0-1152921504606846979:qmfc-4a785e26-5e71-46dd-b595-8abab0f83352
> >  bindingCount=4
> >  arguments={}
> > Broker: org.apache.qpid.broker:broker[0-0-1-0-1152921504606846978]
> > 0-0-1-0-1152921504606846977:5672
> > Call echo method...
> > Result: code=0 text=OK
> >   Output Arg: body => Testing...
> >   Output Arg: sequence => 1"
> >
> > So it does get a non-empty queue-objects list but an empty exchanges
> list.
> > Now, adding a sleep(1) right before the getObjects(list, "exchange") and
> > removing the sleep(1) before the getObjects(list, "queue") :
> > "
> > Creating SessionManager
> > Adding broker
> > Package List:
> > getting exchanges...
> >   returned 6 elements
> > ....."listing the exchanges"
> > getting queues...
> >   returned 2 elements
> > queue: org.apache.qpid.broker:queue[0-218-1-0-3]
> > 0-0-1-0-1152921504606846979:message_queue
> >   bindingCount=2
> >  arguments={}
> > queue: org.apache.qpid.broker:queue[0-218-1-0-563]
> > 0-0-1-0-1152921504606846979:qmfc-aa1d0774-417a-48d5-8af1-a18805b2f532
> >  bindingCount=4
> >  arguments={}
> > Broker: org.apache.qpid.broker:broker[0-0-1-0-1152921504606846978]
> > 0-0-1-0-1152921504606846977:5672
> > Call echo method...
> > Result: code=0 text=OK
> >   Output Arg: body => Testing...
> >   Output Arg: sequence => 1
> > "
> > So now I get a non-empty list every time I call getObjects().
> >
> > So new question :
> >  Is the native ./console example behaving the same way as on my CentOs
> > (with
> > qpid from trunk)
> > on other Linux platforms you guys are using?( I know it  behaves as it
> > should on the Windows version of the example).
> > Cause maybe there's something particular with my configuration. The only
> > odd
> > thing  I have noticed so far with my broker
> > is that I have continous warnings "Timer woken up Xms late". Maybe
> somehow
> > this is the cause of all it.
> >
> > Thanks again :)
> > Edlira,
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2010/1/20, Edlira Nano <[email protected]>:
> > >
> > > Thanks for your answer :)
> > >
> > > Indeed, when I add a sleep(1), the getObjects() seems to always return
> a
> > > non empty object list at first attempt.
> > > But the problem is that according to documentation my program is
> supposed
> > > to do synchronous-only operations.
> > > Maybe I have misunderstood something, but in the
> console/SessionManager.h
> > > class one can read :
> > >
> > > "/** Create a new SessionManager
> > >  *
> > >  * Provide your own subclass of ConsoleListener to receive updates and
> > indications
> > >  * asynchronously or leave it as its default and use only synchronous
> > methods. ...
> > >
> > >
> > >  QPID_CONSOLE_EXTERN SessionManager(ConsoleListener* listener = 0,
> > >                                        Settings settings =
> Settings());"
> > >
> > >
> > > My program uses the default  listener, I thought that the C++
> > getObjects()
> > > would therefore work
> > > synchronously, as it does when following the QMF python console
> tutorial
> > > synchronous style.
> > >
> > > So my question is :
> > > I want no updates on my objects, is there a way to use the C++
> > getObjects()
> > > in a synchronous style like in the qmf python console
> > > (which by the way works fine for me, I never get an empty list of
> objects
> > > with that)?
> > >
> > > Edlira,
> > >
> > > 2010/1/19, Jon Watte <[email protected]>:
> > >
> > >> Here's just guessing from reading the code you posted:
> > >>
> > >> That looks like a spin loop to me. If the objects arrive
> asynchronously,
> > >> you
> > >> won't know how many iterations it will take, because it is timing
> > >> dependent.
> > >> If you add sleep(1) right before you call getObjects() in the loop,
> how
> > >> does
> > >> it behave in that case?
> > >>
> > >> If the documentation contradicts this guess, then I'd vote for
> trusting
> > >> the
> > >> documentation, though :-)
> > >>
> > >> Sincerely,
> > >>
> > >> jw
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Americans might object: there is no way we would sacrifice our living
> > >> standards for the benefit of people in the rest of the world.
> > >> Nevertheless,
> > >> whether we get there willingly or not, we shall soon have lower
> > >> consumption
> > >> rates, because our present rates are unsustainable.
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Jan 19, 2010 at 8:46 AM, Edlira Nano <[email protected]>
> > >> wrote:
> > >>
> > >> > Hi everyone,
> > >> >
> > >> > I am using C++ Broker along with C++ Clients built from trunk on
> > RedHat
> > >> > CentOS.
> > >> >
> > >> > First I noticed that the ./console program from the qmf-console
> > example
> > >> > wasn't
> > >> > getting any object from the broker (while ping and queuestats work
> > fine)
> > >> >
> > >> > Then, I did a little program that uses getObjects() from the console
> > >> > SessionManager
> > >> > and noticed that it is not getting any queue object every time I
> call
> > >> it.
> > >> >
> > >> > Here is what I'm doing :
> > >> > - A broker is running on localhost:5672
> > >> > - A queue named "message_queue" has been created on it (using
> > >> > declare_queues from the direct example)
> > >> > - I wrote the following program which uses getObjects() to get a
> list
> > >> > of queue objects from the broker,
> > >> >  looks for the queue named "message_queue" in the list and prints
> > >> > some information about it. The program
> > >> > is not even implementing its own ConsoleListener like ./console, but
> > >> > it'using the default one  :
> > >> >
> > >> > #include "qpid/console/SessionManager.h"
> > >> > using namespace std;
> > >> > using namespace qpid::console;
> > >> >
> > >> > int main_int(int /*argc*/, char** /*argv*/)
> > >> > {
> > >> >  qpid::client::ConnectionSettings connSettings;
> > >> >
> > >> >  SessionManager sm;
> > >> >  Broker* broker = sm.addBroker(connSettings);
> > >> >
> > >> >  Object::Vector list;
> > >> >  int counter = 0;
> > >> >
> > >> >  do {
> > >> >    counter++;
> > >> >    cout << "Getting queue objects list, attempt no " << counter <<
> > endl;
> > >> >    sm.getObjects(list, "queue");
> > >> >    cout << "   returned " << list.size() << " elements" << endl;
> > >> >  }
> > >> >  while(list.empty());
> > >> >
> > >> >  for (Object::Vector::iterator i = list.begin(); i != list.end();
> > >> >       i++) {
> > >> >    cout << "queue: " << *i << endl;
> > >> >    if ((i->attrString("name")) == "message_queue") {
> > >> >      cout << "nbMessages: " << i->attrUint64("msgDepth") << endl;
> > >> >      cout << "size: " << i->attrUint64("byteDepth") << endl;
> > >> >      break;
> > >> >    }
> > >> >  }
> > >> >  sm.delBroker(broker);
> > >> >  return 0;
> > >> > }
> > >> >
> > >> > int main(int argc, char** argv)
> > >> > {
> > >> >    try {
> > >> >        return main_int(argc, argv);
> > >> >    } catch(std::exception& e) {
> > >> >        cout << "Top Level Exception: " << e.what() << endl;
> > >> >    }
> > >> > }
> > >> >
> > >> > Here are the last lines of the output I get from the above program :
> > >> >
> > >> > Getting queue objects list, attempt no 705
> > >> >   returned 0 elements
> > >> > Getting queue objects list, attempt no 706
> > >> >   returned 4 elements
> > >> > queue: org.apache.qpid.broker:queue[0-217-1-0-3]
> > >> > 0-0-1-0-1152921504606846979:message_queue
> > >> > nbMessages: 11
> > >> > size: 108
> > >> >
> > >> > So, i have to do getObjects() 706 times to get a non empty list of
> > >> > queue objects.
> > >> > The number of attempts varies from one call to another, the max I
> get
> > >> > is around 1200 times, the minimum
> > >> > 120 times.
> > >> >
> > >> > Does anyone have any idea about this?
> > >> >
> > >> > Thanks,
> > >> > Edlira
> > >> >
> > >>
> > >
> > >
> >
>

Reply via email to