[
https://issues.apache.org/jira/browse/TINKERPOP-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1863.
---------------------------------------
Resolution: Fixed
Assignee: stephen mallette
Fix Version/s: 3.3.2
3.2.8
The related PR was merged a while back - I just forgot to close the issue.
Closed now.
> 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
> Assignee: stephen mallette
> Priority: Minor
> Fix For: 3.2.8, 3.3.2
>
>
> 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
(v7.6.3#76005)
