[jira] [Commented] (TINKERPOP-2877) The incorrect result caused by long integer overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695513#comment-17695513
]
Miracy Cavendish commented on TINKERPOP-2877:
-
Many thanks for your valuable response. I also cannot find a very good
solution. Perhaps returning an exception to inform the user when this situation
occurs could provide some relief.
> The incorrect result caused by long integer overflows
> -
>
> Key: TINKERPOP-2877
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2877
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Major
>
> {code:java}
> Gremlin1:
> g.V().both().both().both().both().both().both().values('prop9').sum()
> Result1: -5308416236269507008
> Gremlin2:
> g.V().both().both().both().both().both().both().has('prop2').values('prop9').sum()
> Result2: 756493433251093
> Gremlin3:
> g.V().both().both().both().both().both().both().hasNot('prop2').values('prop9').sum()
> Result3: -8222751935482731416{code}
> We execute the above gremlin queries: Result1 should equal the sum of Result2
> and Result3, whereas -5308416236269507008 ≠756493433251093 +
> -8222751935482731416.
> The possible reason is that long integer overflows happen in the process.
> Could you return an exception to notify the user when the overflow occurs, or
> use BigDecimal during the procedure?
> The graph is created by the following statements:
> {code:java}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1",
[jira] [Commented] (TINKERPOP-2879) java.lang.NumberFormatException triggered by comparing with INFINITY
[
https://issues.apache.org/jira/browse/TINKERPOP-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695510#comment-17695510
]
Miracy Cavendish commented on TINKERPOP-2879:
-
Thank you very much for your valuable feedback. We have used the method you
provided to reduce the samples, and as a result, they have become clearer. It's
really great! I believe that the issue was caused by comparing the sum of INF.
{code:java}
g.inject(Double.POSITIVE_INFINITY).sum().is(inside(Double.NEGATIVE_INFINITY,
Double.POSITIVE_INFINITY))
==> 'result': {'data': {'@type': 'g:List', '@value': []}
g.inject(1.0, 2.0).sum().is(inside(Double.NEGATIVE_INFINITY,
Double.POSITIVE_INFINITY))
==> 'result': {'data': {'@type': 'g:List', '@value': [{'@type':
'gx:BigDecimal', '@value': 3.0}]}
g.inject(1.0,
Double.POSITIVE_INFINITY).sum().is(inside(Double.NEGATIVE_INFINITY,
Double.POSITIVE_INFINITY))
==> java.lang.NumberFormatException{code}
> java.lang.NumberFormatException triggered by comparing with INFINITY
>
>
> Key: TINKERPOP-2879
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2879
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Priority: Major
>
> We execute two gremlin queries, where the first one correctly return the
> result and the second one return an unexpected exception:
> _java.lang.NumberFormatException_
> {code:java}
> Gremlin1:
> g.E().where(__.values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result1: 6
> Gremlin2:
> g.E().where(__.bothV().values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result2: java.lang.NumberFormatException{code}
> The graph (5 vertices, 30 edges) is created by the following statements:
> {code}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
>
[jira] [Commented] (TINKERPOP-2875) Duplicate elements are omitted when turning off bulk optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695479#comment-17695479
]
Lei Tang commented on TINKERPOP-2875:
-
@[~spmallette]
Thanks for your replay. Looking forward to the improvement of documentation.
One more question is that I can count the correct number of vertices even if we
set bulk to false. I think they should be consistent.
{code:java}
gremlin> :> g.withBulk(false).E().outV()
==>v[1]
gremlin> :> g.withBulk(false).E().outV().count()
==>2 {code}
Also, I would like to know how can I turn off "Bulk Optimization"? Since
setting bulk to false affects the query results, what is the point of this
configuration?
> Duplicate elements are omitted when turning off bulk optimization
> -
>
> Key: TINKERPOP-2875
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2875
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Major
>
> I create three vertices and two edges.
> {code:java}
> Vertex v1 = g.addV("vl0").property("vp0", 1).next(); // v[1]
> Vertex v2 = g.addV("vl0").property("vp0", 2).next(); // v[2]
> Vertex v3 = g.addV("vl0").property("vp0", 3).next(); // v[3]
> Edge e1 = g.addE("el0").from(v1).to(v2).next();
> Edge e2 = g.addE("el0").from(v1).to(v3).next();{code}
> When I execute the query 'g.E().outV()' without using bulk optimization, I
> expect the result \{v1,v1} is returned. However, it removes the duplicate
> vertices.
> {code:java}
> gremlin> :> g.withBulk(false).E().outV()
> ==>v[1]
> gremlin> :> g.E().outV()
> ==>v[1]
> ==>v[1]
> {code}
> Since I do not use bulk operations in this query, I expect that even if we
> turn off bulk opitmization, we can compute the correct result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: Upcoming Major Changes to Java Dependencies for 3.5/3.7
These are the awesome news! Thanks Ken for updates! Best regards, Oleksandr On Wed, Mar 1, 2023, 23:16 Ken Hu wrote: > Hi Everyone, > > I just thought I would leave a quick message about the state of some of our > Java dependencies. > We may be able to resolve a long-running performance issue we have had with > newer versions of > Groovy. The change for this is currently in review in PR1983. This change > will allow us to run > process-docs.sh much faster than before. A quick test showed that the time > could be reduced from > 90 minutes to 25 minutes. Once this gets merged, then it should unblock us > from upgrading Groovy. > The current plan is to upgrade to Groovy 4.0.9 on the master branch and to > upgrade to Groovy 2.5.21 > on 3.5-dev and 3.6-dev. > > Once we upgrade Groovy, we can then focus on building and testing with JDK > 17 on the master branch > as Groovy was the major blocker in upgrading the runtime version. There are > other libraries that > will potentially need upgrading such as Spark and Kryo. See TINKERPOP-2703 > for the work that > Stephen has already done for this. Upgrading to Kyro 5.x will likely cause > breaking changes for > those that use Kyro 3.x as the two formats aren't compatible. However, it > seems like we have mostly > deprecated the use of Kyro already so this should reduce its impact. > > To summarize, there will be major version upgrades coming to several Java > libraries (Groovy and Kyro > in particular) in the master branch. This should enable us to run and build > with JDK 17 on master. > > Thanks, > Ken >
Upcoming Major Changes to Java Dependencies for 3.5/3.7
Hi Everyone, I just thought I would leave a quick message about the state of some of our Java dependencies. We may be able to resolve a long-running performance issue we have had with newer versions of Groovy. The change for this is currently in review in PR1983. This change will allow us to run process-docs.sh much faster than before. A quick test showed that the time could be reduced from 90 minutes to 25 minutes. Once this gets merged, then it should unblock us from upgrading Groovy. The current plan is to upgrade to Groovy 4.0.9 on the master branch and to upgrade to Groovy 2.5.21 on 3.5-dev and 3.6-dev. Once we upgrade Groovy, we can then focus on building and testing with JDK 17 on the master branch as Groovy was the major blocker in upgrading the runtime version. There are other libraries that will potentially need upgrading such as Spark and Kryo. See TINKERPOP-2703 for the work that Stephen has already done for this. Upgrading to Kyro 5.x will likely cause breaking changes for those that use Kyro 3.x as the two formats aren't compatible. However, it seems like we have mostly deprecated the use of Kyro already so this should reduce its impact. To summarize, there will be major version upgrades coming to several Java libraries (Groovy and Kyro in particular) in the master branch. This should enable us to run and build with JDK 17 on master. Thanks, Ken
Re: [DISCUSS] Ironbank
Following up, Ironbank is building its own image from the Dockerfile we
give it.
ARG BASE_REGISTRY=registry1.dso.mil
ARG BASE_IMAGE=ironbank/redhat/ubi/ubi8
ARG BASE_TAG="8.7"
FROM ${BASE_REGISTRY}/${BASE_IMAGE}:${BASE_TAG}
USER root
RUN dnf install unzip -y && \
useradd gremlin && \
dnf update -y --nodocs && \
dnf install -y java-11-openjdk && \
dnf clean all && \
rm -rf /var/cache/dnf
WORKDIR /opt/gremlin-server
COPY ["apache-tinkerpop-gremlin-server-3.6.2-bin.zip", "."]
COPY ["apache-tinkerpop-gremlin-console-3.6.2-bin.zip", "."]
RUN set -eux; \
unzip apache-tinkerpop-gremlin-server-3.6.2-bin.zip; \
unzip apache-tinkerpop-gremlin-console-3.6.2-bin.zip; \
cp -R apache-tinkerpop-gremlin-server-3.6.2/* /opt/gremlin-server; \
cp -R apache-tinkerpop-gremlin-console-3.6.2/* /opt/gremlin-server; \
rm apache-tinkerpop-gremlin-server-3.6.2-bin.zip; \
rm apache-tinkerpop-gremlin-console-3.6.2-bin.zip; \
rm -rf apache-tinkerpop-gremlin-server-3.6.2; \
rm -rf apache-tinkerpop-gremlin-console-3.6.2
RUN bin/gremlin-server.sh install org.apache.tinkerpop neo4j-gremlin 3.6.2
COPY config/* conf
COPY config/gremlin-server-neo4j.yaml ./conf/gremlin-server.yaml
COPY scripts/docker-entrypoint.sh /usr/bin
RUN chown -R gremlin .
USER gremlin
HEALTHCHECK NONE
ENTRYPOINT ["docker-entrypoint.sh"]
On Wed, Mar 1, 2023 at 1:59 PM Stephen Mallette
wrote:
> I saw the JIRAs. Most of those seem like transient dependencies that are
> being problematic. Like, this one:
>
> https://issues.apache.org/jira/browse/TINKERPOP-2883
>
> refers to netty 3.x being a problem. But we specifically use netty 4.x:
>
> https://github.com/apache/tinkerpop/blob/3.5.5/pom.xml#L177
>
> The only reference to 3.x that I can think of would come from maybe
> hadoop-gremlin. we could probably make some effort to sort out these
> transitive dependency issues, but i'm curious as to why direct dependencies
> like hadoop, neo4j, etc. are a problem for IronBank. we don't package them
> in Docker images (which i'd come to understand IronBank was interested in)
> nor are they packaged in our binary zip distributions of Gremlin Server or
> Console which you alluded to here:
>
> https://lists.apache.org/thread/vsmrms1sy62sd1z3b7mcmzc9kh4gq5tk
>
> So, why is the IronBank scanner picking up these issues? I guess something
> still isn't connecting for me in what IronBank is doing.
>
>
>
> On Mon, Feb 27, 2023 at 5:10 PM Jim Foscue
> wrote:
>
> > I've added some JIRA tickets with the Label Ironbank.
> >
> > They all involve updating various libraries as part of the build.
> >
> > Jim
> >
> > On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue >
> > wrote:
> >
> > > I can definitely add JIRA issues and share the findings.
> > >
> > > I’ll start with version 3.6.2. Could take a couple of days to get this
> > > going in Ironbank but I’ll keep you updated.
> > >
> > > Jim
> > >
> > > > On Feb 22, 2023, at 11:23 AM, Stephen Mallette >
> > > wrote:
> > > >
> > > > ok - thanks for clarifying. i hope you'll feel free to issue
> PRs/JIRAs
> > > and
> > > > just generally interact with the community to help us get TinkerPop
> > > > IronBank-ready. it would be nice if you kept us apprised of releases
> > that
> > > > were accepted there. i assume we could add a link somewhere to the
> > place
> > > > TinkerPop is hosted in ironbank if there is such a direct link
> publicly
> > > > available and you could share it?
> > > >
> > > >> On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue <
> > > jim.fos...@jdmsolutions.com>
> > > >> wrote:
> > > >>
> > > >> What you're saying makes sense to me. We can be the custodians of
> the
> > > >> Ironbank process/image since we have access.
> > > >>
> > > >> I'm not sure I understand your release process. The ironbank build
> > > pulls
> > > >> in the files from https://dlcdn.apache.org/tinkerpop/.
> > > >>
> > > >> For example
> > > >> # List of resources to make available to the offline build context
> > > >> resources:
> > > >> - url: "
> > > >>
> > > >>
> > >
> >
> https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-server-3.6.1-bin.zip
> > > >> "
> > > >> filename: "apache-tinkerpop-gremlin-server-3.6.1-bin.zip"
> > > >> validation:
> > > >>type: sha512
> > > >>value:
> > > >>
> > > >>
> > >
> >
> 4930e79caeed0ea019bf52da9d78d3440a0e6805b3232763b774116c10e7ee38dbe5ac9bb3873acf318c65349d00b204d7ec89c60324eda9a42c2998053b
> > > >> - url: "
> > > >>
> > > >>
> > >
> >
> https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-console-3.6.1-bin.zip
> > > >> "
> > > >> filename: "apache-tinkerpop-gremlin-console-3.6.1-bin.zip"
> > > >> validation:
> > > >>type: sha512
> > > >>value:
> > > >>
> > > >>
> > >
> >
> 3516b601298427e78580665016f6d29bf5ad39bfeeafe9e4cd762bb7a9454d844e131df4935b4fa61fb2f9d749eb5f2fa4b56df2908a8067825a203423b958c5
> > > >>
> > > >> So when do these get updated? Is it when there is a new release or
> bug
> > > >> fixes?
[jira] [Commented] (TINKERPOP-2526) Gremlin Console performance with incomplete multi-line scripts
[ https://issues.apache.org/jira/browse/TINKERPOP-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695336#comment-17695336 ] ASF GitHub Bot commented on TINKERPOP-2526: --- kenhuuu commented on PR #1983: URL: https://github.com/apache/tinkerpop/pull/1983#issuecomment-1450895996 > Previously building the docs was impossibly slow on any groovy version beyond 2.5.15. What is the doc building performance on newer versions of groovy with these changes included? With these changes and Groovy 2.5.17 (a version we noticed a slowdown with), the 3.5.5 documentation processing took roughly 25 min. The 3.5.5 release code takes about 90m to do the same documentation processing. > Gremlin Console performance with incomplete multi-line scripts > -- > > Key: TINKERPOP-2526 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2526 > Project: TinkerPop > Issue Type: Bug > Components: console, documentation, groovy >Affects Versions: 3.5.0 >Reporter: Stephen Mallette >Priority: Major > > Gremlin Console is impossibly slow for incomplete multi-line use cases which > is common for Gremlin. The issue appears to be related to the Groovy 3.x > upgrade. More details can be found here: GROOVY-9785 > Note that this is a major blocker for 3.5.0 release as we can't generate > documentation right now (takes well over 24 hours to generate and most times > it simply crashes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] Ironbank
Sorry https://issues.apache.org/jira/browse/TINKERPOP-2883 may not be an issue for tinkerpop. We are using the neo4j-gremlin plugin with it. We push a repo to Ironbank with our Dockerfile and some other files required. Their process pulls the zip files from https://dlcdn.apache.org/tinkerpop/3.6.2/apache-tinkerpop-gremlin-server-3.6.2-bin.zip https://dlcdn.apache.org/tinkerpop/3.6.2/apache-tinkerpop-gremlin-console-3.6.2-bin.zip and then runs this command RUN bin/gremlin-server.sh install org.apache.tinkerpop neo4j-gremlin 3.6.2 I assume it pulls in the neo4j-gremlin plugin which is where the netty is referenced. I'm going to modify the Dockerfile to not run that line and see what happens. Thanks for your help. Jim On Wed, Mar 1, 2023 at 1:59 PM Stephen Mallette wrote: > I saw the JIRAs. Most of those seem like transient dependencies that are > being problematic. Like, this one: > > https://issues.apache.org/jira/browse/TINKERPOP-2883 > > refers to netty 3.x being a problem. But we specifically use netty 4.x: > > https://github.com/apache/tinkerpop/blob/3.5.5/pom.xml#L177 > > The only reference to 3.x that I can think of would come from maybe > hadoop-gremlin. we could probably make some effort to sort out these > transitive dependency issues, but i'm curious as to why direct dependencies > like hadoop, neo4j, etc. are a problem for IronBank. we don't package them > in Docker images (which i'd come to understand IronBank was interested in) > nor are they packaged in our binary zip distributions of Gremlin Server or > Console which you alluded to here: > > https://lists.apache.org/thread/vsmrms1sy62sd1z3b7mcmzc9kh4gq5tk > > So, why is the IronBank scanner picking up these issues? I guess something > still isn't connecting for me in what IronBank is doing. > > > > On Mon, Feb 27, 2023 at 5:10 PM Jim Foscue > wrote: > > > I've added some JIRA tickets with the Label Ironbank. > > > > They all involve updating various libraries as part of the build. > > > > Jim > > > > On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue > > > wrote: > > > > > I can definitely add JIRA issues and share the findings. > > > > > > I’ll start with version 3.6.2. Could take a couple of days to get this > > > going in Ironbank but I’ll keep you updated. > > > > > > Jim > > > > > > > On Feb 22, 2023, at 11:23 AM, Stephen Mallette > > > > wrote: > > > > > > > > ok - thanks for clarifying. i hope you'll feel free to issue > PRs/JIRAs > > > and > > > > just generally interact with the community to help us get TinkerPop > > > > IronBank-ready. it would be nice if you kept us apprised of releases > > that > > > > were accepted there. i assume we could add a link somewhere to the > > place > > > > TinkerPop is hosted in ironbank if there is such a direct link > publicly > > > > available and you could share it? > > > > > > > >> On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue < > > > jim.fos...@jdmsolutions.com> > > > >> wrote: > > > >> > > > >> What you're saying makes sense to me. We can be the custodians of > the > > > >> Ironbank process/image since we have access. > > > >> > > > >> I'm not sure I understand your release process. The ironbank build > > > pulls > > > >> in the files from https://dlcdn.apache.org/tinkerpop/. > > > >> > > > >> For example > > > >> # List of resources to make available to the offline build context > > > >> resources: > > > >> - url: " > > > >> > > > >> > > > > > > https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-server-3.6.1-bin.zip > > > >> " > > > >> filename: "apache-tinkerpop-gremlin-server-3.6.1-bin.zip" > > > >> validation: > > > >>type: sha512 > > > >>value: > > > >> > > > >> > > > > > > 4930e79caeed0ea019bf52da9d78d3440a0e6805b3232763b774116c10e7ee38dbe5ac9bb3873acf318c65349d00b204d7ec89c60324eda9a42c2998053b > > > >> - url: " > > > >> > > > >> > > > > > > https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-console-3.6.1-bin.zip > > > >> " > > > >> filename: "apache-tinkerpop-gremlin-console-3.6.1-bin.zip" > > > >> validation: > > > >>type: sha512 > > > >>value: > > > >> > > > >> > > > > > > 3516b601298427e78580665016f6d29bf5ad39bfeeafe9e4cd762bb7a9454d844e131df4935b4fa61fb2f9d749eb5f2fa4b56df2908a8067825a203423b958c5 > > > >> > > > >> So when do these get updated? Is it when there is a new release or > bug > > > >> fixes? Whenever these are updated is when we would get the fixes. > > > >> > > > >> Thoughts? > > > >> > > > >> Jim > > > >> > > > >> On Wed, Feb 22, 2023 at 9:15 AM Stephen Mallette < > > spmalle...@gmail.com> > > > >> wrote: > > > >> > > > >>> Unless I'm not understanding something there isn't much change to > > > process > > > >>> for TinkerPop. You spot a problem in IronBank and either submit a > PR > > to > > > >> fix > > > >>> or create a JIRA for someone else to fix if you don't have the > > ability > > > to > > > >>> do it yourself. It gets merged and presumably you can get your > image > > > into > > > >>> IronBank. > >
[jira] [Commented] (TINKERPOP-2824) Properties on Elements
[ https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695326#comment-17695326 ] ASF GitHub Bot commented on TINKERPOP-2824: --- vkagamlyk commented on code in PR #1843: URL: https://github.com/apache/tinkerpop/pull/1843#discussion_r1122319496 ## docs/src/upgrade/release-3.7.x.asciidoc: ## @@ -29,6 +29,28 @@ Please see the link:https://github.com/apache/tinkerpop/blob/3.7.0/CHANGELOG.asc === Upgrading for Users + Properties on Elements Review Comment: different behavior for different GLV's Python, Go: deserialization error for GraphBinary, skip properties for GraphSON .NET: skip properties Javascript: should work ok also serialization can't be managed with `materializeProperties` option > Properties on Elements > -- > > Key: TINKERPOP-2824 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2824 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, driver, go, javascript, process, python >Affects Versions: 3.5.4 >Reporter: Valentyn Kahamlyk >Assignee: Valentyn Kahamlyk >Priority: Major > > Problem: When a user writes `g.V()` they get back a Vertex object. The > problem is that depending on the execution context of the traversal, the > result could be quite different, with or without properties. > Solution: Implement new finalization strategy DetachStrategy(detachMode, > properties) where mode is one of ALL, NONE or CUSTOM. `properties` is list of > properties name, are taken into account only for CUSTOM mode. > Discussion thread in dev list: [Proposal to handle properties on response > Elements-Apache Mail > Archives|https://lists.apache.org/thread/l8rw7ydj7kym8vhtwk50nhbp45ng9986] > Stephen's thread in dev list: [The Issue of Detachment-Apache Mail > Archives|https://lists.apache.org/thread/xltcon4zxnwq4fyw2r2126syyrqm8spy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [DISCUSS] Ironbank
I saw the JIRAs. Most of those seem like transient dependencies that are being problematic. Like, this one: https://issues.apache.org/jira/browse/TINKERPOP-2883 refers to netty 3.x being a problem. But we specifically use netty 4.x: https://github.com/apache/tinkerpop/blob/3.5.5/pom.xml#L177 The only reference to 3.x that I can think of would come from maybe hadoop-gremlin. we could probably make some effort to sort out these transitive dependency issues, but i'm curious as to why direct dependencies like hadoop, neo4j, etc. are a problem for IronBank. we don't package them in Docker images (which i'd come to understand IronBank was interested in) nor are they packaged in our binary zip distributions of Gremlin Server or Console which you alluded to here: https://lists.apache.org/thread/vsmrms1sy62sd1z3b7mcmzc9kh4gq5tk So, why is the IronBank scanner picking up these issues? I guess something still isn't connecting for me in what IronBank is doing. On Mon, Feb 27, 2023 at 5:10 PM Jim Foscue wrote: > I've added some JIRA tickets with the Label Ironbank. > > They all involve updating various libraries as part of the build. > > Jim > > On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue > wrote: > > > I can definitely add JIRA issues and share the findings. > > > > I’ll start with version 3.6.2. Could take a couple of days to get this > > going in Ironbank but I’ll keep you updated. > > > > Jim > > > > > On Feb 22, 2023, at 11:23 AM, Stephen Mallette > > wrote: > > > > > > ok - thanks for clarifying. i hope you'll feel free to issue PRs/JIRAs > > and > > > just generally interact with the community to help us get TinkerPop > > > IronBank-ready. it would be nice if you kept us apprised of releases > that > > > were accepted there. i assume we could add a link somewhere to the > place > > > TinkerPop is hosted in ironbank if there is such a direct link publicly > > > available and you could share it? > > > > > >> On Wed, Feb 22, 2023 at 11:59 AM Jim Foscue < > > jim.fos...@jdmsolutions.com> > > >> wrote: > > >> > > >> What you're saying makes sense to me. We can be the custodians of the > > >> Ironbank process/image since we have access. > > >> > > >> I'm not sure I understand your release process. The ironbank build > > pulls > > >> in the files from https://dlcdn.apache.org/tinkerpop/. > > >> > > >> For example > > >> # List of resources to make available to the offline build context > > >> resources: > > >> - url: " > > >> > > >> > > > https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-server-3.6.1-bin.zip > > >> " > > >> filename: "apache-tinkerpop-gremlin-server-3.6.1-bin.zip" > > >> validation: > > >>type: sha512 > > >>value: > > >> > > >> > > > 4930e79caeed0ea019bf52da9d78d3440a0e6805b3232763b774116c10e7ee38dbe5ac9bb3873acf318c65349d00b204d7ec89c60324eda9a42c2998053b > > >> - url: " > > >> > > >> > > > https://dlcdn.apache.org/tinkerpop/3.6.1/apache-tinkerpop-gremlin-console-3.6.1-bin.zip > > >> " > > >> filename: "apache-tinkerpop-gremlin-console-3.6.1-bin.zip" > > >> validation: > > >>type: sha512 > > >>value: > > >> > > >> > > > 3516b601298427e78580665016f6d29bf5ad39bfeeafe9e4cd762bb7a9454d844e131df4935b4fa61fb2f9d749eb5f2fa4b56df2908a8067825a203423b958c5 > > >> > > >> So when do these get updated? Is it when there is a new release or bug > > >> fixes? Whenever these are updated is when we would get the fixes. > > >> > > >> Thoughts? > > >> > > >> Jim > > >> > > >> On Wed, Feb 22, 2023 at 9:15 AM Stephen Mallette < > spmalle...@gmail.com> > > >> wrote: > > >> > > >>> Unless I'm not understanding something there isn't much change to > > process > > >>> for TinkerPop. You spot a problem in IronBank and either submit a PR > to > > >> fix > > >>> or create a JIRA for someone else to fix if you don't have the > ability > > to > > >>> do it yourself. It gets merged and presumably you can get your image > > into > > >>> IronBank. > > >>> > > >>> What I don't understand is how you consume that fix. Let's say > IronBank > > >> had > > >>> a problem in 3.6.2. TinkerPop fixes it. Now what? Do you have to wait > > >> until > > >>> we release 3.6.3 to get that into IronBank and hope you don't hit > more > > >>> problems? Is there a way to test an image ahead of a TinkerPop > > release? I > > >>> guess I'm trying to confirm that there really isn't any change to > > >> anything > > >>> TinkerPop does in the normal process of reviewing pull request and > > fixing > > >>> security problems because it seems pretty normal/simple otherwise. No > > one > > >>> at TinkerPop can release anything to IronBank so this is purely a > > >>> third-party maintained convenience which you are handling for the > wider > > >>> community. Is that a fair depiction of what were looking at here? > > >>> > > >>> So, if there's nothing out of the ordinary to do from TinkerPop's > side > > >> then > > >>> I guess you should feel free to let the PRs/JIRAs fly (or maybe just > > call > > >>>
[jira] [Commented] (TINKERPOP-2526) Gremlin Console performance with incomplete multi-line scripts
[ https://issues.apache.org/jira/browse/TINKERPOP-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695260#comment-17695260 ] ASF GitHub Bot commented on TINKERPOP-2526: --- spmallette commented on PR #1983: URL: https://github.com/apache/tinkerpop/pull/1983#issuecomment-1450678996 wow - hard to believe this was the fix all this time. incredible job getting to the bottom of this and working with the Groovy Community to help solve it. this fix unlocks a lot of blockages. hero! needs a CHANGELOG entry, but other than that: VOTE +1 > Gremlin Console performance with incomplete multi-line scripts > -- > > Key: TINKERPOP-2526 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2526 > Project: TinkerPop > Issue Type: Bug > Components: console, documentation, groovy >Affects Versions: 3.5.0 >Reporter: Stephen Mallette >Priority: Major > > Gremlin Console is impossibly slow for incomplete multi-line use cases which > is common for Gremlin. The issue appears to be related to the Groovy 3.x > upgrade. More details can be found here: GROOVY-9785 > Note that this is a major blocker for 3.5.0 release as we can't generate > documentation right now (takes well over 24 hours to generate and most times > it simply crashes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2824) Properties on Elements
[ https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695225#comment-17695225 ] ASF GitHub Bot commented on TINKERPOP-2824: --- spmallette commented on code in PR #1843: URL: https://github.com/apache/tinkerpop/pull/1843#discussion_r1122102698 ## docs/src/upgrade/release-3.7.x.asciidoc: ## @@ -29,6 +29,28 @@ Please see the link:https://github.com/apache/tinkerpop/blob/3.7.0/CHANGELOG.asc === Upgrading for Users + Properties on Elements Review Comment: i can't recall, but are there any compatibility issues to call attention to here? like can a 3.6.x driver work nicely with 3.7.x or the reverse? maybe there is something to call attention to here with that. > Properties on Elements > -- > > Key: TINKERPOP-2824 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2824 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, driver, go, javascript, process, python >Affects Versions: 3.5.4 >Reporter: Valentyn Kahamlyk >Assignee: Valentyn Kahamlyk >Priority: Major > > Problem: When a user writes `g.V()` they get back a Vertex object. The > problem is that depending on the execution context of the traversal, the > result could be quite different, with or without properties. > Solution: Implement new finalization strategy DetachStrategy(detachMode, > properties) where mode is one of ALL, NONE or CUSTOM. `properties` is list of > properties name, are taken into account only for CUSTOM mode. > Discussion thread in dev list: [Proposal to handle properties on response > Elements-Apache Mail > Archives|https://lists.apache.org/thread/l8rw7ydj7kym8vhtwk50nhbp45ng9986] > Stephen's thread in dev list: [The Issue of Detachment-Apache Mail > Archives|https://lists.apache.org/thread/xltcon4zxnwq4fyw2r2126syyrqm8spy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2824) Properties on Elements
[ https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695224#comment-17695224 ] ASF GitHub Bot commented on TINKERPOP-2824: --- spmallette commented on PR #1843: URL: https://github.com/apache/tinkerpop/pull/1843#issuecomment-1450565119 i think you need multiple CHANGELOG entries on this one. you added one feature but a lot of things changed like, major changes to different serializers, changes to where `HaltedTraverserStrategy` was used, `GremlinScriptChecker` changes, etc. > Properties on Elements > -- > > Key: TINKERPOP-2824 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2824 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, driver, go, javascript, process, python >Affects Versions: 3.5.4 >Reporter: Valentyn Kahamlyk >Assignee: Valentyn Kahamlyk >Priority: Major > > Problem: When a user writes `g.V()` they get back a Vertex object. The > problem is that depending on the execution context of the traversal, the > result could be quite different, with or without properties. > Solution: Implement new finalization strategy DetachStrategy(detachMode, > properties) where mode is one of ALL, NONE or CUSTOM. `properties` is list of > properties name, are taken into account only for CUSTOM mode. > Discussion thread in dev list: [Proposal to handle properties on response > Elements-Apache Mail > Archives|https://lists.apache.org/thread/l8rw7ydj7kym8vhtwk50nhbp45ng9986] > Stephen's thread in dev list: [The Issue of Detachment-Apache Mail > Archives|https://lists.apache.org/thread/xltcon4zxnwq4fyw2r2126syyrqm8spy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2824) Properties on Elements
[ https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695220#comment-17695220 ] ASF GitHub Bot commented on TINKERPOP-2824: --- spmallette commented on code in PR #1843: URL: https://github.com/apache/tinkerpop/pull/1843#discussion_r1122096235 ## docs/src/upgrade/release-3.7.x.asciidoc: ## @@ -29,6 +29,28 @@ Please see the link:https://github.com/apache/tinkerpop/blob/3.7.0/CHANGELOG.asc === Upgrading for Users + Properties on Elements Review Comment: This is a major piece of functionality. I think the upgrade documentation needs more content to really impress upon folks just what impact this change has for them. some background on the previous behavior would help, a link to the "history" of why it was that way would be good, some example code, etc. I can help with polishing up wording, but please add a bit more here for us to review. > Properties on Elements > -- > > Key: TINKERPOP-2824 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2824 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, driver, go, javascript, process, python >Affects Versions: 3.5.4 >Reporter: Valentyn Kahamlyk >Assignee: Valentyn Kahamlyk >Priority: Major > > Problem: When a user writes `g.V()` they get back a Vertex object. The > problem is that depending on the execution context of the traversal, the > result could be quite different, with or without properties. > Solution: Implement new finalization strategy DetachStrategy(detachMode, > properties) where mode is one of ALL, NONE or CUSTOM. `properties` is list of > properties name, are taken into account only for CUSTOM mode. > Discussion thread in dev list: [Proposal to handle properties on response > Elements-Apache Mail > Archives|https://lists.apache.org/thread/l8rw7ydj7kym8vhtwk50nhbp45ng9986] > Stephen's thread in dev list: [The Issue of Detachment-Apache Mail > Archives|https://lists.apache.org/thread/xltcon4zxnwq4fyw2r2126syyrqm8spy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2888) DefaultTraversal's applyStrategies performance decrease
[
https://issues.apache.org/jira/browse/TINKERPOP-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695203#comment-17695203
]
Stephen Mallette commented on TINKERPOP-2888:
-
hmm - do you have heavily nested traversals? are there particular strategies
you are using like {{PartitionStrategy}} or {{SubgraphStrategy}}?
> DefaultTraversal's applyStrategies performance decrease
> ---
>
> Key: TINKERPOP-2888
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2888
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Clément de Groc
>Priority: Major
>
> We have recently upgraded from JanusGraph {{0.6.2}} (TinkerPop {{{}3.5.3{}}})
> to JanusGraph {{0.6.3}} (TinkerPop {{{}3.5.5{}}}) and have observed an
> increase in all latency metrics reported by Gremlin Server.
> Using a profiler we have seen that more time is spent in
> {{TraversalHelper.applyTraversalRecursively}} calling itself recursively
> multiple times.
> Then we've narrowed down the issue to [this
> change|https://github.com/apache/tinkerpop/commit/1a548e808922a0eae23b586fe4d6567238989299]
> and resolved the latency problem by reverting the change in
> {{{}DefaultTraversal.java{}}}.
> TLDR; as far as I understand, it looks like, in our case at least, this
> [other round of recursion does have a significant performance
> impact|https://github.com/apache/tinkerpop/pull/1699#issuecomment-1170430130].
> As I'm not too familiar with that part of TinkerPop code, it's unclear to me
> if that's because of our usage of JanusGraph/TinkerPop (feel free to advise).
> But in any case, I thought that was worth reporting in case others hit the
> same issue.
> Happy to share/investigate more if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2879) java.lang.NumberFormatException triggered by comparing with INFINITY
[
https://issues.apache.org/jira/browse/TINKERPOP-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-2879:
Component/s: process
the sample data script fails to execute.
since this is a question of just numbers and not complex traversals, could you
perhaps contrive a simple query using {{inject()}} to demonstrate the problem?
it would make this easier to address i think. something like, {{g.inject(1,
Double.NEGATIVE_INFINITY, Double.NaN).sum()}} would be great.
> java.lang.NumberFormatException triggered by comparing with INFINITY
>
>
> Key: TINKERPOP-2879
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2879
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Priority: Major
>
> We execute two gremlin queries, where the first one correctly return the
> result and the second one return an unexpected exception:
> _java.lang.NumberFormatException_
> {code:java}
> Gremlin1:
> g.E().where(__.values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result1: 6
> Gremlin2:
> g.E().where(__.bothV().values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result2: java.lang.NumberFormatException{code}
> The graph (5 vertices, 30 edges) is created by the following statements:
> {code}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1", -7972953637432281761).property("prop15",
>
[jira] [Commented] (TINKERPOP-2824) Properties on Elements
[
https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695195#comment-17695195
]
ASF GitHub Bot commented on TINKERPOP-2824:
---
FlorianHockmann commented on code in PR #1843:
URL: https://github.com/apache/tinkerpop/pull/1843#discussion_r1121982613
##
docs/src/reference/gremlin-applications.asciidoc:
##
@@ -2250,50 +2250,36 @@ to as "detached elements" and cases where properties
are not included are "refer
With the type of request and detachment model in mind, it is now possible to
discuss how best to consider element
properties in relation to them all in concert.
-By default, Gremlin Server sample configurations utilize
`ReferenceElementStrategy` when creating the out-of-the-box
-`GraphTraversalSource`. As the name suggests, this means that elements will be
detached by reference and will
-therefore not have properties included. The relevant configuration from the
Gremlin Server initialization script looks
-like this:
+By default, Gremlin Server sample configurations return all properties.
+
+To manage properties for each request you can use
<> configuration option
+`materializeProperties`
[source,groovy]
-globals << [g :
traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
+g.with('materializeProperties', 'tokens').V()
-This configuration is global to Gremlin Server and therefore all methods of
connection will always return elements
-without properties. If this strategy is not included, then there are other
considerations to take into account such as
-the connection type (i.e. script or bytecode) and the serializer.
+The `tokens` value for the `materializeProperties` means that need to return
only `id` and `label`. Another option
Review Comment:
```suggestion
The `tokens` value for the `materializeProperties` means that only `id` and
`label` should be returned. Another option
```
##
docs/src/reference/gremlin-applications.asciidoc:
##
@@ -2250,50 +2250,36 @@ to as "detached elements" and cases where properties
are not included are "refer
With the type of request and detachment model in mind, it is now possible to
discuss how best to consider element
properties in relation to them all in concert.
-By default, Gremlin Server sample configurations utilize
`ReferenceElementStrategy` when creating the out-of-the-box
-`GraphTraversalSource`. As the name suggests, this means that elements will be
detached by reference and will
-therefore not have properties included. The relevant configuration from the
Gremlin Server initialization script looks
-like this:
+By default, Gremlin Server sample configurations return all properties.
+
+To manage properties for each request you can use
<> configuration option
+`materializeProperties`
[source,groovy]
-globals << [g :
traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
+g.with('materializeProperties', 'tokens').V()
-This configuration is global to Gremlin Server and therefore all methods of
connection will always return elements
-without properties. If this strategy is not included, then there are other
considerations to take into account such as
-the connection type (i.e. script or bytecode) and the serializer.
+The `tokens` value for the `materializeProperties` means that need to return
only `id` and `label`. Another option
+`all` used to indicate that all properties should be returned and is the
default value.
Review Comment:
I think this needs to be:
> Another option, `all`, _can be_ used [...]
##
docs/src/reference/gremlin-applications.asciidoc:
##
@@ -2307,10 +2293,8 @@ List results =
g.V().hasLabel("person").elementMap('name').toList();
Both of the above requests return a list of `Map` instances that contain the
`id`, `label` and the "name" property.
-TIP: The example graph configurations pre-packaged with Gremlin Server utilize
`ReferenceElementStrategy`
-which convert all graph elements to references by initializing "g" using
-`withStrategies(ReferenceElementStrategy.instance()`. Consider utilizing
`ReferenceElementStrategy` whenever creating
-a `GraphTraversalSource` in Java to ensure the most portable Gremlin.
+TIP: Consider utilizing `ReferenceElementStrategy` whenever creating a
`GraphTraversalSource` in Java to ensure
+the most portable Gremlin.
NOTE: For those interested, please see
link:https://lists.apache.org/thread.html/e959e85d4f8b3d46d281f2742a6e574c7d27c54bfc52f802f7c04af3%40%3Cdev.tinkerpop.apache.org%3E[this
post]
Review Comment:
I think we should remove this thread here or at least mention that it
discusses the history of this and gives pros/cons, but it doesn't reflect the
current situation any more as properties are now returned by default.
##
docs/src/reference/gremlin-applications.asciidoc:
##
@@
[jira] [Commented] (TINKERPOP-2878) Incorrect handling of local operations when there are duplicate elements
[
https://issues.apache.org/jira/browse/TINKERPOP-2878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695181#comment-17695181
]
Stephen Mallette commented on TINKERPOP-2878:
-
i believe this is expected behavior. i wouldn't expect those to provide the
same result. consider the "modern" graph and the first part of your traversals:
{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V().both().local(__.out().count()).max()
==>9
gremlin> g.V().both().dedup().local(__.out().count()).max()
==>3
{code}
taking away the {{max()}} and doing a {{profile()}} yields some insights:
{code}
gremlin> g.V().both().local(__.out().count()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[]) 6
6 0.10719.48
VertexStep(BOTH,vertex) 12
12 0.09417.15
NoOpBarrierStep(2500) 12
6 0.09116.58
LocalStep([VertexStep(OUT,edge), CountGlobalStep]) 6
6 0.25946.79
VertexStep(OUT,edge)16
6 0.041
CountGlobalStep 6
6 0.103
>TOTAL -
- 0.553-
gremlin> g.V().both().dedup().local(__.out().count()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[]) 6
6 0.09422.82
VertexStep(BOTH,vertex) 12
12 0.07518.24
DedupGlobalStep(null,null) 6
6 0.04611.28
LocalStep([VertexStep(OUT,edge), CountGlobalStep]) 6
6 0.19647.67
VertexStep(OUT,edge) 6
6 0.039
CountGlobalStep 6
6 0.055
>TOTAL -
- 0.412-
{code}
when you {{dedup()}} the {{local()}} step only does a {{count()}} on the edges
of each of the 6 unique vertices in the graph. when you don't {{dedup()}} then
{{local()}} processes 16 vertices (duplications of the 6 given traversing over
{{both()}}) counting each of their edges to the same traverser, so you get the
edge count multiplied by the bulk of the traverser basically.
I don't think I'd use {{local()}} in this case. I'd probably prefer {{map()}}
or probably {{dedup().map()}}:
{code}
gremlin> g.V().both().map(__.out().count()).profile()
==>Traversal Metrics
Step Count
Traversers Time (ms)% Dur
=
TinkerGraphStep(vertex,[]) 6
6 0.08422.28
VertexStep(BOTH,vertex) 12
12 0.07419.60
NoOpBarrierStep(2500) 12
6 0.07219.14
TraversalMapStep([VertexStep(OUT,edge), CountGl...12
6 0.14738.98
VertexStep(OUT,edge) 6
6 0.029
CountGlobalStep 6
6 0.036
>TOTAL -
- 0.379-
gremlin> g.V().both().dedup().local(__.out().count()).max()
==>3
gremlin> g.V().both().map(__.out().count()).max()
==>3
gremlin> g.V().both().dedup().map(__.out().count()).max()
==>3
{code}
> Incorrect handling of local operations when there are duplicate elements
>
>
> Key: TINKERPOP-2878
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2878
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.6.2
>
[jira] [Commented] (TINKERPOP-2877) The incorrect result caused by long integer overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695165#comment-17695165
]
Stephen Mallette commented on TINKERPOP-2877:
-
thanks for reporting this - not sure what the solution is but that doesn't seem
so nice. here's a more simple reproducer:
{code}
gremlin> g.inject(Long.MAX_VALUE, 0).sum()
==>9223372036854775807
gremlin> g.inject(Long.MAX_VALUE, 1).sum()
==>-9223372036854775808
gremlin> g.inject(Long.MAX_VALUE, 2).sum()
==>-9223372036854775807
gremlin> g.inject(Long.MAX_VALUE, 3).sum()
==>-9223372036854775806
{code}
> The incorrect result caused by long integer overflows
> -
>
> Key: TINKERPOP-2877
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2877
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Major
>
> {code:java}
> Gremlin1:
> g.V().both().both().both().both().both().both().values('prop9').sum()
> Result1: -5308416236269507008
> Gremlin2:
> g.V().both().both().both().both().both().both().has('prop2').values('prop9').sum()
> Result2: 756493433251093
> Gremlin3:
> g.V().both().both().both().both().both().both().hasNot('prop2').values('prop9').sum()
> Result3: -8222751935482731416{code}
> We execute the above gremlin queries: Result1 should equal the sum of Result2
> and Result3, whereas -5308416236269507008 ≠756493433251093 +
> -8222751935482731416.
> The possible reason is that long integer overflows happen in the process.
> Could you return an exception to notify the user when the overflow occurs, or
> use BigDecimal during the procedure?
> The graph is created by the following statements:
> {code:java}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
>
[jira] [Updated] (TINKERPOP-2877) The incorrect result caused by long integer overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-2877:
Component/s: process
Flags: (was: Important)
Affects Version/s: 3.5.5
(was: 3.6.2)
> The incorrect result caused by long integer overflows
> -
>
> Key: TINKERPOP-2877
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2877
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Major
>
> {code:java}
> Gremlin1:
> g.V().both().both().both().both().both().both().values('prop9').sum()
> Result1: -5308416236269507008
> Gremlin2:
> g.V().both().both().both().both().both().both().has('prop2').values('prop9').sum()
> Result2: 756493433251093
> Gremlin3:
> g.V().both().both().both().both().both().both().hasNot('prop2').values('prop9').sum()
> Result3: -8222751935482731416{code}
> We execute the above gremlin queries: Result1 should equal the sum of Result2
> and Result3, whereas -5308416236269507008 ≠756493433251093 +
> -8222751935482731416.
> The possible reason is that long integer overflows happen in the process.
> Could you return an exception to notify the user when the overflow occurs, or
> use BigDecimal during the procedure?
> The graph is created by the following statements:
> {code:java}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1", -7972953637432281761).property("prop15",
> Double.NaN).property("prop17",
[jira] [Updated] (TINKERPOP-2875) Duplicate elements are omitted when turning off bulk optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-2875:
Component/s: process
Affects Version/s: 3.5.5
> Duplicate elements are omitted when turning off bulk optimization
> -
>
> Key: TINKERPOP-2875
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2875
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Major
>
> I create three vertices and two edges.
> {code:java}
> Vertex v1 = g.addV("vl0").property("vp0", 1).next(); // v[1]
> Vertex v2 = g.addV("vl0").property("vp0", 2).next(); // v[2]
> Vertex v3 = g.addV("vl0").property("vp0", 3).next(); // v[3]
> Edge e1 = g.addE("el0").from(v1).to(v2).next();
> Edge e2 = g.addE("el0").from(v1).to(v3).next();{code}
> When I execute the query 'g.E().outV()' without using bulk optimization, I
> expect the result \{v1,v1} is returned. However, it removes the duplicate
> vertices.
> {code:java}
> gremlin> :> g.withBulk(false).E().outV()
> ==>v[1]
> gremlin> :> g.E().outV()
> ==>v[1]
> ==>v[1]
> {code}
> Since I do not use bulk operations in this query, I expect that even if we
> turn off bulk opitmization, we can compute the correct result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2875) Duplicate elements are omitted when turning off bulk optimization
[
https://issues.apache.org/jira/browse/TINKERPOP-2875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695159#comment-17695159
]
Stephen Mallette commented on TINKERPOP-2875:
-
I think the behavior is expected. You're not really turning off "bulk
optimizations" by setting that to {{false}}. You're forcing the {{bulk}} for a
{{Traverser}} to "1" basically:
https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/traverser/O_OB_S_SE_SL_Traverser.java#L54-L57
Another example to demonstrate:
{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.E().outV().map{[it,it.bulk()]}
==>[v[1],3]
==>[v[1],3]
==>[v[1],3]
==>[v[4],2]
==>[v[4],2]
==>[v[6],1]
gremlin> g.withBulk(false).E().outV().map{[it,it.bulk()]}
==>[v[1],1]
==>[v[4],1]
==>[v[6],1]
{code}
The documentation is fairly poor on {{withBulk()}} - we can leave this open to
ensure the docs are updated and there are appropriate tests.
> Duplicate elements are omitted when turning off bulk optimization
> -
>
> Key: TINKERPOP-2875
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2875
> Project: TinkerPop
> Issue Type: Bug
>Reporter: Lei Tang
>Priority: Major
>
> I create three vertices and two edges.
> {code:java}
> Vertex v1 = g.addV("vl0").property("vp0", 1).next(); // v[1]
> Vertex v2 = g.addV("vl0").property("vp0", 2).next(); // v[2]
> Vertex v3 = g.addV("vl0").property("vp0", 3).next(); // v[3]
> Edge e1 = g.addE("el0").from(v1).to(v2).next();
> Edge e2 = g.addE("el0").from(v1).to(v3).next();{code}
> When I execute the query 'g.E().outV()' without using bulk optimization, I
> expect the result \{v1,v1} is returned. However, it removes the duplicate
> vertices.
> {code:java}
> gremlin> :> g.withBulk(false).E().outV()
> ==>v[1]
> gremlin> :> g.E().outV()
> ==>v[1]
> ==>v[1]
> {code}
> Since I do not use bulk operations in this query, I expect that even if we
> turn off bulk opitmization, we can compute the correct result.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2888) DefaultTraversal's applyStrategies performance decrease
[
https://issues.apache.org/jira/browse/TINKERPOP-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695142#comment-17695142
]
Clément de Groc commented on TINKERPOP-2888:
For one of our datacenters and graphs, p99 latency went from 200 ms to > 1.5s.
> DefaultTraversal's applyStrategies performance decrease
> ---
>
> Key: TINKERPOP-2888
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2888
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Clément de Groc
>Priority: Major
>
> We have recently upgraded from JanusGraph {{0.6.2}} (TinkerPop {{{}3.5.3{}}})
> to JanusGraph {{0.6.3}} (TinkerPop {{{}3.5.5{}}}) and have observed an
> increase in all latency metrics reported by Gremlin Server.
> Using a profiler we have seen that more time is spent in
> {{TraversalHelper.applyTraversalRecursively}} calling itself recursively
> multiple times.
> Then we've narrowed down the issue to [this
> change|https://github.com/apache/tinkerpop/commit/1a548e808922a0eae23b586fe4d6567238989299]
> and resolved the latency problem by reverting the change in
> {{{}DefaultTraversal.java{}}}.
> TLDR; as far as I understand, it looks like, in our case at least, this
> [other round of recursion does have a significant performance
> impact|https://github.com/apache/tinkerpop/pull/1699#issuecomment-1170430130].
> As I'm not too familiar with that part of TinkerPop code, it's unclear to me
> if that's because of our usage of JanusGraph/TinkerPop (feel free to advise).
> But in any case, I thought that was worth reporting in case others hit the
> same issue.
> Happy to share/investigate more if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2888) DefaultTraversal's applyStrategies performance decrease
[
https://issues.apache.org/jira/browse/TINKERPOP-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695128#comment-17695128
]
Stephen Mallette commented on TINKERPOP-2888:
-
how big a change in latency are you seeing?
> DefaultTraversal's applyStrategies performance decrease
> ---
>
> Key: TINKERPOP-2888
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2888
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.6.1, 3.5.4
>Reporter: Clément de Groc
>Priority: Major
>
> We have recently upgraded from JanusGraph {{0.6.2}} (TinkerPop {{{}3.5.3{}}})
> to JanusGraph {{0.6.3}} (TinkerPop {{{}3.5.5{}}}) and have observed an
> increase in all latency metrics reported by Gremlin Server.
> Using a profiler we have seen that more time is spent in
> {{TraversalHelper.applyTraversalRecursively}} calling itself recursively
> multiple times.
> Then we've narrowed down the issue to [this
> change|https://github.com/apache/tinkerpop/commit/1a548e808922a0eae23b586fe4d6567238989299]
> and resolved the latency problem by reverting the change in
> {{{}DefaultTraversal.java{}}}.
> TLDR; as far as I understand, it looks like, in our case at least, this
> [other round of recursion does have a significant performance
> impact|https://github.com/apache/tinkerpop/pull/1699#issuecomment-1170430130].
> As I'm not too familiar with that part of TinkerPop code, it's unclear to me
> if that's because of our usage of JanusGraph/TinkerPop (feel free to advise).
> But in any case, I thought that was worth reporting in case others hit the
> same issue.
> Happy to share/investigate more if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2888) DefaultTraversal's applyStrategies performance decrease
Clément de Groc created TINKERPOP-2888:
--
Summary: DefaultTraversal's applyStrategies performance decrease
Key: TINKERPOP-2888
URL: https://issues.apache.org/jira/browse/TINKERPOP-2888
Project: TinkerPop
Issue Type: Bug
Components: server
Affects Versions: 3.5.4, 3.6.1
Reporter: Clément de Groc
We have recently upgraded from JanusGraph {{0.6.2}} (TinkerPop {{{}3.5.3{}}})
to JanusGraph {{0.6.3}} (TinkerPop {{{}3.5.5{}}}) and have observed an increase
in all latency metrics reported by Gremlin Server.
Using a profiler we have seen that more time is spent in
{{TraversalHelper.applyTraversalRecursively}} calling itself recursively
multiple times.
Then we've narrowed down the issue to [this
change|https://github.com/apache/tinkerpop/commit/1a548e808922a0eae23b586fe4d6567238989299]
and resolved the latency problem by reverting the change in
{{{}DefaultTraversal.java{}}}.
TLDR; as far as I understand, it looks like, in our case at least, this [other
round of recursion does have a significant performance
impact|https://github.com/apache/tinkerpop/pull/1699#issuecomment-1170430130].
As I'm not too familiar with that part of TinkerPop code, it's unclear to me if
that's because of our usage of JanusGraph/TinkerPop (feel free to advise). But
in any case, I thought that was worth reporting in case others hit the same
issue.
Happy to share/investigate more if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
New Committer: Ken Hu
The Project Management Committee (PMC) for Apache TinkerPop has asked Ken Hu to become a committer and we are pleased to announce his acceptance. Ken has already made a lot of great contributions, including bug fixes and improvements to the development workflow. He is also an active member of our community as he helps users and participates in development discussions. Welcome, Ken, and thank you for your efforts!
