You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Hickerson, David A" <da...@boeing.com> on 2011/03/15 01:16:16 UTC
messaging::Message API documentation
I put a Jira issue up for documentation on messaging::Message as suggested.
A little background: I am writing a Qpid communication for a system to receive a variety of data and data types and am trying to get an idea of how I can determine data type information from a Message class object so de-marshaling of the data into objects or strings can be handled.
Here are questions I posted in the Jira issue on Message:
1. Can you tell by calling getContentType whether to call getContent or getContentPtr or getProperties, or does that
require the sender to set the content type? Is there a convention or is there a helping class like possibly Variant?
2. If using the xml mentioned in the AMQP Messaging (Part 2), does Variant.getString() return that xml?
3. By setting TTL, Durable, Redelivered, what behavior does the system exhibit?
4. Does the broker modify any of the settings or are they only for use by the broker? MessageId?
5. Are there any conventions that should be followed for string data in this class that are used in other AMQP systems or language versions of Apid?
Thanks,
Dave
David Hickerson david.a.hickerson@boeing.com<ma...@boeing.com>
Senior Engineer phone: 719-235-3265
Mission Operations
The Boeing Company
1330 Inverness Dr., Suite 330
Colorado Springs, CO 80910
Re: messaging::Message API documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
3. By setting TTL, Durable, Redelivered, what behavior does the system
exhibit?
>
>> TTL, will cause the message to be dequeued and discarded if the TTL has
>> been reached.
>>
>> Durable will cause the message to be written to disk, if the queue it is
>> being routed to is marked as durable.
>>
>> Redelivered is set when a consumer read a message, and then rejects it.
>> The flag is an indication that the
>> message delivery is being re-attempted for the next consumer trying to
>> consume it
>>
>>
> Redelivered will also be set if a message was delivered to a client but who
> has not had time to ack it due to,
>
Rather than saying 'not had time to ack', it's more correct to say 'was
unable to ack'.
> 1) Broker failover
> 2) Client error.
>
In addition to the above 2 cases, a message will be marked redelivered if,
3) A consumer 'releases' a message [*] .
4) A sender had to replay (resend) a message due to failover.
[*] A consumer could release a message for a variety of reasons. By
releasing a message the application notifies the broker that it is no longer
interested in the message. An application cannot release a message that has
already been acknowledged.
> I am not sure if rejected messages are not redelivered. Alan can you please
> confirm.
> A bit later I will actually test this out and let you know.
>
>>
>>
I verified that rejected messages are *not* redelivered. Instead they are
just dropped from the queue.
Therefore if I an application receives a message marked "redelivered" then
the application can safely assume that it wasn't rejected by another
consumer.
The C++ message API clearly states that under the reject method as well.
Re: messaging::Message API documentation
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Mar 16, 2011 at 11:50 AM, Carl Trieloff <cc...@redhat.com>wrote:
>
> 1. Can you tell by calling getContentType whether to call getContent
>> or getContentPtr or getProperties, or does that
>> require the sender to set the content type? Is there a convention or is
>> there a helping class like possibly Variant?
>>
>
> In most cases it requires the sender to set it. If you are using mapped
> message, I believe we set it
>
>
The content type should be set by the client lib for text, list and map
messages across JMS, Python, C++ (and the swig clients off the C++ clients)
with the following exceptions.
map - amqp/map
text - text/plain - for c++ the sender needs to explicitly set it.
list - amqp/list (The JMS client has no direct support for list messages)
if no content type is specified, all clients will treat the payload as
binary.
The JMS client has explicit support for binary via
"application/octet-stream".
Anything else the application will need to explicitly specify the content
type and handle them accordingly at the application level.
>
>
>> 3. By setting TTL, Durable, Redelivered, what behavior does the
>> system exhibit?
>>
>
> TTL, will cause the message to be dequeued and discarded if the TTL has
> been reached.
>
> Durable will cause the message to be written to disk, if the queue it is
> being routed to is marked as durable.
>
> Redelivered is set when a consumer read a message, and then rejects it. The
> flag is an indication that the
> message delivery is being re-attempted for the next consumer trying to
> consume it
>
>
Redelivered will also be set if a message was delivered to a client but who
has not had time to ack it due to,
1) Broker failover
2) Client error.
I am not sure if rejected messages are not redelivered. Alan can you please
confirm.
A bit later I will actually test this out and let you know.
>
> 4. Does the broker modify any of the settings or are they only for
>> use by the broker? MessageId?
>>
>
> Application headers are not touched.
>
> Delivery headers may be updated, for example Sequence numbers can be
> inserted, or we also insert tags for
> federation etc.
>
> MessageID is a client set property.
>
>
> 5. Are there any conventions that should be followed for string data
>> in this class that are used in other AMQP systems or language versions of
>> Apid?
>>
>>
>
binary, text and map data is supported across all clients.
there is no direct support for list messages in JMS - you can however
insert a list inside a map message :)
>
> If you want cross client data interop, take a look at mapped message.
>
>
>
> Thanks,
>>
>> Dave
>>
>> David Hickerson
>> david.a.hickerson@boeing.com<ma...@boeing.com>
>> Senior Engineer
>> phone: <719-235-3265>719-235-3265
>> Mission Operations
>> The Boeing Company
>> 1330 Inverness Dr., Suite 330
>> Colorado Springs, CO 80910
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
Re: messaging::Message API documentation
Posted by Carl Trieloff <cc...@redhat.com>.
> 1. Can you tell by calling getContentType whether to call getContent or getContentPtr or getProperties, or does that
> require the sender to set the content type? Is there a convention or is there a helping class like possibly Variant?
In most cases it requires the sender to set it. If you are using mapped
message, I believe we set it
>
> 3. By setting TTL, Durable, Redelivered, what behavior does the system exhibit?
TTL, will cause the message to be dequeued and discarded if the TTL has
been reached.
Durable will cause the message to be written to disk, if the queue it is
being routed to is marked as durable.
Redelivered is set when a consumer read a message, and then rejects it.
The flag is an indication that the
message delivery is being re-attempted for the next consumer trying to
consume it
> 4. Does the broker modify any of the settings or are they only for use by the broker? MessageId?
Application headers are not touched.
Delivery headers may be updated, for example Sequence numbers can be
inserted, or we also insert tags for
federation etc.
MessageID is a client set property.
> 5. Are there any conventions that should be followed for string data in this class that are used in other AMQP systems or language versions of Apid?
>
If you want cross client data interop, take a look at mapped message.
> Thanks,
>
> Dave
>
> David Hickerson david.a.hickerson@boeing.com<ma...@boeing.com>
> Senior Engineer phone: 719-235-3265
> Mission Operations
> The Boeing Company
> 1330 Inverness Dr., Suite 330
> Colorado Springs, CO 80910
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org