Skip to content
This repository has been archived by the owner on Nov 14, 2024. It is now read-only.

[Conjure Java Runtime] Part 10: Drive a truck through the AtlasDbHttpClients API #4264

Merged
merged 15 commits into from
Sep 30, 2019

Conversation

jeremyk-91
Copy link
Contributor

Goals (and why):

  • Enable live reloadable configuration of whether requests should go through the legacy or CJR path.
  • Avoid having the various methods all end with String userAgent, boolean limitPayloadSize, RemotingClientConfig config

Implementation Description (bullets):

  • Convert the aforementioned parameters into an AuxiliaryRemotingParameters struct
  • Fix the API breaks everywhere
  • Plumb the config through as far as a client talking to timelock is concerned, which is probably where we'll start this off.

Testing (What was existing testing like? What have you done to improve it?):
Not much. Existing tests still work (some were changed as they asserted over-specific things IMO).

Concerns (what feedback would you like?):

  • This PR is kind of large, so I probably missed something or introduced some unnecessary duplication when fixing the fallout of the API break.
  • Is the API break overly aggressive?
  • I changed the expectations of some tests. I think these are reasonable, but worth a second pass.

Where should we start reviewing?:

  • AuxiliaryRemotingParameters

Priority (whenever / two weeks / yesterday): this week would be great!

@changelog-app
Copy link

changelog-app bot commented Sep 26, 2019

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

AtlasDbHttpClients now expects an AuxiliaryRemotingParameters struct which encapsulates information about whether to use payload limiting, the user agent, and any additional remoting client configuration (such as that that may be provided by the AtlasDB library). These were previously expected as primitives.

To replicate previous behaviour, users should create an AuxiliaryRemotingParameters struct, possibly as follows:

AuxiliaryRemotingParameters.builder()
        .userAgent(UserAgents.tryParse(userAgentString))
        .shouldLimitPayload(false)
        .remotingClientConfig(remotingClientConfigSupplier)
        .build();

userAgent and remotingClientConfig are optional; shouldLimitPayload is compulsory.

Check the box to generate changelog(s)

  • Generate changelog entry

@@ -210,6 +213,11 @@ boolean lockImmutableTsOnReadOnlyTransactions() {

abstract String userAgent();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mark this as deprecated?

@@ -258,10 +266,11 @@ public static TransactionManager createInMemory(Set<Schema> schemas) {
AtlasDbConfig config = ImmutableAtlasDbConfig.builder().keyValueService(new InMemoryAtlasDbConfig()).build();
return builder()
.config(config)
.userAgent(UserAgents.DEFAULT_USER_AGENT)
.userAgent(AtlasDbRemotingConstants.DEFAULT_USER_AGENT.toString())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you have to specify both? I think it should be an error if this is done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given we're still keeping userAgent around, and have a default structuredUserAgent, this is sadly a little tricky to do

@@ -1005,7 +1022,7 @@ private static LockAndTimestampServices createRawLeaderServices(
ServiceCreator.createTrustContext(leaderConfig.sslConfiguration()),
Iterables.getOnlyElement(leaderConfig.leaders()),
PingableLeader.class,
userAgent);
userAgent.toString());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unconverted

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the underlying method to take a UserAgent object.


@Value.Default
default UserAgent userAgent() {
return AtlasDbRemotingConstants.DEFAULT_USER_AGENT;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, not sure how I feel about a default user agent

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pairing: we removed the default.

public interface RemotingClientConfig {
RemotingClientConfig DEFAULT = ImmutableRemotingClientConfig.builder().build();

default double maximumV2Probability() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably something a bit more descriptive of the change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, changed

@@ -121,18 +123,16 @@ private AtlasDbHttpClients() {
trustContextCreator,
proxySelectorCreator,
type,
userAgent,
limitPayload),
clientParameters),
DEFAULT_TARGET_FACTORY.getClientVersion()),
ImmutableInstanceAndVersion.of(DEFAULT_TARGET_FACTORY.createLiveReloadingProxyWithFailover(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dunno whyI missed this last time, but the wrapper seems redundant, since the instance and the version is on the factory, unless I'm missing something

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pairing: we pushed InstanceAndVersion down into the TargetFactory layer

@@ -32,31 +33,27 @@
Optional<TrustContext> trustContext,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the option to not retry can fold into AuxiliaryRemotingParameters?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pairing: yep, folded this in to AuxiliaryRemotingParameters


<T> T createProxyWithFailover(
Optional<TrustContext> trustContext,
Optional<ProxySelector> proxySelector,
Collection<String> endpointUris,
Class<T> type,
String userAgent,
boolean limitPayloadSize);
AuxiliaryRemotingParameters parameters);

<T> T createLiveReloadingProxyWithFailover(
Supplier<ServerListConfig> serverListConfigSupplier,
Function<SslConfiguration, TrustContext> trustContextCreator,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should also kill, these two parameters, i.e. trustContextCreator and proxySelectorCreator. We only have one impl, and it's never anything different. All the stuff we need is inside ServerListConfig

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pairing: We removed these functions.


<T> T createProxy(
Optional<TrustContext> trustContext,
String uri,
Class<T> type,
String userAgent,
boolean limitPayloadSize);
AuxiliaryRemotingParameters parameters);

<T> T createProxyWithFailover(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should then make this a default that just takes in a ServerListConfig and then returns a static supplier to the createLiveReloadingProxyWithFailover.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with this, we only have two methods to implement 💃

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pairing: Sadly it goes the other way (the live reloading one falls back to this) so it's not as straightforward

.build();
```

`userAgent` and `remotingClientConfig` are optional; `shouldLimitPayload` is compulsory.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure I agree about userAgent being optional

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, we made it compulsory (I'll need to change the docs).

@jeremyk-91 jeremyk-91 merged commit 305c9d7 into develop Sep 30, 2019
@delete-merged-branch delete-merged-branch bot deleted the jkong/proxy-api-wreck-2 branch September 30, 2019 19:59
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants