[akka-user] Re: Akka Http Client - User-Agent header

[André]

Hi Marcin,

the user agent string is a config property and configured here 

.

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(s"Token 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

[Matan Safriel]

Hi,

I have read this other thread about the case of a remote being unavailable 
. 
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] is this a sensible problem for perdistence?

[Tim Pigden]

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] support for akka persistent plugins

[Tim Pigden]

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] Re: is this a sensible problem for persistence?

[Tim Pigden]

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.

[akka-user] akka-http respond with result of an actor call (java-api)

[Peter]

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: Actor lifecycle with regard to unresponsive actors

[bearrito]

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 
> . 
> 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.

Re: [akka-user] Getting strange error 2.4-Snapshot with stream+http 1.0-M2

[tigerfoot]

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 > 
> 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: 
>> ht

[akka-user] Re: Actor lifecycle with regard to unresponsive actors

[Matan Safriel]

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 
).
 
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 
> 
>
> 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 
>> . 
>> 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.

Re: [akka-user] Not loosing message due to remote actor unavailable.

[Matan Safriel]

Sorry for awakening this old thread... 
Is it really the case that there is all this fancy supervision 
architecture, and then a remote actor that has gone non-responsive, needs 
to be handled outside of the supervision hierarchy alltogether? was it 
considered enabling supervision to work such that the supervisor would know 
in case its remote child has gone unresponsive/gated/quarantined?

Perhaps I misinterpret the reference to the "cluster module" in the 
response by Dr. Roland Kuhn below.

Thanks for clarifying,
Matan

On Thursday, January 31, 2013 at 10:13:26 PM UTC+2, rkuhn wrote:
>
> Hi Juan Pablo,
>
> 30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:
>
> If a remote actor is not available due to power loss Can the supervision 
> strategy handle the situation?
>
>
> No, loss of actors is managed by the Death Watch (
> http://doc.akka.io/docs/akka/2.1.0/general/supervision.html#What_Lifecycle_Monitoring_Means
>  
> ),
>  
> but support for detecting unreachable remote nodes is only present in the 
> cluster module.
>
> I have coded the example and I have shut down the remote actor system but 
> it seems that the supervision strategy only takes into account Exceptions 
> thrown by the remote actor once reached.
>
>
> Yes, that is correct.
>
> I have already implemented the subscription to the events that indicates 
> that error in the connection have occurred. I still need to have access to 
> message the sender sent originally so the message do not get lost.
>
>
> There is nothing you can subscribe to which tells you whether a given 
> message was processed on the remote system. If you cannot lose messages 
> then you need to persist them and use explicit acknowledgements from the 
> receiving actor to retire them from the local storage. You will also need 
> to implement resending and deduplication if you need exactly-once delivery; 
> you might want to read the documentation on message delivery guarantees: 
> http://doc.akka.io/docs/akka/2.1.0/general/message-delivery-guarantees.html
>
> Regards,
>
> Roland
>
> JP.
>
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://akka.io/faq/
> >> 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 .
> To post to this group, send email to akka...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/akka-user?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Empowering professional developers to 
> build amazing apps.
> twitter: @rolandkuhn 
>  
>

-- 
>>  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: Unordered merge of 2..n streams created by groupBy

[Tim Harper]

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] File based mailbox - Files under _mb location grows large consistently without getting cleared

[aramankandath]

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] Re: File based mailbox - Files under _mb location grows large consistently without getting cleared

[aramankandath]

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.

Re: [akka-user] Akka Persistence on the Query Side: The Conclusion

[Jonas Bonér]

That is a great point Greg.

On Wed, Jan 7, 2015 at 10:15 PM, Greg Young  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
>  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 :
> >>
> >> 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  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

Re: [akka-user] Re: File based mailbox - Files under _mb location grows large consistently without getting cleared

[Jonas Bonér]

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,  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 
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)

[Patrik Nordwall]

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  -  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.