blaze
blaze copied to clipboard
http4s
Blazing fast NIO microframework and Http Parser
open JDK 8, Scala `2.12.12` ``` openjdk version "1.8.0_222" OpenJDK Runtime Environment (build 1.8.0_222-b10) OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) ``` ``` Error while closing SSL Engine javax.net.ssl.SSLException:...
this came up in the community build: https://scala-ci.typesafe.com/job/scala-2.12.x-jdk11-integrate-community-build/1084/artifact/logs/blaze-build.log ``` [blaze] [info] SSLStage in server mode should [blaze] [info] + Transcode a single buffer [blaze] [error] x Split large buffers [blaze]...
When starting blaze (`http4s v0.20.0-M1 on blaze v0.14.0-M9 `) with `withSSLContext` and sending a request with `curl` the request is successfully served but I'm getting this log message. I verified...
When running any basic server with blaze on http4s 0.19.x the logs are spammed with ``` [blaze-selector-0-1] WARN o.h.b.p.s.QuietTimeoutStage - org.http4s.blaze.pipeline.stages.QuietTimeoutStage Stage: 30 seconds received unhandled inbound command: Disconnected [blaze-selector-0-1]...
Please review the following changes: https://github.com/TechEmpower/FrameworkBenchmarks/pull/3788
https://github.com/http4s/blaze/blob/c87ff657dc49fd68267ec70faf0389260f988104/core/src/main/scala/org/http4s/blaze/pipeline/stages/SSLStage.scala#L329 I think this isn't ever hit in practice as the handshake happens almost universally in the `syncWrite` path and the read path.
Currently we can only use NIO2 for clients because we don't have a way to hook client sockets into the `SelectorLoop`.
The current pipeline structure is pull-based with read and write operations returning futures, so in some ways, they are like a version of a socket that return a Future instead...
Nothing failed, so I suspect this is a racy shutdown: ``` 16:14:21.837 [anInnocuousThread] ERROR org.http4s.blaze.util.Execution - Trampoline EC Exception caught java.lang.IllegalStateException: Promise already completed. at scala.concurrent.Promise.complete(Promise.scala:49) at scala.concurrent.Promise.complete$(Promise.scala:48) at scala.concurrent.impl.Promise$DefaultPromise.complete(Promise.scala:183)...
The current pipeline model is a pull-based pipeline model which brings some tradeoffs. **Pros** - Clear semantics for backpressure - Intuitive usage pattern **Cons** - `Promise`s at each stage of...