GH-40345: [FlightRPC][C++][Java][Go] Add URI scheme to reuse connection

[lidavidm]

Rationale for this change

https://docs.google.com/document/d/1g9M9FmsZhkewlT1mLibuceQO8ugI0-fqumVAXKFjVGg/edit?usp=sharing

What changes are included in this PR?

Base implementation sans integration test

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [FlightRPC][C++][Go][Java] Add URI scheme to reuse connection #40345

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

In the case of PARQUET issues on JIRA the title also supports:

PARQUET-${JIRA_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[alamb]

Thank you @lidavidm -- this is a valuable feature in my mind.

My only concern is about the terminology -- Fallback is confusing to me as it implies this scheme should only be used when other schemes fail, but I can see cases where the server intends the client to be able to fetch data from the same endpoint as a valid option (not a a fallback in an error case)

Here are some other potential names for consideration that I think may match the intent better:

arrow-flight-generator:// (matches existing terminology)
arrow-flight-default://
arrow-flight-source-location://
arrow-flight-any://

[alamb]

I recommend we put this context and use directly into the Flight protobuf as well so that the spec can be implemented directly from the .proto spec

arrow/format/Flight.proto

Lines 436 to 452 in e83295b

	/*
	* A list of URIs where this ticket can be redeemed via DoGet().
	*
	* If the list is empty, the expectation is that the ticket can only
	* be redeemed on the current service where the ticket was
	* generated.
	*
	* If the list is not empty, the expectation is that the ticket can
	* be redeemed at any of the locations, and that the data returned
	* will be equivalent. In this case, the ticket may only be redeemed
	* at one of the given locations, and not (necessarily) on the
	* current service.
	*
	* In other words, an application can use multiple locations to
	* represent redundant and/or load balanced services.
	*/
	repeated Location location = 2;

[lidavidm]

I've already renamed it and will update the docs. Is the proposed scheme acceptable?

[alamb]

I've already renamed it and will update the docs. Is the proposed scheme acceptable?

I think arrow-flight-reuse-connection:// is acceptable in my opinion - referring to the concept as fallback in the docs is confusing but if we update that then the proposal would be great to me

[github-actions]

⚠️ GitHub issue #40345 has been automatically assigned in GitHub to PR creator.

[lidavidm]

Any final comments?

[kou]

+1

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit ef6ea6b.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details.