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

Allow HTTPServerRequest creation on the current EventLoop only #215

Merged
merged 1 commit into from
Jul 17, 2019

Conversation

pushkarnk
Copy link
Contributor

@pushkarnk pushkarnk commented Jul 15, 2019

An HTTPServerRequest abstracts a received HTTP request. Though an
HTTPServerRequest must be strictly associated with an HTTP connection,
Kitura-NIO allowed creation of HTTPServerRequests from anywhere. Consequently,
to build the URL for the urlURL property, when we need to access
ChannelHandlerContext properties like localAddress or remoteAddress, that
code needs to be dispatched to the EventLoop. Because the computation of
urlURL is synchronous, we also need to wait() for the EventLoop to return. If
urlURL were invoked on an EventLoop, like we do in Kitura-WebSocket-NIO, we
fail with a SwiftNIO assertion that doesn't permit wait() to be invoked on an
EventLoop.

The best possible solution to this issue is to restrict the HTTPServerRequest
creation on the EventLoop associated with the underlying HTTP connection only.
The ChannelHandlerContext properties could then be accessed in the
initializer.

}.flatMap { (webSocketConnectionHandler: ChannelHandler) -> EventLoopFuture<Void> in
var future = ctx.channel.pipeline.addHandler(webSocketConnectionHandler)
if let _extensions = request.headers["Sec-WebSocket-Extensions"].first {
for handler in webSocketHandlerFactory.extensionHandlers(header: _extensions) {
Copy link

Choose a reason for hiding this comment

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

you could also do ctx.channel.pipeline.addHandlers(webSocketHandlerFactory.extensionHandlers(header: _extensions), positition: .before(...)). With addHandlers you can add multiple handlers in one go.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks @weissi !

An `HTTPServerRequest` abstracts a received HTTP request. Though an
`HTTPServerRequest` must be strictly associated with an HTTP connection,
Kitura-NIO allowed creation of HTTPServerRequests from anywhere. Consequently,
to build the `URL` for the `urlURL` property, when we need to access
`ChannelHandlerContext` properties like `localAddress` or `remoteAddress`, that
code needs to be dispatched to the EventLoop. Because the computation of
`urlURL` is synchronous, we also need to wait() for the EventLoop to return. If
`urlURL` were invoked on an EventLoop, like we do in `Kitura-WebSocket-NIO`, we
fail with a SwiftNIO assertion that doesn't permit wait() to be invoked on an
`EventLoop`.

A possible solution to this issue is to restrict the HTTPServerRequest
creation on the EventLoop associated with the underlying HTTP connection only.
The `ChannelHandlerContext` properties could then be accessed in the
initializer.
@pushkarnk pushkarnk force-pushed the server-request-eventloop branch from 44eef79 to 8b3f33e Compare July 15, 2019 17:55
@pushkarnk
Copy link
Contributor Author

pushkarnk commented Jul 15, 2019

Testing todos:

  • Kitura-WebSocket-NIO
  • WebSocket compression tests
  • Kitura-Sample
  • Kitura-CouchDB
  • SwiftMetrics

@pushkarnk
Copy link
Contributor Author

Testing todos:

  • Kitura-WebSocket-NIO
  • WebSocket compression tests
  • Kitura-Sample
  • Kitura-CouchDB
  • SwiftMetrics

The fix has come out clean from these.

@pushkarnk pushkarnk merged commit 893a093 into master Jul 17, 2019
@pushkarnk pushkarnk deleted the server-request-eventloop branch July 29, 2019 05:48
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