[akka-user] Re: Unordered merge of 2..n streams created by groupBy
Akka maintainers, how does this solution look (see mentioned gist in quoted text)? I'll probably need some degree of guidance, but this solution is working well for my needs; I'm happy to produce a pull-request for Akka streams to implement FlattenStrategy.mergeUnordered. On Wednesday, January 7, 2015 at 3:51:09 PM UTC-7, Tim Harper wrote: Gist is here: https://gist.github.com/timcharper/a6642275bfaebbd2194d -- 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: File based mailbox - Files under _mb location grows large consistently without getting cleared
I could see a similar issue was discussed in the below thread from Daniele. https://groups.google.com/forum/#!searchin/akka-user/file$20based/akka-user/0Yt78n73a4o But, I couldn't find an answer there for the files growing big issue. On Friday, January 9, 2015 at 11:56:39 AM UTC+5:30, araman...@gmail.com wrote: Hi Akka Users, I have a problem with actors using the file based mailbox. The size of mailbox files under _mb folder keeps on increasing as the number of messages are processed. All messages are getting processed fine in the system, so shouldn't they be removed from the file when completed? I feel this is not happening, and the mailbox file grows in size finally eating up the diskspace. I do not understand why the messages are still kept in the mailbox when they are successfully processed. I am going with the default configuration values (journal size 16MB etc). Are there any config options that I can use to clear the file contents once a message is processed? Regards, Anoop -- 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] File based mailbox - Files under _mb location grows large consistently without getting cleared
Hi Akka Users, I have a problem with actors using the file based mailbox. The size of mailbox files under _mb folder keeps on increasing as the number of messages are processed. All messages are getting processed fine in the system, so shouldn't they be removed from the file when completed? I feel this is not happening, and the mailbox file grows in size finally eating up the diskspace. I do not understand why the messages are still kept in the mailbox when they are successfully processed. I am going with the default configuration values (journal size 16MB etc). Are there any config options that I can use to clear the file contents once a message is processed? Regards, Anoop -- 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: File based mailbox - Files under _mb location grows large consistently without getting cleared
Durable MBs are no longer supported. I recommend you to switch to Akka Persistence (perhaps with the LevelDB Journal, since it is closest to your durable MB). Is that possible? On Fri, Jan 9, 2015 at 7:27 AM, aramankand...@gmail.com wrote: I could see a similar issue was discussed in the below thread from Daniele. https://groups.google.com/forum/#!searchin/akka-user/file$20based/akka-user/0Yt78n73a4o But, I couldn't find an answer there for the files growing big issue. On Friday, January 9, 2015 at 11:56:39 AM UTC+5:30, araman...@gmail.com wrote: Hi Akka Users, I have a problem with actors using the file based mailbox. The size of mailbox files under _mb folder keeps on increasing as the number of messages are processed. All messages are getting processed fine in the system, so shouldn't they be removed from the file when completed? I feel this is not happening, and the mailbox file grows in size finally eating up the diskspace. I do not understand why the messages are still kept in the mailbox when they are successfully processed. I am going with the default configuration values (journal size 16MB etc). Are there any config options that I can use to clear the file contents once a message is processed? Regards, Anoop -- 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. -- *Jonas Bonér* Home: jonasboner.com Twitter: @jboner https://twitter.com/jboner Public Key: keybase.io/jonas -- 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.actor.ActorNotFound In Spark Streaming on Mesos (using ssc.actorStream)
If the actor system name has changed to sparkExecutor the actor selection using sparkDriver is not valid any more. What happens if you change the actor selection path? /Patrik On Wed, Jan 7, 2015 at 2:52 PM, Christophe Billiard christophe.billi...@gmail.com wrote: Hi all, I have an actorNotFound problem on Spark 1.2.0 on mesos0.21.0 The full problem is described here: http://apache-spark-user-list.1001560.n3.nabble.com/akka-act or-ActorNotFound-In-Spark-Streaming-on-Mesos-using-ssc-actor Stream-tt21014.html To sum up: In local mode path is akka://sparkDriver/user/Supervisor0/helloer And working fine On mesos path is akka://sparkExecutor/user/Supervisor0/helloer Exception in thread main akka.actor.ActorNotFound: Actor not found for: ActorSelection[Anchor(akka://sparkDriver/), Path(/user/Supervisor0/helloer)] Any ideas how to get some useful information on my actor systems (host/port)? Anyone knows about the akka configuration of Spark? Any other ideas? -- 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. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- 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 Persistence on the Query Side: The Conclusion
That is a great point Greg. On Wed, Jan 7, 2015 at 10:15 PM, Greg Young gregoryyou...@gmail.com wrote: The consistency of the query model should be achieved as soon as possible and close to real-time. It really depends on the domain. I have worked in many situations where the data in question would be perfectly fine updated once per month. (e.g. adding a sold out item to the shopping cart). This is a funny example because it shows not that you need to update read models more quickly but that you need to get the whole business on board. Remember that computer systems are normally part of a larger system fulfilling business needs. It really is a mind shift moving to eventual consistency. In the example of adding a sold out item... why stop it? Does it matter that we don't have any of this item? The real question is how quickly we can get it and if its worth our while to do so. To be fair 30 years ago these times were much much higher than what we talk about today and yet businesses still managed to work their way through things. For many of these types allowing things to go incorrectly is actually a good thing (overbooked seats on an airline, overdraft charges at banks...). To really be benefiting from eventual consistency the whole business process must recognize it. In terms of handling failures they are normally handled in a reactive not a preventative manner (like most business problems). Detect the failure, let a human deal with it. At the end of the day the primary role of the computer system is to take workload off of humans. You will hit the law of diminishing returns. dont try to solve every problem :) Greg On Wed, Jan 7, 2015 at 11:07 PM, Sebastian Bach sebastian.tomasz.b...@gmail.com wrote: Hi Roland, one thing to keep in mind in the CQRS/ES architecture is that not only the query side depends on the command side (by following the event stream) but also the command side depends on the query side for validation of complex business rules. This has a deep impact on correctness and throughput. Validation checks on an potentially outdated query model in an eventually consistent architecture is a hard problem (e.g. adding a sold out item to the shopping cart). The consistency of the query model should be achieved as soon as possible and close to real-time. A PersistentView in Akka has a default of 5s? On the other hand the speed of validation depends on the speed of the queries. And the throughput depends on the validation speed. Thus, queries directly on the whole event stream are less useful than persistent projections. Keep up the good work :) Cheers Sebastian W dniu wtorek, 7 października 2014 07:32:20 UTC+2 użytkownik rkuhn napisał: Hi Vaughn, from our side nothing has happened yet: my conclusion is that this thread contains all the information we need when we start working on this. The reason why we are waiting is that this work will depend heavily upon Akka Streams and therefore we are finishing those first, which should take roughly one month. Meanwhile, if use cases come up which could be used to refine the plans, please point them out here so that we can take all the inputs into account. Regards, Roland 6 okt 2014 kl. 20:09 skrev Vaughn Vernon vve...@shiftmethod.com: Hi Roland, I's been a month this the last update on this and I have lost track of the status. Can you provide an update on where this stands? Is there a more recent akka-persistence build that supports the conclusions reached in this discussion? If so, what is the release number? If no, when is will the proposed features be released? Best, Vaughn On Fri, Sep 5, 2014 at 1:09 AM, Roland Kuhn goo...@rkuhn.info wrote: Attempting a second round-up of what shall go into tickets, in addition to my first summary we need to: predefine trait JournalQuery with minimal semantics (to make the Journal support discoverable at runtime) predefine queries for named streams since that is universally useful; these are separate from PersistenceID queries due to different consistency requirements add support for write-side tags (see below) add a comprehensive PersistenceTestKit which supports the fabrication of arbitrary event streams for both PersistentActor and read-side verification Ashley, your challenge about considering non-ES write-sides is one that I think we might not take up: the scope of Akka Persistence is to support persistent Actors and their interactions, therefore I believe we should be opinionated about how we achieve that. If you want to use CQRS without ES then Akka might just not be for you (for some values of “you”, not necessarily you ;-) ). Now why tags? My previous conclusion was that burdening the write-side with generating them goes counter to the spirit of ES in that this tagging should well be possible after the fact.
[akka-user] Re: Akka Http Client - User-Agent header
Hi Marcin,
the user agent string is a config property and configured here
https://github.com/akka/akka/blob/release-2.3-dev/akka-http-core/src/main/resources/reference.conf#L69-L73
.
Cheers
André
On Wednesday, January 7, 2015 9:14:23 PM UTC+1, Marcin Gosk wrote:
Hey guys, is it possible to set custom header (User-Agent) for akka
streams
val connection = Http().outgoingConnection(someServer, 443)
val request:HttpRequest = RequestBuilding.Get(s/some/address.json)
//I want to add header here
//request.addHeader(HttpHeader(User-Agent,Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0)))
Source.single(request).via(connection.flow).runWith(Sink.head).flatMap {
response =
response.status match {
case status if status.isSuccess =
val ticker = Unmarshal(response.entity).to[Ticker]
println(ticker)
ticker
case status =
println(s$status error:${response.toString})
Future.failed(new IOException(sToken request failed with status
${response.status} and error ${response.entity}))
}
}
--
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] Actor lifecycle with regard to unresponsive actors
Hi, I have read this other thread about the case of a remote being unavailable https://groups.google.com/forum/#!msg/akka-user/68TuTZLxqFI/3toNcO8yvMMJ. I assume it still applies to the most current version (?). My question is, how do both the supervision system (the part that's above user code) and the death watch, in short, Akka, determine that a remote is unavailable, and whether that is in any way configurable. I may assume some polling is relied upon and wonder how exactly does it reach that determination of unavailability. In the same vein, I would like to ask whether actors perform any sort of retry of their own, in case they determine that they *failed* *sending or replying to *a message. Or is it the case that message sending is a one time attempt. Pointers to relevant source code are also welcome. Thanks in advance, Matan *P.S. in case relevant changes are on the roadmap, it would be also cool to know about it.* -- 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] support for akka persistent plugins
Which, if any, of the main target plugins (Cassandra, etc) are supported by Typesafe or commercially via other parties? -- 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] is this a sensible problem for perdistence?
Hi I'm looking at modelling a large parcel delivery system with approximately 300k - 1m parcels per day depending on time of year. Each of those parcels has its own life cycle from assignment to a trip through eventual delivery. If parcels are on a route, then, for example, a delivery event at position 5 on the route will cause an update of the ETA for parcels 6 - n where n could be 100 or so. A parcel in position 50 might receive 60 such updates up until it is successfully delivered and therefore retired from active consideration. I'm estimating that with 0.5m parcels and an 8 hour working day, I'll get around 20 delivery notifications per second, each generating a cascade of up to 100 new ETAs - so around 2000 updates/second. In the morning, around 8am and 9am these numbers will peak as high priority orders tend to cluster well geographically so the drivers hit more deliveries in a shorter space of time - so say at Christmas peak we could get up to 5000 updates/second for brief periods. Now I'm not a big data guy. To me this is immense, but realistically is this going to cause any problem for Akka persistence? Is up to 1m separate actor processors a sensible thing to have? There are alternative ways to model it - the updates are internally generated at the vehicle level (so theoretically I only need to persist the incoming vehicle signals) but the parcel life cycle extends beyond the duration of the vehicle trip so that could get messy. -- 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-http respond with result of an actor call (java-api)
Hello,
I'm playing arround with the Java-API of the new akka-http server and I
would like to reply to a request with the result of an asynchronous actor
(i.e. some kind of DB-query).
I would have expected that I somehow can pass a Future to the
context.complete or a Future entity. But this seams not be possible.
One solution seams to be to generate a streaming entity and stream the
result back. But how do I do it if I just want to have a traditional http
response?
import akka.actor.ActorRef;
import akka.actor.ActorSystem;
import akka.actor.Props;
import akka.actor.UntypedActor;
import akka.http.model.japi.HttpMethods;
import akka.http.model.japi.HttpResponse;
import akka.http.model.japi.headers.AccessControlAllowHeaders;
import akka.http.model.japi.headers.AccessControlAllowMethods;
import akka.http.model.japi.headers.AccessControlAllowOrigin;
import akka.http.model.japi.headers.HttpOriginRange;
import akka.http.server.japi.HttpApp;
import akka.http.server.japi.RequestContext;
import akka.http.server.japi.Route;
import akka.pattern.Patterns;
public class MetaApi extends HttpApp {
private static ActorSystem actorSystem;
private static ActorRef handlerActor;
public static class HandlerActor extends UntypedActor {
@Override
public void onReceive( Object message ) throws Exception {
if ( message instanceof RequestContext ) {
RequestContext ctx = (RequestContext)message;
// ...
} else {
unhandled( message );
}
}
}
@Override
public Route createRoute() {
return route( path( meta ).route(
get( handleWith( ctx - {
HttpResponse response = HttpResponse.create()
.addHeader( AccessControlAllowOrigin.create(
HttpOriginRange.ALL ) )
.addHeader(
AccessControlAllowHeaders.create(
Access-Control-Allow-Origin,
Access-Control-Allow-Method,
Content-Type ) )
.addHeader(
AccessControlAllowMethods.create( HttpMethods.GET
, HttpMethods.POST, HttpMethods.PUT,
HttpMethods.OPTIONS, HttpMethods.DELETE ) )
.withEntity( Response of actor? ); // Patterns.ask(
handlerActor, ctx, 10_000 );
return ctx.complete( response );
} ) ) ) );
}
public static void main(String ... args) throws Exception {
MetaApi api = new MetaApi();
actorSystem = ActorSystem.create();
handlerActor = actorSystem.actorOf( Props.create( HandlerActor.
class ), Get Handler );
api.bindRoute(localhost,8080, actorSystem);
}
}
Thanks best regards
Peter
--
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: is this a sensible problem for persistence?
Hmm - on reading other threads and reflection I think I may have the wrong model here. The information about the ETA is possibly not something that should be persisted. It's not hard data. And perhaps my parcel should be split between a persisting actor (still need 1m of them) and some sort of query object that reflects current ETA and the real object is only updated in response to materialisation of the ETA (i.e. sending it to the customer as advice) in which case it's the advice history that's the thing to persist. Is anyone encountering similar modelling issues? On Thursday, January 8, 2015 10:34:10 AM UTC, Tim Pigden wrote: Hi I'm looking at modelling a large parcel delivery system with approximately 300k - 1m parcels per day depending on time of year. Each of those parcels has its own life cycle from assignment to a trip through eventual delivery. If parcels are on a route, then, for example, a delivery event at position 5 on the route will cause an update of the ETA for parcels 6 - n where n could be 100 or so. A parcel in position 50 might receive 60 such updates up until it is successfully delivered and therefore retired from active consideration. I'm estimating that with 0.5m parcels and an 8 hour working day, I'll get around 20 delivery notifications per second, each generating a cascade of up to 100 new ETAs - so around 2000 updates/second. In the morning, around 8am and 9am these numbers will peak as high priority orders tend to cluster well geographically so the drivers hit more deliveries in a shorter space of time - so say at Christmas peak we could get up to 5000 updates/second for brief periods. Now I'm not a big data guy. To me this is immense, but realistically is this going to cause any problem for Akka persistence? Is up to 1m separate actor processors a sensible thing to have? There are alternative ways to model it - the updates are internally generated at the vehicle level (so theoretically I only need to persist the incoming vehicle signals) but the parcel life cycle extends beyond the duration of the vehicle trip so that could get messy. -- 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] Getting strange error 2.4-Snapshot with stream+http 1.0-M2
Yessir. That was the issue. Rebuilt against 2.3.x and its stable.
Thanks!
On Wednesday, January 7, 2015 2:42:56 AM UTC-6, drewhk wrote:
Hi,
Streams is compiled against Akka 2.3.x which is not guaranteed to be
binary compatible with 2.4. I expect that the above code to work with Akka
2.3.x. (if not, then this is a bug)
-Endre
On Wed, Jan 7, 2015 at 4:40 AM, tigerfoot gzo...@gmail.com javascript:
wrote:
Hello,
I've got this code:
def httpGet( uri:String )(implicit s:ActorSystem) = {
implicit val materializer = FlowMaterializer()
var r:HttpResponse = null
val req = HttpRequest(HttpMethods.GET, Uri(uri))
val host:String = req.uri.authority.host.toString
val port:Int = req.uri.effectivePort
val httpClient = Http().outgoingConnection(host,port).flow
val consumer = Sink.foreach[HttpResponse] { resp ⇒ r = resp }
*val finishFuture = Source.single(req).via(httpClient).runWith(consumer)*
*// -- GOES BOOM HERE*
Await.result(finishFuture, Duration(3 seconds))
// unpack result
(r.status.intValue,
Await.result(r.entity.toStrict(FiniteDuration(3,seconds)), Duration(3
seconds) )
.data
.utf8String)
}
This works pretty well--for a while. When run in a long-running process,
eventually it dies with the exception below.
Any idea what's cause it?
Thanks for any ideas,
Greg
Uncaught error from thread [overlord-akka.actor.default-dispatcher-143]
shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled for
ActorSystem[overlord]
java.lang.NoSuchMethodError:
akka.pattern.AskableActorRef$.$qmark$extension(Lakka/actor/ActorRef;Ljava/lang/Object;Lakka/util/Timeout;)Lscala/concurrent/Future;
at
akka.stream.impl.ActorBasedFlowMaterializer.actorOf(ActorBasedFlowMaterializer.scala:471)
at
akka.stream.impl.ActorBasedFlowMaterializer.actorOf(ActorBasedFlowMaterializer.scala:458)
at
akka.stream.impl.ActorBasedFlowMaterializer.materializeJunction(ActorBasedFlowMaterializer.scala:506)
at
akka.stream.scaladsl.FlowGraph$$anonfun$6$$anonfun$apply$8.apply(FlowGraph.scala:1248)
at
akka.stream.scaladsl.FlowGraph$$anonfun$6$$anonfun$apply$8.apply(FlowGraph.scala:1212)
at
akka.stream.impl.DirectedGraphBuilder.edgePredecessorBFSfoldLeft(DirectedGraphBuilder.scala:240)
at akka.stream.scaladsl.FlowGraph$$anonfun$6.apply(FlowGraph.scala:1212)
at akka.stream.scaladsl.FlowGraph$$anonfun$6.apply(FlowGraph.scala:1209)
at
scala.collection.TraversableOnce$$anonfun$foldLeft$1.apply(TraversableOnce.scala:144)
at
scala.collection.TraversableOnce$$anonfun$foldLeft$1.apply(TraversableOnce.scala:144)
at scala.collection.Iterator$class.foreach(Iterator.scala:727)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
at
scala.collection.TraversableOnce$class.foldLeft(TraversableOnce.scala:144)
at scala.collection.AbstractTraversable.foldLeft(Traversable.scala:105)
at akka.stream.scaladsl.FlowGraph.runGraph(FlowGraph.scala:1209)
at akka.stream.scaladsl.FlowGraph.run(FlowGraph.scala:1184)
at akka.stream.scaladsl.Source$class.runWith(Source.scala:38)
at akka.stream.scaladsl.GraphSource.runWith(GraphFlow.scala:128)
*at com.rs.overlord.Util$.httpGet(Util.scala:29) -- HIGHLIGHTED LINE IN
ABOVE CODE*
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1$$anonfun$apply$1.apply$mcV$sp(OverlordActor.scala:32)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1$$anonfun$apply$1.apply(OverlordActor.scala:30)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1$$anonfun$apply$1.apply(OverlordActor.scala:30)
at scala.util.Try$.apply(Try.scala:161)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1.apply(OverlordActor.scala:30)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1$$anonfun$applyOrElse$1.apply(OverlordActor.scala:29)
at scala.collection.immutable.HashMap$HashMap1.foreach(HashMap.scala:224)
at
scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:403)
at
scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:403)
at
com.rs.overlord.OverlordActor$$anonfun$receive$1.applyOrElse(OverlordActor.scala:29)
at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
at com.rs.overlord.OverlordActor.aroundReceive(OverlordActor.scala:24)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
at akka.actor.ActorCell.invoke(ActorCell.scala:487)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)2015-01-06
22:33:46.970 ERROR [overlord-akka.actor.default-dispatcher-156] Uncaught
error from thread [over
--
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
[akka-user] Re: Actor lifecycle with regard to unresponsive actors
Your first step would probably be the documentation at : http://doc.akka.io/docs/akka/snapshot/scala/remoting.html In particular the sections - Lifecycle and Failure Recovery Model You could also have a look at http://doc.akka.io/docs/akka/snapshot/general/configuration.html and any of the sections with keywords gated,retry,quarantine -b On Thursday, January 8, 2015 4:12:08 AM UTC-5, Matan Safriel wrote: Hi, I have read this other thread about the case of a remote being unavailable https://groups.google.com/forum/#!msg/akka-user/68TuTZLxqFI/3toNcO8yvMMJ. I assume it still applies to the most current version (?). My question is, how do both the supervision system (the part that's above user code) and the death watch, in short, Akka, determine that a remote is unavailable, and whether that is in any way configurable. I may assume some polling is relied upon and wonder how exactly does it reach that determination of unavailability. In the same vein, I would like to ask whether actors perform any sort of retry of their own, in case they determine that they *failed* *sending or replying to *a message. Or is it the case that message sending is a one time attempt. Pointers to relevant source code are also welcome. Thanks in advance, Matan *P.S. in case relevant changes are on the roadmap, it would be also cool to know about it.* -- 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: Actor lifecycle with regard to unresponsive actors
Thanks for the reminder. The Phi Accrual Failure Detector is nice, although it is unfortunate that tuning the threshold is an art (see mention of EC2 in http://doc.akka.io/docs/akka/snapshot/scala/remoting.html http://www.google.com/url?q=http%3A%2F%2Fdoc.akka.io%2Fdocs%2Fakka%2Fsnapshot%2Fscala%2Fremoting.htmlsa=Dsntz=1usg=AFQjCNGnALe52S3LT83NV9UJM17jhcxrVg). I wonder what may inconsistent mean in In the face of communication failures that are unrecoverable because the state of the participating systems are inconsistent, the remote system becomes Quarantined. Thanks in advance! On Thursday, January 8, 2015 at 6:29:48 PM UTC+2, bearrito wrote: Your first step would probably be the documentation at : http://doc.akka.io/docs/akka/snapshot/scala/remoting.html http://www.google.com/url?q=http%3A%2F%2Fdoc.akka.io%2Fdocs%2Fakka%2Fsnapshot%2Fscala%2Fremoting.htmlsa=Dsntz=1usg=AFQjCNGnALe52S3LT83NV9UJM17jhcxrVg In particular the sections - Lifecycle and Failure Recovery Model You could also have a look at http://doc.akka.io/docs/akka/snapshot/general/configuration.html and any of the sections with keywords gated,retry,quarantine -b On Thursday, January 8, 2015 4:12:08 AM UTC-5, Matan Safriel wrote: Hi, I have read this other thread about the case of a remote being unavailable https://groups.google.com/forum/#!msg/akka-user/68TuTZLxqFI/3toNcO8yvMMJ. I assume it still applies to the most current version (?). My question is, how do both the supervision system (the part that's above user code) and the death watch, in short, Akka, determine that a remote is unavailable, and whether that is in any way configurable. I may assume some polling is relied upon and wonder how exactly does it reach that determination of unavailability. In the same vein, I would like to ask whether actors perform any sort of retry of their own, in case they determine that they *failed* *sending or replying to *a message. Or is it the case that message sending is a one time attempt. Pointers to relevant source code are also welcome. Thanks in advance, Matan *P.S. in case relevant changes are on the roadmap, it would be also cool to know about it.* -- 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.
