On 03/16/2010 06:05 PM, Kerry Bonin wrote:
r/e headers - I do see the same thing you listed (when I use quotation
marks, I'm on Win32). Your comment implies the basis for my question -
digging into the source I now see properties are internally split into
MessageProperties and DeliveryProperties, and I was expecting to see those
fields when I called getHeaders().
The messaging API is intended to abstract out protocol specifics. So
there are explicit setters/getters for attributes of a message (e.g.
userid or ttl) and these will be mapped on to the underlying protocol
used (in the case of AMQP 0-10, onto fields in Message- or Delivery-
Properties). Then there are generic properties available to applications
for their own purposes. These are name value pairs. In AMQP 0-10 they
map onto MessageProperites::applicationHeaders.
r/e timestamps
- One common use case we have is to have clients synchronize distributed
data sets, which we do by providing a snapshot via request - response as
well as an update broadcast via publish - subscribe. We use timestamps to
determine when an update event was sent relative to the snapshot. We were
including our own timestamp field in the message body for this, and thought
we could use message timestamps.
- Another common use case is to broadcast events. We care when these were
sent, and historically have included a UTC event time in the message that is
used (in part) to identify the event. Again, we could include our own
timestamp in the message body for this, but we thought we could use the
message timestamp for this - so long as it is the time of creation or first
transmission. We haven't seen documentation on the expected behavior of
message timestamps across federated and/or clustered systems, or through
durable queues.
So the timestamp is set by the sender and refers to the creation of the
message or to the time of the event the message represents? (i.e. the
detailed semantics are application specific?)
r/e the asynchronous APIs, this is more of a nice to have, but we have C++
and Python developers who liked not having to create service threads to read
asynchronously for the previous API. Event loops are common, but not always
used...
I agree its nice to have something there out of the box. However even in
the old 0-10 specific API the only really usable solution was
SubscriptionManager::run(). I think you could replace the functionality
of that method with:
typedef std::map<std::string, MessageListener*> Callbacks;
Callbacks callbacks;
//populate per subscription listeners
Listener* default = //default callback
while (true) {
Receiver r = session.nextReceiver();
Callbacks::const_iterator i = callbacks.find(r.getName());
if (i == callbacks.end()) {
default->received(r.fetch());
} else {
i->second->received(r.fetch());
}
}
You can also customise that loop more, e.g. by timing out if nothing is
received after a certain time, or having different strategies for
dispatching the messages to listeners/callbacks.
The above of course still requires a thread per session, but that is no
worse than the old API. The plan is to add the ability to tie in waiting
on one or more connection to the same pattern.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
