What are you doing with the responses? My first guess would be that you're spending cpu pool time handling responses and that's why things are queueing up
Instead of semaphores, making a
Stream of requests and using its concurrency controls may be worth exploring as well.
While people are awake, we have a couple open PRs that would be nice to get an 0.20.2 out.
@Taig json parsing is heavily cpu bound IME
i.e. behavior will change with default behavior having an SSL context or having no ssl context.
As if we were deferring creation, I’d expect I’d see where we called that later with the delayed call.
I don't really like it. If you're on a system where
getDefault throws, it just defers the explosion until the first https call. But the reason it's there is that it gives people who know that getDefault throws a chance to override it. The crucial point is that getDefault not appear as a default argument. That's why we've gotten that bug filed ... twice.
We
*We’ll still get the issue
So…
And it still needs to be lazy, because
Some(sslContext.getDefault) is the right choice for most people.
but, thats for a binary-breaking change.
Then we need to explicitly deal with it somewhere after server creation.
SyncIO makes it lazy and expresses Dragons Be Here.
F[SSLContext] could have a reasonable default.
I don't like the last two because I tend not to like passing effects as parameters.
Our implicits being in last position is really a PITA
I really want
(implicit XYZ)(argumentList)
If we passed
Http1Support and F[SslContext], we've got a ConcurrentEffect[F] (which I'm not proud of), and then could run it in the constructor.
Keeping it lazy in
Http1Support is still important though.
We couldn't just strictly run that effect in
Http1Support, or we'd break people who can't get an SSLContext and don't want one.
As that seems like a value that could be evaluated and not properly seperated if we are concerned about that.