On 03/16/2010 01:20 PM, Gordon Sim wrote:
On 03/16/2010 03:58 PM, Kerry Bonin wrote:
I'm looking at migrating to messaging, and have a few questions.
r/e Message :
- If headers has an accessor, why doesn't it work? It only returns an
empty
map.
It works for me (are you using trunk?):
$ ./examples/messaging/spout --address 'my-queue; {create: always}'
--property my-property=my-value
$ ./examples/messaging/drain --address 'my-queue; {create: always}'
Message(properties={my-property:my-value,
spout-id:eab53080-8f16-48db-b4cf-5cf9bb200ec0:0}, content='')
The above uses Message::getHeaders(), what do you see when you run those
examples?
(Note I'd actually like to change that to getProperties() for
consistency with the python client).
- Why isn't timestamp exposed? (Trust& TZ issues aside, it is common to
want this data, why require recreation?)
How would you expect the timestamp to be used?
r/e Receiver :
- Why did we lose the callback pattern? I now have to (at the least)
spin a
thread across all my receivers to collect asynchronously.
The idea is that some sort of generic dispatcher would be layered on top
of the current api. The plan is to extend or generalise the
Session::nextReceiver() pattern so that Sessions and indeed Connections
could be integrated into a common event loop.
IMO we need the API for that sooner rather than later, as it will be a blocker
to porting existing test programs. I will try to take a shot at it this week.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
