activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce <michael.andre.pea...@me.com>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Wed, 31 May 2017 20:16:03 GMT
@Clebert 

As a extension to the JMS Client.

Just to set the real use case

We want to send Avro records, we know that with a schema registry the serialised bytes are
of orders of magnitude less and also faster at serialising than letting the java serialisation
do it. As well it allows for version projection of the data. 

Though obviously we know/aware that others may want to use other serialisation of their objects.

Intent is just to plug / configure the serialisation/deserialisation impl in the connection
factory. So on ObjectMessage send if present instead of Java serialisation that occurs currently
it uses the custom serdes.
Very similar to kafka producer/consumer.  









Sent from my iPhone

> On 31 May 2017, at 20:02, Clebert Suconic <clebert.suconic@gmail.com> wrote:
> 
> I'm a bit confused about what API are you talking about...
> 
> do you intend for having that as an extension of the JMS Client..
> (including qpid).. or as a tooling in which you could convert bytes
> and buffers to the intended format.
> 
> On Wed, May 31, 2017 at 2:44 PM, Michael André Pearce
> <michael.andre.pearce@me.com> wrote:
>> Hi Matt,
>> 
>> I would suggest that serdes have to provide a mime type, we will have to add method
to expose this, and then we set content-type to the provided mime type string.
>> 
>> Maybe simple method:
>> 
>> String mimeType()
>> 
>> As such if on byte message on consume if custom serdes exist and content type header
exists and matches that returned from the serdes we deserialise via custom.
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On 31 May 2017, at 17:58, Matt Pavlovich <mattrpav@gmail.com> wrote:
>>> 
>>> Hey Mike-
>>> 
>>> You bring up some good points about keeping the serialization simple and separate.
I’m good w/ that approach.
>>> 
>>> The API you propose doesn’t seem to indicate a place to touch the message headers.
Are you suggesting that the Artemis client-side SerDes handler would have a convention where
it would set the classname or other in a standard header? BTW— I think that defining a standard
convention would be preferred. users could still have access to headers / properties ahead
of calling the .send(..).
>>> 
>>> -Thanks,
>>> Matt
>>> 
>>>> On May 30, 2017, at 9:00 PM, Michael André Pearce <michael.andre.pearce@me.com>
wrote:
>>>> 
>>>> Hi Matt,
>>>> 
>>>> I think having just a SerDe interface for payload handling separate from
a general interceptor / client side plugin, is beneficial as then it keeps the logic for serialsation
well encapsulated. And also cleaner if we need to do anything (eg sending it as a bytesmessags
with a header flag)
>>>> 
>>>> I see this very much like difference in kafka where you have payload serialisation
(serdes) and custom-plugin (interceptors)
>>>> 
>>>> Also having just a serde makes interface for people to implement and care
about much simpler. Eg this is almost the interface I would expect:
>>>> 
>>>> byte[] serialize(Destination destination, Object o)
>>>> 
>>>> Object deserialize(Destination destination, byte[] bytes)
>>>> 
>>>> Nice and simple to implement without having to care about anything else.
>>>> 
>>>> Cheers
>>>> Mike
>>>> 
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 30 May 2017, at 23:18, Matt Pavlovich <mattrpav@gmail.com> wrote:
>>>>> 
>>>>> Michael-
>>>>> 
>>>>> +1 dealing with bytes messages is preferred to object messages and custom
object SerDes is super useful.
>>>>> 
>>>>> What do you think about considering a generic client-side plugin approach
vs just a payload handler?
>>>>> 
>>>>>> On May 30, 2017, at 4:03 PM, Michael André Pearce <michael.andre.pearce@me.com>
wrote:
>>>>>> 
>>>>>> If present then this would be used to serialise the Object instead
of the default, and subsequently create/convert to a BytesMessage, with a header set to denote
it was custom serialised.
>>>>> 
>>> 
> 
> 
> 
> -- 
> Clebert Suconic

Mime
View raw message