akka-http | The Streaming-first HTTP server/module of Akka | HTTP library

I tried your "Custom SSLContext" reproducer. Besides timing out, it also produced the following stack track in the logging:

I believe it is because when parameter("token".optional) is rejected, it automatically returns a 401 Unauthorized response.

I believe it's the opposite. You made "token" parameter optional, that means when it's absent it still will be accepted and the directive after | never evaluated. If you drop the .optional and token parameter is not there it will be rejected and directive after | will be evaluated.

As far as Kafka is concerned, the message is consumed as soon as Alpakka Kafka reads it from Kafka.

This is before the actor inside of Alpakka Kafka has emitted it to a downstream consumer for application level processing.

Kafka auto-commit (enable.auto.commit = true) will thus result in the offset being committed before the message has been sent to your actor.

The Kafka docs on offset management do (as of this writing) refer to enable.auto.commit as having an at-least-once semantic, but as noted in my first paragraph, this is an at-least-once delivery semantic, not an at-least-once processing semantic. The latter is an application level concern, and accomplishing that requires delaying the offset commit until processing has completed.

The Alpakka Kafka docs have an involved discussion about at-least-once processing: in this case, at-least-once processing will likely entail introducing manual offset committing and replacing mapAsyncUnordered with mapAsync (since mapAsyncUnordered in conjunction with manual offset committing means that your application can only guarantee that a message from Kafka gets processed at-least-zero times).

In Alpakka Kafka, a broad taxonomy of message processing guarantees:

• hard at-most-once: Consumer.atMostOnceSource - commit after every message before processing
• soft at-most-once: enable.auto.commit = true - "soft" because the commits are actually batched for increased throughput, so this is really "at-most-once, except when it's at-least-once"
• hard at-least-once: manual commit only after all processing has been verified to succeed
• soft at-least-once: manual commit after some processing has been completed (i.e. "at-least-once, except when it's at-most-once")
• exactly-once: not possible in general, but if your processing has the means to dedupe and thus make duplicates idempotent, you can have effectively-once

You are not allowed to use context outside of an actor. And you do it in callback of your future.

There are a bunch of ways to test a microservice developed using akka-http:

1. Unit testing
2. Functional / Integration testing
3. E2E testing
4. Load testing

Unit testing using route-testkit (https://doc.akka.io/docs/akka-http/current/routing-dsl/testkit.html)

Functional testing & E2E testing using Akka HTTP client API (https://doc.akka.io/docs/akka-http/current/client-side/index.html) with API contracts you can validate the status codes and response body.

Load testing can be achieved using a bunch of tools, specifically in Scala you can take a look at Gatling.

The following code is written on top of my head and following the docs, since I can't test it right now.
(thus it may have some typos / errors; if you find one please feel free to edit the answer and thanks!)

The Akka docs call out your situation:

The Akka HTTP WebSocket API does not support half-closed connections which means that if either stream completes the entire connection is closed (after a “Closing Handshake” has been exchanged or a timeout of 3 seconds has passed).

In your case, outgoing (being a Source.single) completes as soon as it has emitted the TextMessage. The webSocketFlow receives the completion message and then tears down the connection.

The solution is to delay when outgoing completes, perhaps even delaying it forever (or at least until the application is killed).

Two standard sources are potentially useful for delaying completion in the scenario where you don't want to send messages through the websocket.

• Source.maybe materializes as a Promise which you can complete with an optional terminating message. It will not complete unless and until the promise is completed.

• Source.never never completes. You could achieve this by just not completing Source.maybe, but this is less overhead than that.

So what would it look like in code?

Using context asynchronously inside a Future is a bad idea. context it is only valid during calls to the actor.

The bug is that context.become(run(openRequests - 1)) uses the value of openRequests at the time the Future is created, not the value when it is called. So when the first request completes it will call context.become(run(-1)) (which is clearly bogus) even though there may be 15 outstanding requests.

The solution is to send a private message to yourself in the foreach rather than calling context.become directly. When the actor handles that message it decrements the current request count and sends a new request if necessary.

Got it working as: