cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Cayenne ROP Improvements
Date Thu, 16 Jun 2016 13:23:45 GMT
> Please, let me know what do you think about all this things?

Sounds reasonable to me. 

> Finally, as Cayenne is becoming more modular, it will be helpful to have
> server and client test jars. It is sometimes frustrating to write
> integration tests for new modules.

No objections here. Let's make sure we set deploy plugin "skip" property to "true". We don't
want them to be part of releases.

Andrus



> On Jun 13, 2016, at 11:40 AM, Savva Kolbachev <s.kolbachev@gmail.com> wrote:
> 
> After some time I think that my current HTTP/2 ROP implementation for
> Cayenne [1] is cumbersome and complicated. I want to refactor it and make
> it as clear as possible, so it will be simple to use out of box.
> So, I suggest to rename module to something like "cayenne-jetty-client" and
> implement only two ROPConnectors: JettyHttpConnector and
> JettyHttp2Connector for HTTP/1.1 and HTTP/2 accordingly. Both will use
> high-level Jetty Client API.
> If someone wants something specific, they could provide their own similar
> implementation. I think the most common case for this is to share one
> HttpClient between ROP and other parts of a project.
> In addition, we will be open to make more modules for other clients, like
> Apache HTTP Client, Netty, OkHttp and etc.
> 
> BTW, I got rid of Hessian ServiceContext in ROPServlet [2] by implementing
> something very similar in Cayenne
> https://github.com/apache/cayenne/commit/85852f92ee05f5e1ae70dae7315beda32f2b4077
> So now Hessian is used only for serialization purposes. As we want to move
> all ROP functionality to the separate module and Hessian serialization has
> problems with Java8, we should decide which serialization service should be
> used by default. For example Protostuff or Java serialization. Hessian one
> we could remain as pluggable.
> 
> Finally, as Cayenne is becoming more modular, it will be helpful to have
> server and client test jars. It is sometimes frustrating to write
> integration tests for new modules.
> 
> Please, let me know what do you think about all this things?
> 
> [1] https://github.com/apache/cayenne/pull/96
> [2] https://issues.apache.org/jira/browse/CAY-2090
> 
> 
> 2016-05-06 3:29 GMT+03:00 Andrus Adamchik <andrus@objectstyle.org>:
> 
>> Good idea. The server part should probably be split from cayenne-server.
>> 
>> Andrus
>> 
>>> On May 5, 2016, at 8:26 PM, Aristedes Maniatis <ari@maniatis.org> wrote:
>>> 
>>> Perhaps the whole of ROP becomes an optional module?
>>> 
>>> Ari
>>> 
>>> 
>>> On 6/05/2016 10:18am, Andrus Adamchik wrote:
>>>> It's been a while since I touched the ROP code. Back in the day Java
>> serialization "kind of worked", but not completely. So you are probably
>> right that it is not a real option. I am just trying to avoid new
>> dependencies (even optional) on third-party libs in the Cayenne core. So
>> perhaps we can simply leave out any "default" serialization and always
>> require an explicit serialization provider.
>>>> 
>>>> Andrus
>>>> 
>>>>> On May 5, 2016, at 8:12 PM, Aristedes Maniatis <ari@maniatis.org>
>> wrote:
>>>>> 
>>>>> Maybe I'm not understanding correctly, but I don't think Java
>> serialisation has been implemented in ROP. The work Dima did was to move
>> away from the Hessian servlet stuff for making the HTTP connection, to
>> plain Java with the option for plugging in Jetty libraries for HTTP/2.
>>>>> 
>>>>> The work Savva did just now was to use protostuff for serialisation,
>> but I'm not sure what's now needed if we wanted plain Java serialisation or
>> whether that's even possible without some sort of library to handle an
>> object graph with cycles.
>>>>> 
>>>>> Or at least that's my understanding.
>>>>> 
>>>>> Ari
>>>>> 
>>>>> 
>>>>> On 6/05/2016 9:55am, Andrus Adamchik wrote:
>>>>>> Thanks for clarification. I would say use Java serialization as a
>> default, and make it easy to plugin Hessian and Protostuff as separate
>> modules.
>>>>>> 
>>>>>> A.
>>>>>> 
>>>>>>> On May 5, 2016, at 5:39 PM, Savva Kolbachev <s.kolbachev@gmail.com>
>> wrote:
>>>>>>> 
>>>>>>> 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
>>>>>> 
>>>>> 
>>>>> --
>>>>> -------------------------->
>>>>> Aristedes Maniatis
>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>>>> 
>>> 
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>> 
>> 
> 
> 
> -- 
> Thanks and Regards
> Savva Kolbachev


Mime
View raw message