[akka-http] How many stream/graph instances will be materialized when binding to Http?

[Leon Ma]

Hi,

Checking below code:

    bind(interface, port, settings, httpsContext, log)

      .mapAsyncUnordered(settings.maxConnections) { connection ⇒

        handleOneConnection(connection).recoverWith {

          // Ignore incoming errors from the connection as they will cancel the binding.

          // As far as it is known currently, these errors can only happen if a TCP error bubbles up

          // from the TCP layer through the HTTP layer to the Http.IncomingConnection.flow.

          // See https://github.com/akka/akka/issues/17992

          case NonFatal(_) ⇒ Future.successful(())

        }(fm.executionContext)

      }

      .to(Sink.ignore)

      .run()

It looks like for each connection, 1 flow (defined by handler) will be materialized.

Does that mean as long as the connection lives, there will only be 1 materialized stream serves for this connection?

And if the connection dies (like idled out from the connection pool), the stream will stop/terminated as well?

Thanks

Leon

[Akka Team]

Hi Leon,

On Tue, Nov 24, 2015 at 2:38 PM, Leon Ma <tutu...@gmail.com> wrote:

Hi,

Checking below code:

    bind(interface, port, settings, httpsContext, log)

      .mapAsyncUnordered(settings.maxConnections) { connection ⇒

        handleOneConnection(connection).recoverWith {

          // Ignore incoming errors from the connection as they will cancel the binding.

          // As far as it is known currently, these errors can only happen if a TCP error bubbles up

          // from the TCP layer through the HTTP layer to the Http.IncomingConnection.flow.

          // See https://github.com/akka/akka/issues/17992

          case NonFatal(_) ⇒ Future.successful(())

        }(fm.executionContext)

      }

      .to(Sink.ignore)

      .run()

It looks like for each connection, 1 flow (defined by handler) will be materialized.

I don't get the context. What is this code doing? What does handleOneConnection do? Are you referring to Akka code or your own code?

 

Does that mean as long as the connection lives, there will only be 1 materialized stream serves for this connection?

Depends what handleOneConnection is doing, but if it connects a handler flow to the connection flow, then yes, that flow will handle each byte that arrives from that TCP connection.

 

And if the connection dies (like idled out from the connection pool),

This looks like a server, how does this relate to a connection pool?

The connection what the BindSource gives is a single incoming TCP connection. If it fails, then the Flow wrapping it will fail too.

 

the stream will stop/terminated as well?

It depends what does it do with the failure.

-Endre

 

Thanks

Leon

--
>>>>>>>>>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Akka Team

Typesafe - Reactive apps on the JVM

Blog: letitcrash.com
Twitter: @akkateam

[Leon Ma]

Hi, Endre

The code snippet is copied from akka.http.scaladsl.Http.scala

在 2015年11月24日星期二 UTC-8上午6:14:30，Akka Team写道：

[Akka Team]

Ok, then the answer is that one stream will be materialized for each incoming connection sharing the lifecycle of the connection.

Why does this matter btw?

-Endre

[Leon Ma]

Just worry about the cost of the materialization, if the stream is pretty complex which involves a lot of actor creations.

If it's just "per connection" rather than "per request", then I think it's not a big deal. (Assuming the connection object is reusable across requests)

Leon

在 2015年11月25日星期三 UTC-8上午2:41:39，Akka Team写道：

[Akka Team]

Hi Leon,

> Just worry about the cost of the materialization, if the stream is pretty complex which involves a lot of actor creations.

Yes, this is one reason why Akka Http is not as fast yet as it can be. Luckily, this is exactly what we are working on, as 2.0 will allow fusing graphs into one actor instead of N.

-Endre

[Leon Ma]

Is it available in 2.0-M1 now?

在 2015年11月26日星期四 UTC-8上午1:17:46，Akka Team写道：

[Akka Team]

On Fri, Nov 27, 2015 at 7:15 AM, Leon Ma <tutu...@gmail.com> wrote:

Is it available in 2.0-M1 now?

2.0-M1 is basically 1.1 so you should update anyway (more likely to M2 which we will release soon). The feature is not yet available as it requires many internal changes that are 90% done now. You won't see the internal changes, but they are there.

Btw, before worrying about the costs you should measure if the performance is up to your expectations.

-Endre