You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2020/08/26 17:28:08 UTC
[DISCUSS] Gryo 4.0
I was just perusing JIRA a bit and came across an item to upgrade to Kryo
4.0 for a performance enhancement:
https://issues.apache.org/jira/browse/TINKERPOP-2398
As I commented on that issue, which has not yet gotten a response, I
believe that upgrading to Kryo 4.0 breaks binary compatibility with Kryo
3.0 which would mean we would probably need to stamp out Gryo 4.0 as a
result.
I'm not sure I see the need to produce another version of Gryo as we've
deprecated it in Gremlin Server already and are pushing for wider use of
GraphBinary as a replacement for Gryo and GraphSON for network
serialization. I'm not sure where that leaves us with disk serialization
but the limitation Gryo has in not working off the JVM hampers it a bit for
what I think of as our current usage these days.
I'm inclined to continue us on a path to full deprecation of Gryo, even for
disk, in favor of GraphBinary, in which case, I don't think it's in our
interest to introduce Gryo 4.0. Does anyone have any thoughts on this topic?
Re: [DISCUSS] Gryo 4.0
Posted by Stephen Mallette <sp...@gmail.com>.
yes - javascript is the only one that is still on GraphSON as of 3.5.0.
On Mon, Dec 27, 2021 at 6:54 PM David Bechberger <da...@bechberger.com>
wrote:
> +1 on removing Gryo support
>
> It would be great to be able to simplify the serializer story. Is
> Javascript the only language without GraphBinary support now?
>
> Dave
>
> On Mon, Dec 27, 2021 at 11:48 AM Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > Just to clarify, I think you are suggesting the removal of the remaining
> > deprecated GryoMessageSerializer instances thus removing Gryo as a
> network
> > serialization option at 3.6.0. We would retain Gryo as it pertains to
> being
> > a file storage format.
> >
> > We removed Gryo Lite for 3.6.0, so complete removal isn't too far around
> > the corner. I dont think I have any problems with just doing it all for
> > 3.6.0. It would continue to simplify the serialization story if it wasn't
> > around. If we could then get Javascript on GraphBinary, we could then
> > retire typed GraphSON versions and promote a simple GraphSON format for
> > HTTP (like GraphSON 1.0).
> >
> > On Mon, Dec 27, 2021 at 7:56 AM Divij Vaidya <di...@gmail.com>
> > wrote:
> >
> > > I agree about sun setting Gryo perhaps starting with the 3.6.x release.
> > >
> > > The reasons for removing it from the code base are as follows:
> > > 1. Gryo serilization of properties is not consistent with the
> GraphBinary
> > > or Graphson. As an example, Gryo tries to fetch the label of the parent
> > > element when serializing a property whereas other serializers only
> > provide
> > > the ID of the parent element.
> > > 2. GraphBinary is a direct replacement with binary serialization
> support
> > > and better performance. GraphBinary support has also been expanded to
> > > Python and is the default serializer starting 3.5.x release train.
> > >
> > > Divij Vaidya
> > >
> > >
> > >
> > > On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette <
> spmallette@gmail.com>
> > > wrote:
> > >
> > > > I was just perusing JIRA a bit and came across an item to upgrade to
> > Kryo
> > > > 4.0 for a performance enhancement:
> > > >
> > > > https://issues.apache.org/jira/browse/TINKERPOP-2398
> > > >
> > > > As I commented on that issue, which has not yet gotten a response, I
> > > > believe that upgrading to Kryo 4.0 breaks binary compatibility with
> > Kryo
> > > > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as
> a
> > > > result.
> > > >
> > > > I'm not sure I see the need to produce another version of Gryo as
> we've
> > > > deprecated it in Gremlin Server already and are pushing for wider use
> > of
> > > > GraphBinary as a replacement for Gryo and GraphSON for network
> > > > serialization. I'm not sure where that leaves us with disk
> > serialization
> > > > but the limitation Gryo has in not working off the JVM hampers it a
> bit
> > > for
> > > > what I think of as our current usage these days.
> > > >
> > > > I'm inclined to continue us on a path to full deprecation of Gryo,
> even
> > > for
> > > > disk, in favor of GraphBinary, in which case, I don't think it's in
> our
> > > > interest to introduce Gryo 4.0. Does anyone have any thoughts on this
> > > > topic?
> > > >
> > >
> >
>
Re: [DISCUSS] Gryo 4.0
Posted by David Bechberger <da...@bechberger.com>.
+1 on removing Gryo support
It would be great to be able to simplify the serializer story. Is
Javascript the only language without GraphBinary support now?
Dave
On Mon, Dec 27, 2021 at 11:48 AM Stephen Mallette <sp...@gmail.com>
wrote:
> Just to clarify, I think you are suggesting the removal of the remaining
> deprecated GryoMessageSerializer instances thus removing Gryo as a network
> serialization option at 3.6.0. We would retain Gryo as it pertains to being
> a file storage format.
>
> We removed Gryo Lite for 3.6.0, so complete removal isn't too far around
> the corner. I dont think I have any problems with just doing it all for
> 3.6.0. It would continue to simplify the serialization story if it wasn't
> around. If we could then get Javascript on GraphBinary, we could then
> retire typed GraphSON versions and promote a simple GraphSON format for
> HTTP (like GraphSON 1.0).
>
> On Mon, Dec 27, 2021 at 7:56 AM Divij Vaidya <di...@gmail.com>
> wrote:
>
> > I agree about sun setting Gryo perhaps starting with the 3.6.x release.
> >
> > The reasons for removing it from the code base are as follows:
> > 1. Gryo serilization of properties is not consistent with the GraphBinary
> > or Graphson. As an example, Gryo tries to fetch the label of the parent
> > element when serializing a property whereas other serializers only
> provide
> > the ID of the parent element.
> > 2. GraphBinary is a direct replacement with binary serialization support
> > and better performance. GraphBinary support has also been expanded to
> > Python and is the default serializer starting 3.5.x release train.
> >
> > Divij Vaidya
> >
> >
> >
> > On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette <sp...@gmail.com>
> > wrote:
> >
> > > I was just perusing JIRA a bit and came across an item to upgrade to
> Kryo
> > > 4.0 for a performance enhancement:
> > >
> > > https://issues.apache.org/jira/browse/TINKERPOP-2398
> > >
> > > As I commented on that issue, which has not yet gotten a response, I
> > > believe that upgrading to Kryo 4.0 breaks binary compatibility with
> Kryo
> > > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a
> > > result.
> > >
> > > I'm not sure I see the need to produce another version of Gryo as we've
> > > deprecated it in Gremlin Server already and are pushing for wider use
> of
> > > GraphBinary as a replacement for Gryo and GraphSON for network
> > > serialization. I'm not sure where that leaves us with disk
> serialization
> > > but the limitation Gryo has in not working off the JVM hampers it a bit
> > for
> > > what I think of as our current usage these days.
> > >
> > > I'm inclined to continue us on a path to full deprecation of Gryo, even
> > for
> > > disk, in favor of GraphBinary, in which case, I don't think it's in our
> > > interest to introduce Gryo 4.0. Does anyone have any thoughts on this
> > > topic?
> > >
> >
>
Re: [DISCUSS] Gryo 4.0
Posted by Stephen Mallette <sp...@gmail.com>.
Just to clarify, I think you are suggesting the removal of the remaining
deprecated GryoMessageSerializer instances thus removing Gryo as a network
serialization option at 3.6.0. We would retain Gryo as it pertains to being
a file storage format.
We removed Gryo Lite for 3.6.0, so complete removal isn't too far around
the corner. I dont think I have any problems with just doing it all for
3.6.0. It would continue to simplify the serialization story if it wasn't
around. If we could then get Javascript on GraphBinary, we could then
retire typed GraphSON versions and promote a simple GraphSON format for
HTTP (like GraphSON 1.0).
On Mon, Dec 27, 2021 at 7:56 AM Divij Vaidya <di...@gmail.com>
wrote:
> I agree about sun setting Gryo perhaps starting with the 3.6.x release.
>
> The reasons for removing it from the code base are as follows:
> 1. Gryo serilization of properties is not consistent with the GraphBinary
> or Graphson. As an example, Gryo tries to fetch the label of the parent
> element when serializing a property whereas other serializers only provide
> the ID of the parent element.
> 2. GraphBinary is a direct replacement with binary serialization support
> and better performance. GraphBinary support has also been expanded to
> Python and is the default serializer starting 3.5.x release train.
>
> Divij Vaidya
>
>
>
> On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > I was just perusing JIRA a bit and came across an item to upgrade to Kryo
> > 4.0 for a performance enhancement:
> >
> > https://issues.apache.org/jira/browse/TINKERPOP-2398
> >
> > As I commented on that issue, which has not yet gotten a response, I
> > believe that upgrading to Kryo 4.0 breaks binary compatibility with Kryo
> > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a
> > result.
> >
> > I'm not sure I see the need to produce another version of Gryo as we've
> > deprecated it in Gremlin Server already and are pushing for wider use of
> > GraphBinary as a replacement for Gryo and GraphSON for network
> > serialization. I'm not sure where that leaves us with disk serialization
> > but the limitation Gryo has in not working off the JVM hampers it a bit
> for
> > what I think of as our current usage these days.
> >
> > I'm inclined to continue us on a path to full deprecation of Gryo, even
> for
> > disk, in favor of GraphBinary, in which case, I don't think it's in our
> > interest to introduce Gryo 4.0. Does anyone have any thoughts on this
> > topic?
> >
>
Re: [DISCUSS] Gryo 4.0
Posted by Divij Vaidya <di...@gmail.com>.
I agree about sun setting Gryo perhaps starting with the 3.6.x release.
The reasons for removing it from the code base are as follows:
1. Gryo serilization of properties is not consistent with the GraphBinary
or Graphson. As an example, Gryo tries to fetch the label of the parent
element when serializing a property whereas other serializers only provide
the ID of the parent element.
2. GraphBinary is a direct replacement with binary serialization support
and better performance. GraphBinary support has also been expanded to
Python and is the default serializer starting 3.5.x release train.
Divij Vaidya
On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette <sp...@gmail.com>
wrote:
> I was just perusing JIRA a bit and came across an item to upgrade to Kryo
> 4.0 for a performance enhancement:
>
> https://issues.apache.org/jira/browse/TINKERPOP-2398
>
> As I commented on that issue, which has not yet gotten a response, I
> believe that upgrading to Kryo 4.0 breaks binary compatibility with Kryo
> 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a
> result.
>
> I'm not sure I see the need to produce another version of Gryo as we've
> deprecated it in Gremlin Server already and are pushing for wider use of
> GraphBinary as a replacement for Gryo and GraphSON for network
> serialization. I'm not sure where that leaves us with disk serialization
> but the limitation Gryo has in not working off the JVM hampers it a bit for
> what I think of as our current usage these days.
>
> I'm inclined to continue us on a path to full deprecation of Gryo, even for
> disk, in favor of GraphBinary, in which case, I don't think it's in our
> interest to introduce Gryo 4.0. Does anyone have any thoughts on this
> topic?
>