Blaze 0.13.0 Support #917
Closed
Blaze 0.13.0 Support #917
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Allow custom scheduler for timeout middleware
…with a literal null for the query parameters, eg. "/foo/bar?null". added a check to add the query only if non null
This attempts to make the log and exception messages a bit more useful when there is a timeout in `ClientTimeoutStage` within the Blaze client.
Words are hard.
Decouple server from Dropwizard Metrics
Empty EntityEncoder
Basic Authentication module now supports passing the cleartext password to a function which can validate the password (for example, by comparing it against a hashed value). Previously, the basic authentication middleware require that the password be stored in plaintext on the server. Fixes http4s#730.
This should resolve the ArrayIndexOutOfBoundsExceptions on Travis.
basicAuth no longer gives default support to cleartext password comparisons. (Removed support for AuthenticationStore in basicAuth object.)
Upgrade sbt-mima-plugin
This fixes bug http4s#704.
It's based entirely on the QValue. This makes it possible to write an `f: CharsetRange => CharsetRange` that determines the QValue by the charset, and breaks `x eqv y ==> f(x) eqv f(y)`. We could make it lawful by using the charset to break ties, but this has no basis in the HTTP spec. One part of the HTTP spec we missed was to prefer atoms over splats. All of this is specific to content-negotation, and belongs in code there, not a general ordering. This was uncovered by `Cogen` in cats-0.8. It will be tested there. /cc @ceedubs, whose morning I helped ruin with this.
…ances Order[CharsetRange] is unlawful, so weaken it to Equal
Mix new `ThreadDumpOnTimeout` into `AsyncHttpClientSpec` and print thread dump to console 500ms before the spec times out. Hoping to better understand: http4s#858 (comment) and also apply `ThreadDumpOnTimeout` to understand http4s#774.
In several of the recent Travis CI build build failures: * [3444.6](https://travis-ci.org/http4s/http4s/jobs/193191028) * [3458.6](https://travis-ci.org/http4s/http4s/jobs/193838431) * [3534.6](https://travis-ci.org/http4s/http4s/jobs/195974285) the test that did not complete was `CharsetRangeSpec`. Mix in `ThreadDumpOnTimeout` and set a 2 second timeout to help identify the source of the deadlock causing http4s#774.
…pecs log thread dump when specs with possible deadlocks exceed timeouts
Define http4sVersion key to derive version for cross builds
Fix the tuts broken by http4s#810, reform syntax
Test output will now include all specs2 expecations and how long each took to complete.
…ion-timing turn on `showtimes` for specs2 to help diagnose http4s#774
Docs on URI / docs/makeSite
Thread dumps[1,2] from http4s#897 show `ExternalBlazeHttp1ClientSpec` running just before `AsyncHttpClientSpec` times out. Might be coincidence, but it seems reasonable to have a (long) timeout for calls to external URLs anyhow. [1] https://travis-ci.org/http4s/http4s/jobs/197158086#L6885 [2] https://travis-ci.org/http4s/http4s/jobs/198883683#L8345 Refs http4s#858 and http4s#817
Wait for up to 20 x 200ms intervals (4 seconds) before triggering a thread dump. Spec frequently runs for 1-2 seconds on Travis CI infrastructure and the 2 second timeout was firing for tests that were likely not deadlocked. Would not have been a big deal, but the thread dumps put Travis over its 4MB log limit and cause the job to fail. Longer term, if we keep the dumps, they should be written to a log file and uploaded to S3 instead of polluting the console output. Refs http4s#774
Minor: add explicit return type to Retry.apply
…for-github-req Set 30 second timeout on blaze client requests to github.com
…pecs Increase `CharsetRangeSpec` timeout to 4 seconds before thread dump
``` case POST -> Root => req.as[Json].flatMap(Ok(_)) ``` If we post `NOT JSON` to that, it should return a 400, not a 500.
Call toHttpResponse on MessageFailures failed/thrown by HttpService
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #894 When It Compiles.
We have an issue upgrade due to the lack of the websocket modules.
Opening the PR so that we can decide where we would like to handle this implementation.