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

Add StreamMessage.of(future) that produces StreamMessage from the future #4995

Merged
merged 8 commits into from Jul 25, 2023

Conversation

minwoox
Copy link
Member

@minwoox minwoox commented Jun 29, 2023

Motivation:
We have HttpResponse.from(future) that produces the HttpResponse when the future completes. It would be nice if we can have it on StreamMessage level.

Modifications:

  • Add StreamMessage.of(future) that produces another StreamMessage from the future

Result:

  • You can now easily create a StreamMessage using a future.

Motivation:
We have `HttpResponse.from(future)` that produces the `HttpResponse` when the future completes.
It woulb be nice if we can have similar one for `HttpRequest` which produces the data and trailers when the future compeltes.

Modifications:
- Add `DeferredHttpRequest` which is created from `HttpRequest.from(future)`.

Result:
- You can now create an `HttpRequest` that produces data and trailers after a future completes.
@minwoox minwoox added this to the 1.25.0 milestone Jun 29, 2023
Copy link
Member

@trustin trustin left a comment

Choose a reason for hiding this comment

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

👍

@minwoox minwoox changed the title Add an HttpRequest that produces the body from a future Add StreamMessage.of(future) that produces StreamMessage from a future Jun 29, 2023
@minwoox minwoox changed the title Add StreamMessage.of(future) that produces StreamMessage from a future Add StreamMessage.of(future) that produces StreamMessage from the future Jun 29, 2023
Copy link
Contributor

@jrhee17 jrhee17 left a comment

Choose a reason for hiding this comment

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

Left some minor comments, but basically looks good 👍 Thanks @minwoox 🙇 👍 🙇

@@ -24,7 +24,7 @@ jobs:
build:
if: github.repository == 'line/armeria'
runs-on: ${{ matrix.on }}
timeout-minutes: 100
timeout-minutes: 120
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this change intentional?

Copy link
Member

Choose a reason for hiding this comment

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

We should revert this before merging.

Copy link
Member Author

Choose a reason for hiding this comment

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

Reverted. 😉

* @param future the {@link CompletableFuture} which will produce the actual data and trailers
*/
static HttpRequest from(RequestHeaders headers,
CompletableFuture<? extends StreamMessage<? extends HttpObject>> future) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Question) Is this API needed since CompletionFuture inherits CompletionStage?

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, will remove it.

*
* @param stage the {@link CompletionStage} which will produce the actual data and trailers
*/
static HttpRequest from(RequestHeaders headers,
Copy link
Contributor

Choose a reason for hiding this comment

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

Question) would it rather make more sense to name this method of, and create the counterparts in HttpResponse? (and deprecate from() factory methods)

Copy link
Member Author

Choose a reason for hiding this comment

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

Changed to of. 😉
For HttpResponse, I actually left TODO for it because it needs to change quite a lot.

//TODO(minwoox): Rename this to 'of' for consistency.

Let me send another PR for that. 😉

* the returned {@link StreamMessage} using {@link #subscribe(Subscriber)}
* or {@link #subscribe(Subscriber, SubscriptionOption...)}.
*/
static <T> StreamMessage<T> of(CompletionStage<? extends StreamMessage<? extends T>> stage,
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 optionally we could also apply the CF completion check here too (I find it odd that only some APIs do this optimization, while others don't)

Copy link
Member Author

Choose a reason for hiding this comment

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

If so, we cannot use the executor specified. 😉 Let me add a comment there.

* the returned {@link StreamMessage} using {@link #subscribe(Subscriber)}
* or {@link #subscribe(Subscriber, SubscriptionOption...)}.
*/
static <T> StreamMessage<T> of(CompletionStage<? extends StreamMessage<? extends T>> stage,
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think of adding of(CompletableFuture<StreamMesage<T>> future, EventExecutor) for consistency, otherwise, removing of(CompletableFuture<StreamMesage<T>> future) from public API?

Copy link
Member Author

Choose a reason for hiding this comment

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

removing of(CompletableFuture<StreamMesage> future) from public API?

+1 for this. I will also deprecate/remove HttpResponse.from(CompletableFuture<? extends HttpResponse> future). 😉

@minwoox
Copy link
Member Author

minwoox commented Jul 21, 2023

@ikhoon Forgot to address the comments. 😓 All addressed. PTAL. 😉

@minwoox minwoox mentioned this pull request Jul 25, 2023
Copy link
Contributor

@ikhoon ikhoon left a comment

Choose a reason for hiding this comment

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

Sorry for the late review. It looks great!

@ikhoon ikhoon merged commit f63dd13 into line:main Jul 25, 2023
12 of 13 checks passed
@minwoox
Copy link
Member Author

minwoox commented Jul 25, 2023

Thanks for reviewing. 😉

@minwoox minwoox deleted the DeferredHttpRequest branch July 25, 2023 04:02
minwoox added a commit to minwoox/armeria that referenced this pull request Jul 26, 2023
Motivation:
We have decided to deprecate `HttpResponse.from(...)` methods and use `HttpResponse.of(...)` instead for consistency.
line#4995 (comment)

Modification:
- Deprecate `HttpResponse.from(CompletionStage)` and its variants.
  - `HttpResponse.of(CompletionStage)` and its variants are added.

Result:
- `HttpResponse.from(CompletionStage)` and its variants methods are deprecated.
  - Use `HttpResponse.of(CompletionStage)` and its variants instead.
ikhoon pushed a commit that referenced this pull request Jul 31, 2023
Motivation:
We have decided to deprecate `HttpResponse.from(...)` methods and use `HttpResponse.of(...)` instead for consistency. #4995 (comment)

Modification:
- Deprecate `HttpResponse.from(CompletionStage)` and its variants.
  - `HttpResponse.of(CompletionStage)` and its variants are added.

Result:
- `HttpResponse.from(CompletionStage)` and its variants methods are deprecated.
  - Use `HttpResponse.of(CompletionStage)` and its variants instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants