[
https://issues.apache.org/jira/browse/TINKERPOP-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18019254#comment-18019254
]
Ken Hu commented on TINKERPOP-2821:
-----------------------------------
CTR
https://github.com/apache/tinkerpop/commit/cb5f9ebc4f0897e97b6a3e1a19581bf44817914d
> Examine use of Tokens.ARGS_HOST as part of a RequestMessage
> -----------------------------------------------------------
>
> Key: TINKERPOP-2821
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2821
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
> Affects Versions: 3.5.4
> Reporter: Stephen Mallette
> Priority: Minor
>
> {{Tokens.ARGS_HOST}} seems to be used in different ways depending on whether
> it's being used in a {{RequestMessage}} where it expects a {{Host}} object
> (which is a bit odd - don't remember what the idea was there exactly) and in
> a {{ResponseMessage}} where it is assigned the {{channel.remoteAddress}} as a
> string in status metadata. I think the original idea was to allow the driver
> to have more control in a session where you could randomly pick any host, use
> the response to then reroute future requests to the same one based on the
> response metadata, but we never built the driver to really work that way. I'm
> not sure if i remember any of that properly though....maybe it was for
> something else? In any event, the currently functionality in
> {{Client.chooseConnection()}} that deals with the {{RequestMessage}} side
> likely isn't in use nor does it seem to be implemented how we would want it
> if it was to actually work. Seems worth examining more closely and likely
> just factoring that behavior out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
