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 Mon, 13 Jun 2016 08:40:57 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message