[
https://issues.apache.org/jira/browse/TINKERPOP-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Hu updated TINKERPOP-2821:
------------------------------
Fix Version/s: 3.8.0
> 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
> Fix For: 3.8.0
>
>
> {{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)
