Hi,
Akka streams is defintely fit for "main stream development with semi
complex business logic", it is however not a framework but a tool in a
toolkit. As such it does have a learning threshold (just like actors do if
you are new to that concept), so some problems may not initially be
expressible using it, and of course not all problems does fit perfectly
with the paradigm.
If you are happy with your actor based solution, I don't see an obvious
need to rewrite using streams, although I personally find the IO part very
nicely expressed with streams. You could also just introduce streams in
parts of your system where you need back pressure and it is an abstraction
that fits the problem, the only thing to think of is the asynchronous
boundaries and where you go from backpressured to not backpressured and how
to deal with that.
1. Sounds like the cross connection session buffer would be nicely kept as
an actor, you can interact with actors from your flows using the ask
pattern and mapAsync, there are also additional stages specifically
designed to interact with actors (Source.actorRef and
Sink.{actorRef|actorRefWithAck} for example).
2. This is just application logic and highly application specific,
deserialize incoming messages and provide a stream or stage that closes the
stream if any other than a valid auth message comes from the client, and
thereafter lets the messages through.
3. To guarantee at least once delivery after the parsing a message you
would have to persist it before parsing, the app could crash, the OS could
crash, the server hardware could fail just the moment after parsing but
before anything has been done with it.
The section on using TCP with streams may be useful:
http://doc.akka.io/docs/akka/2.4.8/scala/stream/stream-io.html#Streaming_TCP
--
Johan
On Tue, Jul 26, 2016 at 9:06 AM, Jarl André Hübenthal
wrote:
> Has some developed an akka stream based TCP server where connections is
> kept open and frame delimited messages is pouring in, and is eventually
> stored somewhere in a database? It seems to be such a simple pattern that i
> am surprised to not find any examples for it. But maybe the world is not so
> simple, or maybe akka streams arent targeted for main stream development
> with semi complex business logic. I need session management, authentication
> (crude) and cross connection session buffer, where connections can connect,
> send a partial message, disconnect for some reason, reconnect and send the
> last part of the message. The first message is always an HELO message (or
> login message). I feel the actor way of doing it is too fragile and
> resource consuming. I have like a river dance of actors doing all the
> wiring to keep session buffer for each connection, store the data and also
> to make sure that each message is at least stored once (only once in fact
> since i use unique index on table).
>
> Today I have:
>
> ActorSystem1(ServerActor -> ConnectionActor * N -> SessionActor * N) ->
> ActorSystem2(BackendRouterActor -> BackendWorkerActor)
>
> The ServerActor is where akka tcp sets up the the server, with host and
> port.
>
> ConnectionActor is one per connection, and validates the first message
> received as a login message. If not a login message, disconnects. If valid
> login message, creates a new SessionActor or finds an existing one, and
> then passes all further messages to the SessionActor.
>
> SessionActor is a persistent actor and keeps in its journal message
> buffer, last message received and message counter, and will process the
> buffer for each incoming message chunk. It searches with a tail recursive
> function (but I could also done look ahead) for messages that ends with
> delimiter, parses this messages into an Event object and sends this off to
> the BackendRouterActor.
>
> BackendRouterActor is a persistent At least once delivery actor, that when
> receives an Event object persists it and sends it off to the worker. If not
> confirmed within a time limt, resends, as usual with ALOD.
>
> I know there may be some weaknesses in this architecture, so general
> advice on the architecture would be great.
>
> But my main question, drawn in direct or abstract lines, how can this be
> done with Akka Streams?
>
> I see three problems (things i dont know the solution for) with akka
> streams:
>
> 1) The cross connection session buffer and other parameters related to
> session
> 2) Connection authentication (HELO message, which must be specific format)
> 2) At least once delivery where all parsed events MUST be stored.
>
> Someone who can shed some insight on possible solutions to these problems
> and the topic in general, how to convert such an actor based stateful app
> to akka streams?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are
