date:20161018

[akka-user] Re: [akka-stream] Problems with the shape creation

2016-10-18 Thread Sergey Sopin

Hi,

Yes, but it seems that I need to create Java API for it, because my app is 
in Java. 
I used Inkscape app. to draw the diagram.

Cheers,
Sergey

среда, 19 октября 2016 г., 0:46:00 UTC+3 пользователь Rafał Krzewski 
написал:
>
> A custom GraphStage [1] using AmorphousShape is probably the way to go in 
> this case.
>
> That's a really neat diagram, BTW! What software did you us to create it?
>
> Cheers,
> Rafał
>
> [1] 
> http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#Custom_processing_with_GraphStage
>
> W dniu wtorek, 18 października 2016 22:12:07 UTC+2 użytkownik Sergey Sopin 
> napisał:
>>
>> Hi again,
>>
>> I have a very specific case. My flow looks like this one:
>>
>>
>> 
>>
>> The idea of multi input/output shape was to redirect messages to a right 
>> output based on the message data.
>>
>> I just learn streams, so maybe you can suggest a better solution?
>>
>> Thanks!
>>
>>
>> Cheers, 
>>
>> Sergey
>>
>>
>>
>> вторник, 18 октября 2016 г., 18:34:22 UTC+3 пользователь Rafał Krzewski 
>> написал:
>>>
>>> It's not clear to me, what are you trying to accomplish. It looks like 
>>> you are trying to implement AmorphousShape (ie. arbitrary number of open 
>>> inlets and outlets) on your own, and then a specific variant of it, that 
>>> has all inlets sharing the same type, and all outlets sharing another type. 
>>> The "Fan" fragment in the names you used is a bit misleading, since in Akka 
>>> Stream's own usage of it names like FanIn / FanOut shape mean that such 
>>> grap has many inlets and single outlet / single inlet many outlets. The 
>>> analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
>>> many blades :) I am wondering what use case you have in mind for your 
>>> AmorphousShape because the graphs that can be materialized and executed 
>>> must ultimately have a ClosedShape. You could use such multi-outlet graphs 
>>> for reusing pieces of functionality, but anything more complex than a 
>>> BidiShape  seems  rather unwieldy to me.
>>>
>>> My understanding is that Graph's shape should not interfere with message 
>>> flow, because it's just a canvas with contact points on the perimeter. What 
>>> matters are the components that you plug into it. Akka just makes sure that 
>>> you don't leave any of the contact points dangling. This makes me think 
>>> that the problems with messages getting "stuck" was caused somewhere other 
>>> than graph shape construction site.
>>>
>>> Have you tried inserting probes alon the lines of 
>>> Flow.alsoTo(Sink.foreach(_ 
>>> => println("beep!"))) (shooting from the hip here, apologies if it does 
>>> not compile straight away) into your graph? That could help you locate 
>>> where the messages are stuck / discarded.
>>>
>>> Cheers,
>>> Rafał
>>>
>>> W dniu poniedziałek, 17 października 2016 20:22:43 UTC+2 użytkownik 
>>> Sergey Sopin napisał:

 Hi,

 I am trying to create my own akka streams shape with several Inlets and 
 Outlets. I have written following code: 

 package kernel.modeller.workers.streamFinder.generic

 import akka.stream.{Shape, Outlet, Inlet}
 import scala.annotation.unchecked.uncheckedVariance
 import scala.collection.immutable

 object FanShape {
   sealed trait Init[_] {
 def inlets: immutable.Seq[Inlet[_]]
 def outlets: immutable.Seq[Outlet[_]]
 def name: String
   }
   final case class Name[_](override val name: String) extends Init[Any] {
 override def inlets: immutable.Seq[Inlet[_]] = Nil
 override def outlets: immutable.Seq[Outlet[_]] = Nil
   }
   final case class Ports[_](override val inlets: immutable.Seq[Inlet[_]], 
 override val outlets: immutable.Seq[Outlet[_]]) extends Init[Any] {
 override def name: String = "FanShape"
   }
 }

 abstract class FanShape[_] private (_in: Iterator[Inlet[_]], _out: 
 Iterator[Outlet[_]], _name: String) extends Shape {
   
   import FanShape._

   def this(init: FanShape.Init[_]) = this(init.inlets.iterator, 
 init.outlets.iterator, init.name)

   final override def outlets: immutable.Seq[Outlet[_]] = _outlets
   final override def inlets: immutable.Seq[Inlet[_]] = _inlets

   private var _outlets: Vector[Outlet[_]] = Vector.empty
   private var _inlets: Vector[Inlet[_]] = Vector.empty

   protected def newOutlet[T](name: String): Outlet[T] = {
 val p = if (_out.hasNext) _out.next().asInstanceOf[Outlet[T]] else 
 Outlet[T](s"${_name}.$name")
 _outlets :+= p
 p
   }

   protected def newInlet[T](name: String): Inlet[T] = {
 val p = if (_in.hasNext) _in.next().asInstanceOf[Inlet[T]] else 
 Inlet[T](s"${_name}.$name")
 _inlets :+= p
 p
   }

   protected def con

[akka-user] Re: Simple beginner questions: Accessing values in flows

2016-10-18 Thread Evgeny Shepelyuk

Hi, could you please spare final code ?

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-stream] Problems with the shape creation

2016-10-18 Thread Rafał Krzewski

A custom GraphStage [1] using AmorphousShape is probably the way to go in 
this case.

That's a really neat diagram, BTW! What software did you us to create it?

Cheers,
Rafał

[1] 
http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#Custom_processing_with_GraphStage

W dniu wtorek, 18 października 2016 22:12:07 UTC+2 użytkownik Sergey Sopin 
napisał:
>
> Hi again,
>
> I have a very specific case. My flow looks like this one:
>
>
> 
>
> The idea of multi input/output shape was to redirect messages to a right 
> output based on the message data.
>
> I just learn streams, so maybe you can suggest a better solution?
>
> Thanks!
>
>
> Cheers, 
>
> Sergey
>
>
>
> вторник, 18 октября 2016 г., 18:34:22 UTC+3 пользователь Rafał Krzewski 
> написал:
>>
>> It's not clear to me, what are you trying to accomplish. It looks like 
>> you are trying to implement AmorphousShape (ie. arbitrary number of open 
>> inlets and outlets) on your own, and then a specific variant of it, that 
>> has all inlets sharing the same type, and all outlets sharing another type. 
>> The "Fan" fragment in the names you used is a bit misleading, since in Akka 
>> Stream's own usage of it names like FanIn / FanOut shape mean that such 
>> grap has many inlets and single outlet / single inlet many outlets. The 
>> analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
>> many blades :) I am wondering what use case you have in mind for your 
>> AmorphousShape because the graphs that can be materialized and executed 
>> must ultimately have a ClosedShape. You could use such multi-outlet graphs 
>> for reusing pieces of functionality, but anything more complex than a 
>> BidiShape  seems  rather unwieldy to me.
>>
>> My understanding is that Graph's shape should not interfere with message 
>> flow, because it's just a canvas with contact points on the perimeter. What 
>> matters are the components that you plug into it. Akka just makes sure that 
>> you don't leave any of the contact points dangling. This makes me think 
>> that the problems with messages getting "stuck" was caused somewhere other 
>> than graph shape construction site.
>>
>> Have you tried inserting probes alon the lines of Flow.alsoTo(Sink.foreach(_ 
>> => println("beep!"))) (shooting from the hip here, apologies if it does 
>> not compile straight away) into your graph? That could help you locate 
>> where the messages are stuck / discarded.
>>
>> Cheers,
>> Rafał
>>
>> W dniu poniedziałek, 17 października 2016 20:22:43 UTC+2 użytkownik 
>> Sergey Sopin napisał:
>>>
>>> Hi,
>>>
>>> I am trying to create my own akka streams shape with several Inlets and 
>>> Outlets. I have written following code: 
>>>
>>> package kernel.modeller.workers.streamFinder.generic
>>>
>>> import akka.stream.{Shape, Outlet, Inlet}
>>> import scala.annotation.unchecked.uncheckedVariance
>>> import scala.collection.immutable
>>>
>>> object FanShape {
>>>   sealed trait Init[_] {
>>> def inlets: immutable.Seq[Inlet[_]]
>>> def outlets: immutable.Seq[Outlet[_]]
>>> def name: String
>>>   }
>>>   final case class Name[_](override val name: String) extends Init[Any] {
>>> override def inlets: immutable.Seq[Inlet[_]] = Nil
>>> override def outlets: immutable.Seq[Outlet[_]] = Nil
>>>   }
>>>   final case class Ports[_](override val inlets: immutable.Seq[Inlet[_]], 
>>> override val outlets: immutable.Seq[Outlet[_]]) extends Init[Any] {
>>> override def name: String = "FanShape"
>>>   }
>>> }
>>>
>>> abstract class FanShape[_] private (_in: Iterator[Inlet[_]], _out: 
>>> Iterator[Outlet[_]], _name: String) extends Shape {
>>>   
>>>   import FanShape._
>>>
>>>   def this(init: FanShape.Init[_]) = this(init.inlets.iterator, 
>>> init.outlets.iterator, init.name)
>>>
>>>   final override def outlets: immutable.Seq[Outlet[_]] = _outlets
>>>   final override def inlets: immutable.Seq[Inlet[_]] = _inlets
>>>
>>>   private var _outlets: Vector[Outlet[_]] = Vector.empty
>>>   private var _inlets: Vector[Inlet[_]] = Vector.empty
>>>
>>>   protected def newOutlet[T](name: String): Outlet[T] = {
>>> val p = if (_out.hasNext) _out.next().asInstanceOf[Outlet[T]] else 
>>> Outlet[T](s"${_name}.$name")
>>> _outlets :+= p
>>> p
>>>   }
>>>
>>>   protected def newInlet[T](name: String): Inlet[T] = {
>>> val p = if (_in.hasNext) _in.next().asInstanceOf[Inlet[T]] else 
>>> Inlet[T](s"${_name}.$name")
>>> _inlets :+= p
>>> p
>>>   }
>>>
>>>   protected def construct(init: Init[_]): FanShape[_]
>>>
>>>   def deepCopy(): FanShape[_] = construct(Ports(inlets.map(_.carbonCopy()), 
>>> outlets.map(_.carbonCopy(
>>>   final def copyFromPorts(inlets: immutable.Seq[Inlet[_]], outlets: 
>>> immutable.Seq[Outlet[_]]): FanShape[_] = {
>>> require(outlets.size == _outlets.size, s"proposed outlets 
>>> [${outlets.mkString(", ")}

[akka-user] Re: [akka-stream] Problems with the shape creation

2016-10-18 Thread Sergey Sopin

Hi again,

I have a very specific case. My flow looks like this one:



The idea of multi input/output shape was to redirect messages to a right 
output based on the message data.

I just learn streams, so maybe you can suggest a better solution?

Thanks!


Cheers, 

Sergey



вторник, 18 октября 2016 г., 18:34:22 UTC+3 пользователь Rafał Krzewski 
написал:
>
> It's not clear to me, what are you trying to accomplish. It looks like you 
> are trying to implement AmorphousShape (ie. arbitrary number of open inlets 
> and outlets) on your own, and then a specific variant of it, that has all 
> inlets sharing the same type, and all outlets sharing another type. The 
> "Fan" fragment in the names you used is a bit misleading, since in Akka 
> Stream's own usage of it names like FanIn / FanOut shape mean that such 
> grap has many inlets and single outlet / single inlet many outlets. The 
> analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
> many blades :) I am wondering what use case you have in mind for your 
> AmorphousShape because the graphs that can be materialized and executed 
> must ultimately have a ClosedShape. You could use such multi-outlet graphs 
> for reusing pieces of functionality, but anything more complex than a 
> BidiShape  seems  rather unwieldy to me.
>
> My understanding is that Graph's shape should not interfere with message 
> flow, because it's just a canvas with contact points on the perimeter. What 
> matters are the components that you plug into it. Akka just makes sure that 
> you don't leave any of the contact points dangling. This makes me think 
> that the problems with messages getting "stuck" was caused somewhere other 
> than graph shape construction site.
>
> Have you tried inserting probes alon the lines of Flow.alsoTo(Sink.foreach(_ 
> => println("beep!"))) (shooting from the hip here, apologies if it does 
> not compile straight away) into your graph? That could help you locate 
> where the messages are stuck / discarded.
>
> Cheers,
> Rafał
>
> W dniu poniedziałek, 17 października 2016 20:22:43 UTC+2 użytkownik Sergey 
> Sopin napisał:
>>
>> Hi,
>>
>> I am trying to create my own akka streams shape with several Inlets and 
>> Outlets. I have written following code: 
>>
>> package kernel.modeller.workers.streamFinder.generic
>>
>> import akka.stream.{Shape, Outlet, Inlet}
>> import scala.annotation.unchecked.uncheckedVariance
>> import scala.collection.immutable
>>
>> object FanShape {
>>   sealed trait Init[_] {
>> def inlets: immutable.Seq[Inlet[_]]
>> def outlets: immutable.Seq[Outlet[_]]
>> def name: String
>>   }
>>   final case class Name[_](override val name: String) extends Init[Any] {
>> override def inlets: immutable.Seq[Inlet[_]] = Nil
>> override def outlets: immutable.Seq[Outlet[_]] = Nil
>>   }
>>   final case class Ports[_](override val inlets: immutable.Seq[Inlet[_]], 
>> override val outlets: immutable.Seq[Outlet[_]]) extends Init[Any] {
>> override def name: String = "FanShape"
>>   }
>> }
>>
>> abstract class FanShape[_] private (_in: Iterator[Inlet[_]], _out: 
>> Iterator[Outlet[_]], _name: String) extends Shape {
>>   
>>   import FanShape._
>>
>>   def this(init: FanShape.Init[_]) = this(init.inlets.iterator, 
>> init.outlets.iterator, init.name)
>>
>>   final override def outlets: immutable.Seq[Outlet[_]] = _outlets
>>   final override def inlets: immutable.Seq[Inlet[_]] = _inlets
>>
>>   private var _outlets: Vector[Outlet[_]] = Vector.empty
>>   private var _inlets: Vector[Inlet[_]] = Vector.empty
>>
>>   protected def newOutlet[T](name: String): Outlet[T] = {
>> val p = if (_out.hasNext) _out.next().asInstanceOf[Outlet[T]] else 
>> Outlet[T](s"${_name}.$name")
>> _outlets :+= p
>> p
>>   }
>>
>>   protected def newInlet[T](name: String): Inlet[T] = {
>> val p = if (_in.hasNext) _in.next().asInstanceOf[Inlet[T]] else 
>> Inlet[T](s"${_name}.$name")
>> _inlets :+= p
>> p
>>   }
>>
>>   protected def construct(init: Init[_]): FanShape[_]
>>
>>   def deepCopy(): FanShape[_] = construct(Ports(inlets.map(_.carbonCopy()), 
>> outlets.map(_.carbonCopy(
>>   final def copyFromPorts(inlets: immutable.Seq[Inlet[_]], outlets: 
>> immutable.Seq[Outlet[_]]): FanShape[_] = {
>> require(outlets.size == _outlets.size, s"proposed outlets 
>> [${outlets.mkString(", ")}] do not fit FanShape")
>> require(inlets.size == _inlets.size, s"proposed inlects 
>> [${inlets.mkString(", ")}] do not fit FanShape")
>> construct(Ports(inlets, outlets))
>>   }
>> }
>>
>> object UniformFanShape {
>>   def apply[I, O](inlets: Array[Inlet[I]], outlets: Outlet[O]*): 
>> UniformFanShape[I, O] =
>> new UniformFanShape(inlets.size, outlets.size, 
>> FanShape.Ports(inlets.toList, outlets.toList))
>> }
>>
>> class UniformFanShape[-I, +O](n: Int, m: Int, _init: FanShape.Init[

[akka-user] Re: Is back pressure triggered upon exceptions

2016-10-18 Thread Kunal Deshpande

Thanks Johannes for your feedback, 

For pt. 2 I am handling errors using Supervision.Resume so the stream 
should technically continue and not complete with an error, correct? 

Dagny - 

1. It is unclear what your graph looks like and how you are materializing 
the value, also which supervision strategy you are employing (default is 
Supervision.Stop) so your stream will complete with an exception which 
means a failed Try with exception from event 2 (basically the first 
exception that causes the stream to fail).

2. I think you are alluding to recovery strategies here, I would suggest 
reading documentation on Supervision strategies to handle errors and 
potentially recover from them. Also, you can use recover / recoverWith ops 
to handle any errors and gracefully complete the stream (these can be 
applied to individual stream stages).



On Sunday, September 25, 2016 at 11:44:40 PM UTC-7, Dagny T wrote:
>
> Hi Kunal and Johannes,
>
> THANKS for your posts on this -- as I was also wondering how 
> exception-handling mid-Flow is supposed to work!
>
> Followup questions for you, please:
>
> - Let's say for simplicity that we have only 3 events flowing through a 
> Streaming Flow with 5 Stages. 
> - We put a Try block around the myGraph.run() materialization
> - Then, say an exception happens on Stage 3, and Event 2.
>
> 1) Does this mean that the resulting Try collection will contain:
> - Success w Result from Event 1, all Stages
> - Failure w Exception from Event 2, Stage 3
> - NOTHING for Event 3; as Materialized Graph would have just stopped on an 
> exception
>
> 2) Does this then imply that Source has to somehow know Events 2,3 got 
> dropped via the UUID of Event- last processed;
> then it has to re-stream those to the Sink?
>
> Please let me know if I'm understanding those two points correctly!
>
> THANKS!
> D
>
> On Wednesday, September 14, 2016 at 10:49:18 PM UTC-7, Kunal Deshpande 
> wrote:
>>
>> Hi, 
>>
>> I have been using Akka streams to implement a saved-search refresh system 
>> as well as a notification processing system at my current company. 
>>
>> Recently we ran into a fast-publisher & slow subscriber problem where the 
>> downstream HTTP services were taking a long time to respond resulting in 
>> Timeout exceptions in our client. Currently we simply drop the event and 
>> resume the stream using Supervision.Resume but I am unsure whether that 
>> translates into back pressure.
>>
>> Few questions on back pressure
>> 1. While using Flows in akka-streams using .via will a downstream flow 
>> apply back pressure to a flow upstream or is back pressure only signaled to 
>> a Source?
>> 2. Will exceptions in a Flow trigger back pressure
>> 3. Is there a mathematical way to represent back pressure and is it 
>> consistent across different reactive streams implementations?
>>
>> Thanks, and really appreciate your time!
>>
>> Kunal
>>
>

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] graph control events propagation

2016-10-18 Thread Kyrylo Stokoz

Hi Akka Team, All,

I have few custom stages, recently i find out that one of them under 
certain conditions was not properly completing graph stage, which was 
causing graph to run forever.
I have timeouts attached to graph and would expect it to fail with timeout 
but it never happened. I created a simple reproducer (below).

I have a BrokenStage that is not completing stage in onUpstreamFinish method 
and i have a graph which has idleTimeout, completionTimeout and killSwitch 
attached. None of this has an effect on the graph it fails with future 
timeout.

I understand that this is developer issue and if i move any of timeouts 
after broken stage it will work as expected.
My questions would be:

1. I would still expect killSwitch or completion timeout to fail the graph, 
why it is not a case?
2. how i can detect such things / safely attach timeouts to graphs? 

Reproducer:
import akka.actor.ActorSystem
import akka.stream._
import akka.stream.scaladsl.{Keep, Sink, Source}
import akka.stream.stage.{GraphStage, GraphStageLogic, InHandler, OutHandler}

import scala.concurrent.Await
import scala.concurrent.duration._


case class BrokenStage[A](name: String) extends GraphStage[FlowShape[A, A]] {
  val in = Inlet[A]("in")
  val out = Outlet[A]("out")
  override val shape: FlowShape[A, A] = FlowShape(in, out)

  override def createLogic(inheritedAttributes: Attributes): GraphStageLogic = 
new GraphStageLogic(shape) {
setHandler(in, new InHandler {
  override def onPush(): Unit = {
println(s"$name: onPush")
push(out, grab(in))
  }
  override def onUpstreamFinish(): Unit = {
println(s"$name: onUpstreamFinish")
  }
  override def onUpstreamFailure(ex: Throwable): Unit = {
println(s"$name: onUpstreamFailure: ${ex.getMessage}")
super.onUpstreamFailure(ex)
  }
})
setHandler(out, new OutHandler {
  override def onPull(): Unit = {
println(s"$name: onPull")
pull(in)
  }
  override def onDownstreamFinish(): Unit = {
println(s"$name: onDownstreamFinish")
super.onDownstreamFinish()
  }
})
  }
}

object Example {

  implicit val actorSystem = ActorSystem()
  implicit val ec = actorSystem.dispatcher
  implicit val materializer = ActorMaterializer()

  def main(args: Array[String]): Unit = {
val source = Source.empty[Int]
val sink = Sink.last[Int]

val (killSwitch, last) =
  source
.idleTimeout(10.second)
.completionTimeout(20.seconds)
.viaMat(KillSwitches.single)(Keep.right)
.via(new BrokenStage("after"))
.toMat(sink)(Keep.both)
.run()

Thread.sleep(1000)
killSwitch.abort(new RuntimeException("boom!"))

Await.result(last, 25.second)
sys.exit(-1)
  }

} 

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] [akka-http] Issue with rendering when using custom ToEntityMarshaller

2016-10-18 Thread 'Sebastian Voss' via Akka User List



I have defined a custom ToEntityMarshaller for type User. When requesting 
/users it returns an empty JSON array. Only when I remove the implicit def 
userMarshaller it return the correct representation of the stream.


Anybody has a pointer on what is going wrong?


import akka.NotUsed
import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.common.{EntityStreamingSupport, 
JsonEntityStreamingSupport}
import akka.http.scaladsl.model.{HttpEntity, StatusCodes, _}
import akka.http.scaladsl.server.Directives._
import akka.stream.ActorMaterializer
import akka.http.scaladsl.marshallers.sprayjson.SprayJsonSupport._
import akka.http.scaladsl.marshalling.{Marshaller, ToEntityMarshaller, 
ToResponseMarshaller}
import akka.http.scaladsl.model.TransferEncodings.gzip
import akka.http.scaladsl.model.headers.{HttpEncoding, HttpEncodings}
import akka.http.scaladsl.model.ws.{Message, TextMessage}
import akka.stream.scaladsl.{Flow, Source}
import akka.util.ByteString
import spray.json.DefaultJsonProtocol
import spray.json.DefaultJsonProtocol._

import scala.concurrent.Future
import scala.io.StdIn
import scala.util.Random

final case class User(name: String, id: String)

trait UserProtocol extends DefaultJsonProtocol {

  import spray.json._

  implicit val userFormat = jsonFormat2(User)

  val `vnd.example.api.v1+json` =
MediaType.applicationWithFixedCharset("vnd.example.api.v1+json", 
HttpCharsets.`UTF-8`)

  implicit def userMarshaller: ToEntityMarshaller[User] = Marshaller.oneOf(
Marshaller.withFixedContentType(`vnd.example.api.v1+json`) { organisation =>
  HttpEntity(`vnd.example.api.v1+json`, organisation.toJson.compactPrint)
})
}

object ApiServer extends App with UserProtocol {
  implicit val system = ActorSystem("api")
  implicit val materializer = ActorMaterializer()
  implicit val executionContext = system.dispatcher

  implicit val jsonStreamingSupport: JsonEntityStreamingSupport = 
EntityStreamingSupport.json()
.withParallelMarshalling(parallelism = 10, unordered = false)

  // (fake) async database query api
  def dummyUser(id: String) = User(s"User $id", id.toString)

  def fetchUsers(): Source[User, NotUsed] = Source.fromIterator(() => 
Iterator.fill(1) {
val id = Random.nextInt()
dummyUser(id.toString)
  })

  val route =
pathPrefix("users") {
get {
  complete(fetchUsers())
}
}

  val bindingFuture = Http().bindAndHandle(route, "localhost", 8080)

  println(s"Server online at http://localhost:8080/\nPress RETURN to stop...")
  StdIn.readLine()
  bindingFuture.flatMap(_.unbind()).onComplete(_ => system.terminate())
}

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-stream] Problems with the shape creation

2016-10-18 Thread Sergey Sopin

Hi, Rafał! 

Thanks a lot! You gave me everything I need :) I was looking 
for AmorphousShape!

Thanks again, I will not be inventing a wheel anymore!

Regards,
Sergey


вторник, 18 октября 2016 г., 18:34:22 UTC+3 пользователь Rafał Krzewski 
написал:
>
> It's not clear to me, what are you trying to accomplish. It looks like you 
> are trying to implement AmorphousShape (ie. arbitrary number of open inlets 
> and outlets) on your own, and then a specific variant of it, that has all 
> inlets sharing the same type, and all outlets sharing another type. The 
> "Fan" fragment in the names you used is a bit misleading, since in Akka 
> Stream's own usage of it names like FanIn / FanOut shape mean that such 
> grap has many inlets and single outlet / single inlet many outlets. The 
> analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
> many blades :) I am wondering what use case you have in mind for your 
> AmorphousShape because the graphs that can be materialized and executed 
> must ultimately have a ClosedShape. You could use such multi-outlet graphs 
> for reusing pieces of functionality, but anything more complex than a 
> BidiShape  seems  rather unwieldy to me.
>
> My understanding is that Graph's shape should not interfere with message 
> flow, because it's just a canvas with contact points on the perimeter. What 
> matters are the components that you plug into it. Akka just makes sure that 
> you don't leave any of the contact points dangling. This makes me think 
> that the problems with messages getting "stuck" was caused somewhere other 
> than graph shape construction site.
>
> Have you tried inserting probes alon the lines of Flow.alsoTo(Sink.foreach(_ 
> => println("beep!"))) (shooting from the hip here, apologies if it does 
> not compile straight away) into your graph? That could help you locate 
> where the messages are stuck / discarded.
>
> Cheers,
> Rafał
>
> W dniu poniedziałek, 17 października 2016 20:22:43 UTC+2 użytkownik Sergey 
> Sopin napisał:
>>
>> Hi,
>>
>> I am trying to create my own akka streams shape with several Inlets and 
>> Outlets. I have written following code: 
>>
>> package kernel.modeller.workers.streamFinder.generic
>>
>> import akka.stream.{Shape, Outlet, Inlet}
>> import scala.annotation.unchecked.uncheckedVariance
>> import scala.collection.immutable
>>
>> object FanShape {
>>   sealed trait Init[_] {
>> def inlets: immutable.Seq[Inlet[_]]
>> def outlets: immutable.Seq[Outlet[_]]
>> def name: String
>>   }
>>   final case class Name[_](override val name: String) extends Init[Any] {
>> override def inlets: immutable.Seq[Inlet[_]] = Nil
>> override def outlets: immutable.Seq[Outlet[_]] = Nil
>>   }
>>   final case class Ports[_](override val inlets: immutable.Seq[Inlet[_]], 
>> override val outlets: immutable.Seq[Outlet[_]]) extends Init[Any] {
>> override def name: String = "FanShape"
>>   }
>> }
>>
>> abstract class FanShape[_] private (_in: Iterator[Inlet[_]], _out: 
>> Iterator[Outlet[_]], _name: String) extends Shape {
>>   
>>   import FanShape._
>>
>>   def this(init: FanShape.Init[_]) = this(init.inlets.iterator, 
>> init.outlets.iterator, init.name)
>>
>>   final override def outlets: immutable.Seq[Outlet[_]] = _outlets
>>   final override def inlets: immutable.Seq[Inlet[_]] = _inlets
>>
>>   private var _outlets: Vector[Outlet[_]] = Vector.empty
>>   private var _inlets: Vector[Inlet[_]] = Vector.empty
>>
>>   protected def newOutlet[T](name: String): Outlet[T] = {
>> val p = if (_out.hasNext) _out.next().asInstanceOf[Outlet[T]] else 
>> Outlet[T](s"${_name}.$name")
>> _outlets :+= p
>> p
>>   }
>>
>>   protected def newInlet[T](name: String): Inlet[T] = {
>> val p = if (_in.hasNext) _in.next().asInstanceOf[Inlet[T]] else 
>> Inlet[T](s"${_name}.$name")
>> _inlets :+= p
>> p
>>   }
>>
>>   protected def construct(init: Init[_]): FanShape[_]
>>
>>   def deepCopy(): FanShape[_] = construct(Ports(inlets.map(_.carbonCopy()), 
>> outlets.map(_.carbonCopy(
>>   final def copyFromPorts(inlets: immutable.Seq[Inlet[_]], outlets: 
>> immutable.Seq[Outlet[_]]): FanShape[_] = {
>> require(outlets.size == _outlets.size, s"proposed outlets 
>> [${outlets.mkString(", ")}] do not fit FanShape")
>> require(inlets.size == _inlets.size, s"proposed inlects 
>> [${inlets.mkString(", ")}] do not fit FanShape")
>> construct(Ports(inlets, outlets))
>>   }
>> }
>>
>> object UniformFanShape {
>>   def apply[I, O](inlets: Array[Inlet[I]], outlets: Outlet[O]*): 
>> UniformFanShape[I, O] =
>> new UniformFanShape(inlets.size, outlets.size, 
>> FanShape.Ports(inlets.toList, outlets.toList))
>> }
>>
>> class UniformFanShape[-I, +O](n: Int, m: Int, _init: FanShape.Init[_]) 
>> extends FanShape(_init) {
>>   def this(n: Int, m: Int) = this (n, m, FanShape.Name("UniformFan"))
>>   def this(n: Int, m: Int, name: String) = this(n, m, FanShape.Name(name))
>>   def this(inlets: Array[Inlet[I]], outlets:

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

2016-10-18 Thread Konrad Malawski

And fixed:
https://github.com/akka/akka-http/commit/66adf848b57abdf6803b5713e1787fd23c00ccdb


-- 
Konrad 'ktoso’ Malawski
Akka  @ Lightbend 
java.pl / geecon.org / krakowscala.pl / lambdakrk.pl /
sckrk.com

On 18 October 2016 at 19:44:07, Eric Swenson (e...@swenson.org) wrote:

I thought as much, but the documentation you just posted here:
http://doc.akka.io/docs/akka-http/current/scala/http/introduction.html still
says:

Akka HTTP is provided in a separate jar file, to use it make sure to
include the following dependency:

"com.typesafe.akka" %% "akka-http-experimental" % "3.0.0-RC1"

— Eric

On Oct 18, 2016, at 10:42, Konrad Malawski 
wrote:

Yes, that's what all the fuss is about ;-)
In fact, in RC it's already removed:
http://search.maven.org/#artifactdetails%7Ccom.typesafe.akka%7Cakka-http%7C3.0.0-RC1%7Cjar

For people not tracking this in detail: please note that all other modules
other than "the DSL" have been stable for a long time already.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 18 October 2016 at 19:41:18, Eric Swenson (e...@swenson.org) wrote:

Congratulations!  Is the plan to remove the "experimental" from
akka-http-experimental when this moves from RC to final?  -- Eric

On Monday, October 17, 2016 at 3:22:17 PM UTC-7, Konrad 'ktoso' Malawski
wrote:
>
> Dear hakkers,
> We are proud to announce the first Release Candidate of the Akka HTTP's
> "fully stable" release–the only missing, bit was the Routing DSLs, which we
> now deem stable enough to support for an extended period of time.
>
> This release marks the first of the 3.0.0 series of this project and
> signifies a large step in terms of confidence in the library, as well as
> the move of Akka HTTP into its own repository. From now on Akka HTTP will
> be versioned separately from Akka “core”. This has been discussed at large
> with the community on akka-meta , and
> the akka-http  repositories on
> github. Thank you very much for your input!
>
> For more background why this move, please read “Akka HTTP - stable,
> growing and tons of opportunity
> ” on akka-meta. While
> preparing In the meantime we have delivered a Proof-of-Concept of HTTP/2
> for Akka HTTP and plan to continue this work later this year–community help
> is very much welcome on this front as well.
>
> The documentation from now on will be available here:
>
> Some noteworthy changes in the *3.0.0-RC1* (since it's move out from
> 2.4.11) release are:
>
>
>- New lightbend/paradox powered documentation
>-
>   - This will allow us to aggregate it together with Akka and other
>   documentation, as well as link more easily to ScalaDoc pages
>   - Akka HTTP documentation will from now on live here:
>   http://doc.akka.io/docs/akka-http/current/index.html
>   
>   - We’ll work on a better theme for it very soon.
>   - Multipart is now correctly Binary MediaType (instead of
>WithOpenCharset) #398 
>- A new designated mailing-list and page for any critical security
>issues that might come up has been created:
>http://doc.akka.io/docs/akka-http/current/security.html
>
>-
>   - Please follow the linked mailing list if you have production Akka
>   systems, so you’ll be the first to know in case a security issue is 
> found
>   and fixed in Akka.
>
>
> The plan regarding releasing a stable 3.0.0 is to wait a little bit for
> community feedback on the release candidates, and call a stable one no
> longer than a few weeks from now. We’re eagerly awaiting your feedback and
> can’t wait to ship the stable version of all of Akka HTTP’s modules!
>
> Credits
>
> A total 15 issues were closed since 2.4.11, most of the work was moving
> source code, documentation and issues to their new places.
>
> The complete list of closed issues can be found on the 3.0.0-RC1
>  milestone on
> github.
>
> For this release we had the help of 14 committers – thank you!
>
> A special thanks to Jonas Fonseca  who did a
> tremendously awesome job at migrating all the docs from sphinx
> (restructuredtext) to paradox (markdown), contributing features that the
> Akka docs needed to upstream Paradox–thanks a lot!
>
> Credits:
>
> commits added removed
>
>   10   22489   24696 Jonas Fonseca
>
>   101927 256 Johannes Rudolph
>
>   10 849 412 Konrad Malawski
>
>4 448 136 Robert Budźko
>
>2  37  37 Bernard Leach
>
>2 107   7 Richard Imaoka
>
>2  26  24 Jakub Kozłowski
>
>1 145 101 Jan @gosubpl
>
>1 108 114 Derek Wya

[akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

2016-10-18 Thread Eric Swenson

Congratulations!  Is the plan to remove the "experimental" from 
akka-http-experimental when this moves from RC to final?  -- Eric

On Monday, October 17, 2016 at 3:22:17 PM UTC-7, Konrad 'ktoso' Malawski 
wrote:
>
> Dear hakkers,
>
> We are proud to announce the first Release Candidate of the Akka HTTP's 
> "fully stable" release–the only missing, bit was the Routing DSLs, which we 
> now deem stable enough to support for an extended period of time.
>
>
> This release marks the first of the 3.0.0 series of this project and 
> signifies a large step in terms of confidence in the library, as well as 
> the move of Akka HTTP into its own repository. From now on Akka HTTP will 
> be versioned separately from Akka “core”. This has been discussed at large 
> with the community on akka-meta , and 
> the akka-http  repositories on 
> github. Thank you very much for your input!
>
> For more background why this move, please read “Akka HTTP - stable, 
> growing and tons of opportunity 
> ” on akka-meta. While 
> preparing In the meantime we have delivered a Proof-of-Concept of HTTP/2 
> for Akka HTTP and plan to continue this work later this year–community help 
> is very much welcome on this front as well.
>
> The documentation from now on will be available here: 
>
> Some noteworthy changes in the *3.0.0-RC1* (since it's move out from 
> 2.4.11) release are:
>
>
>- 
>
>New lightbend/paradox powered documentation
>- 
>   
>   This will allow us to aggregate it together with Akka and other 
>   documentation, as well as link more easily to ScalaDoc pages
>   - 
>   
>   Akka HTTP documentation will from now on live here: 
>   http://doc.akka.io/docs/akka-http/current/index.html
>   - 
>   
>   We’ll work on a better theme for it very soon.
>   - 
>
>Multipart is now correctly Binary MediaType (instead of 
>WithOpenCharset) #398 
>- 
>
>A new designated mailing-list and page for any critical security 
>issues that might come up has been created: 
>http://doc.akka.io/docs/akka-http/current/security.html 
>- 
>   
>   Please follow the linked mailing list if you have production Akka 
>   systems, so you’ll be the first to know in case a security issue is 
> found 
>   and fixed in Akka.
>   
>
> The plan regarding releasing a stable 3.0.0 is to wait a little bit for 
> community feedback on the release candidates, and call a stable one no 
> longer than a few weeks from now. We’re eagerly awaiting your feedback and 
> can’t wait to ship the stable version of all of Akka HTTP’s modules!
>
> Credits
>
> A total 15 issues were closed since 2.4.11, most of the work was moving 
> source code, documentation and issues to their new places.
>
> The complete list of closed issues can be found on the 3.0.0-RC1 
>  milestone on 
> github.
>
> For this release we had the help of 14 committers – thank you!
>
> A special thanks to Jonas Fonseca  who did a 
> tremendously awesome job at migrating all the docs from sphinx 
> (restructuredtext) to paradox (markdown), contributing features that the 
> Akka docs needed to upstream Paradox–thanks a lot!
>
> Credits:
>
> commits added removed
>
>   10   22489   24696 Jonas Fonseca
>
>   101927 256 Johannes Rudolph
>
>   10 849 412 Konrad Malawski
>
>4 448 136 Robert Budźko
>
>2  37  37 Bernard Leach
>
>2 107   7 Richard Imaoka
>
>2  26  24 Jakub Kozłowski
>
>1 145 101 Jan @gosubpl
>
>1 108 114 Derek Wyatt
>
>1  45  33 Wojciech Langiewicz
>
>1  49   0 @2beaucoup
>
>1   6   6 Markus Hauck
>
>1   1   1 Ian Forsey
>
>1   1   1 Johan Andrén
>
>
> Happy hakking!
>
> – The Akka Team
>

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

2016-10-18 Thread Konrad Malawski

Thanks for noticing, that's bug - fixing it right away.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 18 October 2016 at 19:44:03, Eric Swenson (e...@swenson.org) wrote:

I thought as much, but the documentation you just posted here:
http://doc.akka.io/docs/akka-http/current/scala/http/introduction.html still
says:

Akka HTTP is provided in a separate jar file, to use it make sure to
include the following dependency:

"com.typesafe.akka" %% "akka-http-experimental" % "3.0.0-RC1"

— Eric

On Oct 18, 2016, at 10:42, Konrad Malawski 
wrote:

Yes, that's what all the fuss is about ;-)
In fact, in RC it's already removed:
http://search.maven.org/#artifactdetails%7Ccom.typesafe.akka%7Cakka-http%7C3.0.0-RC1%7Cjar

For people not tracking this in detail: please note that all other modules
other than "the DSL" have been stable for a long time already.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 18 October 2016 at 19:41:18, Eric Swenson (e...@swenson.org) wrote:

Congratulations!  Is the plan to remove the "experimental" from
akka-http-experimental when this moves from RC to final?  -- Eric

On Monday, October 17, 2016 at 3:22:17 PM UTC-7, Konrad 'ktoso' Malawski
wrote:
>
> Dear hakkers,
> We are proud to announce the first Release Candidate of the Akka HTTP's
> "fully stable" release–the only missing, bit was the Routing DSLs, which we
> now deem stable enough to support for an extended period of time.
>
> This release marks the first of the 3.0.0 series of this project and
> signifies a large step in terms of confidence in the library, as well as
> the move of Akka HTTP into its own repository. From now on Akka HTTP will
> be versioned separately from Akka “core”. This has been discussed at large
> with the community on akka-meta , and
> the akka-http  repositories on
> github. Thank you very much for your input!
>
> For more background why this move, please read “Akka HTTP - stable,
> growing and tons of opportunity
> ” on akka-meta. While
> preparing In the meantime we have delivered a Proof-of-Concept of HTTP/2
> for Akka HTTP and plan to continue this work later this year–community help
> is very much welcome on this front as well.
>
> The documentation from now on will be available here:
>
> Some noteworthy changes in the *3.0.0-RC1* (since it's move out from
> 2.4.11) release are:
>
>
>- New lightbend/paradox powered documentation
>-
>   - This will allow us to aggregate it together with Akka and other
>   documentation, as well as link more easily to ScalaDoc pages
>   - Akka HTTP documentation will from now on live here:
>   http://doc.akka.io/docs/akka-http/current/index.html
>   
>   - We’ll work on a better theme for it very soon.
>   - Multipart is now correctly Binary MediaType (instead of
>WithOpenCharset) #398 
>- A new designated mailing-list and page for any critical security
>issues that might come up has been created:
>http://doc.akka.io/docs/akka-http/current/security.html
>
>-
>   - Please follow the linked mailing list if you have production Akka
>   systems, so you’ll be the first to know in case a security issue is 
> found
>   and fixed in Akka.
>
>
> The plan regarding releasing a stable 3.0.0 is to wait a little bit for
> community feedback on the release candidates, and call a stable one no
> longer than a few weeks from now. We’re eagerly awaiting your feedback and
> can’t wait to ship the stable version of all of Akka HTTP’s modules!
>
> Credits
>
> A total 15 issues were closed since 2.4.11, most of the work was moving
> source code, documentation and issues to their new places.
>
> The complete list of closed issues can be found on the 3.0.0-RC1
>  milestone on
> github.
>
> For this release we had the help of 14 committers – thank you!
>
> A special thanks to Jonas Fonseca  who did a
> tremendously awesome job at migrating all the docs from sphinx
> (restructuredtext) to paradox (markdown), contributing features that the
> Akka docs needed to upstream Paradox–thanks a lot!
>
> Credits:
>
> commits added removed
>
>   10   22489   24696 Jonas Fonseca
>
>   101927 256 Johannes Rudolph
>
>   10 849 412 Konrad Malawski
>
>4 448 136 Robert Budźko
>
>2  37  37 Bernard Leach
>
>2 107   7 Richard Imaoka
>
>2  26  24 Jakub Kozłowski
>
>1 145 101 Jan @gosubpl
>
>1 108 114 Derek Wyatt
>
>1  45  33 Wojciech Langiewicz
>
>1  49   0 @2beaucoup
>
>1   6   6 Markus Hauc

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

2016-10-18 Thread Eric Swenson

I thought as much, but the documentation you just posted here:  
http://doc.akka.io/docs/akka-http/current/scala/http/introduction.html 
 still 
says:

Akka HTTP is provided in a separate jar file, to use it make sure to include 
the following dependency:

"com.typesafe.akka" %% "akka-http-experimental" % "3.0.0-RC1" 
— Eric

> On Oct 18, 2016, at 10:42, Konrad Malawski  
> wrote:
> 
> Yes, that's what all the fuss is about ;-)
> In fact, in RC it's already removed: 
> http://search.maven.org/#artifactdetails%7Ccom.typesafe.akka%7Cakka-http%7C3.0.0-RC1%7Cjar
>  
> 
> 
> For people not tracking this in detail: please note that all other modules 
> other than "the DSL" have been stable for a long time already.
> 
> -- 
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
> On 18 October 2016 at 19:41:18, Eric Swenson (e...@swenson.org 
> ) wrote:
> 
>> Congratulations!  Is the plan to remove the "experimental" from 
>> akka-http-experimental when this moves from RC to final?  -- Eric
>> 
>> On Monday, October 17, 2016 at 3:22:17 PM UTC-7, Konrad 'ktoso' Malawski 
>> wrote:
>> 
>> Dear hakkers,
>> 
>> We are proud to announce the first Release Candidate of the Akka
>> HTTP's "fully stable" release–the only missing, bit was the Routing
>> DSLs, which we now deem stable enough to support for an extended
>> period of time.
>> 
>> 
>> 
>> This release marks the first of the 3.0.0 series of this project
>> and signifies a large step in terms of confidence in the library,
>> as well as the move of Akka HTTP into its own repository. From now
>> on Akka HTTP will be versioned separately from Akka “core”. This
>> has been discussed at large with the community on 
>> akka-meta ,
>> and the 
>> akka-http  
>> repositories on github. Thank you very much for your
>> input!
>> 
>> 
>> For more background why this move, please read “Akka
>> HTTP - stable, growing and tons of
>> opportunity ”
>> on akka-meta. While preparing In the meantime we have delivered a
>> Proof-of-Concept of HTTP/2 for Akka HTTP and plan to continue this
>> work later this year–community help is very much welcome on this
>> front as well.
>> 
>> 
>> The documentation from now on will be available here:
>> 
>> 
>> Some noteworthy changes in the 
>> 3.0.0-RC1 
>> (since it's move out from 2.4.11) release are:
>> 
>> 
>> New lightbend/paradox powered documentation
>> 
>> This will allow us to aggregate it together with Akka and other
>> documentation, as well as link more easily to ScalaDoc
>> pages
>> 
>> Akka HTTP documentation will from now on live here: 
>> http://doc.akka.io/docs/akka-http/current/index.html 
>> 
>> 
>> We’ll work on a better theme for it very soon.
>> 
>> Multipart 
>> is now correctly Binary MediaType (instead of
>> WithOpenCharset) 
>> #398 
>> 
>> A new designated mailing-list and page for any critical security
>> issues that might come up has been created: 
>> http://doc.akka.io/docs/akka-http/current/security.html 
>> 
>> 
>> Please follow the linked mailing list if you have production Akka
>> systems, so you’ll be the first to know in case a security issue is
>> found and fixed in Akka.
>> 
>> 
>> The plan regarding releasing a stable 3.0.0 is to wait a little bit
>> for community feedback on the release candidates, and call a stable
>> one no longer than a few weeks from now. We’re eagerly awaiting
>> your feedback and can’t wait to ship the stable version of all of
>> Akka HTTP’s modules!
>> 
>> 
>> Credits
>> 
>> A total 15 issues were closed since 2.4.11, most of the work was
>> moving source code, documentation and issues to their new
>> places.
>> 
>> 
>> 
>> The complete list of closed issues can be found on the 
>> 3.0.0-RC1  
>> milestone on github.
>> 
>> 
>> 
>> For this release we had the help of 14 committers – thank
>> you!
>> 
>> 
>> A special thanks to 
>> Jonas Fonseca  
>> who did a tremendously awesome job at migrating all the docs from
>> sphinx (restructuredtext) to paradox (markdown), contributing
>> features that the Akka docs needed to upstream Paradox–thanks a
>> lot!
>> 
>> 
>> 
>> Credits:
>> 
>> 
>> commits added removed
>> 
>> 
>>   10   22489   24696 Jonas
>> Fonseca
>> 
>> 
>>   101927 256
>> Johannes Rudolph
>> 
>> 
>>   10 849
>> 412 Konrad Malawski
>> 
>> 
>>4 448
>> 136 Robert Budźko
>> 
>> 
>>2  37
>>  37 Bernard Leach
>> 
>> 
>>2 107
>>   7 Richard Imaoka
>> 
>> 
>>2

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

2016-10-18 Thread Konrad Malawski

Yes, that's what all the fuss is about ;-)
In fact, in RC it's already removed:
http://search.maven.org/#artifactdetails%7Ccom.typesafe.akka%7Cakka-http%7C3.0.0-RC1%7Cjar

For people not tracking this in detail: please note that all other modules
other than "the DSL" have been stable for a long time already.

-- 
Konrad `ktoso` Malawski
Akka  @ Lightbend 

On 18 October 2016 at 19:41:18, Eric Swenson (e...@swenson.org) wrote:

Congratulations!  Is the plan to remove the "experimental" from
akka-http-experimental when this moves from RC to final?  -- Eric

On Monday, October 17, 2016 at 3:22:17 PM UTC-7, Konrad 'ktoso' Malawski
wrote:
>
> Dear hakkers,
>
> We are proud to announce the first Release Candidate of the Akka HTTP's
> "fully stable" release–the only missing, bit was the Routing DSLs, which we
> now deem stable enough to support for an extended period of time.
>
>
> This release marks the first of the 3.0.0 series of this project and
> signifies a large step in terms of confidence in the library, as well as
> the move of Akka HTTP into its own repository. From now on Akka HTTP will
> be versioned separately from Akka “core”. This has been discussed at large
> with the community on akka-meta , and
> the akka-http  repositories on
> github. Thank you very much for your input!
>
> For more background why this move, please read “Akka HTTP - stable,
> growing and tons of opportunity
> ” on akka-meta. While
> preparing In the meantime we have delivered a Proof-of-Concept of HTTP/2
> for Akka HTTP and plan to continue this work later this year–community help
> is very much welcome on this front as well.
>
> The documentation from now on will be available here:
>
> Some noteworthy changes in the *3.0.0-RC1* (since it's move out from
> 2.4.11) release are:
>
>
>-
>
>New lightbend/paradox powered documentation
>-
>   -
>
>   This will allow us to aggregate it together with Akka and other
>   documentation, as well as link more easily to ScalaDoc pages
>   -
>
>   Akka HTTP documentation will from now on live here:
>   http://doc.akka.io/docs/akka-http/current/index.html
>   
>   -
>
>   We’ll work on a better theme for it very soon.
>   -
>
>Multipart is now correctly Binary MediaType (instead of
>WithOpenCharset) #398 
>-
>
>A new designated mailing-list and page for any critical security
>issues that might come up has been created:
>http://doc.akka.io/docs/akka-http/current/security.html
>
>-
>   -
>
>   Please follow the linked mailing list if you have production Akka
>   systems, so you’ll be the first to know in case a security issue is 
> found
>   and fixed in Akka.
>
>
> The plan regarding releasing a stable 3.0.0 is to wait a little bit for
> community feedback on the release candidates, and call a stable one no
> longer than a few weeks from now. We’re eagerly awaiting your feedback and
> can’t wait to ship the stable version of all of Akka HTTP’s modules!
>
> Credits
>
> A total 15 issues were closed since 2.4.11, most of the work was moving
> source code, documentation and issues to their new places.
>
> The complete list of closed issues can be found on the 3.0.0-RC1
>  milestone on
> github.
>
> For this release we had the help of 14 committers – thank you!
>
> A special thanks to Jonas Fonseca  who did a
> tremendously awesome job at migrating all the docs from sphinx
> (restructuredtext) to paradox (markdown), contributing features that the
> Akka docs needed to upstream Paradox–thanks a lot!
>
> Credits:
>
> commits added removed
>
>   10   22489   24696 Jonas Fonseca
>
>   101927 256 Johannes Rudolph
>
>   10 849 412 Konrad Malawski
>
>4 448 136 Robert Budźko
>
>2  37  37 Bernard Leach
>
>2 107   7 Richard Imaoka
>
>2  26  24 Jakub Kozłowski
>
>1 145 101 Jan @gosubpl
>
>1 108 114 Derek Wyatt
>
>1  45  33 Wojciech Langiewicz
>
>1  49   0 @2beaucoup
>
>1   6   6 Markus Hauck
>
>1   1   1 Ian Forsey
>
>1   1   1 Johan Andrén
>
>
> Happy hakking!
>
> – The Akka Team
>
--
>> 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+unsub

[akka-user] Re: [akka-stream] Problems with the shape creation

2016-10-18 Thread Rafał Krzewski

It's not clear to me, what are you trying to accomplish. It looks like you 
are trying to implement AmorphousShape (ie. arbitrary number of open inlets 
and outlets) on your own, and then a specific variant of it, that has all 
inlets sharing the same type, and all outlets sharing another type. The 
"Fan" fragment in the names you used is a bit misleading, since in Akka 
Stream's own usage of it names like FanIn / FanOut shape mean that such 
grap has many inlets and single outlet / single inlet many outlets. The 
analogy is to a Chinese-style hand held fan, rather than ceiling fan with 
many blades :) I am wondering what use case you have in mind for your 
AmorphousShape because the graphs that can be materialized and executed 
must ultimately have a ClosedShape. You could use such multi-outlet graphs 
for reusing pieces of functionality, but anything more complex than a 
BidiShape  seems  rather unwieldy to me.

My understanding is that Graph's shape should not interfere with message 
flow, because it's just a canvas with contact points on the perimeter. What 
matters are the components that you plug into it. Akka just makes sure that 
you don't leave any of the contact points dangling. This makes me think 
that the problems with messages getting "stuck" was caused somewhere other 
than graph shape construction site.

Have you tried inserting probes alon the lines of Flow.alsoTo(Sink.foreach(_ 
=> println("beep!"))) (shooting from the hip here, apologies if it does not 
compile straight away) into your graph? That could help you locate where 
the messages are stuck / discarded.

Cheers,
Rafał

W dniu poniedziałek, 17 października 2016 20:22:43 UTC+2 użytkownik Sergey 
Sopin napisał:
>
> Hi,
>
> I am trying to create my own akka streams shape with several Inlets and 
> Outlets. I have written following code: 
>
> package kernel.modeller.workers.streamFinder.generic
>
> import akka.stream.{Shape, Outlet, Inlet}
> import scala.annotation.unchecked.uncheckedVariance
> import scala.collection.immutable
>
> object FanShape {
>   sealed trait Init[_] {
> def inlets: immutable.Seq[Inlet[_]]
> def outlets: immutable.Seq[Outlet[_]]
> def name: String
>   }
>   final case class Name[_](override val name: String) extends Init[Any] {
> override def inlets: immutable.Seq[Inlet[_]] = Nil
> override def outlets: immutable.Seq[Outlet[_]] = Nil
>   }
>   final case class Ports[_](override val inlets: immutable.Seq[Inlet[_]], 
> override val outlets: immutable.Seq[Outlet[_]]) extends Init[Any] {
> override def name: String = "FanShape"
>   }
> }
>
> abstract class FanShape[_] private (_in: Iterator[Inlet[_]], _out: 
> Iterator[Outlet[_]], _name: String) extends Shape {
>   
>   import FanShape._
>
>   def this(init: FanShape.Init[_]) = this(init.inlets.iterator, 
> init.outlets.iterator, init.name)
>
>   final override def outlets: immutable.Seq[Outlet[_]] = _outlets
>   final override def inlets: immutable.Seq[Inlet[_]] = _inlets
>
>   private var _outlets: Vector[Outlet[_]] = Vector.empty
>   private var _inlets: Vector[Inlet[_]] = Vector.empty
>
>   protected def newOutlet[T](name: String): Outlet[T] = {
> val p = if (_out.hasNext) _out.next().asInstanceOf[Outlet[T]] else 
> Outlet[T](s"${_name}.$name")
> _outlets :+= p
> p
>   }
>
>   protected def newInlet[T](name: String): Inlet[T] = {
> val p = if (_in.hasNext) _in.next().asInstanceOf[Inlet[T]] else 
> Inlet[T](s"${_name}.$name")
> _inlets :+= p
> p
>   }
>
>   protected def construct(init: Init[_]): FanShape[_]
>
>   def deepCopy(): FanShape[_] = construct(Ports(inlets.map(_.carbonCopy()), 
> outlets.map(_.carbonCopy(
>   final def copyFromPorts(inlets: immutable.Seq[Inlet[_]], outlets: 
> immutable.Seq[Outlet[_]]): FanShape[_] = {
> require(outlets.size == _outlets.size, s"proposed outlets 
> [${outlets.mkString(", ")}] do not fit FanShape")
> require(inlets.size == _inlets.size, s"proposed inlects 
> [${inlets.mkString(", ")}] do not fit FanShape")
> construct(Ports(inlets, outlets))
>   }
> }
>
> object UniformFanShape {
>   def apply[I, O](inlets: Array[Inlet[I]], outlets: Outlet[O]*): 
> UniformFanShape[I, O] =
> new UniformFanShape(inlets.size, outlets.size, 
> FanShape.Ports(inlets.toList, outlets.toList))
> }
>
> class UniformFanShape[-I, +O](n: Int, m: Int, _init: FanShape.Init[_]) 
> extends FanShape(_init) {
>   def this(n: Int, m: Int) = this (n, m, FanShape.Name("UniformFan"))
>   def this(n: Int, m: Int, name: String) = this(n, m, FanShape.Name(name))
>   def this(inlets: Array[Inlet[I]], outlets: Array[Outlet[O]]) = 
> this(inlets.size, outlets.size, FanShape.Ports(inlets.toList, outlets.toList))
>   override protected def construct(init: FanShape.Init[_]): FanShape[_] = new 
> UniformFanShape(n, m, init)
>   override def deepCopy(): UniformFanShape[I, O] = 
> super.deepCopy().asInstanceOf[UniformFanShape[I, O]]
>
>   val inArray: Array[Inlet[I @uncheckedVariance]] = Array.tabulate(n

[akka-user] Re: [akka-stream] Detect failure in MergeHub

2016-10-18 Thread Victor

Sure!

https://github.com/akka/akka/issues/21693

Le mardi 18 octobre 2016 14:36:35 UTC+2, johannes...@lightbend.com a écrit :
>
> Hi Victor,
>
> good point. I think the Scaladoc is wrong there. Could you raise an issue 
> at akka/akka?
>
> Johannes
>
> On Tuesday, October 18, 2016 at 2:28:14 PM UTC+2, Victor wrote:
>>
>> Hi,
>>
>> It's written in the ScalaDoc of the *MergeHub.source* method that:
>>
>> If one of the inputs fails the Sink, the Source is failed in turn
>>
>>
>> But, in the MergeHub source code, the *onUpstreamFailure* method only 
>> throw an exception:
>>
>> override def onUpstreamFailure(ex: Throwable): Unit = {
>>   throw new MergeHub.ProducerFailed("Upstream producer failed with 
>> exception, " +
>> "removing from MergeHub now", ex)
>> }
>>
>> So maybe I'm missing something, but why failing an input will fails the 
>> Source?
>> I need the MergeHub to fails when an input fails, but it doesn't seems to 
>> work.
>>
>> Thanks,
>> Victor
>>
>

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-stream] Detect failure in MergeHub

2016-10-18 Thread johannes . rudolph

Hi Victor,

good point. I think the Scaladoc is wrong there. Could you raise an issue 
at akka/akka?

Johannes

On Tuesday, October 18, 2016 at 2:28:14 PM UTC+2, Victor wrote:
>
> Hi,
>
> It's written in the ScalaDoc of the *MergeHub.source* method that:
>
> If one of the inputs fails the Sink, the Source is failed in turn
>
>
> But, in the MergeHub source code, the *onUpstreamFailure* method only 
> throw an exception:
>
> override def onUpstreamFailure(ex: Throwable): Unit = {
>   throw new MergeHub.ProducerFailed("Upstream producer failed with 
> exception, " +
> "removing from MergeHub now", ex)
> }
>
> So maybe I'm missing something, but why failing an input will fails the 
> Source?
> I need the MergeHub to fails when an input fails, but it doesn't seems to 
> work.
>
> Thanks,
> Victor
>

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] [akka-stream] Detect failure in MergeHub

2016-10-18 Thread Victor

Hi,

It's written in the ScalaDoc of the *MergeHub.source* method that:

If one of the inputs fails the Sink, the Source is failed in turn


But, in the MergeHub source code, the *onUpstreamFailure* method only throw 
an exception:

override def onUpstreamFailure(ex: Throwable): Unit = {
  throw new MergeHub.ProducerFailed("Upstream producer failed with 
exception, " +
"removing from MergeHub now", ex)
}

So maybe I'm missing something, but why failing an input will fails the 
Source?
I need the MergeHub to fails when an input fails, but it doesn't seems to 
work.

Thanks,
Victor

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-stream] Problems with the shape creation

2016-10-18 Thread Sergey Sopin

People say that following article may help: 

http://degoes.net/articles/insufficiently-polymorphic 

However, I still don't understand what's wrong with it. Any help will be 
appreciated.
Thanks!

Regards,
Sergey

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: How to correctly close system when websocket is open?

2016-10-18 Thread Andrzej Giniewicz

Hi,

thanks, putting Channel(processing).via(killSwitch.flow) and shutting
it down later worked!

Regards,
Andrzej.

On Tue, Oct 18, 2016 at 1:23 AM, Rafał Krzewski
 wrote:
> Hi,
> just a quick suggestion: mabe a KillSwitch [1] in Channel flow would help?
>
> cheers,
> Rafał
>
> [1]
> http://doc.akka.io/api/akka/2.4/?_ga=1.230565852.1388425308.1467760779#akka.stream.KillSwitch
>
> W dniu poniedziałek, 17 października 2016 21:52:55 UTC+2 użytkownik Andrzej
> Giniewicz napisał:
>>
>> Hello,
>>
>> I'm building a prototype for application that aims to use akka-http and
>> websockets for communication. It mostly works, but on close we get
>> exception:
>>
>> [ERROR] [10/17/2016 19:38:56.104]
>> [my-system-akka.actor.default-dispatcher-10]
>> [akka.actor.ActorSystemImpl(my-system)] WebSocket handler failed with
>> Processor actor
>> [Actor[akka://my-system/user/StreamSupervisor-0/flow-4-0-unknown-operation#1709634420]]
>> terminated abruptly (akka.stream.AbruptTerminationException)
>>
>> We tried many suggestions over the web, including calling
>> Http().shutdownAllConnectionPools() (which ends with success) and unbind
>> (which ends with success as well). Unfortunately it doesn't help - after
>> calling shutdownAllConnectionPools and unbind the websocket is still up (we
>> can send messages and receive answers from it). How to correctly close the
>> system to avoid such issue?
>>
>> This is how (fragments) of how we build the binding (for now this is
>> single client app, so we have single actor to process messages):
>>
>> val processing = system.actorOf(Props[ProcessingActor],
>> "processing-1")
>> val route = get {
>>   pathEndOrSingleSlash {
>> complete {
>> // ...
>> }
>>   } ~ encodeResponse {
>> getFromResourceDirectory("")
>>   } ~ path("ws") {
>> handleWebSocketMessages(Channel(processing))
>>   }
>> }
>> val bindingFuture = Http().bindAndHandle(route, "localhost", port)
>>
>> and then we wait (readLine) after which we close (as I said we have
>> shutdownAllConnectionPools, unbind and terminate). Page contains html and
>> Channel is custom flow.
>>
>> object Channel {
>>   private val bufferSize = 5
>>   def apply(processing: ActorRef)(implicit system: ActorSystem):
>> Flow[WSMessage, WSMessage, _] = Flow.fromGraph(GraphDSL.create(
>>   Source.actorRef[Message](bufferSize=bufferSize,
>> OverflowStrategy.fail)
>> ) { implicit builder => source =>
>>   val sink = Sink.actorRef[SystemCommand](processing, Close)
>>   val actor = builder.materializedValue.map(a => Initialize(a))
>>   val fromSocket = builder.add(Flow[WSMessage].collect {
>> // ...
>>   })
>>   val toSocket = builder.add(Flow[Message].map {
>> // ...
>>   })
>>   val merge = builder.add(Merge[SystemCommand](2))
>>   fromSocket ~> merge.in(0)
>>   actor ~> merge.in(1)
>>   merge ~> sink
>>   source ~> toSocket
>>   FlowShape(fromSocket.in, toSocket.out)
>>   })
>> }
>>
>> Any help would be appreciated - and btw, this was one of first attempts
>> and we got something up and running in just few hours, so even that we have
>> issues with close, we would like to emphatize that we think Akka is great!
>> Andrzej.
>
> --
>>> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.

-- 
>>  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+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: [akka-stream] Problems with the shape creation

[akka-user] Re: Simple beginner questions: Accessing values in flows

[akka-user] Re: [akka-stream] Problems with the shape creation

[akka-user] Re: [akka-stream] Problems with the shape creation

[akka-user] Re: Is back pressure triggered upon exceptions

[akka-user] graph control events propagation

[akka-user] [akka-http] Issue with rendering when using custom ToEntityMarshaller

[akka-user] Re: [akka-stream] Problems with the shape creation

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

[akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

Re: [akka-user] Re: ANNOUNCE: Akka HTTP 3.0.0-RC1

[akka-user] Re: [akka-stream] Problems with the shape creation

[akka-user] Re: [akka-stream] Detect failure in MergeHub

[akka-user] Re: [akka-stream] Detect failure in MergeHub

[akka-user] [akka-stream] Detect failure in MergeHub

[akka-user] Re: [akka-stream] Problems with the shape creation

Re: [akka-user] Re: How to correctly close system when websocket is open?

19 matches

Site Navigation

Mail list logo

Footer information