Date   

Re: [DISCUSS] Automatic reversal of traversal to exploit index

graham...@...
 

Thanks Ted, That's really helpful. I guess ideally this should be implemented by an OptimizationStrategy, so that it would be portable across graph providers. I guess that requires that we can determine what indexes exist, etc, in a portable manner. If that's not possible - e.g. because we need to use Janus's mgmt system - then the alternative appears to be a ProviderOptimizationStrategy that would be specific to JanusGraph. I will try to take a look at it.


Re: [DISCUSS] Automatic reversal of traversal to exploit index

Ted Wilmes <twi...@...>
 

Hi Graham,
That's a great question. JanusGraph could perform this optimization, but as you're seeing, it doesn't now. This functionality would involve developing a new traversal strategy [1] that would take Janus schema into account, identify patterns where this reversal could be applied, and the traversal would be transparently rewritten to produce a traversal that provides an equivalent (albeit faster) result.

--Ted


On Tuesday, July 18, 2017 at 9:58:51 AM UTC-5, graham...@... wrote:
If a graph has an index on a particular attribute of a vertex with a particular label, and a user issues a gremlin query that attempts to traverse from a non-indexed vertex to the indexed vertex, then can the traversal (or at least this part of it) be reversed to exploit the availability of the index?

Here's an example:

conf=new BaseConfiguration()

graph = JanusGraphFactory.open('c:/dev/janus/janusgraph-0.1.1-hadoop2/conf/janus-berkeley-gw.properties')


mgmt=graph.openManagement()

assetid = mgmt.makePropertyKey('assetid').dataType(String.class).make()

asset=mgmt.makeVertexLabel('Asset').make()

mgmt.buildIndex('assetById',Vertex.class).addKey(assetid).indexOnly(asset).buildCompositeIndex()

mgmt.commit()



for (i in 1..100000) {

  p=graph.addVertex(label,'Person','name',i)

  a=graph.addVertex(label,'Asset','assetid','asset-num-'+i)

  p.addEdge('owns',a)

}

graph.tx().commit()


// 'Forward' query - starts with the non-indexed vertex label and traverses 'out' to connected vertex with indexed attribute

t=System.currentTimeMillis();g.V().hasLabel('Person').out('owns').hasLabel('Asset').has('assetid','asset-num-7').iterate();System.currentTimeMillis()-t

// Issues the usual warning: 14:18:26 WARN  org.janusgraph.graphdb.transaction.StandardJanusGraphTx  - Query requires iterating over all vertices [(~label = Person)]. For better perform

// 2773ms


// 'Reversed' query - starts with the vertex with indexed attribute and traverses 'in' to connected non-indexed vertex

t=System.currentTimeMillis();g.V().hasLabel('Asset').has('assetid','asset-num-7').in('owns').hasLabel('Person').iterate();System.currentTimeMillis()-t

// 2ms


Note that the reversed traversal is many times faster - approx 1000 faster in this particular example.


Given that JanusGraph knows what has been indexed, could JanusGraph determine *automatically* that the traversal would be more efficient starting at the indexed vertex and run backwards? If so, could this be extended to auto-reversal of segments of longer traversals?


Many thanks

  Graham



[DISCUSS] Automatic reversal of traversal to exploit index

graham...@...
 

If a graph has an index on a particular attribute of a vertex with a particular label, and a user issues a gremlin query that attempts to traverse from a non-indexed vertex to the indexed vertex, then can the traversal (or at least this part of it) be reversed to exploit the availability of the index?

Here's an example:

conf=new BaseConfiguration()

graph = JanusGraphFactory.open('c:/dev/janus/janusgraph-0.1.1-hadoop2/conf/janus-berkeley-gw.properties')


mgmt=graph.openManagement()

assetid = mgmt.makePropertyKey('assetid').dataType(String.class).make()

asset=mgmt.makeVertexLabel('Asset').make()

mgmt.buildIndex('assetById',Vertex.class).addKey(assetid).indexOnly(asset).buildCompositeIndex()

mgmt.commit()



for (i in 1..100000) {

  p=graph.addVertex(label,'Person','name',i)

  a=graph.addVertex(label,'Asset','assetid','asset-num-'+i)

  p.addEdge('owns',a)

}

graph.tx().commit()


// 'Forward' query - starts with the non-indexed vertex label and traverses 'out' to connected vertex with indexed attribute

t=System.currentTimeMillis();g.V().hasLabel('Person').out('owns').hasLabel('Asset').has('assetid','asset-num-7').iterate();System.currentTimeMillis()-t

// Issues the usual warning: 14:18:26 WARN  org.janusgraph.graphdb.transaction.StandardJanusGraphTx  - Query requires iterating over all vertices [(~label = Person)]. For better perform

// 2773ms


// 'Reversed' query - starts with the vertex with indexed attribute and traverses 'in' to connected non-indexed vertex

t=System.currentTimeMillis();g.V().hasLabel('Asset').has('assetid','asset-num-7').in('owns').hasLabel('Person').iterate();System.currentTimeMillis()-t

// 2ms


Note that the reversed traversal is many times faster - approx 1000 faster in this particular example.


Given that JanusGraph knows what has been indexed, could JanusGraph determine *automatically* that the traversal would be more efficient starting at the indexed vertex and run backwards? If so, could this be extended to auto-reversal of segments of longer traversals?


Many thanks

  Graham



Re: [DISCUSS] merge/commit flow for committers

sjudeng <sju...@...>
 

Thanks for your summary, it looks looks good and I agree the approaches are very similar. Given this it might just come down to what our preference is as a community. Unlike before we now have time to hopefully come to a stronger consensus. I think we just want to decide either way by the 0.2.0 release.

Few questions about the Spark flow:

1. When cherry-picking what if the commit isn't the most recent, do you need to identify the commit hash (or should you always cherry-pick by hash)?
2. In the case of multiple commits in a PR do you cherry-pick individually or can you cherry pick the merge commit?
3. If a committer wants to check whether master is up-to-date with a release branch how is this done?

With the TinkerPop flow the merge into master (and the check whether master is up-to-date) is always just "git merge release-branch". I like the simplicity, especially for checking whether master is up-to-date. Right now if I want to confirm all commits in 0.1 are in master I try "git log origin/0.1 ^origin/master". But this shows me 29 commits (16 if I add "--no-merges"). Is this expected or did we do something wrong (or is there a better git call for this)? If we followed the TinkerPop flow I could do a "git merge release-branch" and get a satisfying "Already up-to-date" response from git.


On Saturday, July 15, 2017 at 2:48:06 PM UTC-5, Jerry He wrote:

Do we allow direct but protected push to the main repo?  If not, PR will be needed to push to each branch in all approaches.

The work is the same.  There is no easy way out.  The steps may be slightly different.  The goal is the same too, to let the change go to appropriate branches and maintain a relatively clean commit history.


Let’s look at two examples, Spark and TinkerPop, both of which use the PR model, from my understanding. Please correct me if wrong.


Spark flow:

1. JIRA

2. Pull request against master (contributor)

3. Merge PR (committer)

4. Cherry-pick the commit to an old branch if needed, direct push, no PR (committer)

    In rare cases and if the conflicts are non-trivial, the committer will request a PR from the contributor against the old branch and then merge.


TinkerPop flow:

1. JIRA

2. Pull request against master or an old branch (contributor)

3. Merge PR (committer)

4. Merge branch from an old branch that has the PR to master, direct push, no PR (committer).


Again, the work is similar. There is no big difference. 

Spark has additional requirements on the PR and commit message format and hides all pure ‘merge commit’. 


Thanks,


Jerry




On Friday, July 14, 2017 at 6:34:38 PM UTC-7, sjudeng wrote:
At the time of our previous discussion on this we were blocking merge of all PRs until resolution, so I know for my part it seemed reasonable to try an approach and move forward. Similarly could we try the alternative merge strategy for the next round of development (e.g. 0.2 release branch) and see if it works better for us? For one it might make sense to align with TinkerPop on this since many are members of both communities. I agree it does depend on how active development is on release branches. Soon I expect we'll have a 0.2 release branch (tied to TinkerPop-3.2/Spark-1.6) and master (tied to TinkerPop-3.3/Spark-2.1). I had been thinking we would be maintaining both of these in parallel to a much greater extent than we tried to do with 0.1/master, where 0.1 mostly only got bug fixes. It seems like the proposed merge strategy would scale better when many PRs (with potentially multiple commits) will go to both branches. I do like your point regarding the contributor resolving conflicts in both branches. But it also seems odd to me to have duplicate PRs with the same feature going into different branches. Is this common in other projects?

On Thursday, July 13, 2017 at 6:54:18 PM UTC-5, Jerry He wrote:
I recall we had previous discussed this topic, and had a consensus.

Is it not working for us and we need to change direction? 

By looking at the history,  the 3 or so PRs that were missed in master were during the transition time of the previous discussion. Things after that are working as expected. 
But surely we all want to remind ourselves to follow so when we commit.

I see there is no differences in term of the work involved for the different approaches.

We all have to:
1. Decide which version  the change will go into.  
2. After committing to one branch, merge or PR (and resolving conflicts) to the other branches.

The current approach (as agreed upon in the previous thread) is default to master.  Then selectively go to the other branches, which will be done at the same time.
The alternative is to go to the other branches, then merge  (resolving conflicts) to master.  If we do branch merge, then we have the question of how often we do it,  For each commit, or once a while?

Branches will diverge, and can significantly so after a while.  Then there is a question on who is better to do the merge/resolving conflicts.  I think it belongs to the originator of the change, not the committer.  (It could be the same person.)

Also, as we go, the changes that need to go to the other branches should diminish significantly, and we should do it purposefully to reduce our maintenance cost and encourage upgrade.

It does not seem things are broken, or there is an overwhelming advantage of the alternative so that we need to change.


Thanks.

Jerry




On Thursday, July 13, 2017 at 2:22:57 PM UTC-7, Ted Wilmes wrote:
I think the TinkerPop way is a good way to go. It's straightforward and has worked well on that project.

--Ted

On Thursday, July 13, 2017 at 12:04:59 PM UTC-5, Irving Duran wrote:
I like this approach. Does anybody know if this will be a problem for Travis-CI to pick up as of which branch the testing will be done?


Thank You,

Irving Duran

On Wed, Jul 12, 2017 at 8:22 PM, sjudeng <s...@...> wrote:
Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] merge/commit flow for committers

Jerry He <jerr...@...>
 

Do we allow direct but protected push to the main repo?  If not, PR will be needed to push to each branch in all approaches.

The work is the same.  There is no easy way out.  The steps may be slightly different.  The goal is the same too, to let the change go to appropriate branches and maintain a relatively clean commit history.


Let’s look at two examples, Spark and TinkerPop, both of which use the PR model, from my understanding. Please correct me if wrong.


Spark flow:

1. JIRA

2. Pull request against master (contributor)

3. Merge PR (committer)

4. Cherry-pick the commit to an old branch if needed, direct push, no PR (committer)

    In rare cases and if the conflicts are non-trivial, the committer will request a PR from the contributor against the old branch and then merge.


TinkerPop flow:

1. JIRA

2. Pull request against master or an old branch (contributor)

3. Merge PR (committer)

4. Merge branch from an old branch that has the PR to master, direct push, no PR (committer).


Again, the work is similar. There is no big difference. 

Spark has additional requirements on the PR and commit message format and hides all pure ‘merge commit’. 


Thanks,


Jerry




On Friday, July 14, 2017 at 6:34:38 PM UTC-7, sjudeng wrote:
At the time of our previous discussion on this we were blocking merge of all PRs until resolution, so I know for my part it seemed reasonable to try an approach and move forward. Similarly could we try the alternative merge strategy for the next round of development (e.g. 0.2 release branch) and see if it works better for us? For one it might make sense to align with TinkerPop on this since many are members of both communities. I agree it does depend on how active development is on release branches. Soon I expect we'll have a 0.2 release branch (tied to TinkerPop-3.2/Spark-1.6) and master (tied to TinkerPop-3.3/Spark-2.1). I had been thinking we would be maintaining both of these in parallel to a much greater extent than we tried to do with 0.1/master, where 0.1 mostly only got bug fixes. It seems like the proposed merge strategy would scale better when many PRs (with potentially multiple commits) will go to both branches. I do like your point regarding the contributor resolving conflicts in both branches. But it also seems odd to me to have duplicate PRs with the same feature going into different branches. Is this common in other projects?

On Thursday, July 13, 2017 at 6:54:18 PM UTC-5, Jerry He wrote:
I recall we had previous discussed this topic, and had a consensus.

Is it not working for us and we need to change direction? 

By looking at the history,  the 3 or so PRs that were missed in master were during the transition time of the previous discussion. Things after that are working as expected. 
But surely we all want to remind ourselves to follow so when we commit.

I see there is no differences in term of the work involved for the different approaches.

We all have to:
1. Decide which version  the change will go into.  
2. After committing to one branch, merge or PR (and resolving conflicts) to the other branches.

The current approach (as agreed upon in the previous thread) is default to master.  Then selectively go to the other branches, which will be done at the same time.
The alternative is to go to the other branches, then merge  (resolving conflicts) to master.  If we do branch merge, then we have the question of how often we do it,  For each commit, or once a while?

Branches will diverge, and can significantly so after a while.  Then there is a question on who is better to do the merge/resolving conflicts.  I think it belongs to the originator of the change, not the committer.  (It could be the same person.)

Also, as we go, the changes that need to go to the other branches should diminish significantly, and we should do it purposefully to reduce our maintenance cost and encourage upgrade.

It does not seem things are broken, or there is an overwhelming advantage of the alternative so that we need to change.


Thanks.

Jerry




On Thursday, July 13, 2017 at 2:22:57 PM UTC-7, Ted Wilmes wrote:
I think the TinkerPop way is a good way to go. It's straightforward and has worked well on that project.

--Ted

On Thursday, July 13, 2017 at 12:04:59 PM UTC-5, Irving Duran wrote:
I like this approach. Does anybody know if this will be a problem for Travis-CI to pick up as of which branch the testing will be done?


Thank You,

Irving Duran

On Wed, Jul 12, 2017 at 8:22 PM, sjudeng <s...@...> wrote:
Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Should the two GraphFactories have graph-deletion wrapper methods?

sjudeng <sju...@...>
 

David, Keith and Benjamin - Thanks a lot for your work and insights on this. I like the sharp edges analogy. You've got me convinced, I'm good with adding the drop functionality to the core factory API. Maybe give it another few days for any lingering comments here and then move forward?

If/when the delete functionality is added to the core factory API we should make sure it's a complete feature and behaves in the expected manner, which as has been pointed out in the PR and here is the equivalent of DBMS drop functionality, across all storage and indexing backends. The test case for each storage/indexing backend would be "assert keyspace/table/index/etc. does not exist"? Agreed?

One thing to note on this is that existing delete implementations in the storage/indexing backends are not generally consistent with the above expected behavior as it appears they were written to support the testing rather than production use case. For example, Cassandra CQL, ThriftAstyanax and Embedded store managers all truncate instead of drop keyspaces. Likewise for HBaseStoreManagerElasticSearchIndex appears to do the right thing (though need to confirm this works as expected with multi-type indices in pending-merge #336) as does LuceneIndex. On the other hand SolrIndex does not appear to delete collections as would be expected.

The challenge here will be to support dropping keyspaces/etc. through the proposed core factory API delete functionality but still maintain the existing clearStorage implementations for testing. The latter is critical because it's been found that dropping keyspaces/tables during testing has a significant impact on performance (see #384 which showed truncation, among other updates, decreased runtime for the TinkerPop test suite in the CQL module from 15 hours to 3 hours).

I'm thinking this might be why he existing delete implementation is not already in the core factory API ... the current implementation does not consistently perform the expected operation and until it does the feature is hidden off in the JanusGraphCleanup utility class.


On Friday, July 14, 2017 at 1:02:49 PM UTC-5, Benjamin Anderson wrote:
Good tools usually have sharp edges; infantilizing users by protecting
them from themselves is not traditionally well-received in the systems
programming world. Is there any technical benefit to the elision?
E.g., does including a graph deletion method preclude us from
implementing optimizations we'd prefer to take advantage of? Dropping
data is a standard DBMS function (relational or otherwise), so users
are almost certain to ask for it; "we don't want you to hurt yourself"
is a bit of a lame reason to give them.

From another perspective: if there is in fact risk of the users doing
the /wrong/ thing here, e.g., executing the steps in the wrong order,
and compromising system integrity, then it seems we'd be doing them a
service by simplifying the process.

+1 for inclusion of the deletion methods.

Cheers,
--
b


On Thu, Jul 13, 2017 at 9:52 AM, David Pitera <pit...@...> wrote:
> The discussion so far has mostly taken place on my PR here:
> https://github.com/JanusGraph/janusgraph/pull/392#issuecomment-313802891
> following this high level comment to the last comment.
>
> To summarize, Sjudeng so far is of the attitude that the `JanusGraphFactory`
> and `ConfiguredGraphFactory` should not have wrapper methods to delete your
> graphs because it is dangerous and not advised in a production scenario.
>
> So far I and Keith Lohnes are of the attitude that the factories should
> enable graph deletion for:
>
> 1. A complete UX
> 2. A complete DB management toolbox
> 3. If users do not delete their graphs correctly, i.e. 1. removing it from
> cache 2. closing it and 3. clearing the storage (and in this order), they
> can find their db in an unexpected state.
>
> I would appreciate some thoughts/comments on the matter to get the
> discussion going. I want to get this PR in for 0.2.0 and would also like
> this change in 0.2.0.
>
> Thanks!
> David
>
> --
> You received this message because you are subscribed to the Google Groups
> "JanusGraph developer list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to janusgraph-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] merge/commit flow for committers

sjudeng <sju...@...>
 

At the time of our previous discussion on this we were blocking merge of all PRs until resolution, so I know for my part it seemed reasonable to try an approach and move forward. Similarly could we try the alternative merge strategy for the next round of development (e.g. 0.2 release branch) and see if it works better for us? For one it might make sense to align with TinkerPop on this since many are members of both communities. I agree it does depend on how active development is on release branches. Soon I expect we'll have a 0.2 release branch (tied to TinkerPop-3.2/Spark-1.6) and master (tied to TinkerPop-3.3/Spark-2.1). I had been thinking we would be maintaining both of these in parallel to a much greater extent than we tried to do with 0.1/master, where 0.1 mostly only got bug fixes. It seems like the proposed merge strategy would scale better when many PRs (with potentially multiple commits) will go to both branches. I do like your point regarding the contributor resolving conflicts in both branches. But it also seems odd to me to have duplicate PRs with the same feature going into different branches. Is this common in other projects?

On Thursday, July 13, 2017 at 6:54:18 PM UTC-5, Jerry He wrote:

I recall we had previous discussed this topic, and had a consensus.

Is it not working for us and we need to change direction? 

By looking at the history,  the 3 or so PRs that were missed in master were during the transition time of the previous discussion. Things after that are working as expected. 
But surely we all want to remind ourselves to follow so when we commit.

I see there is no differences in term of the work involved for the different approaches.

We all have to:
1. Decide which version  the change will go into.  
2. After committing to one branch, merge or PR (and resolving conflicts) to the other branches.

The current approach (as agreed upon in the previous thread) is default to master.  Then selectively go to the other branches, which will be done at the same time.
The alternative is to go to the other branches, then merge  (resolving conflicts) to master.  If we do branch merge, then we have the question of how often we do it,  For each commit, or once a while?

Branches will diverge, and can significantly so after a while.  Then there is a question on who is better to do the merge/resolving conflicts.  I think it belongs to the originator of the change, not the committer.  (It could be the same person.)

Also, as we go, the changes that need to go to the other branches should diminish significantly, and we should do it purposefully to reduce our maintenance cost and encourage upgrade.

It does not seem things are broken, or there is an overwhelming advantage of the alternative so that we need to change.


Thanks.

Jerry




On Thursday, July 13, 2017 at 2:22:57 PM UTC-7, Ted Wilmes wrote:
I think the TinkerPop way is a good way to go. It's straightforward and has worked well on that project.

--Ted

On Thursday, July 13, 2017 at 12:04:59 PM UTC-5, Irving Duran wrote:
I like this approach. Does anybody know if this will be a problem for Travis-CI to pick up as of which branch the testing will be done?


Thank You,

Irving Duran

On Wed, Jul 12, 2017 at 8:22 PM, sjudeng <s...@...> wrote:
Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Should the two GraphFactories have graph-deletion wrapper methods?

Benjamin Anderson <b...@...>
 

Good tools usually have sharp edges; infantilizing users by protecting
them from themselves is not traditionally well-received in the systems
programming world. Is there any technical benefit to the elision?
E.g., does including a graph deletion method preclude us from
implementing optimizations we'd prefer to take advantage of? Dropping
data is a standard DBMS function (relational or otherwise), so users
are almost certain to ask for it; "we don't want you to hurt yourself"
is a bit of a lame reason to give them.

From another perspective: if there is in fact risk of the users doing
the /wrong/ thing here, e.g., executing the steps in the wrong order,
and compromising system integrity, then it seems we'd be doing them a
service by simplifying the process.

+1 for inclusion of the deletion methods.

Cheers,
--
b

On Thu, Jul 13, 2017 at 9:52 AM, David Pitera <piter...@...> wrote:
The discussion so far has mostly taken place on my PR here:
https://github.com/JanusGraph/janusgraph/pull/392#issuecomment-313802891
following this high level comment to the last comment.

To summarize, Sjudeng so far is of the attitude that the `JanusGraphFactory`
and `ConfiguredGraphFactory` should not have wrapper methods to delete your
graphs because it is dangerous and not advised in a production scenario.

So far I and Keith Lohnes are of the attitude that the factories should
enable graph deletion for:

1. A complete UX
2. A complete DB management toolbox
3. If users do not delete their graphs correctly, i.e. 1. removing it from
cache 2. closing it and 3. clearing the storage (and in this order), they
can find their db in an unexpected state.

I would appreciate some thoughts/comments on the matter to get the
discussion going. I want to get this PR in for 0.2.0 and would also like
this change in 0.2.0.

Thanks!
David

--
You received this message because you are subscribed to the Google Groups
"JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to janusgr...@....
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] merge/commit flow for committers

Jason Plurad <plu...@...>
 

That's right, Jerry. We had consensus. I wanted to revisit it in case it is not working out for us. I'm not certain it is, but we should have the conversation on the dev list, not buried in various PRs.

My main point is I don't want to worry about fixes missing from the right branches. If it was just that one PR, then maybe I don't need to be so worried.

This could be as simple as the approving committer putting a closing comment saying that it needs to be merged/cherry-picked into the other branch.

-- Jason

On Thursday, July 13, 2017 at 7:54:18 PM UTC-4, Jerry He wrote:
I recall we had previous discussed this topic, and had a consensus.

Is it not working for us and we need to change direction? 

By looking at the history,  the 3 or so PRs that were missed in master were during the transition time of the previous discussion. Things after that are working as expected. 
But surely we all want to remind ourselves to follow so when we commit.

I see there is no differences in term of the work involved for the different approaches.

We all have to:
1. Decide which version  the change will go into.  
2. After committing to one branch, merge or PR (and resolving conflicts) to the other branches.

The current approach (as agreed upon in the previous thread) is default to master.  Then selectively go to the other branches, which will be done at the same time.
The alternative is to go to the other branches, then merge  (resolving conflicts) to master.  If we do branch merge, then we have the question of how often we do it,  For each commit, or once a while?

Branches will diverge, and can significantly so after a while.  Then there is a question on who is better to do the merge/resolving conflicts.  I think it belongs to the originator of the change, not the committer.  (It could be the same person.)

Also, as we go, the changes that need to go to the other branches should diminish significantly, and we should do it purposefully to reduce our maintenance cost and encourage upgrade.

It does not seem things are broken, or there is an overwhelming advantage of the alternative so that we need to change.


Thanks.

Jerry




On Thursday, July 13, 2017 at 2:22:57 PM UTC-7, Ted Wilmes wrote:
I think the TinkerPop way is a good way to go. It's straightforward and has worked well on that project.

--Ted

On Thursday, July 13, 2017 at 12:04:59 PM UTC-5, Irving Duran wrote:
I like this approach. Does anybody know if this will be a problem for Travis-CI to pick up as of which branch the testing will be done?


Thank You,

Irving Duran

On Wed, Jul 12, 2017 at 8:22 PM, sjudeng <s...@...> wrote:
Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] merge/commit flow for committers

Jerry He <jerr...@...>
 

I recall we had previous discussed this topic, and had a consensus.
https://groups.google.com/forum/#!topic/janusgraph-dev/RbpP6H0W4dM

Is it not working for us and we need to change direction? 

By looking at the history,  the 3 or so PRs that were missed in master were during the transition time of the previous discussion. Things after that are working as expected. 
But surely we all want to remind ourselves to follow so when we commit.

I see there is no differences in term of the work involved for the different approaches.

We all have to:
1. Decide which version  the change will go into.  
2. After committing to one branch, merge or PR (and resolving conflicts) to the other branches.

The current approach (as agreed upon in the previous thread) is default to master.  Then selectively go to the other branches, which will be done at the same time.
The alternative is to go to the other branches, then merge  (resolving conflicts) to master.  If we do branch merge, then we have the question of how often we do it,  For each commit, or once a while?

Branches will diverge, and can significantly so after a while.  Then there is a question on who is better to do the merge/resolving conflicts.  I think it belongs to the originator of the change, not the committer.  (It could be the same person.)

Also, as we go, the changes that need to go to the other branches should diminish significantly, and we should do it purposefully to reduce our maintenance cost and encourage upgrade.

It does not seem things are broken, or there is an overwhelming advantage of the alternative so that we need to change.


Thanks.

Jerry




On Thursday, July 13, 2017 at 2:22:57 PM UTC-7, Ted Wilmes wrote:
I think the TinkerPop way is a good way to go. It's straightforward and has worked well on that project.

--Ted

On Thursday, July 13, 2017 at 12:04:59 PM UTC-5, Irving Duran wrote:
I like this approach. Does anybody know if this will be a problem for Travis-CI to pick up as of which branch the testing will be done?


Thank You,

Irving Duran

On Wed, Jul 12, 2017 at 8:22 PM, sjudeng <s...@...> wrote:
Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] merge/commit flow for committers

Ted Wilmes <twi...@...>
 

I think the TinkerPop way is a good way to go. It's straightforward and has worked well on that project.

--Ted


On Thursday, July 13, 2017 at 12:04:59 PM UTC-5, Irving Duran wrote:
I like this approach. Does anybody know if this will be a problem for Travis-CI to pick up as of which branch the testing will be done?


Thank You,

Irving Duran

On Wed, Jul 12, 2017 at 8:22 PM, sjudeng <sju...@...> wrote:
Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] merge/commit flow for committers

Irving Duran <irvin...@...>
 

I like this approach. Does anybody know if this will be a problem for Travis-CI to pick up as of which branch the testing will be done?


Thank You,

Irving Duran

On Wed, Jul 12, 2017 at 8:22 PM, sjudeng <sju...@...> wrote:
Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[DISCUSS] Should the two GraphFactories have graph-deletion wrapper methods?

David Pitera <piter...@...>
 

The discussion so far has mostly taken place on my PR here: https://github.com/JanusGraph/janusgraph/pull/392#issuecomment-313802891 following this high level comment to the last comment.

To summarize, Sjudeng so far is of the attitude that the `JanusGraphFactory` and `ConfiguredGraphFactory` should not have wrapper methods to delete your graphs because it is dangerous and not advised in a production scenario.

So far I and Keith Lohnes are of the attitude that the factories should enable graph deletion for:

1. A complete UX
2. A complete DB management toolbox
3. If users do not delete their graphs correctly, i.e. 1. removing it from cache 2. closing it and 3. clearing the storage (and in this order), they can find their db in an unexpected state.

I would appreciate some thoughts/comments on the matter to get the discussion going. I want to get this PR in for 0.2.0 and would also like this change in 0.2.0.

Thanks!
David


Re: [DISCUSS] merge/commit flow for committers

sjudeng <sju...@...>
 

Based on our trial with the approach of merging into master and cherry-picking commits into release branches, I'd like to suggest we instead follow the TinkerPop process and merge features into relevant release branches and then merge release branches into master. I'd suggest we make this change after releasing 0.2.0, depending on the separate decision on how branching occurs after that (e.g. if we created a 0.2 branch and bumped master to 0.3.0-SNAPSHOT).

Some of the problems with the current approach have come up in the past weeks, including updates merged into 0.1 but not master (Jason this comment is what started it). There have also been cases where contributors are trying to solve this disconnect on their own by submitting multiple PRs for the same feature, one for the release branch and one for master. This makes it more difficult for us as reviewers and also makes it hard to track all interactions on an issue because comments are spread across multiple PRs.


On Wednesday, July 12, 2017 at 2:09:12 PM UTC-5, Jason Plurad wrote:
I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason


[DISCUSS] merge/commit flow for committers

Jason Plurad <plu...@...>
 

I came across PR-393 the other day as I was looking through the latest commits.

> A number of commits in 0.1 are missing in master. @srosenthal Thanks for catching.

Many thanks to everybody that helped identify and fix that situation!

However I was left wondering a bunch of things:
1. Where would I find the conversation that triggered the PR?
2. How did we miss merging commits into master?
3. How are we tracking which issues get merged into which branches?
4. Do we have the merge/commit process sufficiently documented?

We have this document on pull requests http://docs.janusgraph.org/latest/pull-requests.html but it doesn't seem to cover anything about how to handle merges for multiple branches. For example, TinkerPop is a bit more clear on how it handles this http://tinkerpop.apache.org/docs/3.2.5/dev/developer/#branches

There's some good discussion in PR-393. If we reached a consensus on what the right strategy is, feel free to chime in here amcp, jerryjch, sjudeng, srosenthal, and others so we can get it documented and publicized more widely.

-- Jason


Re: Gremlin-Python in JanusGraph

john....@...
 

Thank you Jason, that fixed the problem!


On Thursday, July 6, 2017 at 11:29:40 PM UTC-4, Jason Plurad wrote:
Hi John, you probably installed the wrong version of gremlin-python plugin. If you're using JanusGraph 0.1.1, the TinkerPop version is 3.2.3. If you're building master from source, it has TinkerPop 3.2.5 now.

Try this:

cd janusgraph-0.1.1-hadoop2
rm
-rf ext/gremlin-python/
bin
/gremlin-server.sh -i org.apache.tinkerpop gremlin-python 3.2.3

-- Jason

On Thursday, July 6, 2017 at 7:45:21 PM UTC-4, john.helmsen wrote:
Gentlemen and Ladies,

Thank you for your help with the previous difficulties that we have been having in configuring our system.  We have recently gotten JanusGraph running in Server mode with HBase, and it is working correctly.  However, we have recently tried to add gremlin-python access to the server, so that we can work with it via a python client.

We are following the instructions on this page, which we have established work correctly when interfacing with GremlinServer running TinkerGraph: http://tinkerpop.apache.org/docs/current/reference/#gremlin-python

The problem is that when running starting the JanusGraph server referencing the following file:
host: localhost
port: 8182
threadPoolWorker: 1
gremlinPool: 8
scriptEvaluationTimeout: 30000
graphs: {
  graph: conf/tinkergraph-empty.properties}
scriptEngines: {
  gremlin-groovy: {
    plugins: { org.apache.tinkerpop.gremlin.server.jsr223.GremlinServerGremlinPl
ugin: {},
               org.apache.tinkerpop.gremlin.tinkergraph.jsr223.TinkerGraphGremli
nPlugin: {},
               org.apache.tinkerpop.gremlin.jsr223.ImportGremlinPlugin: {classIm
ports: [java.lang.Math], methodImports: [java.lang.Math#*]},
               org.apache.tinkerpop.gremlin.jsr223.ScriptFileGremlinPlugin: {fil
es: [scripts/generate-modern.groovy]}}},
  gremlin-jython: {},
  gremlin-python: {}
}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.
TinkerIoRegistryV1d0] }}            # application/vnd.gremlin-v1.0+gryo
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializ
erV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/vnd.gremlin-v1.0+gryo-lite
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { serializeResultToString: true }}        # application/vnd.gremlin-
v1.0+gryo-stringd
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV1d0] }} # application/vnd.gremlin-v1.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV2d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV2d0] }} # application/vnd.gremlin-v2.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erV3d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/json
metrics: {
  slf4jReporter: {enabled: true, interval: 180000}}
strictTransactionManagement: false
threadPoolBoss: 1
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64


or this file:

host: localhost
port: 8182
scriptEvaluationTimeout: 30000
channelizer: org.apache.tinkerpop.gremlin.server.channel.WebSocketChannelizer
graphs: {
  graph: conf/gremlin-server/janusgraph-hbase-server.properties}
plugins:
  - janusgraph.imports
scriptEngines: {
  gremlin-groovy: {
    imports: [java.lang.Math],
    staticImports: [java.lang.Math.PI],
    scripts: [scripts/empty-sample.groovy]},
  gremlin-jython: {},
  gremlin-python: {}}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { bufferSize: 8192, ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
processors:
  - { className: org.apache.tinkerpop.gremlin.server.op.session.SessionOpProcessor, config: { sessionTimeout: 28800000 }}
  - { className: org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor, config: { cacheExpirationTime: 600000, cacheMaxSize: 1000 }}
metrics: {
  consoleReporter: {enabled: true, interval: 180000},
  csvReporter: {enabled: true, interval: 180000, fileName: /tmp/gremlin-server-metrics.csv},
  jmxReporter: {enabled: true},
  slf4jReporter: {enabled: true, interval: 180000},
  gangliaReporter: {enabled: false, interval: 180000, addressingMode: MULTICAST},
  graphiteReporter: {enabled: false, interval: 180000}}
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64
writeBufferLowWaterMark: 32768
writeBufferHighWaterMark: 65536
ssl: {
  enabled: false}


They give this error:
Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngine.<init>(GremlinJythonScriptEngine.java:86)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngineFactory.getScriptEngine(GremlinJythonScriptEngineFactory.java:110)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.createGremlinScriptEngine(DefaultGremlinScriptEngineManager.java:420)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.getEngineByName(DefaultGremlinScriptEngineManager.java:215)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.createScriptEngine(ScriptEngines.java:424)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.reload(ScriptEngines.java:187)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.lambda$createScriptEngines$11(GremlinExecutor.java:408)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.<init>(ScriptEngines.java:92)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.createScriptEngines(GremlinExecutor.java:404)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:110)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:74)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor$Builder.create(GremlinExecutor.java:651)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:136)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:83)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.<init>(GremlinServer.java:110)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.main(GremlinServer.java:344)


I am not actually using gremlin-jython, so I did make sure to remove the gremlin-jython references from both files and test them as well.  The results are the same. My best guess is that there is an API for the plugins of gremlin-jython and gremlin-python that is not matching up with JanusGraph properly, but it is unclear how to fix this.  Would anyone have any ideas?

Note, I can connect to the gremlin server in python using gremlinclient, and I can send commands to the server using the standard gremlin console as a client, so the server is operational.

Gremlin-python is considerably easier to develop in and preferable, so does anyone know how to fix this?  Thank you for all your help!


Re: 0.2.0-SNAPSHOT updates?

Jason Plurad <plu...@...>
 

I've deployed snapshot updates to Sonatype for 0.2.0-SNAPSHOT and 0.1.2-SNAPSHOT.

-- Jason


On Friday, June 30, 2017 at 11:29:19 AM UTC-4, Austin Sharp wrote:
FWIW we're very eager to see new snapshots and hopefully an 0.2.0 release soon as well. Eager enough that we are working on a branch that works with the 0.2.0 snapshot, and debating whether we'd (if it takes too long) release with the 0.2.0 snapshot or backport some changes to a forked version of 0.1.1.

On Tuesday, June 27, 2017 at 9:08:54 AM UTC-7, Ted Wilmes wrote:
Hey Jason,
I think you should be good to go since you added your name to the list on this issue: https://github.com/janusgraph/janusgraph/issues/97. With Sonatype permissions you'll be able to deploy the snapshot. Since that doesn't include binaries at this point, I've used the GitHub release feature to upload snapshot binaries before.  If you try it out and run into any issues, let me know.

--Ted

On Monday, June 26, 2017 at 8:42:20 PM UTC-5, Jason Plurad wrote:
Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason

On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
Hello,

I've been waiting for some features recently added to Janus to give it a go.
But it seems that last snapshot available for 0.2.0 release is a month old (24 May 2017):

https://oss.sonatype.org/content/repositories/snapshots/org/janusgraph/janusgraph-core/0.2.0-SNAPSHOT/

I know I could built it from source and host it somewhere privately, but I kind of defeats the purpose of having dev snapshots in the first place.

Can we expect some updates to this snapshot anytime soon?

Having this automated and pushed on regular basis would be great too :)


MapReduceIndexManagement - can anyone make it work?

Nigel Brown <nigel...@...>
 

Please see 
https://groups.google.com/forum/#!topic/janusgraph-users/aM9YThbqU-4
Has anyone made this work?
What conditions?
Which version?


Re: Gremlin-Python in JanusGraph

Jason Plurad <plu...@...>
 

Hi John, you probably installed the wrong version of gremlin-python plugin. If you're using JanusGraph 0.1.1, the TinkerPop version is 3.2.3. If you're building master from source, it has TinkerPop 3.2.5 now.

Try this:

cd janusgraph-0.1.1-hadoop2
rm
-rf ext/gremlin-python/
bin
/gremlin-server.sh -i org.apache.tinkerpop gremlin-python 3.2.3

-- Jason


On Thursday, July 6, 2017 at 7:45:21 PM UTC-4, john.helmsen wrote:
Gentlemen and Ladies,

Thank you for your help with the previous difficulties that we have been having in configuring our system.  We have recently gotten JanusGraph running in Server mode with HBase, and it is working correctly.  However, we have recently tried to add gremlin-python access to the server, so that we can work with it via a python client.

We are following the instructions on this page, which we have established work correctly when interfacing with GremlinServer running TinkerGraph: http://tinkerpop.apache.org/docs/current/reference/#gremlin-python

The problem is that when running starting the JanusGraph server referencing the following file:
host: localhost
port: 8182
threadPoolWorker: 1
gremlinPool: 8
scriptEvaluationTimeout: 30000
graphs: {
  graph: conf/tinkergraph-empty.properties}
scriptEngines: {
  gremlin-groovy: {
    plugins: { org.apache.tinkerpop.gremlin.server.jsr223.GremlinServerGremlinPl
ugin: {},
               org.apache.tinkerpop.gremlin.tinkergraph.jsr223.TinkerGraphGremli
nPlugin: {},
               org.apache.tinkerpop.gremlin.jsr223.ImportGremlinPlugin: {classIm
ports: [java.lang.Math], methodImports: [java.lang.Math#*]},
               org.apache.tinkerpop.gremlin.jsr223.ScriptFileGremlinPlugin: {fil
es: [scripts/generate-modern.groovy]}}},
  gremlin-jython: {},
  gremlin-python: {}
}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.
TinkerIoRegistryV1d0] }}            # application/vnd.gremlin-v1.0+gryo
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializ
erV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/vnd.gremlin-v1.0+gryo-lite
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { serializeResultToString: true }}        # application/vnd.gremlin-
v1.0+gryo-stringd
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV1d0] }} # application/vnd.gremlin-v1.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV2d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV2d0] }} # application/vnd.gremlin-v2.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erV3d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/json
metrics: {
  slf4jReporter: {enabled: true, interval: 180000}}
strictTransactionManagement: false
threadPoolBoss: 1
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64


or this file:

host: localhost
port: 8182
scriptEvaluationTimeout: 30000
channelizer: org.apache.tinkerpop.gremlin.server.channel.WebSocketChannelizer
graphs: {
  graph: conf/gremlin-server/janusgraph-hbase-server.properties}
plugins:
  - janusgraph.imports
scriptEngines: {
  gremlin-groovy: {
    imports: [java.lang.Math],
    staticImports: [java.lang.Math.PI],
    scripts: [scripts/empty-sample.groovy]},
  gremlin-jython: {},
  gremlin-python: {}}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { bufferSize: 8192, ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
processors:
  - { className: org.apache.tinkerpop.gremlin.server.op.session.SessionOpProcessor, config: { sessionTimeout: 28800000 }}
  - { className: org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor, config: { cacheExpirationTime: 600000, cacheMaxSize: 1000 }}
metrics: {
  consoleReporter: {enabled: true, interval: 180000},
  csvReporter: {enabled: true, interval: 180000, fileName: /tmp/gremlin-server-metrics.csv},
  jmxReporter: {enabled: true},
  slf4jReporter: {enabled: true, interval: 180000},
  gangliaReporter: {enabled: false, interval: 180000, addressingMode: MULTICAST},
  graphiteReporter: {enabled: false, interval: 180000}}
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64
writeBufferLowWaterMark: 32768
writeBufferHighWaterMark: 65536
ssl: {
  enabled: false}


They give this error:
Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngine.<init>(GremlinJythonScriptEngine.java:86)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngineFactory.getScriptEngine(GremlinJythonScriptEngineFactory.java:110)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.createGremlinScriptEngine(DefaultGremlinScriptEngineManager.java:420)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.getEngineByName(DefaultGremlinScriptEngineManager.java:215)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.createScriptEngine(ScriptEngines.java:424)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.reload(ScriptEngines.java:187)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.lambda$createScriptEngines$11(GremlinExecutor.java:408)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.<init>(ScriptEngines.java:92)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.createScriptEngines(GremlinExecutor.java:404)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:110)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:74)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor$Builder.create(GremlinExecutor.java:651)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:136)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:83)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.<init>(GremlinServer.java:110)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.main(GremlinServer.java:344)


I am not actually using gremlin-jython, so I did make sure to remove the gremlin-jython references from both files and test them as well.  The results are the same. My best guess is that there is an API for the plugins of gremlin-jython and gremlin-python that is not matching up with JanusGraph properly, but it is unclear how to fix this.  Would anyone have any ideas?

Note, I can connect to the gremlin server in python using gremlinclient, and I can send commands to the server using the standard gremlin console as a client, so the server is operational.

Gremlin-python is considerably easier to develop in and preferable, so does anyone know how to fix this?  Thank you for all your help!


Gremlin-Python in JanusGraph

john....@...
 

Gentlemen and Ladies,

Thank you for your help with the previous difficulties that we have been having in configuring our system.  We have recently gotten JanusGraph running in Server mode with HBase, and it is working correctly.  However, we have recently tried to add gremlin-python access to the server, so that we can work with it via a python client.

We are following the instructions on this page, which we have established work correctly when interfacing with GremlinServer running TinkerGraph: http://tinkerpop.apache.org/docs/current/reference/#gremlin-python

The problem is that when running starting the JanusGraph server referencing the following file:
host: localhost
port: 8182
threadPoolWorker: 1
gremlinPool: 8
scriptEvaluationTimeout: 30000
graphs: {
  graph: conf/tinkergraph-empty.properties}
scriptEngines: {
  gremlin-groovy: {
    plugins: { org.apache.tinkerpop.gremlin.server.jsr223.GremlinServerGremlinPl
ugin: {},
               org.apache.tinkerpop.gremlin.tinkergraph.jsr223.TinkerGraphGremli
nPlugin: {},
               org.apache.tinkerpop.gremlin.jsr223.ImportGremlinPlugin: {classIm
ports: [java.lang.Math], methodImports: [java.lang.Math#*]},
               org.apache.tinkerpop.gremlin.jsr223.ScriptFileGremlinPlugin: {fil
es: [scripts/generate-modern.groovy]}}},
  gremlin-jython: {},
  gremlin-python: {}
}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.
TinkerIoRegistryV1d0] }}            # application/vnd.gremlin-v1.0+gryo
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializ
erV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/vnd.gremlin-v1.0+gryo-lite
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { serializeResultToString: true }}        # application/vnd.gremlin-
v1.0+gryo-stringd
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV1d0] }} # application/vnd.gremlin-v1.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV2d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV2d0] }} # application/vnd.gremlin-v2.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erV3d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/json
metrics: {
  slf4jReporter: {enabled: true, interval: 180000}}
strictTransactionManagement: false
threadPoolBoss: 1
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64


or this file:

host: localhost
port: 8182
scriptEvaluationTimeout: 30000
channelizer: org.apache.tinkerpop.gremlin.server.channel.WebSocketChannelizer
graphs: {
  graph: conf/gremlin-server/janusgraph-hbase-server.properties}
plugins:
  - janusgraph.imports
scriptEngines: {
  gremlin-groovy: {
    imports: [java.lang.Math],
    staticImports: [java.lang.Math.PI],
    scripts: [scripts/empty-sample.groovy]},
  gremlin-jython: {},
  gremlin-python: {}}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { bufferSize: 8192, ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
processors:
  - { className: org.apache.tinkerpop.gremlin.server.op.session.SessionOpProcessor, config: { sessionTimeout: 28800000 }}
  - { className: org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor, config: { cacheExpirationTime: 600000, cacheMaxSize: 1000 }}
metrics: {
  consoleReporter: {enabled: true, interval: 180000},
  csvReporter: {enabled: true, interval: 180000, fileName: /tmp/gremlin-server-metrics.csv},
  jmxReporter: {enabled: true},
  slf4jReporter: {enabled: true, interval: 180000},
  gangliaReporter: {enabled: false, interval: 180000, addressingMode: MULTICAST},
  graphiteReporter: {enabled: false, interval: 180000}}
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64
writeBufferLowWaterMark: 32768
writeBufferHighWaterMark: 65536
ssl: {
  enabled: false}


They give this error:
Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngine.<init>(GremlinJythonScriptEngine.java:86)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngineFactory.getScriptEngine(GremlinJythonScriptEngineFactory.java:110)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.createGremlinScriptEngine(DefaultGremlinScriptEngineManager.java:420)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.getEngineByName(DefaultGremlinScriptEngineManager.java:215)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.createScriptEngine(ScriptEngines.java:424)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.reload(ScriptEngines.java:187)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.lambda$createScriptEngines$11(GremlinExecutor.java:408)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.<init>(ScriptEngines.java:92)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.createScriptEngines(GremlinExecutor.java:404)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:110)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:74)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor$Builder.create(GremlinExecutor.java:651)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:136)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:83)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.<init>(GremlinServer.java:110)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.main(GremlinServer.java:344)


I am not actually using gremlin-jython, so I did make sure to remove the gremlin-jython references from both files and test them as well.  The results are the same. My best guess is that there is an API for the plugins of gremlin-jython and gremlin-python that is not matching up with JanusGraph properly, but it is unclear how to fix this.  Would anyone have any ideas?

Note, I can connect to the gremlin server in python using gremlinclient, and I can send commands to the server using the standard gremlin console as a client, so the server is operational.

Gremlin-python is considerably easier to develop in and preferable, so does anyone know how to fix this?  Thank you for all your help!

1261 - 1280 of 1585