[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time
[ https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1631#comment-1631 ] ASF GitHub Bot commented on TINKERPOP-1863: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/771 Thanks @EugeneChung - as this was minor change that was discussed on the dev mailing list already I decided to just CTR and merge it without further votes. I updated the CHANGELOG and made a minor tweak to the equality check for null: https://github.com/apache/tinkerpop/commit/c4b0f9de04fda08db5b6b03a91ba58f3def0217a > Delaying the setting of requestId till the RequestMessage instantiation time > > > Key: TINKERPOP-1863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1863 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Eugene Chung >Priority: Minor > > The Builder class of > org.apache.tinkerpop.gremlin.driver.message.RequestMessage class sets its > requestId field as UUID.randomUUID() by default. > But I think it should be fixed not to be set by default. The reasons are > below; > - UUID.randomUUID() uses SecureRandom which grabs the lock at JVM level, > which means whole threads calling this API compete against each other. > - Getting random value from SecureRandom is somewhat CPU-intensive job. > - If a gremlin client sends requestId by itself, the costs above are useless. > https://lists.apache.org/thread.html/a7e6cfeadad10852a2deed8616e47df6738c13c47119c12f98dcd3e1@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time
[ https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316657#comment-16316657 ] ASF GitHub Bot commented on TINKERPOP-1863: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/771 > Delaying the setting of requestId till the RequestMessage instantiation time > > > Key: TINKERPOP-1863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1863 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Eugene Chung >Priority: Minor > > The Builder class of > org.apache.tinkerpop.gremlin.driver.message.RequestMessage class sets its > requestId field as UUID.randomUUID() by default. > But I think it should be fixed not to be set by default. The reasons are > below; > - UUID.randomUUID() uses SecureRandom which grabs the lock at JVM level, > which means whole threads calling this API compete against each other. > - Getting random value from SecureRandom is somewhat CPU-intensive job. > - If a gremlin client sends requestId by itself, the costs above are useless. > https://lists.apache.org/thread.html/a7e6cfeadad10852a2deed8616e47df6738c13c47119c12f98dcd3e1@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time
[ https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16316385#comment-16316385 ] ASF GitHub Bot commented on TINKERPOP-1863: --- Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/771 VOTE +1 > Delaying the setting of requestId till the RequestMessage instantiation time > > > Key: TINKERPOP-1863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1863 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Eugene Chung >Priority: Minor > > The Builder class of > org.apache.tinkerpop.gremlin.driver.message.RequestMessage class sets its > requestId field as UUID.randomUUID() by default. > But I think it should be fixed not to be set by default. The reasons are > below; > - UUID.randomUUID() uses SecureRandom which grabs the lock at JVM level, > which means whole threads calling this API compete against each other. > - Getting random value from SecureRandom is somewhat CPU-intensive job. > - If a gremlin client sends requestId by itself, the costs above are useless. > https://lists.apache.org/thread.html/a7e6cfeadad10852a2deed8616e47df6738c13c47119c12f98dcd3e1@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time
[ https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16314063#comment-16314063 ] ASF GitHub Bot commented on TINKERPOP-1863: --- GitHub user EugeneChung opened a pull request: https://github.com/apache/tinkerpop/pull/771 TINKERPOP-1863 Delaying the setting of requestId till the RequestMess… …age instantiation time You can merge this pull request into a Git repository by running: $ git pull https://github.com/EugeneChung/tinkerpop patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/771.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 #771 commit 7e80bccb4c0195a510bb20be4d5da65629ee2a7f Author: Eugene Chung Date: 2018-01-05T22:46:42Z TINKERPOP-1863 Delaying the setting of requestId till the RequestMessage instantiation time > Delaying the setting of requestId till the RequestMessage instantiation time > > > Key: TINKERPOP-1863 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1863 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Eugene Chung >Priority: Minor > > The Builder class of > org.apache.tinkerpop.gremlin.driver.message.RequestMessage class sets its > requestId field as UUID.randomUUID() by default. > But I think it should be fixed not to be set by default. The reasons are > below; > - UUID.randomUUID() uses SecureRandom which grabs the lock at JVM level, > which means whole threads calling this API compete against each other. > - Getting random value from SecureRandom is somewhat CPU-intensive job. > - If a gremlin client sends requestId by itself, the costs above are useless. -- This message was sent by Atlassian JIRA (v6.4.14#64029)