-
Notifications
You must be signed in to change notification settings - Fork 79
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
Update plugin interceptor examples. #173
Update plugin interceptor examples. #173
Conversation
c75fae1
to
867add0
Compare
.header("X-Foo", "Bar") | ||
.build()); | ||
} | ||
Transforming request object synchronously is trivial. Just call `request.newBuilder()` to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change
Transforming request object
to
Transforming a request object
It might also be worth noting that "synchronously" means "in the same thread" here, rather than having to synchronise something.
} | ||
Transforming request object synchronously is trivial. Just call `request.newBuilder()` to | ||
create a new `HttpRequest.Builder` object. It has already been initialised with the copy of | ||
the original `request`. Modify the builder as desired, consturct a new version, and pass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo:
consturct
} | ||
|
||
This example demonstrates how to synchronously transform a HTTP response. We will | ||
use a `StyxObservable` `map` method to add an "X-Foo" header to the response. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a
StyxObservable
map
method
I think this should be
the
StyxObservable.map
method
return requestAccessQueryAsync(request) | ||
.flatMap((allowed) -> allowed ? chain.proceed(request) : Observable.just(rejected)); | ||
} | ||
Sometimes it is necessary to transform the request asynchronously. For example, may need to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, may need to
may be
For example, you may need to
.flatMap((allowed) -> allowed ? chain.proceed(request) : Observable.just(rejected)); | ||
} | ||
Sometimes it is necessary to transform the request asynchronously. For example, may need to | ||
look up external key value stores to parametrise the request transformation. The example below |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo
parametrise
should be
parameterise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears to be a valid alternative spelling for "parameterise". But I have changed regardless.
business domain object. Here we will explain how to do this. And as always, this can be done in a synchronous or | ||
asynchronous fashion. | ||
private static CompletableFuture<String> callTo3rdParty(String myHeader) { | ||
return CompletableFuture.completedFuture("value"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To reduce confusion we could just put something like
private static CompletableFuture<String> callTo3rdParty(String myHeader) {
// make call here
}
instead of a dummy implementation
.flatMap(response -> // (3) | ||
StyxObservable | ||
.from(callTo3rdParty(response.header(X_MY_HEADER).orElse("default"))) // (1) | ||
.map(value -> // (4) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe rename value
to resultOf3rdPartyCall
or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if long variable names make lambda expressions any clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Length was not my goal, just meaning. But this is pretty minor so feel free to leave it as it is.
@@ -106,6 +107,8 @@ private synchronized void bootstrap(Connection.Settings connectionSettings) { | |||
protected void initChannel(Channel ch) { | |||
ChannelPipeline pipeline = ch.pipeline(); | |||
|
|||
pipeline.addLast("logging-handler-1", new LoggingHandler()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why -1
and -2
? The names should explain why we need two.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were these pushed accidentally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some instrumentation hoping to replicate a CI test failure.
Backing this off.
@@ -136,9 +136,12 @@ private void scheduleResourcesTearDown(ChannelHandlerContext ctx) { | |||
protected void channelRead0(ChannelHandlerContext ctx, Object msg) throws Exception { | |||
ensureContentProducerIsCreated(ctx); | |||
|
|||
LOGGER.warn("channelRead0: {}", msg); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this pushed accidentally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
as releasing them if necessary. | ||
Alternatively, streaming messages can be aggregated into a `FullHttpRequest` or `FullHttpResponse` | ||
messages. The full HTTP message body is then available at interceptor's disposal. Note that content | ||
aggregation is always an asynchronous operation. This is because Styx must wait until all content |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be better to say "content aggregation must be performed asynchronously to prevent blocking of the I/O thread" or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. This is because content aggregation will happen asynchronously anyway, and therefore it won't be blocking a thread.
The real reason why the aggregation has to happen asynchronously is because the content simply won't be available in full at the time of aggregation. Styx simply has to wait until the underlying stream produces the necessary content.
Well, one could say that it "must be performed asynchronously to prevent blocking the IO thread", but that is missing the point, really.
I have attempted to clarify this:
Styx exposes HTTP messages to interceptors as streaming `HttpRequest` and `HttpResponse` messages.
In this form, the interceptors can process the content in a streaming fashion. That is, they they
can look into, and modify the content as it streams through.
Alternatively, streaming messages can be aggregated into a `FullHttpRequest` or `FullHttpResponse`
messages. The full HTTP message body is then available at interceptor's disposal. Note that content
aggregation is always an asynchronous operation. This is because the streaming HTTP message is
exposing the content, in byte buffers, as it arrives from the network, and Styx must wait until
all content has been received.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that this PR needs some clean up to remove code that was added during troubleshooting.
a business domain object of type T. Styx will take care of managing all aspects related to direct memory buffers, such | ||
as releasing them if necessary. | ||
Alternatively, streaming messages can be aggregated into a `FullHttpRequest` or `FullHttpResponse` | ||
messages. The full HTTP message body is then available at interceptor's disposal. Note that content |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would change
The full HTTP message body is then available at interceptor's disposal.
to
The full HTTP message body is then available for the interceptor to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course. It reads better that way.
Bring plugins-scenarios.md up-to-date with new 1.0 API.