[
https://issues.apache.org/jira/browse/TINKERPOP-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18018130#comment-18018130
]
Ken Hu commented on TINKERPOP-2821:
-----------------------------------
These are my findings after some investigation.
Client used to make use of the "host" from RequestMessage as a means of
directing the request to a particular host in order to support remote traversal
side effects. However, that capabilitity was deprecated in TINKERPOP-2265 and
then removed in TINKERPOP-2269. This means that the driver itself will no
longer populate "host" into the RequestMessage args.
ResponseMessage added returning the remoteAddress in the status metadata as an
example of how status metadata could be used. This fulfilled the asks from
TINKERPOP-1913 and TINKERPOP-1494.
> 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)
