[jira] [Commented] (TINKERPOP-1863) Delaying the setting of requestId till the RequestMessage instantiation time

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)