[akka-user] [akka-http] java completeWith mapping future

Hi, I'm using akka http with Java DSL and I'm trying to handle a get request with an actor and map my actor's response to the HTTP response as follows: private Route getTasksRoute(){ return path("tasks").route(pathEndOrSingleSlash().route(get(this.handleWith( (ctx) ->

[akka-user] Reconnect TCP after connection is closed

Hi, I've been working on a service that connects to a tool called GNIP that streams tweets through a TCP connection. I have two services that independently connect to GNIP and yesterday both of them went simultaneously down. I checked nestat and saw that the tcp connection was gone which made

[akka-user] Re: [akka-http] java completeWith mapping future

Hi Benoit, you should take a look at http://doc.akka.io/docs/akka/snapshot/java/futures.html#Future_is_a_Monad. Mapper should solve your Problem. Cheers André On Wednesday, November 11, 2015 at 12:01:05 PM UTC+1, Benoit Guillon wrote: > > Hi, > > I'm using akka http with Java DSL and I'm

Re: [akka-user] Replacing Remoting Protocol?

Thanks! That's the approach I'll take in my proof-of-technology, then. On Tuesday, November 10, 2015 at 4:27:38 AM UTC-5, drewhk wrote: > > Hi Rob, > > I don't think the Akka remoting protocol is suitable for implementations > over HTTP. There are heartbeats and other periodic messages sent,

Re: [akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

true, a new new-IO would have to be written :) and a lot of libraries to be modified which would not be easy. But the problem with blocking syscalls is true for actors too. And the developer needs to take extra care anyway. Maybe rephrase and say that continuations would make parallel code

[akka-user] Re: [akka-http] An issue with spay-json and collections

It appears this is an Intellij IDEA issue and the code actually compiles and works without the extra implicit that I described above. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html

Re: [akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

useful advice, thanks everyone. I wonder why continuations didn't catch up. continuations "blocking" would be of no issue. I/O and even sleep(x) would be possible with no overhead. On 11/11/15 14:37, Richard Rodseth wrote: Also see

Re: [akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

hmm, I guess it is probably a bigger discussion. Does it matter if the code is async? I think (maybe) this all relates to why typed-actors was deprecated. I can't find the link about the discussion why it was deprecated, anyone has it? I remember seeing something a few months ago. On 11/11/15

Re: [akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

Also see http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management On Tue, Nov 10, 2015 at 2:04 PM, Guido Medina wrote: > I have actors such like *AccountProcessor* and *AccountPersistor*, > AccountPersistor is a child of

Re: [akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

On Wed, Nov 11, 2015 at 4:02 PM, 'Konstantinos Kougios' via Akka User List < akka-user@googlegroups.com> wrote: > useful advice, thanks everyone. > > I wonder why continuations didn't catch up. continuations "blocking" would > be of no issue. I/O and even sleep(x) would be possible with no

Re: [akka-user] Re: code that will block for some time, part of an actor or should I wrap it inside a Feature?

I think that's a matter of taste. Having async code look exactly like sync code means that it's going ot be hard to see in the code whether you're doing something sync or async. On Wed, Nov 11, 2015 at 4:39 PM, 'Konstantinos Kougios' via Akka User List < akka-user@googlegroups.com> wrote: >

Re: [akka-user] [akka-http] An issue with spay-son and collections

Konrad, Thanks for the reply! In fact I have the very same code separation: *object ApiJsonProtocol extends ApiJsonProtocoltrait ApiJsonProtocol extends SprayJsonSupport with DefaultJsonProtocol { implicit val feedFormat = jsonFormat2(Feed) // implicit val feedsWriter =

Re: [akka-user] [akka-http] An issue with spay-son and collections

Usually one would do something like this: trait MyModelJsonProtocol extends DefaultJsonProtocol {   implicit val feedFormat = jsonFormat2(Feed) } object MyModelJsonProtocol extends MyModelJsonProtocol And use it like so: trait MyHelloWorldRoute extends MyModelJsonProtocol = {   val route =

[akka-user] [akka-http] An issue with spay-son and collections

Hi Guys, I'm trying out Akka-http on a small pet project of mine(where I'm gonna use it to implement some REST API) and I've stumbled upon an interesting problem with implicits. So, long story short it appears that I need to add an implicit Json writer for each collection-entity pair that I

[akka-user] Akka cluster sharding exception propagation to the parent actor

Hello, In a multi node cluster sharding scenario if a persistent actor throws an exception, it is not propagating to the Parent Actor supervisor strategy, instead the persistent actor retries for ever, I haven't tried the BackOffSupervisor yet but does it help in propagating the exception to

[akka-user] Immutable message library

I was recently working on a multi-threaded service application using akka actor. It has to send and receive and re-send various instructions as messages, akka's immutable message specs really bothered me. I couldn't find any library coping with this *unchangable* message. In this note I

[akka-user] Supervision: Who just died

The one thing I keep struggling with is the opaqueness of failures in Akka, i.e. that all the conditions at failure time are not available to either the actor or the supervisor. What I just came across was a failure during creation. The supervisor saw it and logged it and I found where it died

[akka-user] Sender reference for RandomPool in a cluster

Hello! I would like to clarify the point of *sender()* reference. In a cluster sometimes I observe some strage effect when an actor A sends a message to some actor B, and actor B sends a message back to actor A using *sender()* - but the actual message is delivered to actor C (the same type

[akka-user] Re: [akka-stream] some questions about error handling

Let's assume that instead of exceptions each flow instead follows this pattern: Flow[Request, Either[Error, Result], Unit]. You could build a custom flow that routes errors to one output and results to the other, then merge all the errors and results and send them to the sink. I've done this

Re: [akka-user] ActorSelection vs ActorRef

Hi Roland, I have a similar question, i do prefer ActorRef since i m able to assign the actor references on startup in the right hierarchy. But if the underlying actor crashes and then restarts(due to the right recovery strategy), then the ActorRef i hold is obsolete, and all messages to it

[akka-user] Re: [akka-stream] some questions about error handling

I'm actually coming right up on this very problem at work myself and I would love to see an example of what you're talking about. (My code follows something like Flow[Request, Try[Result], Unit] but I can transcribe whatever you present). On Wednesday, November 11, 2015 at 3:08:02 PM UTC-5,

[akka-user] Re: [akka-stream] some questions about error handling

This uses our disjunction wrapper type, Or, which is just a wrapper around scalaz's disjunction package object disjunction extends ToEitherOps { type Or[L, R] = \/[L, R] type Bad[L] = -\/[L] type Good[R] = \/-[R] object Bad { def apply[L](left: L) = -\/(left) def unapply[L,