Re: [akka-user] Response reason phrase exceeds the configured limit of 64 characters
Hi - it's a reasonable question. I found Mathias's comment.
What I'm getting back is the full path name of the missing resource. And
since I'm nesting resources and using 64-bit uuids in resource names this
is way over 64 characters.
I'm using the exist xml database but I have no (easy) way to control it's
responses. Of course if I don't ask for what's not there, the problem
doesn't manifest itself and theoretically i know what is there but
somebody else might have deleted it.
From my reading of the second post, the 31 characters is not a defined
standard, merely the largest standard message, and no defined maximum.
Since the eXist database is only serving my application on a local net my
easiest solution is just to up the count.
On 21 February 2015 at 19:51, Reid Spencer r...@reactific.com wrote:
Tim,
You can find more about this from this thread:
https://groups.google.com/forum/#!topic/spray-user/CF2rsUKNvwQ and this
stack overflow questiON:
http://stackoverflow.com/questions/9513447/http-response-status-line-maximum-size
While setting the value higher will undoubtedly fix the problem, you have
to ask yourself why your server is sending back such large response reason
phrases when the standard shows a limit of 31 characters for these. What's
the reason phrase you are getting?
Reid.
On Saturday, February 21, 2015 at 11:05:35 AM UTC-5, Tim Pigden wrote:
to answer myself, config (note you need to use client to override it)
akka.http.client.parsing {
max-response-reason-length = 512
}
On 21 February 2015 at 15:08, Tim Pigden tim.p...@optrak.com wrote:
Hi - I get the following. Not sure how to find out what the response was or
how to change the configuration. Any help much appreciated as I'm now stuck.
akka.http.model.IllegalResponseException: Response reason phrase exceeds
the configured limit of 64 characters
at
akka.http.engine.client.HttpClient$$anonfun$2.applyOrElse(HttpClient.scala:89)
~[akka-http-core-experimental_2.11-1.0-M3.jar:1.0-M3]
at
akka.http.engine.client.HttpClient$$anonfun$2.applyOrElse(HttpClient.scala:86)
~[akka-http-core-experimental_2.11-1.0-M3.jar:1.0-M3]
--
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 a topic in the
Google Groups Akka User List group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/akka-user/KqfZ18SWN78/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in
England and Wales.
Company Registration No. 2327613 Registered Offices: Suite 6,The
Maltings, Hoe Lane, Ware, SG12 9LR England
This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Optrak Distribution Software Ltd. If you are not the
intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender
if you believe you have received this email in error.
--
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 a topic in the
Google Groups Akka User List group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/akka-user/KqfZ18SWN78/unsubscribe.
To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in England
and Wales.
Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings,
Hoe Lane, Ware, SG12 9LR England
This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Optrak
[akka-user] Akka-http - Why does UserCredentials class have a verifySecret method?
Very simple questions: 99% of times a system does not have the user's
secret but only some hashed form of it.
I need to pass the clear-text password to the verifySecret method in the
Provided credentials, in order to match it with the one in the basic
authentication header.
Is all the BasicAuthentication code useless unless I know the user's secret
or there's something I'm missing? Right now I'm basically rewriting that
code to apply bcrypt to the received password and compare it with the
hashed value i retrieve from the user service.
I see some nice-to-have features like fastfutures and secure comparisons,
but if I can only compare to the clear text data it's not much use.
Something like a mapSecret would be useful.
Thanks
G
object UserCredentials {
case object Missing extends UserCredentials
abstract case class Provided(username: String) extends UserCredentials {
def verifySecret(secret: String): Boolean
}
}
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Re: [Akka-stream] Distributed actor communication via Ask pattern or ActorPublisher/ActorSubscriber
To me, this isn't the correct solution. Passing Source(data) around seems wrong, it would seem dangerous for large files and impossible for remote actors if the source were pointer based. The tl;dr is that IMHO the correct solution, where you process indexing responses in a flow based way, is difficult to get done correctly right now. I'm waiting for this missing component: https://github.com/akka/akka/issues/16416. Read on for what turned into a pretty long winded brain dump... I think of Actors as little (possibly stateful) message processors. They react to messages, and sometimes produce directed response messages. These messages generally ought to be small and immutable. I see Streams and Flows as higher level constructs. As if someone stepped back, looked at all the little discrete message processors that he had and wanted to model and materialize a processing engine out of those parts. In your case I'd probably break things into a few components. Files, IndexingManager, FileToLinesGenerator, any number of LineToX mappers along with XtoY mappers, YtoZ mappers, etc. Finish things off with an Indexer component. You want to get files indexed. That overall responsibility would be owned by the IndexingManager. He'd be responsible for constructing the high level materialized flow, from the building blocks at hand. Maybe he's an actor that gets a NewFile(location) message whenever some file shows up somewhere. He than sets up and executes the indexing flow. I'd probably use a scala.io.Source to get an iterator over that file content. Source(file).getLines() or zipWithIndex() if you want line number information as well (I would). Construct your FlowGraph with whatever intermediate steps you like, and eventually get a small message over to your Indexer. Maybe that message looks like IndexingRequest(fileMetadata, lineNumber, line). It then indexes this bite sized message (also able to be sent across remote boundaries). Eventually the flow completes and your IndexingManager does some final book keeping and declares victory. This is how I'd model an overall indexing system. And it would probably work reasonably well in one direction, from FileData - Indexing. But we want to have the Indexer tell someone about the indexing results. For me, I'm waiting for https://github.com/akka/akka/issues/16416 to come out. It should make custom request/response protocols much easier to model. Until then, I'm probably not going to mess with cyclic flow graphs with Akka Streams. In the mean time, if I needed custom request/response logic I'd build non-Streams logic into my IndexingManager. I'd have the IndexingManager manually buffer requests/responses and simply have some basic ack-based back-pressure (send a few indexing requests blind, and then wait for responses to show up before I sent more requests). This assumes that the IndexingManager is going to do something special with responses. If all it's going to do is log errors, or send them to a queue for followup and possible reprocessing, the Indexer could do that and you can have a unidirectional flow managed by Akka Steams again. On 2nd thought, the blind send of IndexingRequests is probably poor form, knowing a bit about how Streams works I'd probably start the conversation off with a single IndexingSessionRequest that basically says, hey I want to send stuff, how many can you handle. The response can help the IndexingManager set internal buffers as well. The Indexer can respond with IndexingSessionResponse(send me 5) or IndexingSessionResponse(too busy, ask again in 5.seconds). -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Performance Of Akka IO
Hi Jim, I will certainly track down that example Spray app and take a look; however, my understanding of the Scheduler’s tick-duration configuration field is that it only affects scheduled messages. Since I’m not using the scheduler’s interface at all, I figured that setting was irrelevant. Are you implying that Akka IO uses the scheduler under the covers? In any event, I’ll take a look at this and report back later. In the mean time, I did some statistics on a 10,000 request sample run of my insert workload (YCSB workloada) which came out like this: Measurement Sum Average max min median wait 2748551 274.827617238276 16805 147 223 write 1042354 104.22497750225 1712 46 77 read 2142823 214.260873912609 47757 98 144 Times are all in microseconds. The three measurements are: wait - time between request/reply cycles (i.e. the application getting the next request ready) write - the time waiting for the write ACK in Akka IO read - the time waiting for Akka IO to reply with the next read message My earlier perusal of this data (a limited visual sample) concluded that the write time was much higher than the read time but this doesn’t hold statistically over the whole sample. 104 microseconds for a write isn’t terrible, it’s just not as good as other implementations of a mongo driver :) Reid. On Feb 21, 2015, at 5:24 PM, Jim Hazen jimhazen2...@gmail.com wrote: Hi Reid, Sorry I don't have my IDE in front of me. You might take a look at some of Akka's scheduling configuration options. You mentioned Spray, and there's a benchmark example Spray app that ships with a pretty good application.conf that exposes and tweaks some of these config values, the scheduler being one of them. AFAIK the scheduler fires completed tasks on a clock/tick based timer. You may be bumping up against the scheduler's default clock timing threshold, which can be reduced. Hope that helps. -Jim -- Read the docs: http://akka.io/docs/ http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user https://groups.google.com/group/akka-user --- You received this message because you are subscribed to a topic in the Google Groups Akka User List group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/zI0iXocMtig/unsubscribe https://groups.google.com/d/topic/akka-user/zI0iXocMtig/unsubscribe. To unsubscribe from this group and all its topics, send an email to akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto:akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Re: Performance Of Akka IO
Hmm. Then I must have been playing with the setting around the same time. It's
definitely related to overall thread scheduling. Poke around the reference.conf
files in the core akka jars. There should be a description of the overall
methodology in there as well. Timer granularity and number of buckets are the
big factors.
-Jim
-- Sent from my mobile device
On Feb 21, 2015, at 2:47 PM, Reid Spencer r...@reactific.com wrote:
Jim,
The spray-can example benchmark program has an application.conf like this:
akka {
loglevel = INFO
event-handlers = [akka.event.slf4j.Slf4jEventHandler]
actor.default-dispatcher {
fork-join-executor {
parallelism-min = 1
parallelism-factor = 1
#parallelism-max = 1
}
}
}
(non-akka parts elided)
The only interesting thing there is parallelism-factor which is 1 here while
I use 2. I'll try it with the lower value.
Thanks,
Reid.
On Saturday, February 21, 2015 at 5:24:40 PM UTC-5, Jim Hazen wrote:
Hi Reid,
Sorry I don't have my IDE in front of me. You might take a look at some of
Akka's scheduling configuration options. You mentioned Spray, and there's a
benchmark example Spray app that ships with a pretty good application.conf
that exposes and tweaks some of these config values, the scheduler being one
of them. AFAIK the scheduler fires completed tasks on a clock/tick based
timer. You may be bumping up against the scheduler's default clock timing
threshold, which can be reduced.
Hope that helps.
-Jim
--
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 a topic in the Google
Groups Akka User List group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/akka-user/zI0iXocMtig/unsubscribe.
To unsubscribe from this group and all its topics, 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Response reason phrase exceeds the configured limit of 64 characters
Hi - I get the following. Not sure how to find out what the response was or how to change the configuration. Any help much appreciated as I'm now stuck. akka.http.model.IllegalResponseException: Response reason phrase exceeds the configured limit of 64 characters at akka.http.engine.client.HttpClient$$anonfun$2.applyOrElse(HttpClient.scala:89) ~[akka-http-core-experimental_2.11-1.0-M3.jar:1.0-M3] at akka.http.engine.client.HttpClient$$anonfun$2.applyOrElse(HttpClient.scala:86) ~[akka-http-core-experimental_2.11-1.0-M3.jar:1.0-M3] -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] akka-streams - How to define a Source from an arbitrary event stream?
but this approach forces you to call the thing that produces items and
block in the same dispatcher as the consumer, doesn't it?
What's the best option here? Having an Iterator[Future[T]] that return
promises of something that's being executed in a different exec. context?
Thank you
G
On Friday, 20 February 2015 18:42:06 UTC, Luis Ángel Vicente Sánchez wrote:
That's quite a nice little trick Endre, way better that writing an
ActorPublisher if you don't need to communicate with the Producer. I did
something similar to create an infinite stream from Amazon SQS (using an
infinite Iterator[Unit] and mapAsyncUnordered) but this seems a much better
approach.
2015-02-20 10:20 GMT+00:00 Endre Varga endre...@typesafe.com
javascript::
Hi Simon,
One trick I like to use is to define a Source in terms of a
PushPullStage. Now this sounds strange, since a PushPullStage is supposed
to be someting that transforms incoming element into outgoing elements, how
can that be a Source? Well, the trick is this:
def mySource = Source.empty.transform(...)
Since the upstream Source of the stage is immediately completed one, you
can call ctx.absorbTermination() and then only handle element emission from
onPull. Of course you have to propagate the first pull upstream. For
example:
Source.empty.transform(() ⇒ {
new PushPullStage[Nothing, T] {
val iterator: Iterator[T] = myIterator
// Upstream is guaranteed to be empty
override def onPush(elem: Nothing, ctx: Context[T]): Directive =
throw new UnsupportedOperationException(The IterableSource stage
cannot be pushed)
override def onUpstreamFinish(ctx: Context[T]): TerminationDirective
= {
if (iterator.hasNext) ctx.absorbTermination()
else ctx.finish()
}
override def onPull(ctx: Context[T]): Directive = {
if (!ctx.isFinishing) {
ctx.pull()
} else {
val elem = iterator.next()
if (iterator.hasNext) ctx.push(elem)
else ctx.pushAndFinish(elem)
}
}
}
The above is a simplified version of the new upcoming iterator source in
M4.
I guess this pattern can be made proper by a simple DSL that handles the
boilerplate. Currently the drawback of this approach is that you cannot
send external async events to this kind of source, so it is a bit limited
for now, but we will solve that in the future.
-Endre
On Thu, Feb 19, 2015 at 11:41 PM, Simon Schäfer ma...@antoras.de
javascript: wrote:
I struggle in nicely defining a Source that gets its elements from an
arbitrary event stream. At the moment my code looks like this:
def watchKey[A : Reads](key: SettingKey[A])(implicit ctx:
ExecutionContext): Source[Out[A]] = {
Source(new Publisher[Out[A]] {
var requestedElems = 0L
var cancellation: sbt.client.Subscription = _
val subs = new Subscription {
def request(n: Long): Unit = {
requestedElems = n
}
def cancel(): Unit = {
cancellation.cancel()
}
}
override def subscribe(s: Subscriber[_ : Out[A]]): Unit = {
def sendElem(elem: Out[A]) = {
requestedElems -= 1
s.onNext(elem)
}
s.onSubscribe(subs)
cancellation = client.lazyWatch(key) { (key, res) ⇒
val elem = res map (key → _)
if (requestedElems 0)
sendElem(elem)
else
??? // TODO handle case of no requested elems
}
}
})
}
I had to define my own (incorrect) Publisher+Subscription, which seems
to me not being the right way to do this. The `lazyWatch` method takes a
function that is called each time an event occurs. Furthermore a
subscription needs to be canceled when no new events should be sent. What
abstractions does akke-streams provide to make doing this sort of thing
easier?
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google
Groups Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send
an email to akka-user+...@googlegroups.com javascript:.
To post to this group, send email to akka...@googlegroups.com
javascript:.
Visit this group at http://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+...@googlegroups.com javascript:.
To post to this group,
[akka-user] Re: akka-http port binding disappeared and ActorSystem disappeared as well...
Luis, Interesting report. I noted that ConcatAllImpl was started three times and stopped twice. I'm assuming that it was the last start that caused the problem after which there was no more logging? Reid. On Friday, February 20, 2015 at 1:30:09 PM UTC-5, Luis Ángel Vicente Sánchez wrote: We might have found a potential issue on akka-http / akka. We have an application that is using akka-http hosted on Amazon EC2; we decided to scale horizontally to 2 instances and added a Amazon ELB. The ELB was doing this simple health check every 3 seconds: 1.- Connect to the HTTP port (i.e. 9000). 2.- Close connection. The ELB was not sending anything through the connection, just opening it and closing it if there was no error. After 10-15min our servers stopped serving requests; we checked both instances and the port 9000 was not binded anymore (nobody was listening at that port) but there were no error messages in our log files. The application has some actors running to handle a autorefreshing cache and those actors were also gone. After upgrading from akka 2.3.7 to akka 2.3.9, akka-http from 1.0-M2 to akka-http 1.0-M3, nothing changed. We decided to create a PING endpoint and configure ELB to use that ping endpoint and check the status of the response and everything worked flawlessly. It seems that, somehow, the ELB was crashing the entire ActorSystem by just opening a connection and closing it afterwards, every 3 seconds. This might be related to this other issue: https://groups.google.com/d/msg/akka-user/QZhDFmrXZaY/21B1O9VsPAMJ We enabled all akka debug options and we got this log: 16:52:01.468 [application-akka.actor.default-dispatcher-24] DEBUG akka.stream.impl.io.TcpListenStreamActor - no longer watched by Actor[akka://application/system/IO-TCP/selectors/$a/84#843677859] 16:52:01.468 [application-akka.actor.default-dispatcher-24] DEBUG akka.stream.impl.io.InboundTcpStreamActor - now watched by Actor[akka://application/system/IO-TCP/selectors/$a/84#843677859] 16:52:01.468 [application-akka.actor.default-dispatcher-24] DEBUG akka.stream.impl.fusing.ActorInterpreter - started (akka.stream.impl.fusing.ActorInterpreter@1e825a3c) 16:52:01.469 [application-akka.actor.default-dispatcher-24] DEBUG akka.stream.impl.MapAsyncProcessorImpl - stopped 16:52:01.469 [application-akka.actor.default-dispatcher-24] DEBUG akka.stream.impl.fusing.ActorInterpreter - stopped 16:52:01.474 [application-akka.actor.default-dispatcher-17] DEBUG akka.stream.impl.StreamSupervisor - now supervising Actor[akka://application/user/$a/flow-584-flexiMerge-BypassMerge#-453617052] 16:52:01.475 [application-akka.actor.default-dispatcher-17] DEBUG akka.stream.impl.FlexiMergeImpl - started (akka.stream.impl.FlexiMergeImpl@4ee3cfbf) 16:52:01.475 [application-akka.actor.default-dispatcher-17] DEBUG akka.stream.impl.StreamSupervisor - now supervising Actor[akka://application/user/$a/flow-585-4-errorLogger-stageFactory#1706326930] 16:52:01.475 [application-akka.actor.default-dispatcher-17] DEBUG akka.stream.impl.fusing.ActorInterpreter - started (akka.stream.impl.fusing.ActorInterpreter@4e5c2d0f) 16:52:01.475 [application-akka.actor.default-dispatcher-23] DEBUG akka.stream.impl.StreamSupervisor - now supervising Actor[akka://application/user/$a/flow-585-3-concatAll#1209633305] 16:52:01.475 [application-akka.actor.default-dispatcher-23] DEBUG akka.stream.impl.ConcatAllImpl - started (akka.stream.impl.ConcatAllImpl@5925bfa) 16:52:01.476 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.StreamSupervisor - now supervising Actor[akka://application/user/$a/flow-585-2-renderer-stageFactory#1040213155] 16:52:01.476 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.fusing.ActorInterpreter - started (akka.stream.impl.fusing.ActorInterpreter@4bd47cf1) 16:52:01.476 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.StreamSupervisor - now supervising Actor[akka://application/user/$a/flow-585-1-recover-stageFactory#-503454149] 16:52:01.477 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.fusing.ActorInterpreter - started (akka.stream.impl.fusing.ActorInterpreter@6b56d91b) 16:52:01.477 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.StreamSupervisor - now supervising Actor[akka://application/user/$a/flow-586-broadcast-bypassFanout#-2076126366] 16:52:01.477 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.Broadcast - started (akka.stream.impl.Broadcast@12c7b2ab) 16:52:01.487 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.StreamSupervisor - now supervising Actor[akka://application/user/$a/flow-587-1-filter#2048673253] 16:52:01.487 [application-akka.actor.default-dispatcher-22] DEBUG akka.stream.impl.fusing.ActorInterpreter - started (akka.stream.impl.fusing.ActorInterpreter@74a3022e)
Re: [akka-user] FuncIterable IterableSource is calling next concurrently
Hi, it was my fault, I finally understand the concept behind it, I can see what is running concurrently/sequentially now. Thank you -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
[akka-user] [Akka-stream] Distributed actor communication via Ask pattern or ActorPublisher/ActorSubscriber
Hi,
If ActorX needs to pass a load of data to be processed to a remote ActorY,
is this a correct think to do?
Imagine the data is rows of huge files that are downloaded on ActorX and to
be processed and indexed on ActorY.
trait IndexReq {
def source: Source[Row]
def flow: Flow[Row, Rec] // processing from a row to a record
}
trait IndexRes[T] {
def source: Source[T]
}
So that ActorX loads 1 - x rows of the file as immutable.Iterable and does :
actorY ? IndexReq(Source(data))
and ActorY Materializes the Source and does :
source.grouped(Int.MaxValue).runWith(Sink.head) onComplete {
case Success(results) = actorX ! IndexRes(Source(results))
}
Is this a correct solution to this problem?
Or should actorX be ActorPublisher and actorY ActorSubscriber. But the
distributed nature of it is not documented much and it'd be more of an
experiment for me.
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
