qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: On vacation next week for 4 weeks.
Date Thu, 06 Jul 2017 18:01:38 GMT
On Wed, 2017-07-05 at 01:23 +0300, Fj wrote:
> Have fun on your vacation, but actually I have a question (with an implied
> complaint): how do I serialize and deserialize `message.correlation_id()`?

OOps, vacation message to mailing list was a goof, but since we are
here:

> Like, *naturally* when writing an AMQP bridge to some other application
> server, you have to do it asynchronously, and for that you have to pass
> through the `correlation_id` thing among other things. So that when the
> bridge receives a response from some application it knows where and how to
> send it. Which means either storing the original message in some std::map,
> which is fraught with soft memory leaks and actual crashes in my
> experience, 

Please raise JIRAs for such issues if you come across them again, that
definitely should not be the case.

> or you serialize the required stuff, so that you get all you
> need to send a response from some std::string field that was passed all the
> way around.
> 
> So, are there an Industry Best Practices™ regarding passing through the
> `correlation_id`?
> 
> What they should cover: the python class proton.utils.SyncRequestResponse
> that I'm using in tests uses `uint64_t` as `correlation_id` and expects the
> same `uint64_t` in the response. So in my actual C++ code I have to
> serialize to a string *both* the type of the original `correlation_id` and
> its value, and then deserialize when I'm sending a response with a correct
> type so that the python unit test passes (proton.utils.SyncRequestResponse
> checks the `correlation_id` against the original python int value). And, of
> course, I'd like some other client to get an uuid or string or whatever
> they originally sent as a correlation id.
> 
> Is there already some code that takes care of that, serializing a
> `correlation_id` into a csv or json or anything that could be passed around
> as a dumb string? Or do I have to write it myself?

Not to CSV or JSON that I know of. AMQP does of course define a binary
serialization (may contain NUL chars so not safe for C strings) - in
C++ you can use  proton::codec::encoder/decoder to stream arbitrary
data to/from AMQP binary form. proton::message has handy encode() and
decode() functions to serialize/deserialize an entire message.

HOWEVER: if you're just trying to preserve and pass on the value in
C++, you don't need to go that far: message::correlation_id
returns/takes a proton::message_id, which is a "holder" that can hold
any legal correlation-id value:

/// An AMQP message ID.
///
/// It can contain one of the following types:
///
///  - uint64_t
///  - std::string
///  - proton::uuid
///  - proton::binary
///
class message_id : public scalar_base { ...

So if you just care about passing the value along you can do something
like:

    proton::message_id x(incoming.correlation_id());
    ....
    outgoing.correlation_id(x);

Note there are several other similar "holders" with different
restrictions on what they can hold for type safety, the most general is
proton::value which can hold any AMQP data type, including lists, maps
etc.


> 
> Again, have fun on your vacation, but you said that you are here for three
> more days, and I couldn't resist asking what's on my mind.
> 
> On Tue, Jul 4, 2017 at 7:14 PM, Alan Conway <aconway@redhat.com> wrote:
> 
> > If you have anything that needs my urgent attention, ahhhahahahahhaaha!
> > 
> > But seriously, I have 4 days to commiserate with you before I do a
> > runner.
> > 
> > I am working on one urgent item before I go - add reconnect support to
> > the python qmf.client we created for Satellite. That is on track.
> > Otherwise I'm mostly involved in very new or very old projects that
> > should all be here when I get back.
> > 
> > Cheers,
> > Alan.
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> > 
> > 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message