[jira] [Created] (TINKERPOP-1769) Python graph[empty] string representation is confusing

[Jason Plurad (JIRA)]

Jason Plurad created TINKERPOP-1769:
---

 Summary: Python graph[empty] string representation is confusing
 Key: TINKERPOP-1769
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1769
 Project: TinkerPop
  Issue Type: Bug
  Components: language-variant
Affects Versions: 3.2.6
Reporter: Jason Plurad
Priority: Minor


>From this [StackOverflow 
>post|https://stackoverflow.com/questions/46070265/gremlin-python-returning-empty-graph/46082468#46082468],
> the string representation of the [Python 
>Graph|https://github.com/apache/tinkerpop/blob/3.2.6/gremlin-python/src/main/jython/gremlin_python/structure/graph.py#L37]
> object is:

{noformat}graph[empty]{noformat}

This is likely trying to be similar to {{EmptyGraph}} in Java, but this can be 
misleading for new users, especially if they had been using TinkerGraph which 
shows how many vertices and edges are in the graph. Something like one of these 
could be less confusing:

{noformat}
graph[remote]
graph[]
{noformat}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1766) Gremlin.Net: Closed connections should not be re-used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1766:
---

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/704
  
I just pushed a commit that addresses your comments, @jorgebay.


> Gremlin.Net: Closed connections should not be re-used 
> --
>
> Key: TINKERPOP-1766
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1766
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>
> The driver of Gremlin.Net is kept very simle which holds especially true for 
> the {{ConnectionPool}}. It simply returns every connection to its pool of 
> usable connections that was {{disposed}} by the client. Unfortunately, this 
> also applies in case the submit failed due to an already closed connection 
> which means that the client will get the closed connection back from the 
> {{ConnectionPool}} later and continues trying to submit messages over this 
> closed connection.
> This can be fixed by checking whether the {{Connection}} is still open before 
> adding it back to the {{ConnectionPool}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: io and graphson-v3

[Stephen Mallette]

pieter, i updated that branch and issued this PR (and i'm running the full
test suite now):

https://github.com/apache/tinkerpop/pull/706

please review/VOTE if i got it right - let's finish off any final
discussion/tweaks on the PR itself. thanks for noting this problem.

> This v3 looks like a <3 heart where the top broke off.

hehe



On Wed, Sep 6, 2017 at 1:56 PM, Paul A. Jackson  wrote:

> This v3 looks like a <3 heart where the top broke off.
>
> Sad.
>
>
> -Original Message-
> From: Stephen Mallette [mailto:spmalle...@gmail.com]
> Sent: Wednesday, September 06, 2017 1:45 PM
> To: dev@tinkerpop.apache.org
> Subject: Re: io and graphson-v3
>
> never mind - i see what's messed up
>
> On Wed, Sep 6, 2017 at 1:43 PM, Stephen Mallette 
> wrote:
>
> > Which tests in particular are failing for SerializationTest? all of them?
> >
> > On Wed, Sep 6, 2017 at 1:35 PM, pieter gmail 
> > wrote:
> >
> >> Hi,
> >>
> >> Pulled TINKERPOP-1767 branch, changed SqlgGraph's io method and ran
> >> the tests.
> >>
> >> All the io tests are passing.
> >> Only SerializationTest fails for the same reason. It too needs the
> >> version specified. I did that locally and then all tests passes.
> >>
> >> Thanks
> >> Pieter
> >>
> >> On 06/09/2017 18:09, Stephen Mallette wrote:
> >>
> >>> Pieter, I created this issue:
> >>>
> >>> https://issues.apache.org/jira/browse/TINKERPOP-1767
> >>>
> >>> and made an effort to try to figure a way to fix it:
> >>>
> >>> https://github.com/apache/tinkerpop/tree/TINKERPOP-1767
> >>>
> >>> Note the change to TinkerGraph and its io() method. I suppose you
> >>> could do something similar to get the right registry in play? could
> >>> you have a look and see if what i did helps? if that works then i'll
> >>> issue a PR and we can get it reviewed/merged.
> >>>
> >>>
> >>> On Tue, Sep 5, 2017 at 12:10 PM, pieter gmail
> >>> 
> >>> wrote:
> >>>
> >>> Ok, at present there is only one SimpleModule, the default. I can
> >>> make it
>  v2 or v3 but not both.
> 
>  Lets say I make the SimpleModule support V2.
>  Then when calling IoEdgeTest for
> 
>   {"graphson-v3", true, true,
>   (Function) g -> g.io
>  (IoCore.graphson()).reader
>  ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
>  mapper().create()).create(),
>   (Function) g -> g.io
>  (IoCore.graphson()).writer
>  ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
>  mapper().create()).create()},
> 
>  then the deserializers that run are for V2,
> 
>   static class SchemaTableIdJacksonDeserializerV2d0 extends
>  AbstractObjectDeserializer {
>   SchemaTableIdJacksonDeserializerV2d0() {
>   super(SchemaTable.class);
>   }
> 
>   @Override
>   public SchemaTable createObject(final Map data) {
>   return SchemaTable.of((String)data.get("schema"),
>  (String) data.get("table"));
>   }
>   }
> 
>  when createObject fires the map data has V3 elements in it like
>  @type and @value whilst its expecting "schema" and "table"
> 
>  If we make the SimpleModule support V3 then graphson-v2 will fail.
> 
>  {"graphson-v2", false, false,
>  (Function) g -> g.io
>  (IoCore.graphson()).reader
>  ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
>  mapper().typeInfo(TypeInfo.NO_TYPES).create()).create(),
>  (Function) g -> g.io
>  (IoCore.graphson()).writer
>  ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
> 
>  mapper().typeInfo(TypeInfo.NO_TYPES).create()).create()},
> 
>  Now the deserializers are for V3.
> 
>   static class SchemaTableJacksonDeserializerV3d0 extends
>  StdDeserializer {
>   public SchemaTableJacksonDeserializerV3d0() {
>   super(RecordId.class);
>   }
> 
>   @Override
>   public SchemaTable deserialize(final JsonParser
>  jsonParser, final DeserializationContext deserializationContext)
>  throws IOException, JsonProcessingException {
>   final Map data =
>  deserializationContext.readValue(jsonParser,
>  Map.class);
>   return SchemaTable.of((String)data.get("schema"),
>  (String) data.get("table"));
>   }
> 
>   @Override
>   public boolean isCachable() {
>   return true;
>   }
>   }
> 
>  This does not fire at all. Eventually I get a detached edge with an
>  id that is a map. It never deserialized.
> 
>  So basically it only works if the SimpleModule version, i.e.
>  serialize/deserialize code 

[jira] [Commented] (TINKERPOP-1767) Method for graph providers to check an IO version and type

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1767:
---

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/706

TINKERPOP-1767 Added Io.requiresVersion(Object)

https://issues.apache.org/jira/browse/TINKERPOP-1767

Allows the graph provider to determine type and version of the Io being 
constructed so that they can properly choose the right IoRegistry to assign. 
Also set the defaults for GraphSON and Gryo to 3.0 when doing `graph.io()` 
(should have been done for 3.3.0 unfortunately).

running full test suite now - will update this PR when complete with my vote

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1767

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/706.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #706


commit 0d266da3e5c274afa9306367263e5c9098bedd93
Author: Stephen Mallette 
Date:   2017-09-06T16:02:53Z

TINKERPOP-1767 Added Io.requiresVersion(Object)

Allows the graph provider to determine type and version of the Io being 
constructed so that they can properly choose the right IoRegistry to assign.




> Method for graph providers to check an IO version and type
> --
>
> Key: TINKERPOP-1767
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1767
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.3.1
>
>
> The basic problem is described here:
> https://lists.apache.org/thread.html/5d46643614c5306d38bfbec11cee3aa7653f440d276e7cbe189e@%3Cdev.tinkerpop.apache.org%3E
> but in summary, the graph provider needs a way to check the type of io and 
> version so that they have the opportunity to assign the correct instance of 
> their {{IoRegistry}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #706: TINKERPOP-1767 Added Io.requiresVersion(Object)

[spmallette]

GitHub user spmallette opened a pull request:

https://github.com/apache/tinkerpop/pull/706

TINKERPOP-1767 Added Io.requiresVersion(Object)

https://issues.apache.org/jira/browse/TINKERPOP-1767

Allows the graph provider to determine type and version of the Io being 
constructed so that they can properly choose the right IoRegistry to assign. 
Also set the defaults for GraphSON and Gryo to 3.0 when doing `graph.io()` 
(should have been done for 3.3.0 unfortunately).

running full test suite now - will update this PR when complete with my vote

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1767

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/706.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #706


commit 0d266da3e5c274afa9306367263e5c9098bedd93
Author: Stephen Mallette 
Date:   2017-09-06T16:02:53Z

TINKERPOP-1767 Added Io.requiresVersion(Object)

Allows the graph provider to determine type and version of the Io being 
constructed so that they can properly choose the right IoRegistry to assign.




---

[jira] [Created] (TINKERPOP-1768) Bump to Jackson 2.8.10

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1768:
---

 Summary: Bump to Jackson 2.8.10
 Key: TINKERPOP-1768
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1768
 Project: TinkerPop
  Issue Type: Improvement
  Components: io
Affects Versions: 3.2.6
Reporter: stephen mallette
Assignee: stephen mallette


Jackson 2.8.10 has some important bug fixes - hoping for a fix for 
TINKERPOP-1509



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

RE: io and graphson-v3

[Paul A. Jackson]

This v3 looks like a <3 heart where the top broke off.

Sad.


-Original Message-
From: Stephen Mallette [mailto:spmalle...@gmail.com] 
Sent: Wednesday, September 06, 2017 1:45 PM
To: dev@tinkerpop.apache.org
Subject: Re: io and graphson-v3

never mind - i see what's messed up

On Wed, Sep 6, 2017 at 1:43 PM, Stephen Mallette 
wrote:

> Which tests in particular are failing for SerializationTest? all of them?
>
> On Wed, Sep 6, 2017 at 1:35 PM, pieter gmail 
> wrote:
>
>> Hi,
>>
>> Pulled TINKERPOP-1767 branch, changed SqlgGraph's io method and ran 
>> the tests.
>>
>> All the io tests are passing.
>> Only SerializationTest fails for the same reason. It too needs the 
>> version specified. I did that locally and then all tests passes.
>>
>> Thanks
>> Pieter
>>
>> On 06/09/2017 18:09, Stephen Mallette wrote:
>>
>>> Pieter, I created this issue:
>>>
>>> https://issues.apache.org/jira/browse/TINKERPOP-1767
>>>
>>> and made an effort to try to figure a way to fix it:
>>>
>>> https://github.com/apache/tinkerpop/tree/TINKERPOP-1767
>>>
>>> Note the change to TinkerGraph and its io() method. I suppose you 
>>> could do something similar to get the right registry in play? could 
>>> you have a look and see if what i did helps? if that works then i'll 
>>> issue a PR and we can get it reviewed/merged.
>>>
>>>
>>> On Tue, Sep 5, 2017 at 12:10 PM, pieter gmail 
>>> 
>>> wrote:
>>>
>>> Ok, at present there is only one SimpleModule, the default. I can 
>>> make it
 v2 or v3 but not both.

 Lets say I make the SimpleModule support V2.
 Then when calling IoEdgeTest for

  {"graphson-v3", true, true,
  (Function) g -> g.io 
 (IoCore.graphson()).reader 
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
 mapper().create()).create(),
  (Function) g -> g.io 
 (IoCore.graphson()).writer 
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
 mapper().create()).create()},

 then the deserializers that run are for V2,

  static class SchemaTableIdJacksonDeserializerV2d0 extends 
 AbstractObjectDeserializer {
  SchemaTableIdJacksonDeserializerV2d0() {
  super(SchemaTable.class);
  }

  @Override
  public SchemaTable createObject(final Map data) {
  return SchemaTable.of((String)data.get("schema"), 
 (String) data.get("table"));
  }
  }

 when createObject fires the map data has V3 elements in it like 
 @type and @value whilst its expecting "schema" and "table"

 If we make the SimpleModule support V3 then graphson-v2 will fail.

 {"graphson-v2", false, false,
 (Function) g -> g.io 
 (IoCore.graphson()).reader 
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
 mapper().typeInfo(TypeInfo.NO_TYPES).create()).create(),
 (Function) g -> g.io 
 (IoCore.graphson()).writer 
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).

 mapper().typeInfo(TypeInfo.NO_TYPES).create()).create()},

 Now the deserializers are for V3.

  static class SchemaTableJacksonDeserializerV3d0 extends 
 StdDeserializer {
  public SchemaTableJacksonDeserializerV3d0() {
  super(RecordId.class);
  }

  @Override
  public SchemaTable deserialize(final JsonParser 
 jsonParser, final DeserializationContext deserializationContext) 
 throws IOException, JsonProcessingException {
  final Map data = 
 deserializationContext.readValue(jsonParser,
 Map.class);
  return SchemaTable.of((String)data.get("schema"), 
 (String) data.get("table"));
  }

  @Override
  public boolean isCachable() {
  return true;
  }
  }

 This does not fire at all. Eventually I get a detached edge with an 
 id that is a map. It never deserialized.

 So basically it only works if the SimpleModule version, i.e.
 serialize/deserialize code matches up with the version.

 Sqlg serializes RecordId to,

  static class RecordIdJacksonSerializerV3d0 extends 
 StdScalarSerializer {
  public RecordIdJacksonSerializerV3d0() {
  super(RecordId.class);
  }
  @Override
  public void serialize(final RecordId recordId, final 
 JsonGenerator jsonGenerator, final SerializerProvider 
 serializerProvider)
  throws IOException, JsonGenerationException {
  final Map m = new HashMap<>();
  m.put("schemaTable", recordId.getSchemaTable());

Re: io and graphson-v3

[Stephen Mallette]

never mind - i see what's messed up

On Wed, Sep 6, 2017 at 1:43 PM, Stephen Mallette 
wrote:

> Which tests in particular are failing for SerializationTest? all of them?
>
> On Wed, Sep 6, 2017 at 1:35 PM, pieter gmail 
> wrote:
>
>> Hi,
>>
>> Pulled TINKERPOP-1767 branch, changed SqlgGraph's io method and ran the
>> tests.
>>
>> All the io tests are passing.
>> Only SerializationTest fails for the same reason. It too needs the
>> version specified. I did that locally and then all tests passes.
>>
>> Thanks
>> Pieter
>>
>> On 06/09/2017 18:09, Stephen Mallette wrote:
>>
>>> Pieter, I created this issue:
>>>
>>> https://issues.apache.org/jira/browse/TINKERPOP-1767
>>>
>>> and made an effort to try to figure a way to fix it:
>>>
>>> https://github.com/apache/tinkerpop/tree/TINKERPOP-1767
>>>
>>> Note the change to TinkerGraph and its io() method. I suppose you could
>>> do
>>> something similar to get the right registry in play? could you have a
>>> look
>>> and see if what i did helps? if that works then i'll issue a PR and we
>>> can
>>> get it reviewed/merged.
>>>
>>>
>>> On Tue, Sep 5, 2017 at 12:10 PM, pieter gmail 
>>> wrote:
>>>
>>> Ok, at present there is only one SimpleModule, the default. I can make it
 v2 or v3 but not both.

 Lets say I make the SimpleModule support V2.
 Then when calling IoEdgeTest for

  {"graphson-v3", true, true,
  (Function) g -> g.io
 (IoCore.graphson()).reader
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
 mapper().create()).create(),
  (Function) g -> g.io
 (IoCore.graphson()).writer
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
 mapper().create()).create()},

 then the deserializers that run are for V2,

  static class SchemaTableIdJacksonDeserializerV2d0 extends
 AbstractObjectDeserializer {
  SchemaTableIdJacksonDeserializerV2d0() {
  super(SchemaTable.class);
  }

  @Override
  public SchemaTable createObject(final Map data) {
  return SchemaTable.of((String)data.get("schema"), (String)
 data.get("table"));
  }
  }

 when createObject fires the map data has V3 elements in it like @type
 and
 @value whilst its expecting "schema" and "table"

 If we make the SimpleModule support V3 then graphson-v2 will fail.

 {"graphson-v2", false, false,
 (Function) g -> g.io
 (IoCore.graphson()).reader
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
 mapper().typeInfo(TypeInfo.NO_TYPES).create()).create(),
 (Function) g -> g.io
 (IoCore.graphson()).writer
 ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).

 mapper().typeInfo(TypeInfo.NO_TYPES).create()).create()},

 Now the deserializers are for V3.

  static class SchemaTableJacksonDeserializerV3d0 extends
 StdDeserializer {
  public SchemaTableJacksonDeserializerV3d0() {
  super(RecordId.class);
  }

  @Override
  public SchemaTable deserialize(final JsonParser jsonParser,
 final
 DeserializationContext deserializationContext) throws IOException,
 JsonProcessingException {
  final Map data =
 deserializationContext.readValue(jsonParser,
 Map.class);
  return SchemaTable.of((String)data.get("schema"), (String)
 data.get("table"));
  }

  @Override
  public boolean isCachable() {
  return true;
  }
  }

 This does not fire at all. Eventually I get a detached edge with an id
 that is a map. It never deserialized.

 So basically it only works if the SimpleModule version, i.e.
 serialize/deserialize code matches up with the version.

 Sqlg serializes RecordId to,

  static class RecordIdJacksonSerializerV3d0 extends
 StdScalarSerializer {
  public RecordIdJacksonSerializerV3d0() {
  super(RecordId.class);
  }
  @Override
  public void serialize(final RecordId recordId, final
 JsonGenerator
 jsonGenerator, final SerializerProvider serializerProvider)
  throws IOException, JsonGenerationException {
  final Map m = new HashMap<>();
  m.put("schemaTable", recordId.getSchemaTable());
  m.put("id", recordId.getId());
  jsonGenerator.writeObject(m);
  }
  }

 and

  static class SchemaTableJacksonSerializerV3d0 extends
 StdScalarSerializer {
  

Re: io and graphson-v3

[Stephen Mallette]

Which tests in particular are failing for SerializationTest? all of them?

On Wed, Sep 6, 2017 at 1:35 PM, pieter gmail 
wrote:

> Hi,
>
> Pulled TINKERPOP-1767 branch, changed SqlgGraph's io method and ran the
> tests.
>
> All the io tests are passing.
> Only SerializationTest fails for the same reason. It too needs the version
> specified. I did that locally and then all tests passes.
>
> Thanks
> Pieter
>
> On 06/09/2017 18:09, Stephen Mallette wrote:
>
>> Pieter, I created this issue:
>>
>> https://issues.apache.org/jira/browse/TINKERPOP-1767
>>
>> and made an effort to try to figure a way to fix it:
>>
>> https://github.com/apache/tinkerpop/tree/TINKERPOP-1767
>>
>> Note the change to TinkerGraph and its io() method. I suppose you could do
>> something similar to get the right registry in play? could you have a look
>> and see if what i did helps? if that works then i'll issue a PR and we can
>> get it reviewed/merged.
>>
>>
>> On Tue, Sep 5, 2017 at 12:10 PM, pieter gmail 
>> wrote:
>>
>> Ok, at present there is only one SimpleModule, the default. I can make it
>>> v2 or v3 but not both.
>>>
>>> Lets say I make the SimpleModule support V2.
>>> Then when calling IoEdgeTest for
>>>
>>>  {"graphson-v3", true, true,
>>>  (Function) g -> g.io
>>> (IoCore.graphson()).reader
>>> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
>>> mapper().create()).create(),
>>>  (Function) g -> g.io
>>> (IoCore.graphson()).writer
>>> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
>>> mapper().create()).create()},
>>>
>>> then the deserializers that run are for V2,
>>>
>>>  static class SchemaTableIdJacksonDeserializerV2d0 extends
>>> AbstractObjectDeserializer {
>>>  SchemaTableIdJacksonDeserializerV2d0() {
>>>  super(SchemaTable.class);
>>>  }
>>>
>>>  @Override
>>>  public SchemaTable createObject(final Map data) {
>>>  return SchemaTable.of((String)data.get("schema"), (String)
>>> data.get("table"));
>>>  }
>>>  }
>>>
>>> when createObject fires the map data has V3 elements in it like @type and
>>> @value whilst its expecting "schema" and "table"
>>>
>>> If we make the SimpleModule support V3 then graphson-v2 will fail.
>>>
>>> {"graphson-v2", false, false,
>>> (Function) g -> g.io
>>> (IoCore.graphson()).reader
>>> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
>>> mapper().typeInfo(TypeInfo.NO_TYPES).create()).create(),
>>> (Function) g -> g.io
>>> (IoCore.graphson()).writer
>>> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
>>>
>>> mapper().typeInfo(TypeInfo.NO_TYPES).create()).create()},
>>>
>>> Now the deserializers are for V3.
>>>
>>>  static class SchemaTableJacksonDeserializerV3d0 extends
>>> StdDeserializer {
>>>  public SchemaTableJacksonDeserializerV3d0() {
>>>  super(RecordId.class);
>>>  }
>>>
>>>  @Override
>>>  public SchemaTable deserialize(final JsonParser jsonParser,
>>> final
>>> DeserializationContext deserializationContext) throws IOException,
>>> JsonProcessingException {
>>>  final Map data =
>>> deserializationContext.readValue(jsonParser,
>>> Map.class);
>>>  return SchemaTable.of((String)data.get("schema"), (String)
>>> data.get("table"));
>>>  }
>>>
>>>  @Override
>>>  public boolean isCachable() {
>>>  return true;
>>>  }
>>>  }
>>>
>>> This does not fire at all. Eventually I get a detached edge with an id
>>> that is a map. It never deserialized.
>>>
>>> So basically it only works if the SimpleModule version, i.e.
>>> serialize/deserialize code matches up with the version.
>>>
>>> Sqlg serializes RecordId to,
>>>
>>>  static class RecordIdJacksonSerializerV3d0 extends
>>> StdScalarSerializer {
>>>  public RecordIdJacksonSerializerV3d0() {
>>>  super(RecordId.class);
>>>  }
>>>  @Override
>>>  public void serialize(final RecordId recordId, final
>>> JsonGenerator
>>> jsonGenerator, final SerializerProvider serializerProvider)
>>>  throws IOException, JsonGenerationException {
>>>  final Map m = new HashMap<>();
>>>  m.put("schemaTable", recordId.getSchemaTable());
>>>  m.put("id", recordId.getId());
>>>  jsonGenerator.writeObject(m);
>>>  }
>>>  }
>>>
>>> and
>>>
>>>  static class SchemaTableJacksonSerializerV3d0 extends
>>> StdScalarSerializer {
>>>  SchemaTableJacksonSerializerV3d0() {
>>>  super(SchemaTable.class);
>>>  }
>>>
>>>  @Override
>>>  public void serialize(final SchemaTable schemaTable, final
>>> JsonGenerator jsonGenerator, final SerializerProvider serializerProvider)
>>> 

Re: io and graphson-v3

[pieter gmail]

Hi,

Pulled TINKERPOP-1767 branch, changed SqlgGraph's io method and ran the 
tests.


All the io tests are passing.
Only SerializationTest fails for the same reason. It too needs the 
version specified. I did that locally and then all tests passes.


Thanks
Pieter

On 06/09/2017 18:09, Stephen Mallette wrote:

Pieter, I created this issue:

https://issues.apache.org/jira/browse/TINKERPOP-1767

and made an effort to try to figure a way to fix it:

https://github.com/apache/tinkerpop/tree/TINKERPOP-1767

Note the change to TinkerGraph and its io() method. I suppose you could do
something similar to get the right registry in play? could you have a look
and see if what i did helps? if that works then i'll issue a PR and we can
get it reviewed/merged.


On Tue, Sep 5, 2017 at 12:10 PM, pieter gmail 
wrote:


Ok, at present there is only one SimpleModule, the default. I can make it
v2 or v3 but not both.

Lets say I make the SimpleModule support V2.
Then when calling IoEdgeTest for

 {"graphson-v3", true, true,
 (Function) g -> g.io(IoCore.graphson()).reader
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
mapper().create()).create(),
 (Function) g -> g.io(IoCore.graphson()).writer
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
mapper().create()).create()},

then the deserializers that run are for V2,

 static class SchemaTableIdJacksonDeserializerV2d0 extends
AbstractObjectDeserializer {
 SchemaTableIdJacksonDeserializerV2d0() {
 super(SchemaTable.class);
 }

 @Override
 public SchemaTable createObject(final Map data) {
 return SchemaTable.of((String)data.get("schema"), (String)
data.get("table"));
 }
 }

when createObject fires the map data has V3 elements in it like @type and
@value whilst its expecting "schema" and "table"

If we make the SimpleModule support V3 then graphson-v2 will fail.

{"graphson-v2", false, false,
(Function) g -> g.io(IoCore.graphson()).reader
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
mapper().typeInfo(TypeInfo.NO_TYPES).create()).create(),
(Function) g -> g.io(IoCore.graphson()).writer
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
mapper().typeInfo(TypeInfo.NO_TYPES).create()).create()},

Now the deserializers are for V3.

 static class SchemaTableJacksonDeserializerV3d0 extends
StdDeserializer {
 public SchemaTableJacksonDeserializerV3d0() {
 super(RecordId.class);
 }

 @Override
 public SchemaTable deserialize(final JsonParser jsonParser, final
DeserializationContext deserializationContext) throws IOException,
JsonProcessingException {
 final Map data = 
deserializationContext.readValue(jsonParser,
Map.class);
 return SchemaTable.of((String)data.get("schema"), (String)
data.get("table"));
 }

 @Override
 public boolean isCachable() {
 return true;
 }
 }

This does not fire at all. Eventually I get a detached edge with an id
that is a map. It never deserialized.

So basically it only works if the SimpleModule version, i.e.
serialize/deserialize code matches up with the version.

Sqlg serializes RecordId to,

 static class RecordIdJacksonSerializerV3d0 extends
StdScalarSerializer {
 public RecordIdJacksonSerializerV3d0() {
 super(RecordId.class);
 }
 @Override
 public void serialize(final RecordId recordId, final JsonGenerator
jsonGenerator, final SerializerProvider serializerProvider)
 throws IOException, JsonGenerationException {
 final Map m = new HashMap<>();
 m.put("schemaTable", recordId.getSchemaTable());
 m.put("id", recordId.getId());
 jsonGenerator.writeObject(m);
 }
 }

and

 static class SchemaTableJacksonSerializerV3d0 extends
StdScalarSerializer {
 SchemaTableJacksonSerializerV3d0() {
 super(SchemaTable.class);
 }

 @Override
 public void serialize(final SchemaTable schemaTable, final
JsonGenerator jsonGenerator, final SerializerProvider serializerProvider)
 throws IOException, JsonGenerationException {
 // when types are not embedded, stringify or resort to JSON
primitive representations of the
 // type so that non-jvm languages can better interoperate with
the TinkerPop stack.
 final Map m = new LinkedHashMap<>();
 m.put("schema", schemaTable.getSchema());
 m.put("table", schemaTable.getTable());
 jsonGenerator.writeObject(m);
 }

 }

Hope it all makes some sense,
Pieter


On 05/09/2017 17:31, Stephen Mallette wrote:


I guess I'm trying to understand why it matters for purpose of 

[GitHub] tinkerpop issue #705: make TinkerGraph cloneable

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/705
  
You could deep clone (brand new vertices/edges/properties) of tinkergraph 
by using detachment. Do something like this:

```text
gremlin> graph1 = TinkerFactory.createModern()
==>tinkergraph[vertices:6 edges:6]
gremlin> graph2 = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph1.vertices().forEachRemaining { v -> 
DetachedFactory.detach(v, true).attach(Attachable.Method.create(graph2)) }
gremlin> graph2
==>tinkergraph[vertices:6 edges:0]
gremlin> graph1.edges().forEachRemaining { e -> DetachedFactory.detach(e, 
true).attach(Attachable.Method.create(graph2)) }
gremlin> graph2
==>tinkergraph[vertices:6 edges:6]
```

I think that gets it, right?



---

Re: io and graphson-v3

[pieter gmail]

Thanks, I'll have a look.
For now on 3.3.0 I'll OptOut of some io tests. I'll let you know the 
OptOut list.


Thanks
Pieter

On 06/09/2017 18:09, Stephen Mallette wrote:

Pieter, I created this issue:

https://issues.apache.org/jira/browse/TINKERPOP-1767

and made an effort to try to figure a way to fix it:

https://github.com/apache/tinkerpop/tree/TINKERPOP-1767

Note the change to TinkerGraph and its io() method. I suppose you could do
something similar to get the right registry in play? could you have a look
and see if what i did helps? if that works then i'll issue a PR and we can
get it reviewed/merged.


On Tue, Sep 5, 2017 at 12:10 PM, pieter gmail 
wrote:


Ok, at present there is only one SimpleModule, the default. I can make it
v2 or v3 but not both.

Lets say I make the SimpleModule support V2.
Then when calling IoEdgeTest for

 {"graphson-v3", true, true,
 (Function) g -> g.io(IoCore.graphson()).reader
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
mapper().create()).create(),
 (Function) g -> g.io(IoCore.graphson()).writer
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
mapper().create()).create()},

then the deserializers that run are for V2,

 static class SchemaTableIdJacksonDeserializerV2d0 extends
AbstractObjectDeserializer {
 SchemaTableIdJacksonDeserializerV2d0() {
 super(SchemaTable.class);
 }

 @Override
 public SchemaTable createObject(final Map data) {
 return SchemaTable.of((String)data.get("schema"), (String)
data.get("table"));
 }
 }

when createObject fires the map data has V3 elements in it like @type and
@value whilst its expecting "schema" and "table"

If we make the SimpleModule support V3 then graphson-v2 will fail.

{"graphson-v2", false, false,
(Function) g -> g.io(IoCore.graphson()).reader
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
mapper().typeInfo(TypeInfo.NO_TYPES).create()).create(),
(Function) g -> g.io(IoCore.graphson()).writer
().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
mapper().typeInfo(TypeInfo.NO_TYPES).create()).create()},

Now the deserializers are for V3.

 static class SchemaTableJacksonDeserializerV3d0 extends
StdDeserializer {
 public SchemaTableJacksonDeserializerV3d0() {
 super(RecordId.class);
 }

 @Override
 public SchemaTable deserialize(final JsonParser jsonParser, final
DeserializationContext deserializationContext) throws IOException,
JsonProcessingException {
 final Map data = 
deserializationContext.readValue(jsonParser,
Map.class);
 return SchemaTable.of((String)data.get("schema"), (String)
data.get("table"));
 }

 @Override
 public boolean isCachable() {
 return true;
 }
 }

This does not fire at all. Eventually I get a detached edge with an id
that is a map. It never deserialized.

So basically it only works if the SimpleModule version, i.e.
serialize/deserialize code matches up with the version.

Sqlg serializes RecordId to,

 static class RecordIdJacksonSerializerV3d0 extends
StdScalarSerializer {
 public RecordIdJacksonSerializerV3d0() {
 super(RecordId.class);
 }
 @Override
 public void serialize(final RecordId recordId, final JsonGenerator
jsonGenerator, final SerializerProvider serializerProvider)
 throws IOException, JsonGenerationException {
 final Map m = new HashMap<>();
 m.put("schemaTable", recordId.getSchemaTable());
 m.put("id", recordId.getId());
 jsonGenerator.writeObject(m);
 }
 }

and

 static class SchemaTableJacksonSerializerV3d0 extends
StdScalarSerializer {
 SchemaTableJacksonSerializerV3d0() {
 super(SchemaTable.class);
 }

 @Override
 public void serialize(final SchemaTable schemaTable, final
JsonGenerator jsonGenerator, final SerializerProvider serializerProvider)
 throws IOException, JsonGenerationException {
 // when types are not embedded, stringify or resort to JSON
primitive representations of the
 // type so that non-jvm languages can better interoperate with
the TinkerPop stack.
 final Map m = new LinkedHashMap<>();
 m.put("schema", schemaTable.getSchema());
 m.put("table", schemaTable.getTable());
 jsonGenerator.writeObject(m);
 }

 }

Hope it all makes some sense,
Pieter


On 05/09/2017 17:31, Stephen Mallette wrote:


I guess I'm trying to understand why it matters for purpose of the test.
If
you mix/match versions I can't think of why the test would care one way or
the other. does sqlg serialize its id to a JSON Map?

[jira] [Commented] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1287:
-

[~twilmes] is there anything to do on this one. doesn't seem like streams were 
hurting anything and i think dan submitted a PR a while back to make 
{{intern()}} configurable (maybe it should have just been removed). anyway, 
anything else to do here?

> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from 
> TinkerGraph made it much faster. It would be good if we did the same thing 
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: io and graphson-v3

[Stephen Mallette]

Pieter, I created this issue:

https://issues.apache.org/jira/browse/TINKERPOP-1767

and made an effort to try to figure a way to fix it:

https://github.com/apache/tinkerpop/tree/TINKERPOP-1767

Note the change to TinkerGraph and its io() method. I suppose you could do
something similar to get the right registry in play? could you have a look
and see if what i did helps? if that works then i'll issue a PR and we can
get it reviewed/merged.


On Tue, Sep 5, 2017 at 12:10 PM, pieter gmail 
wrote:

> Ok, at present there is only one SimpleModule, the default. I can make it
> v2 or v3 but not both.
>
> Lets say I make the SimpleModule support V2.
> Then when calling IoEdgeTest for
>
> {"graphson-v3", true, true,
> (Function) g -> g.io(IoCore.graphson()).reader
> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
> mapper().create()).create(),
> (Function) g -> g.io(IoCore.graphson()).writer
> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V3_0)).
> mapper().create()).create()},
>
> then the deserializers that run are for V2,
>
> static class SchemaTableIdJacksonDeserializerV2d0 extends
> AbstractObjectDeserializer {
> SchemaTableIdJacksonDeserializerV2d0() {
> super(SchemaTable.class);
> }
>
> @Override
> public SchemaTable createObject(final Map data) {
> return SchemaTable.of((String)data.get("schema"), (String)
> data.get("table"));
> }
> }
>
> when createObject fires the map data has V3 elements in it like @type and
> @value whilst its expecting "schema" and "table"
>
> If we make the SimpleModule support V3 then graphson-v2 will fail.
>
>{"graphson-v2", false, false,
>(Function) g -> g.io(IoCore.graphson()).reader
> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
> mapper().typeInfo(TypeInfo.NO_TYPES).create()).create(),
>(Function) g -> g.io(IoCore.graphson()).writer
> ().mapper(g.io(GraphSONIo.build(GraphSONVersion.V2_0)).
> mapper().typeInfo(TypeInfo.NO_TYPES).create()).create()},
>
> Now the deserializers are for V3.
>
> static class SchemaTableJacksonDeserializerV3d0 extends
> StdDeserializer {
> public SchemaTableJacksonDeserializerV3d0() {
> super(RecordId.class);
> }
>
> @Override
> public SchemaTable deserialize(final JsonParser jsonParser, final
> DeserializationContext deserializationContext) throws IOException,
> JsonProcessingException {
> final Map data = 
> deserializationContext.readValue(jsonParser,
> Map.class);
> return SchemaTable.of((String)data.get("schema"), (String)
> data.get("table"));
> }
>
> @Override
> public boolean isCachable() {
> return true;
> }
> }
>
> This does not fire at all. Eventually I get a detached edge with an id
> that is a map. It never deserialized.
>
> So basically it only works if the SimpleModule version, i.e.
> serialize/deserialize code matches up with the version.
>
> Sqlg serializes RecordId to,
>
> static class RecordIdJacksonSerializerV3d0 extends
> StdScalarSerializer {
> public RecordIdJacksonSerializerV3d0() {
> super(RecordId.class);
> }
> @Override
> public void serialize(final RecordId recordId, final JsonGenerator
> jsonGenerator, final SerializerProvider serializerProvider)
> throws IOException, JsonGenerationException {
> final Map m = new HashMap<>();
> m.put("schemaTable", recordId.getSchemaTable());
> m.put("id", recordId.getId());
> jsonGenerator.writeObject(m);
> }
> }
>
> and
>
> static class SchemaTableJacksonSerializerV3d0 extends
> StdScalarSerializer {
> SchemaTableJacksonSerializerV3d0() {
> super(SchemaTable.class);
> }
>
> @Override
> public void serialize(final SchemaTable schemaTable, final
> JsonGenerator jsonGenerator, final SerializerProvider serializerProvider)
> throws IOException, JsonGenerationException {
> // when types are not embedded, stringify or resort to JSON
> primitive representations of the
> // type so that non-jvm languages can better interoperate with
> the TinkerPop stack.
> final Map m = new LinkedHashMap<>();
> m.put("schema", schemaTable.getSchema());
> m.put("table", schemaTable.getTable());
> jsonGenerator.writeObject(m);
> }
>
> }
>
> Hope it all makes some sense,
> Pieter
>
>
> On 05/09/2017 17:31, Stephen Mallette wrote:
>
>> I guess I'm trying to understand why it matters for purpose of the test.
>> If
>> you mix/match versions I can't think of why the test would care one way or
>> the other. does sqlg serialize its id to a JSON Map?
>>

[jira] [Created] (TINKERPOP-1767) Method for graph providers to check an IO version and type

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1767:
---

 Summary: Method for graph providers to check an IO version and type
 Key: TINKERPOP-1767
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1767
 Project: TinkerPop
  Issue Type: Improvement
  Components: io
Affects Versions: 3.3.0
Reporter: stephen mallette
Assignee: stephen mallette
 Fix For: 3.3.1


The basic problem is described here:

https://lists.apache.org/thread.html/5d46643614c5306d38bfbec11cee3aa7653f440d276e7cbe189e@%3Cdev.tinkerpop.apache.org%3E

but in summary, the graph provider needs a way to check the type of io and 
version so that they have the opportunity to assign the correct instance of 
their {{IoRegistry}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1759) Improve hashcode and equals for Traverser implementations

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1759.
---
Resolution: Fixed

> Improve hashcode and equals for Traverser implementations
> -
>
> Key: TINKERPOP-1759
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1759
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1759) Improve hashcode and equals for Traverser implementations

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1759:

Fix Version/s: (was: 3.3.1)

> Improve hashcode and equals for Traverser implementations
> -
>
> Key: TINKERPOP-1759
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1759
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1759) Improve hashcode and equals for Traverser implementations

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1759:
-

> Improve hashcode and equals for Traverser implementations
> -
>
> Key: TINKERPOP-1759
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1759
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TINKERPOP-1766) Gremlin.Net: Closed connections should not be re-used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1766:
---

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/704
  
Thanks for your comments so far, I'll implement the changes you suggested.

I definitely agree that the driver and especially the connection pool needs 
to be improved and I would really appreciate any effort you (and of course als 
anyone else) put into this as I'm not exactly an expert in writing database 
drivers.

Could you clarify what you mean with _request pipelining on the same 
connection_? If you mean sending multiple requests in parallel over the same 
websocket connection, then I think that it's not possible as [the 
documentation](https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.clientwebsocket.sendasync?view=netframework-4.7#Remarks)
 states that

> Exactly one send and one receive is supported on each ClientWebSocket 
object in parallel.

The upside of this is of course that the implementation of the `Connection` 
and the `ConnectionPool` is much simpler when every `Connection` can just send 
one single request at a time as we don't have to match incoming responses with 
the correct requests they belong to.


> Gremlin.Net: Closed connections should not be re-used 
> --
>
> Key: TINKERPOP-1766
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1766
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>
> The driver of Gremlin.Net is kept very simle which holds especially true for 
> the {{ConnectionPool}}. It simply returns every connection to its pool of 
> usable connections that was {{disposed}} by the client. Unfortunately, this 
> also applies in case the submit failed due to an already closed connection 
> which means that the client will get the closed connection back from the 
> {{ConnectionPool}} later and continues trying to submit messages over this 
> closed connection.
> This can be fixed by checking whether the {{Connection}} is still open before 
> adding it back to the {{ConnectionPool}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #704: TINKERPOP-1766 Gremlin.Net: Add handling for closed co...

[FlorianHockmann]

Github user FlorianHockmann commented on the issue:

https://github.com/apache/tinkerpop/pull/704
  
Thanks for your comments so far, I'll implement the changes you suggested.

I definitely agree that the driver and especially the connection pool needs 
to be improved and I would really appreciate any effort you (and of course als 
anyone else) put into this as I'm not exactly an expert in writing database 
drivers.

Could you clarify what you mean with _request pipelining on the same 
connection_? If you mean sending multiple requests in parallel over the same 
websocket connection, then I think that it's not possible as [the 
documentation](https://docs.microsoft.com/en-us/dotnet/api/system.net.websockets.clientwebsocket.sendasync?view=netframework-4.7#Remarks)
 states that

> Exactly one send and one receive is supported on each ClientWebSocket 
object in parallel.

The upside of this is of course that the implementation of the `Connection` 
and the `ConnectionPool` is much simpler when every `Connection` can just send 
one single request at a time as we don't have to match incoming responses with 
the correct requests they belong to.


---

[jira] [Commented] (TINKERPOP-1766) Gremlin.Net: Closed connections should not be re-used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1766:
---

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/704
  
I've left some line comments on the pr.

Apart from the issue this patch is addressing, we should create separate 
tickets for issues related to the .NET driver pool:
- Blocking (use of `lock`).
- An unbounded number of connections can be created under pressure.
- Lack of request pipelining on the same connection.

I wasn't able to focus on the .NET driver itself, my initial priority was 
getting a stable `GraphTraversal` API and bytecode serialization, but we can 
tackle these issues progressively in the next versions. 


> Gremlin.Net: Closed connections should not be re-used 
> --
>
> Key: TINKERPOP-1766
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1766
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>
> The driver of Gremlin.Net is kept very simle which holds especially true for 
> the {{ConnectionPool}}. It simply returns every connection to its pool of 
> usable connections that was {{disposed}} by the client. Unfortunately, this 
> also applies in case the submit failed due to an already closed connection 
> which means that the client will get the closed connection back from the 
> {{ConnectionPool}} later and continues trying to submit messages over this 
> closed connection.
> This can be fixed by checking whether the {{Connection}} is still open before 
> adding it back to the {{ConnectionPool}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #704: TINKERPOP-1766 Gremlin.Net: Add handling for closed co...

[jorgebay]

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/704
  
I've left some line comments on the pr.

Apart from the issue this patch is addressing, we should create separate 
tickets for issues related to the .NET driver pool:
- Blocking (use of `lock`).
- An unbounded number of connections can be created under pressure.
- Lack of request pipelining on the same connection.

I wasn't able to focus on the .NET driver itself, my initial priority was 
getting a stable `GraphTraversal` API and bytecode serialization, but we can 
tackle these issues progressively in the next versions. 


---

[jira] [Commented] (TINKERPOP-1766) Gremlin.Net: Closed connections should not be re-used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1766:
---

Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/704#discussion_r137214097
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs ---
@@ -74,6 +85,36 @@ private void AddConnection(Connection connection)
 }
 }
 
+private void ConsiderUnavailable()
+{
+CloseAndRemoveAllConnections();
+}
+
+private void CloseAndRemoveAllConnections()
+{
+lock (_connectionsLock)
+{
+TeardownAsync().WaitUnwrap();
+RemoveAllConnections();
+}
+}
+
+private void RemoveAllConnections()
+{
+while (!_connections.IsEmpty)
+{
+_connections.TryTake(out var connection);
+connection.Dispose();
+}
+}
+
+private async Task TeardownAsync()
+{
+var closeTasks = new List(_connections.Count);
--- End diff --

The list isn't necessary, you can use the `Task.WhenAll(IEnumerable)` 
overload instead: `Task.WhenAll(_connections.Select(c => c.CloseAsync()))`


> Gremlin.Net: Closed connections should not be re-used 
> --
>
> Key: TINKERPOP-1766
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1766
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>
> The driver of Gremlin.Net is kept very simle which holds especially true for 
> the {{ConnectionPool}}. It simply returns every connection to its pool of 
> usable connections that was {{disposed}} by the client. Unfortunately, this 
> also applies in case the submit failed due to an already closed connection 
> which means that the client will get the closed connection back from the 
> {{ConnectionPool}} later and continues trying to submit messages over this 
> closed connection.
> This can be fixed by checking whether the {{Connection}} is still open before 
> adding it back to the {{ConnectionPool}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #704: TINKERPOP-1766 Gremlin.Net: Add handling for cl...

[jorgebay]

Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/704#discussion_r137214097
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs ---
@@ -74,6 +85,36 @@ private void AddConnection(Connection connection)
 }
 }
 
+private void ConsiderUnavailable()
+{
+CloseAndRemoveAllConnections();
+}
+
+private void CloseAndRemoveAllConnections()
+{
+lock (_connectionsLock)
+{
+TeardownAsync().WaitUnwrap();
+RemoveAllConnections();
+}
+}
+
+private void RemoveAllConnections()
+{
+while (!_connections.IsEmpty)
+{
+_connections.TryTake(out var connection);
+connection.Dispose();
+}
+}
+
+private async Task TeardownAsync()
+{
+var closeTasks = new List(_connections.Count);
--- End diff --

The list isn't necessary, you can use the `Task.WhenAll(IEnumerable)` 
overload instead: `Task.WhenAll(_connections.Select(c => c.CloseAsync()))`


---

[jira] [Commented] (TINKERPOP-1766) Gremlin.Net: Closed connections should not be re-used

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1766:
---

Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/704#discussion_r137213383
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs ---
@@ -74,6 +85,36 @@ private void AddConnection(Connection connection)
 }
 }
 
+private void ConsiderUnavailable()
+{
+CloseAndRemoveAllConnections();
+}
+
+private void CloseAndRemoveAllConnections()
+{
+lock (_connectionsLock)
+{
+TeardownAsync().WaitUnwrap();
+RemoveAllConnections();
+}
+}
+
+private void RemoveAllConnections()
+{
+while (!_connections.IsEmpty)
--- End diff --

Using `TryTake()` and `IsEmpty` can create race conditions.
Use `while (bag.TryTake(out c))` instead.


> Gremlin.Net: Closed connections should not be re-used 
> --
>
> Key: TINKERPOP-1766
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1766
> Project: TinkerPop
>  Issue Type: Bug
>  Components: language-variant
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Florian Hockmann
>
> The driver of Gremlin.Net is kept very simle which holds especially true for 
> the {{ConnectionPool}}. It simply returns every connection to its pool of 
> usable connections that was {{disposed}} by the client. Unfortunately, this 
> also applies in case the submit failed due to an already closed connection 
> which means that the client will get the closed connection back from the 
> {{ConnectionPool}} later and continues trying to submit messages over this 
> closed connection.
> This can be fixed by checking whether the {{Connection}} is still open before 
> adding it back to the {{ConnectionPool}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop pull request #704: TINKERPOP-1766 Gremlin.Net: Add handling for cl...

[jorgebay]

Github user jorgebay commented on a diff in the pull request:

https://github.com/apache/tinkerpop/pull/704#discussion_r137213383
  
--- Diff: gremlin-dotnet/src/Gremlin.Net/Driver/ConnectionPool.cs ---
@@ -74,6 +85,36 @@ private void AddConnection(Connection connection)
 }
 }
 
+private void ConsiderUnavailable()
+{
+CloseAndRemoveAllConnections();
+}
+
+private void CloseAndRemoveAllConnections()
+{
+lock (_connectionsLock)
+{
+TeardownAsync().WaitUnwrap();
+RemoveAllConnections();
+}
+}
+
+private void RemoveAllConnections()
+{
+while (!_connections.IsEmpty)
--- End diff --

Using `TryTake()` and `IsEmpty` can create race conditions.
Use `while (bag.TryTake(out c))` instead.


---

Re: Gremlin.Net GA release

[Jorge Bay Gondra]

I've forgotten about TINKERPOP-1730 and TINKERPOP-1731 was not under my
radar... makes sense to target 3.2.7 / 3.3.1.

I think I'll be able to dedicate some time to those tickets by the end of
this week.

Thanks,
Jorge

On Fri, Sep 1, 2017 at 6:27 PM, Stephen Mallette 
wrote:

> Thanks for bringing this up, Jorge. There were a handful of blockers that
> everyone seemed to agree on that prevented us from going right to GA for
> 3.2.6/3.3.0. Here were some of the key blockers that I remember:
>
> https://issues.apache.org/jira/browse/TINKERPOP-1731 - docker build needs
> to work for .NET - pretty crucial
> https://issues.apache.org/jira/browse/TINKERPOP-1734 - it seems we have a
> pattern for DSLs - just need to document it
> https://issues.apache.org/jira/browse/TINKERPOP-1730 - we need everything
> supporting the latest GraphSON version for full Gremlin support
>
> finally - and we don't have a ticket yet that i know of - but we really
> should figure out how to fully test .NET Gremlin against the test suite.
> Not sure how that will work - it will need some thought and will need to be
> generalized so that we can use that same pattern against future GLVs that
> aren't on the JVM at all.
>
> I think we should focus on trying to clear these issues (and others if they
> exist) for 3.2.7/3.3.1 so that we can go full GA with .NET for those
> releases. Does that sound like a plan?
>
>
>
>
> On Fri, Sep 1, 2017 at 8:48 AM, Jorge Bay Gondra  >
> wrote:
>
> > Hi,
> > I think starting with a release candidate of the Gremlin.Net language
> > variant package was a good choice for the first official release of the
> > package after being included in TinkerPop project.
> >
> > Now that the release candidate has been individually checked, it would be
> > nice to move forward and make a GA release of 3.2.6 and 3.3.0, that way
> it
> > can be the default download on nuget.org
> >  (prereleases are not shown
> on
> > dotnet toolchain by default) and we can make it easier for newcomers to
> use
> > the GLV.
> >
> > Cheers,
> > Jorge
> >
>

[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV

[jorgebay]

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
Great! It would be really nice to have a working 
`GremlinJavaScriptScriptEngine`!


---

[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1489:
---

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/695
  
Great! It would be really nice to have a working 
`GremlinJavaScriptScriptEngine`!


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.5
>Reporter: Jorge Bay
>
> It would be nice to have a Javascript Gremlin Language Variant that could 
> work with any ES5 runtime, specially the ones that support 
> [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js.
> Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but 
> provides [additional 
> extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] 
> making modular JavaScript possible. Nashorn should be supported in order to 
> run glv tests under the same infrastructure (JDK8).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)