Re: [akka-user] Akka stream out of band data

Hey Roland > On 18 Feb 2018, at 22:45, 'Roland Kuhn' via Akka User List > wrote: > > Yes, we considered it with varying depth on multiple occasions and never > found a satisfactory solution. Since graph stages are free to transform not > only individual elements but also the stream structure

Re: [akka-user] Akka stream out of band data

> On 18 Feb 2018, at 21:10, Viktor Klang wrote: > > How do you deal with M:N ports or X:Y element permutations? No idea. :-) My main question is, has there been any thinking around associating metadata with elements in the past? Thanks. Cheers C -- >> Read the docs: http://

Re: [akka-user] Akka stream element meta data

> On 18 Feb 2018, at 3:18 pm, Christopher Hunt wrote: > > It just occurred to me that compound types might be the way to solve this eg > `new Element with OOB[Span]`. I shall experiment further... and then PR the > Akka stream doco with a section on OOB/instrumentation if t

Re: [akka-user] Akka stream out of band data

> On 18 Feb 2018, at 11:53, Christopher Hunt wrote: > > By way of solution, perhaps this could be achieved similarly to the > materialiser api calls eg viaMat/viaOob. It just occurred to me that compound types might be the way to solve this eg `new Element with OOB[Spa

[akka-user] Akka stream out of band data

Hi there, I’ve been wondering recently if there’s been any thought around carrying out of band data through an Akka Stream in the spirit of network streams: https://en.m.wikipedia.org/wiki/Out-of-band_data One use case is for carrying Open Tracing Spans with elements without polluting stream

Re: [akka-user] Akka Persistence and avoiding var in favor of context.become

> On 13 Feb 2018, at 20:50, Christopher Hunt wrote: > > While receiveRecover is executing though, I presume that I’m going to have to > store the current state in a var…? Here’s what I’ve started with: > override def receiveRecover: Receive = { > case e: Event

Re: [akka-user] Akka Persistence and avoiding var in favor of context.become

> On 13 Feb 2018, at 8:26 pm, Patrik Nordwall wrote: > > You have to do the right become transitions in the replay of the events, and > when consuming snapshots. Especially the latter is very easy to get wrong. > Thanks Patrik, that shouldn’t be an issue for my use case. My states are unauth

Re: [akka-user] Akka Persistence and avoiding var in favor of context.become

On Friday, 15 September 2017 16:41:42 UTC+10, Konrad Malawski wrote: > > I would recommend avoiding become with PersistentActors in general, it > gets very complex. > The Akka doc (1) suggests that the use of become should be fine. Are you able to expand on the complexity statement above? I'd a

Re: [akka-user] Akka, Akka Typed and dead code elimination

Hi Roland, > On 3 Feb 2018, at 5:56 pm, Roland Kuhn wrote: > > I agree on the tendency. In the case of Akka there are two reasons for using > reflection and neither of them is caused by a lack of static types: > extensibility and remote marshaling. A new implementation could remove > configur

Re: [akka-user] Akka, Akka Typed and dead code elimination

Hi Roland, > On 3 Feb 2018, at 5:16 pm, Roland Kuhn wrote: > > could you elaborate on how exactly Akka Typed is expected to help with your > use-case? The only difference I can see is that the new (and currently > removed) implementation contained fewer extension points, but that is > unrelat

Re: [akka-user] Akka, Akka Typed and dead code elimination

he core set of excludes, that sounds useful. We in > the time are unlikely to have the time to maintain or help much with this > though. > > -- > Cheers, > Konrad 'ktoso <http://kto.so/>' Malawski > Akka <http://akka.io/> @ Lightbend <http:/

[akka-user] Akka, Akka Typed and dead code elimination

Hi everyone, I’ve got a requirement to run services on machines with limited resources, memory in particular, but also disk (disk == memory for my use case!) In addition, I wish to reduce the attack surface area of a service by eliminating code that isn’t used. I’d therefore like to take a uni

Re: [akka-user] Kafka journal

Replying to an old thread. I’m interested to learn of any advancements in thinking on this topic over the past 3+ years. ‪If I have Kafka and want CQRS, how much do I need #akka-persistence? I’m starting to wonder if I need it at all and just treating CQRS as the architectural pattern that it

Re: [akka-user] Supporting transient states using Akka FSM

gt; Home: heikoseeberger.de > Twitter: @hseeberger > Public key: keybase.io/hseeberger > > > >> Am 22.12.2017 um 09:15 schrieb Christopher Hunt : >> >> Hey there, >> >> I've recently come across a situation with transient FSM states that I'd >

[akka-user] Supporting transient states using Akka FSM

Hey there, I've recently come across a situation with transient FSM states that I'd like to model in Akka FSM. I'm wondering if there's a better way than below in terms of expressing transient states: onTransition { case A -> B goto(C) } when(B) { case _ => log.error("we should never

Re: [akka-user] Akka Unix Domain Socket support interest given code written

As a follow-up in order to close off this thread, I've now submitted a PR for Alpakka: https://github.com/akka/alpakka/pull/623 -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >>

Re: [akka-user] Overriding onUpstreamFinish behaviour for FlowOps

As a follow-up, I’ve implemented a custom half close stage after having a good night’s sleep and thinking about it. :-) First, the simple half-close custom stage: https://github.com/huntc/landlord/pull/14/files#diff-b745088184322d5d8e53de44d17b9ca6R262

Re: [akka-user] Overriding onUpstreamFinish behaviour for FlowOps

tml?language=scala#delayed-restarts-with-a-backoff-stage > other than supervision which isn’t generic. > > > > -- > Cheers, > Konrad 'ktoso' Malawski > Akka @ Lightbend > >> On November 27, 2017 at 14:14:33, Christopher Hunt (hunt...@gmail.com) wrote:

Re: [akka-user] Overriding onUpstreamFinish behaviour for FlowOps

> On 27 Nov 2017, at 4:17 pm, Konrad “ktoso” Malawski > wrote: > > What kind of Flow exactly. What does it do? I’m implementing Unix Domain Sockets and the following interface borrowed from Tcp: def outgoingConnection( remoteAddress: UnixSocketAddress, localAddress: Option[UnixSocketAddre

[akka-user] Overriding onUpstreamFinish behaviour for FlowOps

Hi there. I've got a requirement for a flow to keep going when its upstream input completes/fails. I could write a custom flow stage and override onUpstreamFinish, but I was wondering if there were a means to express this just using the FlowOps API. FlowOps.detach got me excited, but that isn't

Re: [akka-user] Akka Unix Domain Socket support interest given code written

> On 25 Nov 2017, at 01:02, Martynas Mickevičius > wrote: > > this looks really cool! I think extracting it to a separate module for > Alpakka is a great idea as well. Thanks! I’ll finish my PR for Landlord and then migrate it. Should be started within a week. -- >> Read

[akka-user] Akka Unix Domain Socket support interest given code written

Hi Akka team, Over the past week, I've implemented Akka Streams support for Unix Domain Sockets by leveraging the JNR library. There's more work to be done and my progress can be seen here: https://github.com/huntc/landlord/pull/14 (the UnixDomainSocket class itself: https://github.com/huntc/

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

Thanks Viktor, I’ve gone with your suggestion which I think is nice and explicit: private val eh = Thread.currentThread().getUncaughtExceptionHandler system.whenTerminated .andThen { case _ => try { println("Exiting") System.exit(exitStatus.getOrElse(1)) } catch

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

Ah yes, uncaught. Thanks for the correction. > On 13 Nov 2017, at 21:12, Viktor Klang wrote: > > When you say "unhandled exception" you mean "uncaught exception"? > >> On Mon, Nov 13, 2017 at 4:48 AM, Christopher Hunt wrote: >> Hi everyone, &g

[akka-user] Allowing SecurityException to propagate during actor system termination

Hi everyone, I have a situation where I need to call System.exit upon an actor system having terminated. In some runtime situations, a SecurityException will be thrown and I need that to be propagated as an unhandled exception. I can go into the details of why if required, but my question is ho

Re: [akka-user] Debugging postStop cause within a custom stage

As a follow-up to this, the problem was of course of my own creation. However, what wasn’t obvious to me was that the default behaviour of an InHandler is to complete the stage once the upstream is completed. The API doc states: Called when the input port is finished. After this callback

Re: [akka-user] Debugging postStop cause within a custom stage

I’m wondering if I'm seeing a problem related to https://github.com/akka/akka/issues/23111 . My `Source.single` completes quite quickly. I also have a custom stage with an async callback. I have observed that the stage registers as being completed wh

Re: [akka-user] Debugging postStop cause within a custom stage

> On 3 Nov 2017, at 8:30 am, Patrik Nordwall wrote: > > Could it be that the materializer is shutting down? > “Abrupt termination” > /Patrik I don’t *think* so, as I should see that exception manifest itself in the test: https://github.com/huntc/landlord/blob/8671d90dba7247db517ef21b64b84d65908

[akka-user] Re: FSM, how to make stateTimeout relative?

Perhaps something like this in order to get your FiniteDuration: Duration.ofMillis( ChronoUnit.MILLIS.between( ZonedDateTime.parse("2007-12-03T10:15:30+01:00[Europe/Paris]"), ZonedDateTime.now ) ) -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ:

[akka-user] Debugging postStop cause within a custom stage

Hi there, I've got a situation where I observe a postStop being called within my custom GraphStage prior to when I'd expect. I'm sure Akka is doing the right thing but, what's the best way to debug what is causing the postStop? My understanding is that the input and output connections should al

Re: [akka-user] Artery and IPC

gt; Patrik > >> On Sat, Oct 28, 2017 at 2:38 AM, Christopher Hunt wrote: >> Hi there >> >> I’m thinking of using Akka cluster in a single machine style scenario (low >> powered router), so that I can use distributed pub/sub across processes in >> particular

[akka-user] Artery and IPC

Hi there I’m thinking of using Akka cluster in a single machine style scenario (low powered router), so that I can use distributed pub/sub across processes in particular. I see that Aeron supports IPC as a transport, but Akka’s Artery doesn’t appear to be able to utilise it - I could be misread

[akka-user] Re: FlowOps concat with Source.fromFuture behaviour

Thanks for the advice Johan. I thought I had it all cracked given my last reply, but alas, no. So perhaps this is the issue that you describe after all. I'm quite confused at this point. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

It turns out not to be an issue with concat and futures... I believe the issue is in relation to my usage of BroadcastHub (which I didn't reveal before). Here's a reproducer: import akka.actor.ActorSystem import akka.stream.ActorMaterializer import akka.stream.scaladsl.{ BroadcastHub, Keep, Sour

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

How weird, I don't appear to be able to reproduce in a simplified fashion. I shall investigate further. Here's my attempt (that works as expected): import akka.actor.ActorSystem import akka.stream.ActorMaterializer import akka.stream.scaladsl.Source import scala.concurrent.duration._ import scala

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

> On 25 Oct 2017, at 10:25 pm, Viktor Klang wrote: > > Sure, I'm asking if it behaves differently because AFAICT they shouldn't. So > if the alternate encoding fixes it, then it's pretty simple to utility-fy it > until the inconsistency is fixed. > Hey Viktor, You suggestion didn’t make any

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

> On 25 Oct 2017, at 21:05, Viktor Klang wrote: > > Does it behave differently from > `Source.single(somePromise.future).mapAsync(1)(identity)` ? Interesting idea. Thanks Viktor. I’ll try it in the morning. It feels a little odd to look at though... -- >> Read the docs: http:

[akka-user] FlowOps concat with Source.fromFuture behaviour

Hey community, I've got a situation where there's a promise that, when completed, I'd like to concat its value onto the *end* of any stream elements before it i.e.: someSource.concat(Source.fromFuture(somePromise.future)) What I'm noticing is that if the promise is completed then the promised

[akka-user] Re: Custom stage with a sub-flow maintaining backpressure

Ah, I re-discovered the async callback APIs... I'd forgotten about them. Thus, my code now becomes: val (queue, ar) = Source .queue[ByteString](100, OverflowStrategy.backpressure) .prefixAndTail(0) .map { case (_, in) => in } .toMat(Sink.head)(Keep.both) .run val

[akka-user] Custom stage with a sub-flow maintaining backpressure

Hi Akka community, I'm looking to confirm that the below strategy for managing back pressure in sub-flows is sane. I have a need to create a sub-flow within a custom stage. In order to create the sub-flow, I'm using `prefixAndTail` as follows: val (queue, source) = Source .queue[ByteStr

Re: [akka-user] Is there an Akka stream mapAsync equivalent for yielding a Source?

:$ Thanks Konrad. -- >> 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 a

[akka-user] Is there an Akka stream mapAsync equivalent for yielding a Source?

Hey everyone, Given that mapAsync yields a Future, I was looking for a similar type of stage that yields a Source instead. My goal is to direct the flow's input to an in-process actor and then have that actor feedback its reply as a Source (the reply is most certainly a stream). Thanks for any

[akka-user] Re: ConductR sandbox linking to another container

Hi Chris, There's nothing built in to do this right now. Sounds like what we need to do here is allow the service locator to be configured with an external service. We have this on our to-do list. However you should be able to pass an environment var via the -e option though and have that envi

Re: [akka-user] Akka and Lagom

Akka is a low level toolkit. Lagom is a higher level framework. Frameworks are opinionated and tend to be strongly focused on developer productivity. This is a goal of Lagom. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/do

Re: [akka-user] Akka stream compression / decompression

...but your example doesn't close the output stream right? Don't you want something like this: writeToFile .future(someMaterializer) .andThen { case _ => out.close() } On Thursday, 9 October 2014 00:57:30 UTC+11, Nicolas Jozwiak wrote: > > Yes we close the outputstream at the end. > >

Re: [akka-user] Re: Multiple Futures inside Actor's receive

. On 08/08/2014, at 5:55 PM, √iktor Ҡlang wrote: > In the example you are closing over 'this.log...' > -- Christopher Hunt Senior Engineer Typesafe – Build Reactive Apps on the JVM! Twitter: @huntchr -- >>>>>>>>>> Read the docs:

[akka-user] Re: Multiple Futures inside Actor's receive

IMHO the key is to minimise the potential for closing over state that isn't available to a future's callback. This is tricky, and the approach I'm going to suggest only diminishes the risk, it does not eliminate it. I see that there are broadly two options: either create a worker actor to manag

Re: [akka-user] [Java] Registering Actors with Guice

My two cents: The actor system should be made available as something that is injectable (a bean). The actor system should be used to resolve actor refs via actor selection. Any actors that require construction either from the actor system or the context should call upon the bean context to reso