Re: [akka-user] Akka TCP with Actors vs Akka Streams and Flows/Graphs

[Akka Team]

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 <jarl....@gmail.com> 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 subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.