[akka-user] Again about tell don't ask and use Actor tell instead future

[Владимир Морозов]

Hi All,

this question about design, for example now I have some process that load 
task list and try process each task, it looks like this:

import scala.concurrent.{ExecutionContext, Future}


case class TaskId(processorName: String, id: String)

case class TaskDetails(id: TaskId, status: String, json: String)

trait DAO {
  def loadTaskIds(processorName: String): Future[Seq[TaskId]]

  def loadTaskDetails(id: TaskId): Future[Option[TaskDetails]]

  def deleteTask(id: TaskId): Future[Boolean]

  def markSuccess(id: TaskId): Future[Boolean]
}

class Processor(name: String, dao: DAO, implicit val ec: ExecutionContext) {
  def process(): Unit = {
dao
  .loadTaskIds(name)
  .map(_.map {
  case taskId =>
dao.loadTaskDetails(taskId).flatMap {
  case None =>
delete(taskId)
  case Some(task) if task.status == "success" =>
delete(taskId)
  case Some(task) =>
doProcess(task).flatMap {
  case true =>
dao.markSuccess(taskId).map {
  case true =>
Some(task)
  case false =>
// log.error(...)
None
}
  case false =>
// log.error(...)
Future.successful(None)
}
}
}).map {
  case processingFutures =>
Future.sequence(processingFutures).map(_.flatten).map {
  case completedTasks =>
  // log.info(s"Processing '$name' tasks, complete 
[${completedTasks.map(_.id).mkString(", ")}]")
}
}
  }

  private def doProcess(task: TaskDetails): Future[Boolean] = ???

  private def delete(taskId: TaskId): Future[Option[TaskDetails]] =
dao.deleteTask(taskId).map {
  case true =>
None
  case false =>
// log.error(...)
None
}
}


My question: how I need to change this code for getting 'True' Actor based 
application without using futures or ask pattern.

PS: I read that I need use only actor tell (!) but I can't understand how I 
can rewrite my logic and DAO as an actor.

With best regards, Vladimir.

-- 
>>  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: Problems using a Remote Actor

[Jim Hazen]

Have you followed all of the instructions for interacting with remote 
actors here: http://doc.akka.io/docs/akka/2.3.9/scala/remoting.html ?

>From the error it appears to me that:
1. You are attempting to create a remote actor from a peer
2. This peer isn't able to properly interact with [akka.tcp://
RemoteActorSystem-Client@127.0.0.1:55003]

Are you using a Remote or Clustered ActorRefProviders on both nodes?  Is 
your remote transport properly configured to run on those ports?  Is it 
starting properly? Is your networking configured to allow access to those 
ports (software firewalls on a node have burned me in the past).  Does the 
RemoteActorSystem-Client AS exist on that port, or is some other AS running 
there?  There's a lot to look at, but it ought to work once everything is 
wired properly.  Maybe look for a working example (from Activator) and then 
adapt the working thing to your needs?

-- 
>>  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: getting scala-zeromq (and/or akka-zeromq) to work with c++ program

[Patrik Nordwall]

Thanks for the update!
/Patrik

On Tue, Mar 10, 2015 at 5:56 PM, ankit master 
wrote:

> Found the solution, just in case anyone gets in the same spot as I was
> earlier, the problem is with the incompatibility between zmq 2.2 and zmq
> 4.0.4, although zmq website advertises zmq latest version stating it is
> backwards compatible it is NOT. when I stepped down my zmq version to 3.2.5
> my scala and c++ zmq programs started talking.
>
>
>
> On Monday, March 9, 2015 at 3:50:54 PM UTC-7, ankit master wrote:
>>
>> Hello,
>>
>> I am trying to get c++(publisher) to my scala(subscriber ) with little
>> luck, I tried using both akka-zeromq and scala-zeromq to get this working
>> with little luck. however, my program *does work* with *scala being the
>> publisher and c++ being the subscriber (but not other way around)*, can
>> anyone please help me figure out what I am doing wrong here !!
>>
>> The following code will not work, I dont get any messages over on scala
>> side, will be very grateful of any help here.
>>
>> / Scala Code  , zmq version 2.2
>>
>> import akka.actor._
>> import org.zeromq.ZMQ
>> import org.zeromq.ZMQ._
>>
>> object ZMQWithoutAkkaExtensionApp extends App {
>>   val numberOfMessages = 10
>>
>>   val system = ActorSystem("zmq")
>>   val subscriber = system.actorOf(Props[Sub])
>>   subscriber ! "start"
>> }
>>
>>
>> class Sub extends Actor {
>>   var contextZMQ: ZMQ.Context = null
>>   var subscriberSocket: ZMQ.Socket = null
>>
>>   override def preStart = {
>> contextZMQ = ZMQ.context(1)
>> subscriberSocket = contextZMQ.socket(ZMQ.SUB)
>> subscriberSocket.connect("tcp://localhost:1234")
>> subscriberSocket.subscribe("".getBytes())
>> Thread.sleep(1000)
>>   }
>>
>>   def receive = {
>> case msg => handleMessages
>>   }
>>
>>   private def handleMessages = {
>> while (true) {
>>   println("-")
>>   val request = subscriberSocket.recv(0)
>>   println(s"request : $request")
>>   val data = new String(request)
>>   println(s"data: $data" )
>> }
>>   }
>> }
>>
>>
>>
>>  C++ Code , zmq version 4.0.4
>>
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> using namespace std;
>> void Pub()
>> {
>> cout << " Running Pub " << endl;
>>
>> zmq::context_t context(1);
>> zmq::socket_t publisher(context, ZMQ_PUB);
>> publisher.bind("tcp://*:1234");
>>
>> Sleep(4000);
>> cout << " awake again " << endl;
>>
>> int cc = 0;
>> while (1) {
>> //  Write two messages, each with an envelope and content
>> string msg = " hello ";
>> zmq::message_t req(5);
>> memcpy((void *)req.data(), "World", 5);
>>
>> publisher.send(req);
>>  cout << cc++ << endl;
>>
>> Sleep(1000);
>> }
>> }
>>
>> int main()
>> {
>>
>> Pub();
>>
>> return 0;
>> }
>>
>>
>> Thank you
>> Sincerely,
>> AVM
>>
>  --
> >> 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

[image: Scala Days] 

-- 
>>  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: CORS Support Akka-http

[Tim Pigden]

This thread may help:
https://groups.google.com/forum/#!searchin/akka-user/cors/akka-user/msJfSkHDCxA/foDrnQPBx2gJ

I've not got around to looking at it yet.


On Tuesday, March 10, 2015 at 2:14:53 PM UTC, Ganta Murali Krishna wrote:
>
> Hello,
>
> I am currently experimenting with Akka-http on one of our modules. *Below 
> (or attached) is my current CORS file for spray*. I am struggling with 
> conversion, for e.g.: I cant find alternative to mapRequestContext. Can 
> any help me to rewrite/convert this please. So I can use this with 
> akka-http. Any help is appreciated.
>
> Regards
> Murali
>
> import spray.http.{HttpMethods, HttpMethod, HttpResponse, AllOrigins}
> import spray.http.HttpHeaders._
> import spray.http.HttpMethods._
> import spray.routing._
>
> trait CORSSupport {
>   this: HttpService =>
>   private val allowOriginHeader = `Access-Control-Allow-Origin`(AllOrigins)
>   private val optionsCorsHeaders = List(
> `Access-Control-Allow-Headers`("Origin, 
> X-Requested-With,Authorization,Content-Type, Accept, Accept-Encoding, 
> Accept-Language, Host, Referer, User-Agent,apiKey"),
> `Access-Control-Max-Age`(1728000))
>
>   def cors[T]: Directive0 = mapRequestContext { ctx => 
> ctx.withRouteResponseHandling({
> //It is an option requeset for a resource that responds to some other 
> method
> case Rejected(x) if (ctx.request.method.equals(HttpMethods.OPTIONS) && 
> !x.filter(_.isInstanceOf[MethodRejection]).isEmpty) => {
>   val allowedMethods: List[HttpMethod] = 
> x.filter(_.isInstanceOf[MethodRejection]).map(rejection => {
> rejection.asInstanceOf[MethodRejection].supported
>   })
>   ctx.complete(HttpResponse().withHeaders(
> `Access-Control-Allow-Methods`(OPTIONS, allowedMethods: _*) :: 
> allowOriginHeader ::
>   optionsCorsHeaders
>   ))
> }
>   }).withHttpResponseHeadersMapped { headers =>
> allowOriginHeader :: headers
>   }
>   }
> }
>
>

-- 
>>  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 http: how to change the response code?

[Mark Hatton]

Hi Yann,

There is an implicit conversion from a status code & entity tuple, thus 
this should work:
  complete(Created -> ast)

Similarly you can provide a Tuple3 with status code, response headers and 
entity.

Agree that the current API doesn't make this obvious.

Mark


On Tuesday, March 10, 2015 at 5:09:11 PM UTC, Yann Simon wrote:
>
> Hi,
>
> by using:
> import akka.http.marshallers.sprayjson.SprayJsonSupport._
> import spray.json.DefaultJsonProtocol._
>
> I can complete a http response with complete(ast) and the ast value is 
> marshalled into JSON.
>
> This response is default with the HTTP code OK.
> I'd like the change the HTTP code to Created for example.
> How can I do that?
>
> If I use:
> complete(HttpResponse(status = Created, entity = ast))
> it does not compile.
>
> I tried to find my way between all implicit conversions 
> to ToResponseMarshallable, ToResponseMarshaller and co and cannot find a 
> solution.
>
> Maybe somebody more experienced than me can guide me here?
>
> Cheers,
> Yann
>

-- 
>>  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: how to change the response code?

[Yann Simon]

Hi,

by using:
import akka.http.marshallers.sprayjson.SprayJsonSupport._
import spray.json.DefaultJsonProtocol._

I can complete a http response with complete(ast) and the ast value is
marshalled into JSON.

This response is default with the HTTP code OK.
I'd like the change the HTTP code to Created for example.
How can I do that?

If I use:
complete(HttpResponse(status = Created, entity = ast))
it does not compile.

I tried to find my way between all implicit conversions
to ToResponseMarshallable, ToResponseMarshaller and co and cannot find a
solution.

Maybe somebody more experienced than me can guide me here?

Cheers,
Yann

-- 
>>  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: akka-http: combine path together

[Yann Simon]

Do you mean, instead of:
 path("v2.0") {
path("tokens") {
  post {
complete("it does not work")
  }
}
  }

writing:
 path("v2.0") ~
path("tokens") {
  post {
complete("it does not work")
  }
  }

This does not compile AFAIK.

Le mar. 10 mars 2015 à 15:59, Jim Hazen  a écrit :

> You're missing the route concatenation operator ~ between the two Path
> directives.
>
> --
> >>  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.
>

-- 
>>  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: Problems using a Remote Actor

[Sandro Martini]

Hi Patrik, 
thanks for the info ... I tried your suggestion both with Akka-2.2.5 and 
2.3.9 but I still have some error, this is the log from 2.3.9:

remote actor lookup using actor selection
Get Actor Selection to greetingActor: 
ActorSelection[Anchor(akka.tcp://RemoteActorSystem@127.0.0.1:2552/), 
Path(/user/greetingActor)]
[WARN] [03/10/2015 16:12:32.607] 
[RemoteActorSystem-akka.remote.default-remote-dispatcher-6] 
[akka.tcp://RemoteActorSystem@127.0.0.1:2552/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FRemoteActorSystem-Client%40127.0.0.1%3A55003-0]
 
Association with remote system 
[akka.tcp://RemoteActorSystem-Client@127.0.0.1:55003] has failed, address 
is now gated for [5000] ms. Reason is: [exception during creation].remote 
actor 

whatr does it mean ? my actor should be Serializable ?

lookup using actor for
[INFO] [03/10/2015 16:12:33.000] 
[RemoteActorSystem-akka.actor.default-dispatcher-15] 
[akka://RemoteActorSystem/user/greetingActor] java.lang.String: "Test 
Remote"
[INFO] [03/10/2015 16:12:33.001] 
[RemoteActorSystem-akka.actor.default-dispatcher-2] 
[akka://RemoteActorSystem/deadLetters] Message [java.lang.String] from 
Actor[akka://RemoteActorSystem/user/greetingActor#2062187471] to 
Actor[akka://RemoteActorSystem/deadLetters] was not delivered. [3] dead 
letters encountered. This logging can be turned off or adjusted with 
configuration settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.

as you can see using actorFor something seems to be a little better but 
still not working ...


I really don't understand what could be wrong in my code ... please help me 
to make it work :-) .
Should I open an issue ?


Thanks a lot,
Sandro


Il giorno martedì 10 marzo 2015 15:07:51 UTC+1, Patrik Nordwall ha scritto:
>
> Hi Sandro,
>
> This looks bad:
> [ERROR] [03/04/2015 19:04:36.647] 
> [RemoteActorSystem-akka.actor.default-dispatcher-2] 
> [akka://RemoteActorSystem/system/endpointManager/reliableEnd
> pointWriter-akka.tcp%3A%2F%2FRemoteActorSystem-Client%
> 40127.0.0.1%3A63830-0/endpointWriter] changing Recreate into Create after 
> akka.actor.ActorInitializationException: exception during creation
>
> Try with serialize-creators = off and serialize-messages = off.
>
> It might be an issue with these settings that has been fixed in 2.3.x.
>
> /Patrik
>
> On Tue, Mar 10, 2015 at 10:32 AM, Sandro Martini  > wrote:
>
>> Hi, sorry but even after some small changes I'm still stuck with the 
>> problem, tried with Akka-2.2.4, 2.2.5, 2.3.9 .
>> From local actor system all works good.
>>
>> I don't really understand the error when using remote actor with 
>> actorSelection:
>>
>> [ERROR] [03/09/2015 18:33:44.918] 
>> [RemoteActorSystem-akka.actor.default-dispatcher-3] 
>> [akka://RemoteActorSystem/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FRemoteActorSystem-Client%40127.0.0.1%3A57311-0/endpointWriter]
>>  
>> changing Recreate into Create after 
>> akka.actor.ActorInitializationException: exception during creation
>>
>> Instead, using the deprecated methos (actorFor) I don't have the error, 
>> but messages goes to deadLetters, so maybe even in this case there is 
>> something to fix ...
>> The source for the "server" is here:
>>
>> https://github.com/smartiniOnGitHub/akka-tests/blob/master/akka-tests-java/src/main/java/akka_tests/java/server/AkkaRemoteServer.java
>>
>> Someone can give me some hint ?
>>
>> Thanks a lot,
>> Sandro
>>
>>
>>
>> Il giorno giovedì 5 marzo 2015 18:52:55 UTC+1, Sandro Martini ha scritto:
>>>
>>> Hi all,
>>> I'm doing some tests with Akka Remote Actors, but I'm in trouble with 
>>> some strange problem, but I think it's something that I'm doing in the 
>>> wrong way ...
>>>
>>> I'm using Akka-2.2.4 (tomorrow I'll update to 2.2.5) with an updated JDK 
>>> 7 on Windows 7.
>>> My sources are here: https://github.com/smartiniOnGitHub/akka-tests
>>> the project is a Gradle (2.3) multi-project, because I'm trying to make 
>>> it work with Java and then to port all in Groovy (and then in Scala), so 
>>> please now let's focus on the Java version.
>>>
>>> The make some test, you can run the following commands (under Windows):
>>>
>>> rem cls && gradle tasks
>>> cls && gradle clean build --refresh-dependencies
>>> cls && gradle runJavaAkkaRemoteServer
>>> or
>>> cls && start gradle runJavaAkkaRemoteServer
>>> cls && gradle runJavaAkkaRemoteClient
>>>
>>> Anyway the "server" source is here: 
>>> https://github.com/smartiniOnGitHub/akka-tests/
>>> blob/master/akka-tests-java/src/main/java/akka_tests/java/
>>> server/AkkaRemoteServer.java
>>>
>>> When I run the "server", I get this:
>>>
>>> :akka-tests-java:runJavaAkkaRemoteServer
>>> Application: main, start a simple server console application for 
>>> creating some Akka Actors and make them reachable from other (remote) 
>>> processes
>>>
>>> setup: start at Wed Mar 04 19:04:33 CET 2015.
>>> Akka Config: akka {
>>> loglevel = "INFO"
>>> actor {
>>> provid

Re: [akka-user] Cluster: Multiple leaders / ReachableMember not propagated / ...?

[Patrik Nordwall]

What was puzzling me was:
Cluster Node [akka.tcp://...Node4...] - Marking node(s) as REACHABLE
[Member(address = akka.tcp://Node1..., status = Up)]

but looking at the code revealed that this is only an notification that
Node4 thinks that Node1 is reachable again. The ReachableMember event is
fired when all thinks it is reachable again, and that will not happen until
Node3 is back in business or removed.

/Patrik

On Tue, Mar 10, 2015 at 3:43 PM, michaels  wrote:

> Hello Patrik,
>
> added the output of ClusterStatus below,
>
>
>> == Test Steps: ==
>>> 1.) Start 4 JVMs (all on local host) - Nodes form a cluster - Leader  =
>>> 1 - same information on all nodes (VisualVM MBean akka.cluster)
>>> 2.) With Sys-Internal Process Explorer Suspend Process of Node 1
>>> 3.) Looking with Java VisualVM on akka.cluster MBeans
>>> 4.) Waiting for all other nodes (2,3,4) to mark 1 as Unreachable. New
>>> Leader is now 2.
>>> 5.) With Sys-Internal Process Explorer Suspend Process of Node 3
>>> 6.) Waiting for all other working nodes (2,4) to mark 3 also as
>>> Unreachable. Leader is still 2.
>>> 7.) With Sys-Internal Process Explorer Resume Process of Node 1
>>>
>>> Now strange things happen/can be seen:
>>> JMX MBean akka.cluster:
>>> - Node 1: MemberStatus=Up, Leader = 1 / Unreachable = Node 3
>>> - Node 2: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
>>> - Node 4: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
>>>
>>> It seems there are multiple leaders in the cluster.
>>> Node 1 thinks almost everything is fine and believes it is the leader of
>>> the cluster.
>>> This state does not change, even after a long time...(30 minutes+, no
>>> application load on cluster, just the cluster running.)
>>>
>>
> Additional info from JMX MBean akka.cluster - ClusterStatus
> Node 1:
> "unreachable" : [{
> "node" : "akka.tcp://Node3",
> "observed-by" : ["akka.tcp://...Node1"]
> }
>
> Node4:
> "unreachable" : [{
> "node" : "akka.tcp://...Node1",
> "observed-by" : ["akka.tcp://...Node3"]
> }, {
> "node" : "akka.tcp://...Node3",
> "observed-by" : ["akka.tcp://...Node1", "akka.tcp://Node2"
> , "akka.tcp://...Node4"]
> }
> ]
>
> So...Node 4 still believes Node 1 is unreachable, because the - now
> unreachable - Node 3 has told it so.
>
>
> There can be multiple leaders. The leader is simply the member with lowest
>> address among the currently reachable members (as seen from a specific
>> node). There are some more rules regarding member status, but that is
>> irrelevant for this.
>>
>
> Thanks for the clarification. If you don't see a problem with that, i will
> not do it either :-)
>
>
>
>>> - Is the JMX MBean akka.cluster showing wrong information in this case?
>>> As pointed out above there is no ReachableMember event after "the marking
>>> node as REACHABLE" trace in this case. Maybe the component preparing the
>>> MBean information is also missing the event?
>>>
>>
>> That is interesting. You should receive the ReachableMember. The MBean
>> also subscribes to these events. If you look at clusterStatus you should
>> see more information about who thinks that it is still unreachable.
>>
>
>> /Patrik
>>
>
> Thanks for the hint - i have not yet discovered the observed-by-part.
>
> The event is not received. And it believe it is also not received by the
> MBean.
> However when Step 8 is performed (see example in original post), we
> immediately receive the event after the "the marking node as REACHABLE"
> trace. (And also the MBean receives it, because afterwards no more
> unreachable nodes in the list anywhere).
>
> Maybe there might be reasons why Node 4 (and Node 2) keep the reachable
> Node 1 as Unreachable (so they don't want to emit the event to the
> listeners like our actor or the MBean) or?
>
> Or the trace "Ignoring received gossip from unreachable" is a hint?
> Shouldn't the algorithm trust Node 1 more than Node 3 (Node 1 which was
> Unreachable but it is now in fact talking to me...than Node 3 who has told
> me something a long time ago but is now unreachable).
>
>
> Best regards,
>
> Michael
>
>   --
> >> 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

[image: Scala Days] 

[akka-user] Testing actors expectMsgType[HttpResponse] with matchers gives different results when using "should equal" or triple equal sign '==='

[Avi Levi]

Hi,
I am not sure where is the right place to put this , but after banging my 
head against the wall trying to figure out why my tests are not working is 
expected, I thought it's worth sharing.
I have noticed that my test pass with this assertion 

expectMsgType[HttpResponse].status === StatusCodes.OK but also with this 
expectMsgType[HttpResponse].status === StatusCodes.*BadRequest *pass the test. 

I have noticed that the triple equality accepts all status codes, however using 
"Should" works as expected 

expectMsgType[HttpResponse].status should equal(StatusCodes.OK)


*did I do something wrong or is a bug ?*


*best *

*Avi*

-- 
>>  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-http: combine path together

[Jim Hazen]

You're missing the route concatenation operator ~ between the two Path 
directives. 

-- 
>>  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: akka-persistance - nested persist

[Patrik Nordwall]

On Tue, Mar 10, 2015 at 3:03 PM, Manuel Bernhardt <
bernhardt.man...@gmail.com> wrote:

> Hi!
>
> And sorry for the late reply. We discussed this at LambdaDays with Konrad,
> it's only normal this doesn't work. I'm exploring other alternatives for
> simulating the change in the most lazy possible manner.
>
> A quick clarification: I'm working on a reservation system, and quite a
> number of events can have an impact on available quota. When one of those
> events is persisted I need to look up the impact the quota change has on a
> waiting-list, and promote waiting-list entries accordingly. That should
> happen before any other reservation could slip in and fetch a spot that
> would have been assigned to one of the waiting-list entries.
>
> I am fully aware that the correct way is to simulate what is going to
> happen before persisting any of those events and persist the event and
> eventual promotions of the waiting-list entries in one go.
>
> Out of curiosity (not that my case requires it, but I am wondering about
> it nonetheless): is there a way to persist a batch of events that are
> connected, so that if the Nth isn't persisted we get to roll back on the
> whole batch and don't end up with inconsistent state?
>

The documented behaviour is: "All events that are persisted in context of a
single command are written as a single batch to the journal (even if
persist is called multiple times per command). The recovery of a
PersistentActor will therefore never be done partially (with only a subset
of events persisted by a single command)."

We have not enforced that in the TCK, so I'm not sure all journals
implement it that way. We will think about this more and consider if we
need some other atomic batch concept. See issue:
https://github.com/akka/akka/issues/15377


>
> Thanks,
>
> Manuel
>
>
> On Mon, Mar 2, 2015 at 9:06 AM, Patrik Nordwall  > wrote:
>
>> I think this is a known issue 
>> .
>>
>> On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski 
>> wrote:
>>
>>> Hi Manuel,
>>> as discussed on LambdaDays today: this won't work, because what
>>> guarantees persist() is meant to give.
>>> Instead you could become() and then do things inside there, or send
>>> other commands to yourself to which the actor should react.
>>>
>>> On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
>>> wrote:
>>>
 I am not sure I understand what you are trying to accomplish. Don't you
 know the consequences of the state change before you do a persist? You
 could calculate all the changes you want to do, and them persist them in
 order...

 Regards,

 Anders

 fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:

> Hi,
>
> I'm in a situation where it would be lovely to be able to do a "nested
> persist", i.e.:
>
> persist(SomeEvent)(handle)
>
> ...
>
> def handle = {
>   case SomeEvent =>
> changeState()
> stateChangeConsequences().foreach { _ =>
>   persist(SomeOtherEvent)(handle)
> }
> }
>
> According to a quick experimentation this does not seem to be quite
> working. The reason I am looking for this kind of perhaps not entirely
> ethical behaviour (commands should create events, not event creating
> events, if I got things correctly) is that I need SomeOtherEvent to be
> fired right away without giving the chance to someone else to come in (I'm
> building a reservation system and this part is about waiting-list 
> handling).
>
> The other possible option would be to simulate state change and revert
> it before persisting SomeEvent, but it would considerably complicate the
> flow (the example above is oversimplified and there's already a simulation
> going on).
>
> Is there any recommended approach for this kind of behaviour?
>
> Thanks,
>
> Manuel
>
>
  --
 >> 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.

>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso' Malawski
>>> Akka  @ Typesafe 
>>>
>>> JOIN US. REGISTER TODAY!
>>> 
>>> Scala 
>>> Days 
>>

Re: [akka-user] Re: akka-persistance - nested persist

[Greg Young]

In terms of engines supporting. Event Store as an example supports
transactions between multiple requests that could support exactly this.

eg

begin transaction
write
write
write
write
commit / rollback

and it can be between multiple actors so long as the transaction id is
shared between them. There is a limitation that they must be in the same
stream but thats easy to work around.

That said we have considered removing this functionality as its not so much
something you should be doing.




>From a more general level on the problem (in terms of interactions leaving
out all technology). Could you wait until the coordination is done before
ack/naking the end user and use a coordinator/process manager to coordinate
the work internally rolling back if need be?

Cheers,

Greg

On Tue, Mar 10, 2015 at 4:57 PM, Patrik Nordwall 
wrote:

>
>
> On Tue, Mar 10, 2015 at 3:03 PM, Manuel Bernhardt <
> bernhardt.man...@gmail.com> wrote:
>
>> Hi!
>>
>> And sorry for the late reply. We discussed this at LambdaDays with
>> Konrad, it's only normal this doesn't work. I'm exploring other
>> alternatives for simulating the change in the most lazy possible manner.
>>
>> A quick clarification: I'm working on a reservation system, and quite a
>> number of events can have an impact on available quota. When one of those
>> events is persisted I need to look up the impact the quota change has on a
>> waiting-list, and promote waiting-list entries accordingly. That should
>> happen before any other reservation could slip in and fetch a spot that
>> would have been assigned to one of the waiting-list entries.
>>
>> I am fully aware that the correct way is to simulate what is going to
>> happen before persisting any of those events and persist the event and
>> eventual promotions of the waiting-list entries in one go.
>>
>> Out of curiosity (not that my case requires it, but I am wondering about
>> it nonetheless): is there a way to persist a batch of events that are
>> connected, so that if the Nth isn't persisted we get to roll back on the
>> whole batch and don't end up with inconsistent state?
>>
>
> The documented behaviour is: "All events that are persisted in context of
> a single command are written as a single batch to the journal (even if
> persist is called multiple times per command). The recovery of a
> PersistentActor will therefore never be done partially (with only a subset
> of events persisted by a single command)."
>
> We have not enforced that in the TCK, so I'm not sure all journals
> implement it that way. We will think about this more and consider if we
> need some other atomic batch concept. See issue:
> https://github.com/akka/akka/issues/15377
>
>
>>
>> Thanks,
>>
>> Manuel
>>
>>
>> On Mon, Mar 2, 2015 at 9:06 AM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>>> I think this is a known issue
>>> .
>>>
>>> On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski 
>>> wrote:
>>>
 Hi Manuel,
 as discussed on LambdaDays today: this won't work, because what
 guarantees persist() is meant to give.
 Instead you could become() and then do things inside there, or send
 other commands to yourself to which the actor should react.

 On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
 wrote:

> I am not sure I understand what you are trying to accomplish. Don't
> you know the consequences of the state change before you do a persist? You
> could calculate all the changes you want to do, and them persist them in
> order...
>
> Regards,
>
> Anders
>
> fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:
>
>> Hi,
>>
>> I'm in a situation where it would be lovely to be able to do a
>> "nested persist", i.e.:
>>
>> persist(SomeEvent)(handle)
>>
>> ...
>>
>> def handle = {
>>   case SomeEvent =>
>> changeState()
>> stateChangeConsequences().foreach { _ =>
>>   persist(SomeOtherEvent)(handle)
>> }
>> }
>>
>> According to a quick experimentation this does not seem to be quite
>> working. The reason I am looking for this kind of perhaps not entirely
>> ethical behaviour (commands should create events, not event creating
>> events, if I got things correctly) is that I need SomeOtherEvent to be
>> fired right away without giving the chance to someone else to come in 
>> (I'm
>> building a reservation system and this part is about waiting-list 
>> handling).
>>
>> The other possible option would be to simulate state change and
>> revert it before persisting SomeEvent, but it would considerably 
>> complicate
>> the flow (the example above is oversimplified and there's already a
>> simulation going on).
>>
>> Is there any recommended approach for this kind of behaviour?
>>
>> Thanks,
>>
>> Manuel
>>
>>
>  --
> >

Re: [akka-user] Cluster: Multiple leaders / ReachableMember not propagated / ...?

[michaels]

Hello Patrik,

added the output of ClusterStatus below,
 

> == Test Steps: ==
>> 1.) Start 4 JVMs (all on local host) - Nodes form a cluster - Leader  = 1 
>> - same information on all nodes (VisualVM MBean akka.cluster)
>> 2.) With Sys-Internal Process Explorer Suspend Process of Node 1
>> 3.) Looking with Java VisualVM on akka.cluster MBeans
>> 4.) Waiting for all other nodes (2,3,4) to mark 1 as Unreachable. New 
>> Leader is now 2.
>> 5.) With Sys-Internal Process Explorer Suspend Process of Node 3
>> 6.) Waiting for all other working nodes (2,4) to mark 3 also as 
>> Unreachable. Leader is still 2.
>> 7.) With Sys-Internal Process Explorer Resume Process of Node 1
>>
>> Now strange things happen/can be seen:
>> JMX MBean akka.cluster:
>> - Node 1: MemberStatus=Up, Leader = 1 / Unreachable = Node 3
>> - Node 2: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
>> - Node 4: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
>>
>> It seems there are multiple leaders in the cluster.
>> Node 1 thinks almost everything is fine and believes it is the leader of 
>> the cluster.
>> This state does not change, even after a long time...(30 minutes+, no 
>> application load on cluster, just the cluster running.)
>>
>
Additional info from JMX MBean akka.cluster - ClusterStatus
Node 1:
"unreachable" : [{
"node" : "akka.tcp://Node3",
"observed-by" : ["akka.tcp://...Node1"]
}

Node4:
"unreachable" : [{
"node" : "akka.tcp://...Node1",
"observed-by" : ["akka.tcp://...Node3"]
}, {
"node" : "akka.tcp://...Node3",
"observed-by" : ["akka.tcp://...Node1", "akka.tcp://Node2", 
"akka.tcp://...Node4"]
}
]

So...Node 4 still believes Node 1 is unreachable, because the - now 
unreachable - Node 3 has told it so. 


There can be multiple leaders. The leader is simply the member with lowest 
> address among the currently reachable members (as seen from a specific 
> node). There are some more rules regarding member status, but that is 
> irrelevant for this.
>

Thanks for the clarification. If you don't see a problem with that, i will 
not do it either :-)



>> - Is the JMX MBean akka.cluster showing wrong information in this case? 
>> As pointed out above there is no ReachableMember event after "the marking 
>> node as REACHABLE" trace in this case. Maybe the component preparing the 
>> MBean information is also missing the event?
>>
>
> That is interesting. You should receive the ReachableMember. The MBean 
> also subscribes to these events. If you look at clusterStatus you should 
> see more information about who thinks that it is still unreachable.
>

> /Patrik
>

Thanks for the hint - i have not yet discovered the observed-by-part.

The event is not received. And it believe it is also not received by the 
MBean. 
However when Step 8 is performed (see example in original post), we 
immediately receive the event after the "the marking node as REACHABLE" 
trace. (And also the MBean receives it, because afterwards no more 
unreachable nodes in the list anywhere).

Maybe there might be reasons why Node 4 (and Node 2) keep the reachable 
Node 1 as Unreachable (so they don't want to emit the event to the 
listeners like our actor or the MBean) or?

Or the trace "Ignoring received gossip from unreachable" is a hint? 
Shouldn't the algorithm trust Node 1 more than Node 3 (Node 1 which was 
Unreachable but it is now in fact talking to me...than Node 3 who has told 
me something a long time ago but is now unreachable).


Best regards,

Michael

 

-- 
>>  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] CORS Support Akka-http

[Ganta Murali Krishna]

Hello,

I am currently experimenting with Akka-http on one of our modules. *Below 
(or attached) is my current CORS file for spray*. I am struggling with 
conversion, for e.g.: I cant find alternative to mapRequestContext. Can any 
help me to rewrite/convert this please. So I can use this with akka-http. 
Any help is appreciated.

Regards
Murali

import spray.http.{HttpMethods, HttpMethod, HttpResponse, AllOrigins}
import spray.http.HttpHeaders._
import spray.http.HttpMethods._
import spray.routing._

trait CORSSupport {
  this: HttpService =>
  private val allowOriginHeader = `Access-Control-Allow-Origin`(AllOrigins)
  private val optionsCorsHeaders = List(
`Access-Control-Allow-Headers`("Origin, 
X-Requested-With,Authorization,Content-Type, Accept, Accept-Encoding, 
Accept-Language, Host, Referer, User-Agent,apiKey"),
`Access-Control-Max-Age`(1728000))

  def cors[T]: Directive0 = mapRequestContext { ctx => 
ctx.withRouteResponseHandling({
//It is an option requeset for a resource that responds to some other method
case Rejected(x) if (ctx.request.method.equals(HttpMethods.OPTIONS) && 
!x.filter(_.isInstanceOf[MethodRejection]).isEmpty) => {
  val allowedMethods: List[HttpMethod] = 
x.filter(_.isInstanceOf[MethodRejection]).map(rejection => {
rejection.asInstanceOf[MethodRejection].supported
  })
  ctx.complete(HttpResponse().withHeaders(
`Access-Control-Allow-Methods`(OPTIONS, allowedMethods: _*) :: 
allowOriginHeader ::
  optionsCorsHeaders
  ))
}
  }).withHttpResponseHeadersMapped { headers =>
allowOriginHeader :: headers
  }
  }
}

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


CORSSupport.scala
Description: Binary data

[akka-user] akka-http: combine path together

[Yann Simon]

Hi,

when I combine path together, the resource is never found:
path("v2.0" / "tokens") {
  post {
complete("it works")
  }
}

  path("v2.0") {
path("tokens") {
  post {
complete("it does not work")
  }
}
  }

Am I missing something?

Cheers, Yann

-- 
>>  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-http: combine path together

[Yann Simon]

I answer to myself: for this, I can use pathPrefix.

It'd be great if composing path would work, or would not compile, forcing
to use pathPrefix for this.


Le mar. 10 mars 2015 à 11:55, Yann Simon  a écrit :

> Hi,
>
> when I combine path together, the resource is never found:
> path("v2.0" / "tokens") {
>   post {
> complete("it works")
>   }
> }
>
>   path("v2.0") {
> path("tokens") {
>   post {
> complete("it does not work")
>   }
> }
>   }
>
> Am I missing something?
>
> Cheers, Yann
>

-- 
>>  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: Problems using a Remote Actor

[Patrik Nordwall]

Hi Sandro,

This looks bad:
[ERROR] [03/04/2015 19:04:36.647]
[RemoteActorSystem-akka.actor.default-dispatcher-2]
[akka://RemoteActorSystem/system/endpointManager/reliableEnd
pointWriter-akka.tcp%3A%2F%2FRemoteActorSystem-Client%40127.0.0.1%3A63830-0/
endpointWriter] changing Recreate into Create after akka.actor.
ActorInitializationException: exception during creation

Try with serialize-creators = off and serialize-messages = off.

It might be an issue with these settings that has been fixed in 2.3.x.

/Patrik

On Tue, Mar 10, 2015 at 10:32 AM, Sandro Martini 
wrote:

> Hi, sorry but even after some small changes I'm still stuck with the
> problem, tried with Akka-2.2.4, 2.2.5, 2.3.9 .
> From local actor system all works good.
>
> I don't really understand the error when using remote actor with
> actorSelection:
>
> [ERROR] [03/09/2015 18:33:44.918]
> [RemoteActorSystem-akka.actor.default-dispatcher-3]
> [akka://RemoteActorSystem/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FRemoteActorSystem-Client%40127.0.0.1%3A57311-0/endpointWriter]
> changing Recreate into Create after
> akka.actor.ActorInitializationException: exception during creation
>
> Instead, using the deprecated methos (actorFor) I don't have the error,
> but messages goes to deadLetters, so maybe even in this case there is
> something to fix ...
> The source for the "server" is here:
>
> https://github.com/smartiniOnGitHub/akka-tests/blob/master/akka-tests-java/src/main/java/akka_tests/java/server/AkkaRemoteServer.java
>
> Someone can give me some hint ?
>
> Thanks a lot,
> Sandro
>
>
>
> Il giorno giovedì 5 marzo 2015 18:52:55 UTC+1, Sandro Martini ha scritto:
>>
>> Hi all,
>> I'm doing some tests with Akka Remote Actors, but I'm in trouble with
>> some strange problem, but I think it's something that I'm doing in the
>> wrong way ...
>>
>> I'm using Akka-2.2.4 (tomorrow I'll update to 2.2.5) with an updated JDK
>> 7 on Windows 7.
>> My sources are here: https://github.com/smartiniOnGitHub/akka-tests
>> the project is a Gradle (2.3) multi-project, because I'm trying to make
>> it work with Java and then to port all in Groovy (and then in Scala), so
>> please now let's focus on the Java version.
>>
>> The make some test, you can run the following commands (under Windows):
>>
>> rem cls && gradle tasks
>> cls && gradle clean build --refresh-dependencies
>> cls && gradle runJavaAkkaRemoteServer
>> or
>> cls && start gradle runJavaAkkaRemoteServer
>> cls && gradle runJavaAkkaRemoteClient
>>
>> Anyway the "server" source is here:
>> https://github.com/smartiniOnGitHub/akka-tests/
>> blob/master/akka-tests-java/src/main/java/akka_tests/java/
>> server/AkkaRemoteServer.java
>>
>> When I run the "server", I get this:
>>
>> :akka-tests-java:runJavaAkkaRemoteServer
>> Application: main, start a simple server console application for creating
>> some Akka Actors and make them reachable from other (remote) processes
>>
>> setup: start at Wed Mar 04 19:04:33 CET 2015.
>> Akka Config: akka {
>> loglevel = "INFO"
>> actor {
>> provider = "akka.remote.RemoteActorRefProvider"
>> }
>> remote {
>> enabled-transports = ["akka.remote.netty.tcp"]
>> netty.tcp {
>> hostname = "127.0.0.1"
>> # Server, listen on default Akka tcp port (2552)
>> port = 2552
>> }
>> log-sent-messages = on
>> log-received-messages = on
>> log-remote-lifecycle-events = on
>> log-frame-size-exceeding = on
>> # log-buffer-size-exceeding = 5
>> }
>> }
>> using Java ClassLoader: sun.misc.Launcher$AppClassLoader@187aeca
>> using Akka version: 2.2.4
>> Actor System configuration: Config(SimpleConfigObject({"
>> akka":{"loglevel":"INFO","remote":{"log-remote-
>> lifecycle-events":"on","netty":{"tcp":{"port":2552,"
>> hostname":"127.0.0.1"}},"enabled-transports":["akka.
>> remote.netty.tcp"],"log-frame-size-exceeding":"on","log-
>> sent-messages":"on","log-received-messages":"on"},"
>> actor":{"provider":"akka.remote.RemoteActorRefProvider"}}}))
>> [INFO] [03/04/2015 19:04:34.241] [main] [Remoting] Starting remoting
>> [INFO] [03/04/2015 19:04:34.408] [main] [Remoting] Remoting started;
>> listening on addresses :[akka.tcp://RemoteActorSystem@127.0.0.1:2552]
>> [INFO] [03/04/2015 19:04:34.410] [main] [Remoting] Remoting now listens
>> on addresses: [akka.tcp://RemoteActorSystem@127.0.0.1:2552]
>> Actor System instance: akka://RemoteActorSystem
>> props: 
>> Props(Deploy(,Config(SimpleConfigObject({})),NoRouter,NoScopeGiven,,),class
>> akka_tests.java.actor.GreetingActor,List())
>> setup: end at Wed Mar 04 19:04:34 CET 2015.
>> Get Actor Reference to greetingActor: Actor[akka://
>> RemoteActorSystem/user/greetingActor#-1752332594]
>> setup: end at Wed Mar 04 19:04:35 CET 2015.
>> check: start at Wed Mar 04 19:04:35 CET 2015.
>> Actor Reference instance is: Actor[akka://RemoteActorSystem/user/$a#-
>> 314651576]
>> [INFO] [03/04/2015 19:04:35.429] 
>>

Re: [akka-user] Re: akka-persistance - nested persist

[Manuel Bernhardt]

Hi!

And sorry for the late reply. We discussed this at LambdaDays with Konrad,
it's only normal this doesn't work. I'm exploring other alternatives for
simulating the change in the most lazy possible manner.

A quick clarification: I'm working on a reservation system, and quite a
number of events can have an impact on available quota. When one of those
events is persisted I need to look up the impact the quota change has on a
waiting-list, and promote waiting-list entries accordingly. That should
happen before any other reservation could slip in and fetch a spot that
would have been assigned to one of the waiting-list entries.

I am fully aware that the correct way is to simulate what is going to
happen before persisting any of those events and persist the event and
eventual promotions of the waiting-list entries in one go.

Out of curiosity (not that my case requires it, but I am wondering about it
nonetheless): is there a way to persist a batch of events that are
connected, so that if the Nth isn't persisted we get to roll back on the
whole batch and don't end up with inconsistent state?

Thanks,

Manuel


On Mon, Mar 2, 2015 at 9:06 AM, Patrik Nordwall 
wrote:

> I think this is a known issue .
>
> On Thu, Feb 26, 2015 at 2:00 PM, Konrad Malawski 
> wrote:
>
>> Hi Manuel,
>> as discussed on LambdaDays today: this won't work, because what
>> guarantees persist() is meant to give.
>> Instead you could become() and then do things inside there, or send other
>> commands to yourself to which the actor should react.
>>
>> On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand 
>> wrote:
>>
>>> I am not sure I understand what you are trying to accomplish. Don't you
>>> know the consequences of the state change before you do a persist? You
>>> could calculate all the changes you want to do, and them persist them in
>>> order...
>>>
>>> Regards,
>>>
>>> Anders
>>>
>>> fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:
>>>
 Hi,

 I'm in a situation where it would be lovely to be able to do a "nested
 persist", i.e.:

 persist(SomeEvent)(handle)

 ...

 def handle = {
   case SomeEvent =>
 changeState()
 stateChangeConsequences().foreach { _ =>
   persist(SomeOtherEvent)(handle)
 }
 }

 According to a quick experimentation this does not seem to be quite
 working. The reason I am looking for this kind of perhaps not entirely
 ethical behaviour (commands should create events, not event creating
 events, if I got things correctly) is that I need SomeOtherEvent to be
 fired right away without giving the chance to someone else to come in (I'm
 building a reservation system and this part is about waiting-list 
 handling).

 The other possible option would be to simulate state change and revert
 it before persisting SomeEvent, but it would considerably complicate the
 flow (the example above is oversimplified and there's already a simulation
 going on).

 Is there any recommended approach for this kind of behaviour?

 Thanks,

 Manuel


>>>  --
>>> >> 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.
>>>
>>
>>
>>
>> --
>> Cheers,
>> Konrad 'ktoso' Malawski
>> Akka  @ Typesafe 
>>
>> JOIN US. REGISTER TODAY!
>> 
>> Scala 
>> Days 
>> March 16th-18th, 
>> San Francisco 
>>
>> --
>> >> 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/opto

Re: [akka-user] Cluster: Multiple leaders / ReachableMember not propagated / ...?

[Patrik Nordwall]

Hi Michael,

On Tue, Mar 10, 2015 at 1:15 PM, michaels  wrote:

> Hello.
>
> We did tests with akka cluster and Unreachable / Reachable state and
> discovered the following reproducible behaviour, which might be a problem -
> but still unsure :-)
>
> == Environment: ==
> - Could be reproduced with 2.3.7 as well as with 2.3.9
> - Cluster with 4 nodes, seed nodes = 1,2,3
> - config: both akka.remote and akka.cluster:
> watch-failure-detector.threshold = 12.0, .acceptable-heartbeat-pause =  30 s
> - config: auto-downing off,
> actor.provider="akka.cluster.ClusterActorRefProvider" and
> akka.remote.enabled-transports =["akka.remote.netty.tcp"]
>
> == Test Steps: ==
> 1.) Start 4 JVMs (all on local host) - Nodes form a cluster - Leader  = 1
> - same information on all nodes (VisualVM MBean akka.cluster)
> 2.) With Sys-Internal Process Explorer Suspend Process of Node 1
> 3.) Looking with Java VisualVM on akka.cluster MBeans
> 4.) Waiting for all other nodes (2,3,4) to mark 1 as Unreachable. New
> Leader is now 2.
> 5.) With Sys-Internal Process Explorer Suspend Process of Node 3
> 6.) Waiting for all other working nodes (2,4) to mark 3 also as
> Unreachable. Leader is still 2.
> 7.) With Sys-Internal Process Explorer Resume Process of Node 1
>
> Now strange things happen/can be seen:
> JMX MBean akka.cluster:
> - Node 1: MemberStatus=Up, Leader = 1 / Unreachable = Node 3
> - Node 2: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
> - Node 4: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
>
> It seems there are multiple leaders in the cluster.
> Node 1 thinks almost everything is fine and believes it is the leader of
> the cluster.
> This state does not change, even after a long time...(30 minutes+, no
> application load on cluster, just the cluster running.)
>
> == Additional Info from Traces: ==
> When Node 1 is resumed (Step 7) Node Node 4 prints the following
> (shortened):
>
> Cluster Node [akka.tcp://...Node4...] - Ignoring received gossip from
> unreachable [UniqueAddress(akka.tcp://...Node1...)]
> Cluster Node [akka.tcp://...Node4...] - Ignoring received gossip from
> unreachable [UniqueAddress(akka.tcp://...Node1...)]
> :
> Cluster Node [akka.tcp://...Node4...] - Ignoring received gossip from
> unreachable [UniqueAddress(akka.tcp://...Node1...)]
> :
> Cluster Node [akka.tcp://...Node4...] - Marking node(s) as REACHABLE
> [Member(address = akka.tcp://Node1..., status = Up)]
> :
> (XXX)
>
> Additionally (Missing traces in XXX):
> - A custom actor in our system receives the ReachableMember and
> UnreachableMember events.
> - In other places whenever a trace like "Marking node(s) as REACHABLE" or
> "UNREACHABLE" appears, our actor gets the according events.
> - But: At location XXX the event is NOT received.
>
> === Step 8) 
> - After the above state and after having Node 1 suspended for 30minutes+:
> - Resume process of Node 1 with Process Explorer.
> - JMX Beans on all nodes show the same cluster status again. Leader = 1,
> no Unreachable Members.
>
>
> = Questions: ===
> - According to JMX it seems there are multiple leaders in the clusters -
> and even after a very long time the cluster status on the Nodes being alive
> differs. Can (should) this ever happen?
>

There can be multiple leaders. The leader is simply the member with lowest
address among the currently reachable members (as seen from a specific
node). There are some more rules regarding member status, but that is
irrelevant for this.


>
> - Is the JMX MBean akka.cluster showing wrong information in this case? As
> pointed out above there is no ReachableMember event after "the marking node
> as REACHABLE" trace in this case. Maybe the component preparing the MBean
> information is also missing the event?
>

That is interesting. You should receive the ReachableMember. The MBean also
subscribes to these events. If you look at clusterStatus you should see
more information about who thinks that it is still unreachable.

/Patrik


>
>
> Best regards,
>
> Michael
>
>
>  --
> >> 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

[image: Scala Days] 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs

Re: [akka-user] Large List message passing to Actor

[Patrik Nordwall]

On Mon, Mar 9, 2015 at 10:52 PM,  wrote:

> How can one pass a list of BigDecimal to an Actor to process efficiently?
> I ask this because Actors should only be sent short messages.
> What if you have a List of 1 million BigDecimal? How is this done with a
> local actor? Remote Actor? I would like the actor to take the list
> and send back a short message with the sum.
>

Local messages are passed by reference so the message size is not a
concern, but it will not work for remote messages, and you should design
for location transparency unless you know 100% that you will never need it.
In general you must chunk up a large message into smaller messages.

Another approach is to store the data somewhere else, and only pass a
reference to that location so that it can be retrieved by the destination.

A third approach is to transfer the data with a side channel, such as HTTP
or Akka IO.

/Patrik


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

[image: Scala Days] 

-- 
>>  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: persistAsync interaction with snapshots

[Patrik Nordwall]

On Tue, Mar 10, 2015 at 11:36 AM, Tal Pressman  wrote:

> Hi,
>
> Thanks for your response. Let me (try to) clarify my questions.
>
> I guess I oversimplified my example so it, so I'll try again. I have an
> actor (persistent with at-least-once-delivery), and I want it to process
> messages "immediately" upon arrival. That is, I don't want to wait for the
> persistence handlers to fire before updating my state, delivering messages
> downstream, etc.. I would also like to be able to recover from crashes to a
> consistent state.
>
> So now let's look at an example actor (assuming recovery behaves exactly
> the same, but without the persistence calls):
>
> class MyActor extends PersistentActor with AtLeastOnceDelivery {
>   var counter = 0
>   override def receiveCommand: Receive = {
> case Increment =>
>   counter += 1
>   deliver(somewhere, id => Count(counter, id))
>   persistAsync(Increment) { _ =>
> sender ! Persisted
>   }
> case a@Ack(id) =>
>   counter -= 1
>   confirmDelivery(id)
>   persistAsync(a) { _ =>
> // nothing to do here
>   }
> case Snapshot =>
>   saveSnapshot(Snapshot(counter, getDeliverySnapshot))
>   }
> }
>
>
> Here, I would expect the counter to be the same as the number of
> unconfirmed messages as long as there are no crashes.
>
> Could I miss messages here? Would crashes always restore my actor to a
> consistent state as well?
>

The only potential problem I can see is if you have a crash immediately
after the first deliver or if the persistAsync fails. Then you have sent a
message that you have not any records of. After restart the same deliveryId
might get used again, but for a completely different message. That could be
a problem if you use the deliveryId in the destination for deduplication.
Also, the Ack of the first message might be in flight, and when it is
received it might be used to confirmDelivery of another message that was
sent in between.

That might be completely alright in your application and a reasonable
tradeoff for reducing the latency. You can mitigate the risk by using uuid
in the messages keeping track of mapping between uuid and deliveryId. In
that way you can discard Ack with unknown uuid.

The deliveryId is a counter that is incremented for each call to `deliver`.
It is assumed that it reach the same value after recovery, i.e. that the
same number of delivery calls were made. That is one of the reasons why its
important to use getDeliverySnapshot/setDeliverySnapshot when using
snapshots with AtLeastOnceDelivery.

/Patrik


>
> I didn't observe any problems, it was just something I thought about
> during the design phase, and since it relates to thread timings and crashes
> it would be kind of hard to create the problematic scenarios ahead-of-time.
>
> Thanks,
> Tal
>
>
> On Monday, March 9, 2015 at 3:55:39 PM UTC+2, Patrik Nordwall wrote:
>>
>> I don't see what this has to do with snapshots, and what the problem
>> could be. This is not the kind of mutability that Björn warned about. He
>> was thinking about mutability of the instance passed to saveSnapshot.
>>
>
>
>>  You can do that, but then you risk that the message may not be delivered
>> (re-delivered) if things crash before the event has been saved.
>>
>> Snapshots and persistent events are not re-ordered, so it is supposed to
>> just work, and that should not change because of persistAsync. Have you
>> seen any problems?
>>
>  --
> >> 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

[image: Scala Days] 

-- 
>>  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] Cluster: Multiple leaders / ReachableMember not propagated / ...?

[michaels]

Hello.

We did tests with akka cluster and Unreachable / Reachable state and 
discovered the following reproducible behaviour, which might be a problem - 
but still unsure :-)

== Environment: ==
- Could be reproduced with 2.3.7 as well as with 2.3.9
- Cluster with 4 nodes, seed nodes = 1,2,3
- config: both akka.remote and akka.cluster: 
watch-failure-detector.threshold = 12.0, .acceptable-heartbeat-pause =  30 s
- config: auto-downing off, 
actor.provider="akka.cluster.ClusterActorRefProvider" and 
akka.remote.enabled-transports =["akka.remote.netty.tcp"]

== Test Steps: ==
1.) Start 4 JVMs (all on local host) - Nodes form a cluster - Leader  = 1 - 
same information on all nodes (VisualVM MBean akka.cluster)
2.) With Sys-Internal Process Explorer Suspend Process of Node 1
3.) Looking with Java VisualVM on akka.cluster MBeans
4.) Waiting for all other nodes (2,3,4) to mark 1 as Unreachable. New 
Leader is now 2.
5.) With Sys-Internal Process Explorer Suspend Process of Node 3
6.) Waiting for all other working nodes (2,4) to mark 3 also as 
Unreachable. Leader is still 2.
7.) With Sys-Internal Process Explorer Resume Process of Node 1

Now strange things happen/can be seen:
JMX MBean akka.cluster:
- Node 1: MemberStatus=Up, Leader = 1 / Unreachable = Node 3
- Node 2: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3
- Node 4: MemberStatus=Up, Leader = 2 / Unreachable = Node 1, 3

It seems there are multiple leaders in the cluster.
Node 1 thinks almost everything is fine and believes it is the leader of 
the cluster.
This state does not change, even after a long time...(30 minutes+, no 
application load on cluster, just the cluster running.)

== Additional Info from Traces: ==
When Node 1 is resumed (Step 7) Node Node 4 prints the following 
(shortened):

Cluster Node [akka.tcp://...Node4...] - Ignoring received gossip from 
unreachable [UniqueAddress(akka.tcp://...Node1...)]
Cluster Node [akka.tcp://...Node4...] - Ignoring received gossip from 
unreachable [UniqueAddress(akka.tcp://...Node1...)]
:
Cluster Node [akka.tcp://...Node4...] - Ignoring received gossip from 
unreachable [UniqueAddress(akka.tcp://...Node1...)]
:
Cluster Node [akka.tcp://...Node4...] - Marking node(s) as REACHABLE 
[Member(address = akka.tcp://Node1..., status = Up)]
:
(XXX)

Additionally (Missing traces in XXX):
- A custom actor in our system receives the ReachableMember and 
UnreachableMember events.
- In other places whenever a trace like "Marking node(s) as REACHABLE" or 
"UNREACHABLE" appears, our actor gets the according events.
- But: At location XXX the event is NOT received.

=== Step 8) 
- After the above state and after having Node 1 suspended for 30minutes+:
- Resume process of Node 1 with Process Explorer.
- JMX Beans on all nodes show the same cluster status again. Leader = 1, no 
Unreachable Members.


= Questions: ===
- According to JMX it seems there are multiple leaders in the clusters - 
and even after a very long time the cluster status on the Nodes being alive 
differs. Can (should) this ever happen?

- Is the JMX MBean akka.cluster showing wrong information in this case? As 
pointed out above there is no ReachableMember event after "the marking node 
as REACHABLE" trace in this case. Maybe the component preparing the MBean 
information is also missing the event?


Best regards,

Michael


-- 
>>  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] Starting Akka Cluster & Seed Nodes in Torque/SGE/HPC Environment

[Patrik Nordwall]

On Wed, Mar 4, 2015 at 11:57 PM, Steve Ramage  wrote:

> I'm writing a task dispatching system for scientific data collection on
> timesharing clusters. There is a specific API for submission of tasks and a
> few implementations one of which does the data collection locally, another
> to a MySQL Server, and the one I am working on currently an Akka based
> distributed system. It is a standard many producer, many consumer system,
> where the consumer tasks very in length from subsecond to several hours in
> lengths. Different producers may be different algorithms entirely, with
> different workloads (most typically the workloads are either here are 4
> million tasks to do, or keep generating tasks until all consumers are busy,
> and then slowly keep generating more to keep them busy).
>
> The typical use case is for a series of jobs to be submitted to torque or
> some dispatch system, almost surely consumers will be dispatched this way.
> In some cases producers may be run on a dedicated node, in others they may
> be queued as well. Consumers and producers may run on the same node, or on
> different nodes but pairwise communication is always possible. Users of
> this system really don't want to know or care about how their tasks are
> executed just that they are and that it is done as simple as possible. The
> whole actor system may exist only few a few hours, or may exist over a few
> days cycling both producers and consumers.
>
> The one problem I have right now is configuration of the cluster
> (singleton) in the akka sense. Users have no idea what machine will execute
> the tasks. A realistic assumption is that there exists a shared file
> system, which can always be relied upon. Most likely failure of nodes will
> occur due to being terminated for violating walltime or memory limits.
>
> My thoughts on how to deal with this are as follows:
>
> 1) Pick a random number >= 1024 to serve as the port.
> 2) Users will supply the network to bound too, or it will be auto-detected.
> 3) Look in a known directory and scan for files of the name akka.N, where
> N is an integer.
> 4) Take the highest number add 1 (or assume the highest number is 0), read
> the other files and put the ipaddress : ports as seed nodes.
> 5) Try to write the file as new akka.N+1, if this fails go back to step 1.
> 6) Try to start the actor system, if this fails go back to step 1.
> 7) When shutting down the actor system delete the file akka.N+1. (also
> happens in step 5 and step 6)
>
> Question 1) Is there a better option, and/or is there a problem with the
> above. I am somewhat concerned about producers and consumers not forming
> one cohesive cluster but little islands.
>

I think your solution will work fine. The key to avoiding islands is that a
node can only join an existing member, and only the first seed node joins
itself for bootstrapping. The first seed node is defined in the akka.0
file, so you must use that as the first seed node everywhere.


>
> Question 2) If I detect that one of my nodes has been quarantined by
> another node can I just restart the actor system using the above protocol
> to get it to rejoin the pool.
>

yes

/Patrik


> I actually think partitions will never happen as far as I'm concerned,
> although node deaths might happen. Any other weird failures would result in
> the network operations team terminating every job anyway and shutting down
> the cluster so I don't really need to be robust to that.
>
>
> Thanks,
>
> Steve Ramage
>
>  --
> >> 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

[image: Scala Days] 

-- 
>>  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] Integration test for actor with router created in the constructor

[Patrik Nordwall]

Hi George,

I don't fully understand the problem. Perhaps you don't mean integration
test, but unit test with router and listener stubbed out?

/Patrik

On Wed, Mar 4, 2015 at 2:07 PM, George Lu  wrote:

> Hi all,
>
> I have an actor which in the constructor creates a router actor which
> creates several workers.
> Also, in that actor, it creates an actor do so some separate stuff, so the
> structure is like:
>
> actor > router --> a bunch of workers
> > listener
>
> As said, router and listener are created in the constructor of the
> leftmost actor.
>
> I want to do some integration test on the leftmost actor, how to do that?
>
> I would like to use JavaTestKit.
>
> Thanks!
>
> George
>
> --
> >> 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

[image: Scala Days] 

-- 
>>  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] Recommended actor hierarchy for running a database migration job from different dbs?

[Patrik Nordwall]

Supervision hierarchy is about how to handle failures.

Perhaps setup a pipeline of these actors. Use a parent actor that creates
the other processing actors, with forward references to the next actor in
the chain, i.e. Actor1 takes the ActorRef of Actor2 as constructor
parameter.

Note that this setup is static, not creating a new actor for each row. I
don't know why you would need to create a new actor for each row.

If you need more parallelism for each actor type you can replace it with a
router.

You might also need to consider backpressure if the later stages are slower
than the previous stages, otherwise you will fill up the memory. That can
be achieved by not reading more rows in Actor1 until it has got a signal
from Actor3 that current batch is done.

Regards
Patrik

On Sat, Feb 28, 2015 at 3:01 AM, Ali Akhtar  wrote:

> I'm in the process of running some data migration jobs. Basically, I have
> some data that needs to be moved from legacy db 1 and 2 into new db.
>
> For this purpose, I think I need 3 actors:
>
> Actor 1: Pulls in data from legacy db 1
>
> Actor 2: Receives one row of data at a time, for each row it pulls
> additional info from legacy db 2.
>
> Actor 3: Also receives one row of data at a time, which has gone through
> Actors 1 & 2 and contains full data. Inserts this row into new db.
>
> I'd like some pointers on how to structure the actor hierarchy for this.
> I'm considering having Actor 1 at the root, which pulls in 100 rows at a
> time, and loops over them. For each row it creates a child Actor 2, passing
> it the row. But what I'm not sure on is, should actor 2 create actor 3 as a
> child, or should it just do the job of actor 3 as well, and pull in data
> from legacy db 2, and then also insert this data in new db?
>
> Which way would be the most performant / get this done fastest?
>
> Thanks.
>
> --
> >> 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

[image: Scala Days] 

-- 
>>  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 SupervisorStrategy strange behavior

[Patrik Nordwall]

Hi George,

I think you will find the answer here:
http://doc.akka.io/docs/akka/2.3.9/java/routing.html#Supervision

Regards,
Patrik

On Mon, Feb 23, 2015 at 1:56 PM, George Lu  wrote:

> Dear all,
>
> For learning Akka, I wrote below in Java to test fault-tolerance.
> I have a master actor to assign job to worker actors, in the master actor,
> simply divide the job into several pieces and use round robin router to
> assign to workers (i.e. let workers add slices of a summation).
>
> In the worker onReceive, I let the first worker who does its job to throw
> an Exception, please consider below code:
>
> WorkerActor/onReceive:
>
> if(RetryCount >=1 ) {
> RetryCount--;
> throw new Exception("exception thrown from worker");
> }
>
> WorkerActor/preRestart:
> public void preRestart(Throwable cause, Option msg) {
> System.out.println("Thread "+Thread.currentThread().getId()+" get restart
> message ");
> if(cause instanceof Exception && msg.nonEmpty()) {
> WorkerMessage workerMsg = (WorkerMessage)msg.get();
> getSelf().forward(workerMsg, getContext());
> //getSelf().tell(workerMsg, getSender());
> }
> else {
> return;
> }
> }
>
> For the master actor:
> router = getContext().actorOf(
> Props.create(WorkerActor.class).withRouter(
> new RoundRobinRouter(10)));
>
> private static SupervisorStrategy strategy = new OneForOneStrategy(10,
> Duration.create(1, TimeUnit.MINUTES),
> new Function() {
>
> public Directive apply(Throwable exception) throws Exception {
> if (exception instanceof Exception) {
> return SupervisorStrategy.restart();
> } else {
> return SupervisorStrategy.escalate();
> }
> }
>
> });
>
> @Override
> public SupervisorStrategy supervisorStrategy() {
> return strategy;
> }
>
> I have 10 workers running and tasks assigned in round-robin algorithm,
> after running the example, the restart run as expected, but I have several
> questions:
> 1) All 10 workers' preRestart get called, why is that, is that correct as
> I used OneForOneStrategy and I thrown exception only from one worker?
> I use the msg.nonEmpty() to get rid of those null msg passed in as
> from my running result, all 10 workers run the preRestart which I am quite
> confused.
>
> 2) After one worker forwards the message, another worker receives the
> message and re-process it, they are not the same thread, is that correct?
> Thread 11 processing worker 1
> Thread 11 throw exception
> Thread 18 processing worker 1
> From the output, thread 11 throw exception and thread 18 process later for
> fail-over. From understanding, if one child actor failed, then parent actor
> should invoke that child actor's preRestart method only, not for all child
> actors. Is that correct?
>
> Thanks in advance!
>
> Regards,
> George
>
>  --
> >> 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

[image: Scala Days] 

-- 
>>  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: persistAsync interaction with snapshots

[Tal Pressman]

Hi,

Thanks for your response. Let me (try to) clarify my questions.

I guess I oversimplified my example so it, so I'll try again. I have an 
actor (persistent with at-least-once-delivery), and I want it to process 
messages "immediately" upon arrival. That is, I don't want to wait for the 
persistence handlers to fire before updating my state, delivering messages 
downstream, etc.. I would also like to be able to recover from crashes to a 
consistent state.

So now let's look at an example actor (assuming recovery behaves exactly 
the same, but without the persistence calls):

class MyActor extends PersistentActor with AtLeastOnceDelivery {
  var counter = 0
  override def receiveCommand: Receive = {
case Increment =>
  counter += 1
  deliver(somewhere, id => Count(counter, id))
  persistAsync(Increment) { _ =>
sender ! Persisted
  }
case a@Ack(id) =>
  counter -= 1
  confirmDelivery(id)
  persistAsync(a) { _ =>
// nothing to do here
  }
case Snapshot =>
  saveSnapshot(Snapshot(counter, getDeliverySnapshot))
  }
}


Here, I would expect the counter to be the same as the number of 
unconfirmed messages as long as there are no crashes.

Could I miss messages here? Would crashes always restore my actor to a 
consistent state as well?

I didn't observe any problems, it was just something I thought about during 
the design phase, and since it relates to thread timings and crashes it 
would be kind of hard to create the problematic scenarios ahead-of-time.

Thanks,
Tal


On Monday, March 9, 2015 at 3:55:39 PM UTC+2, Patrik Nordwall wrote:
>
> I don't see what this has to do with snapshots, and what the problem could 
> be. This is not the kind of mutability that Björn warned about. He was 
> thinking about mutability of the instance passed to saveSnapshot.
>
 

>  You can do that, but then you risk that the message may not be delivered 
> (re-delivered) if things crash before the event has been saved.
>
> Snapshots and persistent events are not re-ordered, so it is supposed to 
> just work, and that should not change because of persistAsync. Have you 
> seen any problems?
>

-- 
>>  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 1.0 release date?

[Patrik Nordwall]

We will release 1.0 as soon as possible, but not earlier. We will continue
to release frequent milestones until we reach release candidate quality. We
don't have an estimate of how long that will take, but I guess it is in the
magnitude of a few months.

Regards,
Patrik

On Mon, Mar 9, 2015 at 6:48 PM, Ali Beyad  wrote:

> Dear All,
>
> Is there any projected timeframe for releasing version 1.0?  After the
> release of 1.0-M4, I wasn't sure how close Akka was to the official 1.0
> release of streams.
>
> Thank you,
>
> Ali Beyad
>
> --
> >> 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

[image: Scala Days] 

-- 
>>  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 routing DSL: execution context needed for simple conversion?

[Yann Simon]

Hi,

I'm testing the akka http routing DSL
(
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/http/routing.html
)

I am quite surprised that I need an ExecutionContext to use an implicit
marshaller (ToResponseMarshallable).
It makes the code quite complicated for a very simple use case like that
one:

import akka.http.server.Directives._
import akka.http.server.Route
import scala.concurrent.ExecutionContext

object Routes {
  def index(implicit ec: ExecutionContext): Route =
get {
  path("") {
complete("hello")
  }
}
}

What's your opinion?

Cheers, Yann

-- 
>>  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: Problems using a Remote Actor

[Sandro Martini]

Hi, sorry but even after some small changes I'm still stuck with the 
problem, tried with Akka-2.2.4, 2.2.5, 2.3.9 .
>From local actor system all works good.

I don't really understand the error when using remote actor with 
actorSelection:

[ERROR] [03/09/2015 18:33:44.918] 
[RemoteActorSystem-akka.actor.default-dispatcher-3] 
[akka://RemoteActorSystem/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FRemoteActorSystem-Client%40127.0.0.1%3A57311-0/endpointWriter]
 
changing Recreate into Create after 
akka.actor.ActorInitializationException: exception during creation

Instead, using the deprecated methos (actorFor) I don't have the error, but 
messages goes to deadLetters, so maybe even in this case there is something 
to fix ...
The source for the "server" is here:
https://github.com/smartiniOnGitHub/akka-tests/blob/master/akka-tests-java/src/main/java/akka_tests/java/server/AkkaRemoteServer.java

Someone can give me some hint ?

Thanks a lot,
Sandro



Il giorno giovedì 5 marzo 2015 18:52:55 UTC+1, Sandro Martini ha scritto:
>
> Hi all,
> I'm doing some tests with Akka Remote Actors, but I'm in trouble with some 
> strange problem, but I think it's something that I'm doing in the wrong way 
> ...
>
> I'm using Akka-2.2.4 (tomorrow I'll update to 2.2.5) with an updated JDK 7 
> on Windows 7.
> My sources are here: https://github.com/smartiniOnGitHub/akka-tests
> the project is a Gradle (2.3) multi-project, because I'm trying to make it 
> work with Java and then to port all in Groovy (and then in Scala), so 
> please now let's focus on the Java version.
>
> The make some test, you can run the following commands (under Windows):
>
> rem cls && gradle tasks
> cls && gradle clean build --refresh-dependencies
> cls && gradle runJavaAkkaRemoteServer
> or
> cls && start gradle runJavaAkkaRemoteServer
> cls && gradle runJavaAkkaRemoteClient
>
> Anyway the "server" source is here: 
>
> https://github.com/smartiniOnGitHub/akka-tests/blob/master/akka-tests-java/src/main/java/akka_tests/java/server/AkkaRemoteServer.java
>
> When I run the "server", I get this:
>
> :akka-tests-java:runJavaAkkaRemoteServer
> Application: main, start a simple server console application for creating 
> some Akka Actors and make them reachable from other (remote) processes
>
> setup: start at Wed Mar 04 19:04:33 CET 2015.
> Akka Config: akka {
> loglevel = "INFO"
> actor {
> provider = "akka.remote.RemoteActorRefProvider"
> }
> remote {
> enabled-transports = ["akka.remote.netty.tcp"]
> netty.tcp {
> hostname = "127.0.0.1"
> # Server, listen on default Akka tcp port (2552)
> port = 2552
> }
> log-sent-messages = on
> log-received-messages = on
> log-remote-lifecycle-events = on
> log-frame-size-exceeding = on
> # log-buffer-size-exceeding = 5
> }
> }
> using Java ClassLoader: sun.misc.Launcher$AppClassLoader@187aeca
> using Akka version: 2.2.4
> Actor System configuration: 
> Config(SimpleConfigObject({"akka":{"loglevel":"INFO","remote":{"log-remote-lifecycle-events":"on","netty":{"tcp":{"port":2552,"hostname":"127.0.0.1"}},"enabled-transports":["akka.remote.netty.tcp"],"log-frame-size-exceeding":"on","log-sent-messages":"on","log-received-messages":"on"},"actor":{"provider":"akka.remote.RemoteActorRefProvider"}}}))
> [INFO] [03/04/2015 19:04:34.241] [main] [Remoting] Starting remoting
> [INFO] [03/04/2015 19:04:34.408] [main] [Remoting] Remoting started; 
> listening on addresses :[akka.tcp://RemoteActorSystem@127.0.0.1:2552]
> [INFO] [03/04/2015 19:04:34.410] [main] [Remoting] Remoting now listens on 
> addresses: [akka.tcp://RemoteActorSystem@127.0.0.1:2552]
> Actor System instance: akka://RemoteActorSystem
> props: 
> Props(Deploy(,Config(SimpleConfigObject({})),NoRouter,NoScopeGiven,,),class 
> akka_tests.java.actor.GreetingActor,List())
> setup: end at Wed Mar 04 19:04:34 CET 2015.
> Get Actor Reference to greetingActor: 
> Actor[akka://RemoteActorSystem/user/greetingActor#-1752332594]
> setup: end at Wed Mar 04 19:04:35 CET 2015.
> check: start at Wed Mar 04 19:04:35 CET 2015.
> Actor Reference instance is: 
> Actor[akka://RemoteActorSystem/user/$a#-314651576]
> [INFO] [03/04/2015 19:04:35.429] 
> [RemoteActorSystem-akka.actor.default-dispatcher-6] 
> [akka://RemoteActorSystem/user/$a] akka_tests.java.message.Greeting: Hello 
> "Test Greeting"
> [INFO] [03/04/2015 19:04:35.434] 
> [RemoteActorSystem-akka.actor.default-dispatcher-2] 
> [akka://RemoteActorSystem/deadLetters] Message [java.lang.String] from 
> Actor[akka://RemoteActorSystem/user/$a#-314651576] to 
> Actor[akka://RemoteActorSystem/deadLetters] was not delivered. [1] dead 
> letters encountered. This logging can be turned off or adjusted with 
> configuration settings 'akka.log-dead-letters' and 
> 'akka.log-dead-letters-during-shutdown'.
> [INFO] [03/04/2015 19:04:35.439] 
> [RemoteActorSystem-akka.actor.default-dispatcher-6