cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Savva Kolbachev <s.kolbac...@gmail.com>
Subject Re: Cayenne ROP Improvements
Date Thu, 05 May 2016 21:39:34 GMT
Hi Andrus,

> So which one is the default, Hessian or Java?
We still use Hessian for serialization by default
https://github.com/apache/cayenne/blob/master/cayenne-server/src/main/java/org/apache/cayenne/rop/HessianROPSerializationService.java
But we use java.net.URLConnection for establish connection and sending
messages from client to server
https://github.com/apache/cayenne/blob/master/cayenne-client/src/main/java/org/apache/cayenne/rop/http/HttpROPConnector.java
So we have escaped from Hessian only in connectivity layer.

> I don't have a problem with Protostuff being a recommended default, but
for dependency management purposes I'd rather we split all third-party
integrations in separate modules, and use whatever provider is hooked up in
runtime. Kind of what we do with Joda/Java8 extensions.
I already did it in this way. I created separate module for Protostuff
serialization.

As Hessian serialization has some troubles with Java8 types and provide
less efficient serialization than Protostuff, I suggest to use Protostuff
as default serialization service or to use Java serialization. So I just
suggest to escape from Hessian :)

2016-05-05 19:41 GMT+03:00 Savva Kolbachev <s.kolbachev@gmail.com>:

> Hi Ari,
>
> Looks like Protostuff works faster than Protobuf in some cases. For
> example Serializers (no shared refs) and Cross Lang Binary Serializers
> sections here http://hperadin.github.io/jvm-serializers-report/report.html
>
> In our case we need to serialize graph of objects (Full Object Graph
> Serializers section in link above). Protobuf can't do it out of the box
> but Protostuff can. In my implementation I use protostuff-graph-runtime
> which generates a schema from objects at runtime and caches it.
>
> Protostuff schema is something like .proto files but in Java:
> http://www.protostuff.io/documentation/schema/
> Runtime schema: http://www.protostuff.io/documentation/runtime-schema/
>
> As you could see in benchmarks there is a small difference in efficiency
> between protostuff-graph and protostuff-graph-runtime. The ser/deser
> overhead is related to runtime schema generation. The size penalty is that
> Protostuff adds class name for objects and than uses those for find
> appropriate classes via reflection.
> Hessian also adds fields names so the size of Hessian serialization is
> much bigger. In my small example with selection of 6 objects Hessian
> serialization size is more than 2400 bytes while Protostuff runtime is
> about 800 bytes.
>
> If we don't want to have ser/deser and size overhead we could find a way
> to generate schemas via Velocity. And we should provide schemas for some
> Cayenne classes. But it will require a lot of efforts.
>
>
> 2016-05-05 13:44 GMT+03:00 Aristedes Maniatis <ari@maniatis.org>:
>
>> On 5/05/2016 7:35pm, Savva Kolbachev wrote:
>> > Protostuff (licensed under Apache 2.0 licence) is based on Google's
>> > Protocol-Buffers (Protobuf) but has some optimizations and some cool
>> things
>> > like runtime serialization graph of objects (like Hessian). It also
>> could
>> > generate schema on runtime so we shouldn't define .proto files although
>> it
>> > might increase efficiency. It works faster than Hessian and could handle
>> > Java8 Date and Time types. Here is some benchmarks. Take a look at Full
>> > Object Graph Serializers section.
>> > http://hperadin.github.io/jvm-serializers-report/report.html
>> > https://github.com/eishay/jvm-serializers/wiki
>>
>> According to those benchmarks there appears to be no performance or size
>> penalty to using protostuff over protobuffers. Am I reading that right?
>>
>> I don't really understand... doesn't the serialiser have to construct a
>> .proto definition and then include it in the message? So shouldn't it be
>> faster/smaller to predefine these?
>>
>> If we did, we could create them with velocity in the same way we create
>> Java _superclasses today. Fairly trivial I'm guessing.
>>
>> Ari
>>
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>>
>
>
>
> --
> Thanks and Regards
> Savva Kolbachev
>



-- 
Thanks and Regards
Savva Kolbachev

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message