[jira] (TINKERPOP-1597) PathRetractionStrategy messing up certain traversals

2017-01-31 Thread Ted Wilmes (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Wilmes closed TINKERPOP-1597.
-
Resolution: Fixed

A `PathRetractionStrategy` test has been added to verify the nested `dedup` 
does not drop labels.  The new `OptionalTest` test method provided by 
[~dkuppitz] is affected by TINKERPOP-1619 so it was not merged as part of this 
ticket.

> PathRetractionStrategy messing up certain traversals
> 
>
> Key: TINKERPOP-1597
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1597
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: Ted Wilmes
> Fix For: 3.3.0
>
>
> There are certain types of traversals that do not work when 
> {{PathRetractionStrategy}} is included. This ticket discusses one specific 
> case that is only reproducible in {{3.3.0-SNAPSHOT}} / current {{master/}}.
> Here's the traversal and the expected result:
> {noformat}
> gremlin> 
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").select("a","b").,
>  project("a").by(select("a")))
> ==>[a:v[2]]
> ==>[a:v[1],b:e[9][1-created->3]]
> ==>[a:v[1],b:e[7][1-knows->2]]
> ==>[a:v[1],b:e[8][1-knows->4]]
> {noformat}
> With {{PathRetractionStrategy}} included we get:
> {noformat}
> gremlin> 
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> ==>[a:v[2]]
> {noformat}
> What's interesting is, that the following 2 traversals compile to the same 
> final traversal (according to {{.explain()}}):
> {noformat}
> g.withoutStrategies(PathRetractionStrategy).V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b").barrier(2500),
>  select("a","b").barrier(2500), project("a").by(select("a").barrier(2500)))
> g.V(1,2).as("a").optional(bothE().dedup().as("b")).choose(select("b"), 
> select("a","b"), project("a").by(select("a")))
> {noformat}
> ...but the one w/ {{PathRetractionStrategy}} still returns the wrong result, 
> while the other traversal returns the expected result.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

2017-01-31 Thread Ted Wilmes (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847131#comment-15847131
 ] 

Ted Wilmes commented on TINKERPOP-1619:
---

Ok, that makes sense.  I was wondering if when I bumped the worker count to 4 
the duplicate edges were no longer being processed by the same worker and the 
dedup wasn't global.  Kuppitz had a variation of this query as a test case for 
TINKERPOP-1597 so I'll go ahead and close that one out now.

> TinkerGraphComputer worker count affects OptionalStep query results
> ---
>
> Key: TINKERPOP-1619
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Ted Wilmes
>
> I found that when I bump the worker count up to 4 on my local box, the dedup 
> nested in the optional appears to not be handled correctly.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> ==>v[2]
> gremlin> g.withComputer(Computer.compute().workers(4)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

2017-01-31 Thread Marko A. Rodriguez (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847125#comment-15847125
 ] 

Marko A. Rodriguez commented on TINKERPOP-1619:
---

Ah. I know why cause its a "pseudo" local child (like {{LocalStep}}). Its 
local to the worker, not to the traverser h. Anywho, yea, I know 
why its doing that, but I have no good solution off the top of my head.

> TinkerGraphComputer worker count affects OptionalStep query results
> ---
>
> Key: TINKERPOP-1619
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Ted Wilmes
>
> I found that when I bump the worker count up to 4 on my local box, the dedup 
> nested in the optional appears to not be handled correctly.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> ==>v[2]
> gremlin> g.withComputer(Computer.compute().workers(4)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

2017-01-31 Thread Marko A. Rodriguez (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847118#comment-15847118
 ] 

Marko A. Rodriguez commented on TINKERPOP-1619:
---

This makes sense. This is the problem with {{optional()}} in tp32/. It is used 
"twice" (once to check existence, and once to iterate results). Regarding 
{{master/}}, that doesn't make sense since the optional traversal of 
{{OptionalStep}} is a "local child." We'll figure out...

> TinkerGraphComputer worker count affects OptionalStep query results
> ---
>
> Key: TINKERPOP-1619
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Ted Wilmes
>
> I found that when I bump the worker count up to 4 on my local box, the dedup 
> nested in the optional appears to not be handled correctly.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> ==>v[2]
> gremlin> g.withComputer(Computer.compute().workers(4)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: gremlin-python test SimpleAuthenticator

2017-01-31 Thread David Brown 
The current tests do not include authentication or ssl. I think after
we merge the latest driver/driver test changes this should be the next
order of business. I would be happy to do a PR.

On Mon, Jan 30, 2017 at 3:19 PM, Stephen Mallette  wrote:
> If i remember correctly Marko had wanted to have the two instances
> configured with the idea that we would test gremlin-python against both. I
> think that remains a work in progress. David Brown has some changes coming
> in a PR to tp32 that make some improvements to the tests over there.
> Perhaps we can look at getting security hooked up appropriately after that
> so that we can get some tests rolling there.
>
> On Mon, Jan 30, 2017 at 3:16 PM, vtslab  wrote:
>
>>
>> While trying to get gremlin-python to work with the proposed Kerberos
>> authenticator for gremlin-server (https://github.com/apache/tin
>> kerpop/pull/534), I noticed that gremlin-python's pom.xml starts a
>> gremlin-server with SimpleAuthenticator (port 45941) but no tests seem to
>> use it, nor are the user= and password= arguments of the
>> driver_remote_connection.py ever tested. Is this still work in progress or
>> do I miss something?
>>
>> Possibly related to this, @davebshow remarks about the recenntly
>> closed/merged issue https://issues.apache.org/jira/browse/TINKERPOP-1600
>> , that all gremlin-python remote_driver_connection tests pass. Does this
>> include username/password authentication for which the netty handler coding
>> possibly changed due to TINKERPOP-1600?
>>
>> Cheers,   Marc
>>



-- 
David M. Brown
R.A. CulturePlex Lab, Western University

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

2017-01-31 Thread Ted Wilmes (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847108#comment-15847108
 ] 

Ted Wilmes commented on TINKERPOP-1619:
---

That's a good question, {{tp32}} throws this exception with that query:

{code}
gremlin> g = TinkerFactory.createModern().traversal()
gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
2).optional(bothE().dedup())
   [33/1896]
java.lang.RuntimeException: java.lang.IllegalStateException: 
java.lang.IllegalArgumentException: The provided key is not a memory compute 
key: 1.2.1(1.1.0(2.0.0()))
Type ':help' or ':h' for help.
Display stack trace? [yN]y
java.lang.IllegalStateException: java.lang.RuntimeException: 
java.lang.IllegalStateException: java.lang.IllegalArgumentException: The 
provided key is not a memory compute key: 1.2.1(1.1.0(2.0.0()))
at 
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.VertexProgramStep.processNextStart(VertexProgramStep.java:88)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.ExpandableStepIterator.next(ExpandableStepIterator.java:50)
at 
org.apache.tinkerpop.gremlin.process.computer.traversal.step.map.ComputerResultStep.processNextStart(ComputerResultStep.java:68)
at 
org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.hasNext(AbstractStep.java:143)
at 
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.hasNext(DefaultTraversal.java:184)
at 
org.apache.tinkerpop.gremlin.console.Console$_closure3.doCall(Console.groovy:237)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at 
org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1027)
at 
org.codehaus.groovy.tools.shell.Groovysh.setLastResult(Groovysh.groovy:447)
at org.codehaus.groovy.tools.shell.Groovysh.execute(Groovysh.groovy:191)
at 
org.apache.tinkerpop.gremlin.console.GremlinGroovysh.super$3$execute(GremlinGroovysh.groovy)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1218)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
at 
org.apache.tinkerpop.gremlin.console.GremlinGroovysh.execute(GremlinGroovysh.groovy:72)
at org.codehaus.groovy.tools.shell.Shell.leftShift(Shell.groovy:122)
at 
org.codehaus.groovy.tools.shell.ShellRunner.work(ShellRunner.groovy:95)
at 
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$work(InteractiveShellRunner.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1218)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:132)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:152)
at 
org.codehaus.groovy.tools.shell.InteractiveShellRunner.work(InteractiveShellRunner.groovy:124)
at 
org.codehaus.groovy.tools.shell.ShellRunner.run(ShellRunner.groovy:59)
at 
org.codehaus.groovy.tools.shell.InteractiveShellRunner.super$2$run(InteractiveShellRunner.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

2017-01-31 Thread Marko A. Rodriguez (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15847101#comment-15847101
 ] 

Marko A. Rodriguez commented on TINKERPOP-1619:
---

And {{tp32/}} branch, it works? I ask this cause we introduced a new 
{{OptionalStep}} in {{master/}} (3.3.0).

> TinkerGraphComputer worker count affects OptionalStep query results
> ---
>
> Key: TINKERPOP-1619
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Ted Wilmes
>
> I found that when I bump the worker count up to 4 on my local box, the dedup 
> nested in the optional appears to not be handled correctly.
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> ==>v[2]
> gremlin> g.withComputer(Computer.compute().workers(4)).V(1, 
> 2).optional(bothE().dedup())
> ==>e[9][1-created->3]
> ==>e[7][1-knows->2]
> ==>e[7][1-knows->2]
> ==>e[8][1-knows->4]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (TINKERPOP-1619) TinkerGraphComputer worker count affects OptionalStep query results

2017-01-31 Thread Ted Wilmes (JIRA) 
Ted Wilmes created TINKERPOP-1619:
-

 Summary: TinkerGraphComputer worker count affects OptionalStep 
query results
 Key: TINKERPOP-1619
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1619
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.3.0
Reporter: Ted Wilmes


I found that when I bump the worker count up to 4 on my local box, the dedup 
nested in the optional appears to not be handled correctly.

{code}
gremlin> g = TinkerFactory.createModern().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.withComputer(Computer.compute().workers(3)).V(1, 
2).optional(bothE().dedup())
==>e[9][1-created->3]
==>e[7][1-knows->2]
==>e[8][1-knows->4]
==>v[2]
gremlin> g.withComputer(Computer.compute().workers(4)).V(1, 
2).optional(bothE().dedup())
==>e[9][1-created->3]
==>e[7][1-knows->2]
==>e[7][1-knows->2]
==>e[8][1-knows->4]
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)