Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Method to Retryable Exception for evaluation #744

Merged
merged 4 commits into from
Jul 24, 2018

Conversation

kdavisk6
Copy link
Member

Closes #719

This change adds the original Request Method to RetryableException,
allowing implementers to determine if a retry should occur based on
method and exception type.

To support this, Response objects now require that the original
Request be present. Test Cases, benchmarks, and documentation have
been added.

Closes OpenFeign#719

This change adds the original Request Method to `RetryableException`,
allowing implementers to determine if a retry should occur based on
method and exception type.

To support this, `Response` objects now require that the original
`Request` be present.  Test Cases, benchmarks, and documentation have
been added.
Copy link
Member

@velo velo left a comment

Choose a reason for hiding this comment

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

I add a few pointer... overall looks good.

@@ -65,7 +65,7 @@ public Default(SSLSocketFactory sslContextFactory, HostnameVerifier hostnameVeri
@Override
public Response execute(Request request, Options options) throws IOException {
HttpURLConnection connection = convertAndSend(request, options);
return convertResponse(connection).toBuilder().request(request).build();
return convertResponse(connection, request).toBuilder().request(request).build();
Copy link
Member

Choose a reason for hiding this comment

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

By doing this you can eliminate the .toBuilder().request(request).build()

Copy link
Member Author

@kdavisk6 kdavisk6 Jul 20, 2018

Choose a reason for hiding this comment

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

I must have missed this one during testing. I'll remove it.

@@ -37,15 +41,15 @@ public static Request create(String method,
return new Request(method, url, headers, body, charset);
}

private final String method;
private final Methods method;
Copy link
Member

Choose a reason for hiding this comment

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

Nice... maybe just call it Method? Or HttpMethod to avoid conflict with other methods =D

Copy link
Member Author

Choose a reason for hiding this comment

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

I had not considered that, good catch! I'll rename to HttpMethod

@@ -45,11 +45,12 @@

private Response(Builder builder) {
checkState(builder.status >= 200, "Invalid status code: %s", builder.status);
checkState(builder.request != null, "original request is required");
Copy link
Member

Choose a reason for hiding this comment

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

why not use checkNotNull?

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted an IllegalStateException thrown and not a NullPointerException. From my point of view, I prefer not to throw NPE's directly. But I'm open to change it if you feel strongly enough.

checkNotNull(request, "the original request is required on all responses");

/* don't keep the body, we don't want to tie up memory on large requests */
this.request = Request.create(
Copy link
Member

Choose a reason for hiding this comment

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

IMO, Request and Response object are short lived, so, feels like any gain we would have memory usage by creating a new request, we would loose on GC time for 2 objects....

If someone decides to keep the Response in memory for some reason, I think, they would like to have the whole Request.

Lemme know your thoughts

Copy link
Member Author

Choose a reason for hiding this comment

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

My concern is with larger requests that deal with multi-part uploads and pure binary requests. Keeping the body in memory after the request feels like it may lead to unexpected memory usages and leaks. I had not considered the GC impact.

Copy link
Member

Choose a reason for hiding this comment

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

It feels like an early optimization for me.

What if we include the original Request for now, and try to fix the problem when we spot real use cases?

Copy link
Member Author

Choose a reason for hiding this comment

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

Understood. I'll change to to reference the original and not create a new request.

@@ -24,20 +24,23 @@
private static final long serialVersionUID = 1L;

private final Long retryAfter;
private final String method;
Copy link
Member

Choose a reason for hiding this comment

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

What about using the enumeration Methods?

@@ -54,7 +58,7 @@ public static Request create(String method,

/* Method to invoke on the server. */
public String method() {
Copy link
Member

Choose a reason for hiding this comment

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

I thin we should create a new method httpMethod() that will return the enum and then deprecate this one to be removed on feign 12!?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, let's do that. I had not added the Enum to RetryableException due to this method. I'll make that change here and in RetryableException

@@ -13,6 +13,7 @@
*/
package feign.client;

import feign.FeignException;
Copy link
Member

Choose a reason for hiding this comment

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

Think that is not necessary

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll clean that up.

@kdavisk6
Copy link
Member Author

@velo, remarks addressed and the PR has been updated.

* Added `HttpMethod` enum that represents the supported HTTP methods
replacing String handling.
* Deprecated `Request#method()` in favor of `Request#httpMethod()`
@kdavisk6 kdavisk6 force-pushed the 719-retry-on-get-only branch from 47e071f to 5993c5e Compare July 20, 2018 16:25
@kdavisk6 kdavisk6 added the waiting for feedback Issues waiting for a response from either to the author or other maintainers label Jul 20, 2018
Copy link
Member

@velo velo left a comment

Choose a reason for hiding this comment

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

LGTM, feel free to hit the button

@@ -43,7 +43,7 @@ public int status() {

static FeignException errorReading(Request request, Response ignored, IOException cause) {
return new FeignException(
format("%s reading %s %s", cause.getMessage(), request.method(), request.url()),
format("%s reading %s %s", cause.getMessage(), request.httpMethod().name(), request.url()),
Copy link
Member

Choose a reason for hiding this comment

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

format should be able to deal with Enums just fine. no need to call name()

There is no need to have an explicit call to `Enum.name`.  Removed.
Style Compliance.
@kdavisk6 kdavisk6 merged commit 9875a16 into OpenFeign:master Jul 24, 2018
@kdavisk6 kdavisk6 deleted the 719-retry-on-get-only branch July 24, 2018 00:53
@kdavisk6 kdavisk6 removed the waiting for feedback Issues waiting for a response from either to the author or other maintainers label Aug 5, 2018
@kdavisk6 kdavisk6 added this to the 10.0 milestone Aug 10, 2018
velo pushed a commit that referenced this pull request Oct 7, 2024
Closes #719

This change adds the original Request Method to `RetryableException`,
allowing implementers to determine if a retry should occur based on
method and exception type.

To support this, `Response` objects now require that the original
`Request` be present.  Test Cases, benchmarks, and documentation have
been added.

* Refactored Request Method Attribute on Requests
* Added `HttpMethod` enum that represents the supported HTTP methods
replacing String handling.
* Deprecated `Request#method()` in favor of `Request#httpMethod()`
velo pushed a commit that referenced this pull request Oct 8, 2024
Closes #719

This change adds the original Request Method to `RetryableException`,
allowing implementers to determine if a retry should occur based on
method and exception type.

To support this, `Response` objects now require that the original
`Request` be present.  Test Cases, benchmarks, and documentation have
been added.

* Refactored Request Method Attribute on Requests
* Added `HttpMethod` enum that represents the supported HTTP methods
replacing String handling.
* Deprecated `Request#method()` in favor of `Request#httpMethod()`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants