Have fun on your vacation, but actually I have a question (with an implied complaint): how do I serialize and deserialize `message.correlation_id()`?
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, 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? 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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
