[
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 <bluewolf.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)
