[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant
[ https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323144#comment-16323144 ] ASF GitHub Bot commented on TINKERPOP-1489: --- Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/695 Quick update - I plan to check this PR this weekend. > Provide a Javascript Gremlin Language Variant > - > > Key: TINKERPOP-1489 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1489 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >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)
[GitHub] tinkerpop issue #695: TINKERPOP-1489 JavaScript GLV
Github user jbmusso commented on the issue: https://github.com/apache/tinkerpop/pull/695 Quick update - I plan to check this PR this weekend. ---
[jira] [Commented] (TINKERPOP-1858) HttpChannelizer regression: Does not create specified AuthenticationHandler
[ https://issues.apache.org/jira/browse/TINKERPOP-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322976#comment-16322976 ] ASF GitHub Bot commented on TINKERPOP-1858: --- Github user krlohnes commented on the issue: https://github.com/apache/tinkerpop/pull/767 I added in the CHANGELOG entry > HttpChannelizer regression: Does not create specified AuthenticationHandler > --- > > Key: TINKERPOP-1858 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1858 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.3.0 > Environment: All >Reporter: Keith Lohnes > Labels: easyfix, regression > Original Estimate: 1h > Remaining Estimate: 1h > > HttpChannelizer creates a HttpBasicAuthenticationHandler instead of > instantiating the specified AuthenticationHandler from the configuration -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #767: TINKERPOP-1858: HttpChannelizer Regression: Does not c...
Github user krlohnes commented on the issue: https://github.com/apache/tinkerpop/pull/767 I added in the CHANGELOG entry ---
Re: [DISCUSS] TinkerGraph Memory Usage Enhancements
Thanks Stephen. Just adding a few notes: * As mentioned before I'm happy to provide a PR to the Apache Tinkergraph and thereby close down our fork. If others prefer to not dilute the waters, I'll equally happily maintain the fork and bring in changes from Tinkerpop releases (as I've just done with 3.3.1) * By default, even our fork still uses the same (generic, non-strict) mode. The user can enable the specialised/strict/memory-efficient mode by providing factories for their specialised elements * It's all-or-nothing: either all elements are specialised or all elements are generic. Technically this can be changed, I just didn't have the need and time to do it. Cheers Michael On 12/01/18 00:50, Stephen Mallette wrote: > Michael Pollmeier recently authored a blog post that described how their > fork of TinkerGraph memory usage could be reduced by 70% assuming usage of > a strict schema: > > https://blog.shiftleft.io/open-sourcing-our-specialized-tinkergraph-with-70-memory-reduction-and-strict-schema-validation-fa5cfb3dd82d > > The question at this point, is whether or not similar enhancements should > be made to TinkerPop's TinkerGraph. I've had a few minutes to get to > understand the changes that make the memory improvement possible - here's > my thoughts: > > 1. This was a clever way to extend TinkerGraph. > 2. The schema is implemented by way of concrete graph element classes shown > here: > > https://github.com/ShiftLeftSecurity/tinkergraph-gremlin/tree/master/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/specialized/gratefuldead > > 3. Given that approach, you give up some flexibility in favor of improved > memory usage > 4. This approach started to feel sufficiently different to me to warrant > this improvement as being more than just a "performance enhancement" and > more like a fundamental change to what TinkerGraph is about. > 5. Of course, Michael had said on the user mailing list that the strict > schema was optional - though you needed to use it to get the improved > memory usage. > 6. SoI think the questions forming in my mind are: (a) do we want a > major new feature (schema support) on TinkerGraph? (b) if so, is the schema > support implemented in the manner in which we would want it (i.e. concrete > classes)? (c) is this new feature changing TinkerGraph's mission in > TinkerPop? (d) if so, should it simply remain as a fork (presumably under a > different name to avoid confusion) so that it is not bound by what > TinkerGraph is meant to be and can develop more freely?. > > I'll leave it at that for now and see what other people think. > > Irrespective of how this ends, I'd quickly offer another round of thanks to > Michael and his colleagues for coming up with a neat feature and > performance enhancement that could be useful to the TinkerPop community. > signature.asc Description: OpenPGP digital signature
[jira] [Commented] (TINKERPOP-1858) HttpChannelizer regression: Does not create specified AuthenticationHandler
[ https://issues.apache.org/jira/browse/TINKERPOP-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322283#comment-16322283 ] ASF GitHub Bot commented on TINKERPOP-1858: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/767 VOTE +1 > HttpChannelizer regression: Does not create specified AuthenticationHandler > --- > > Key: TINKERPOP-1858 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1858 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.3.0 > Environment: All >Reporter: Keith Lohnes > Labels: easyfix, regression > Original Estimate: 1h > Remaining Estimate: 1h > > HttpChannelizer creates a HttpBasicAuthenticationHandler instead of > instantiating the specified AuthenticationHandler from the configuration -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #767: TINKERPOP-1858: HttpChannelizer Regression: Does not c...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/767 VOTE +1 ---
[jira] [Commented] (TINKERPOP-1858) HttpChannelizer regression: Does not create specified AuthenticationHandler
[
https://issues.apache.org/jira/browse/TINKERPOP-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322233#comment-16322233
]
ASF GitHub Bot commented on TINKERPOP-1858:
---
Github user krlohnes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/767#discussion_r160963168
--- Diff:
gremlin-server/src/test/java/org/apache/tinkerpop/gremlin/server/channel/HttpChannelizerIntegrateTest.java
---
@@ -18,15 +18,40 @@
*/
package org.apache.tinkerpop.gremlin.server.channel;
-
+import org.apache.http.NoHttpResponseException;
import org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator;
import org.apache.tinkerpop.gremlin.server.Settings;
+import org.junit.Test;
+
import java.util.Map;
import java.util.HashMap;
+import java.net.SocketException;
public class HttpChannelizerIntegrateTest extends
AbstractGremlinServerChannelizerIntegrateTest {
+@Override
+public Settings overrideSettings(final Settings settings) {
+super.overrideSettings(settings);
+final String nameOfTest = name.getMethodName();
+if (nameOfTest.equals("shouldBreakOnInvalidAuthenticationHandler")
) {
+settings.authentication = getAuthSettings();
+settings.authentication.authenticationHandler = "Foo.class";
+}
+return settings;
+}
+
+@Test
+public void shouldBreakOnInvalidAuthenticationHandler() throws
Exception {
+final CombinedTestClient client = new
CombinedTestClient(getProtocol());
+try {
+client.sendAndAssert("2+2", 4);
--- End diff --
Fixed
> HttpChannelizer regression: Does not create specified AuthenticationHandler
> ---
>
> Key: TINKERPOP-1858
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1858
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.3.0
> Environment: All
>Reporter: Keith Lohnes
> Labels: easyfix, regression
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> HttpChannelizer creates a HttpBasicAuthenticationHandler instead of
> instantiating the specified AuthenticationHandler from the configuration
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop pull request #767: TINKERPOP-1858: HttpChannelizer Regression: Doe...
Github user krlohnes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/767#discussion_r160963168
--- Diff:
gremlin-server/src/test/java/org/apache/tinkerpop/gremlin/server/channel/HttpChannelizerIntegrateTest.java
---
@@ -18,15 +18,40 @@
*/
package org.apache.tinkerpop.gremlin.server.channel;
-
+import org.apache.http.NoHttpResponseException;
import org.apache.tinkerpop.gremlin.server.auth.SimpleAuthenticator;
import org.apache.tinkerpop.gremlin.server.Settings;
+import org.junit.Test;
+
import java.util.Map;
import java.util.HashMap;
+import java.net.SocketException;
public class HttpChannelizerIntegrateTest extends
AbstractGremlinServerChannelizerIntegrateTest {
+@Override
+public Settings overrideSettings(final Settings settings) {
+super.overrideSettings(settings);
+final String nameOfTest = name.getMethodName();
+if (nameOfTest.equals("shouldBreakOnInvalidAuthenticationHandler")
) {
+settings.authentication = getAuthSettings();
+settings.authentication.authenticationHandler = "Foo.class";
+}
+return settings;
+}
+
+@Test
+public void shouldBreakOnInvalidAuthenticationHandler() throws
Exception {
+final CombinedTestClient client = new
CombinedTestClient(getProtocol());
+try {
+client.sendAndAssert("2+2", 4);
--- End diff --
Fixed
---
[DISCUSS] TinkerGraph Memory Usage Enhancements
Michael Pollmeier recently authored a blog post that described how their fork of TinkerGraph memory usage could be reduced by 70% assuming usage of a strict schema: https://blog.shiftleft.io/open-sourcing-our-specialized-tinkergraph-with-70-memory-reduction-and-strict-schema-validation-fa5cfb3dd82d The question at this point, is whether or not similar enhancements should be made to TinkerPop's TinkerGraph. I've had a few minutes to get to understand the changes that make the memory improvement possible - here's my thoughts: 1. This was a clever way to extend TinkerGraph. 2. The schema is implemented by way of concrete graph element classes shown here: https://github.com/ShiftLeftSecurity/tinkergraph-gremlin/tree/master/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/specialized/gratefuldead 3. Given that approach, you give up some flexibility in favor of improved memory usage 4. This approach started to feel sufficiently different to me to warrant this improvement as being more than just a "performance enhancement" and more like a fundamental change to what TinkerGraph is about. 5. Of course, Michael had said on the user mailing list that the strict schema was optional - though you needed to use it to get the improved memory usage. 6. SoI think the questions forming in my mind are: (a) do we want a major new feature (schema support) on TinkerGraph? (b) if so, is the schema support implemented in the manner in which we would want it (i.e. concrete classes)? (c) is this new feature changing TinkerGraph's mission in TinkerPop? (d) if so, should it simply remain as a fork (presumably under a different name to avoid confusion) so that it is not bound by what TinkerGraph is meant to be and can develop more freely?. I'll leave it at that for now and see what other people think. Irrespective of how this ends, I'd quickly offer another round of thanks to Michael and his colleagues for coming up with a neat feature and performance enhancement that could be useful to the TinkerPop community.
