[akka-user] Scheduling using ActorSelection
Hello and thanks again for an excellent framework. I'm have a minor question about schedulers. As ActorRefs are somewhat harder to lookup these days it would be really sweet if the Scheduler interface could have a schedule method that takes an ActorSelection. Also as I understand the ActorRef this would also allow you to schedule without worrying about actor restarts (since an ActorRef can become stale) and schedule messages to groups of actors. Would this make the interface too bloated or is the entire concept of scheduling to ActorSelections a bad idea? I see that the ActorRef method has a stop condition (receiver.isTerminated) which I guess would be hard to replicate for selections. All this can ofcourse be accomplished using anonymous Runnables, would just be nice to avoid it if there are no outstanding issues. Best Regards Måns Schultz -- 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 Persistence and time series data
Hi guys, We're currently on the verge of refactoring a traditional CRUD based application into a reactive one. We're planning to apply event sourcing with Akka Persitence in order to put in practice CQRS/ES principles. In general terms, we know how to apply this principles when it comes to solving typical business use cases, i.e., adding a new client, managing user accounts, and so on. But, we're not sure whether we should apply this principles and Akka Persistence when it comes to dealing with time series data. For example, suppose that we need to deal with meteorological data which is captured every hour in the form of batches. Every batch contains data in 10-second intervals. Is event sourcing and Akka Persistence also suitable to solve this kind of scenarios?. How would you model the events?. Would every piece of data be an event or it would be every batch?. Thanks in advance for your thoughts and ideas. Regards, Juanjo. -- 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] Scheduling using ActorSelection
I like this idea! Just a side note: Restarting an actor won't lead to a stale ActorRef; the opposite is the case! Heiko On 07 Jul 2014, at 09:19, Måns Schultz gfae...@gmail.com wrote: Hello and thanks again for an excellent framework. I'm have a minor question about schedulers. As ActorRefs are somewhat harder to lookup these days it would be really sweet if the Scheduler interface could have a schedule method that takes an ActorSelection. Also as I understand the ActorRef this would also allow you to schedule without worrying about actor restarts (since an ActorRef can become stale) and schedule messages to groups of actors. Would this make the interface too bloated or is the entire concept of scheduling to ActorSelections a bad idea? I see that the ActorRef method has a stop condition (receiver.isTerminated) which I guess would be hard to replicate for selections. All this can ofcourse be accomplished using anonymous Runnables, would just be nice to avoid it if there are no outstanding issues. Best Regards Måns Schultz -- 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. -- Heiko Seeberger Twitter: @hseeberger Web: heikoseeberger.de -- 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 and time series data
Hi Juan, Glad to hear you've picked persistence :-) My immediate reaction would be to store each data point as an event - that will make replaying and analysing the data simpler. It also means no need to think about oh yeah, we were getting the data in batches, so it's batches stored in the db. Having more insights into sizes of these events will influence the design though. Count wise I understand you're getting 360 events in one batch? That's not much by itself, but how many of these persistent entities will you have in your system? Related question: which datastore are you looking into using to back your system? On Mon, Jul 7, 2014 at 12:14 PM, Juan José Vázquez Delgado jvazq...@tecsisa.com wrote: Hi guys, We're currently on the verge of refactoring a traditional CRUD based application into a reactive one. We're planning to apply event sourcing with Akka Persitence in order to put in practice CQRS/ES principles. In general terms, we know how to apply this principles when it comes to solving typical business use cases, i.e., adding a new client, managing user accounts, and so on. But, we're not sure whether we should apply this principles and Akka Persistence when it comes to dealing with time series data. For example, suppose that we need to deal with meteorological data which is captured every hour in the form of batches. Every batch contains data in 10-second intervals. Is event sourcing and Akka Persistence also suitable to solve this kind of scenarios?. How would you model the events?. Would every piece of data be an event or it would be every batch?. Thanks in advance for your thoughts and ideas. Regards, Juanjo. -- 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 hAkker @ Typesafe http://typesafe.com -- 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] Scheduling using ActorSelection
Thanks for the reply! Thanks for the correction about stale ActorRefs. But the statement holds true if I kill the actor and replace it with something else on the same path right? (like switching a service at runtime). Best Regards Måns Schultz 2014-07-07 12:16 GMT+02:00 Heiko Seeberger hseeber...@posteo.de: I like this idea! Just a side note: Restarting an actor won’t lead to a stale ActorRef; the opposite is the case! Heiko On 07 Jul 2014, at 09:19, Måns Schultz gfae...@gmail.com wrote: Hello and thanks again for an excellent framework. I'm have a minor question about schedulers. As ActorRefs are somewhat harder to lookup these days it would be really sweet if the Scheduler interface could have a schedule method that takes an ActorSelection. Also as I understand the ActorRef this would also allow you to schedule without worrying about actor restarts (since an ActorRef can become stale) and schedule messages to groups of actors. Would this make the interface too bloated or is the entire concept of scheduling to ActorSelections a bad idea? I see that the ActorRef method has a stop condition (receiver.isTerminated) which I guess would be hard to replicate for selections. All this can ofcourse be accomplished using anonymous Runnables, would just be nice to avoid it if there are no outstanding issues. Best Regards Måns Schultz -- 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. -- Heiko Seeberger Twitter: @hseeberger Web: heikoseeberger.de -- 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] Akka cluster - seed node goes down and is not discoverable afterwards
Hi Ryadh, ActorSystem can only join a Cluster once. Have you seen the documentation on Cluster Usage? http://doc.akka.io/docs/akka/2.3.4/java/cluster-usage.html The relevant excerpt from that page: An actor system can only join a cluster once. Additional attempts will be ignored. When it has successfully joined it must be restarted to be able to join another cluster or to join the same cluster again. It can use the same host name and port after the restart, but it must have been removed from the cluster before the join request is accepted. So it is not the case that Cluster is deployed on ActorSystem. But rather ActorSystem joins a particular Cluster. On Fri, Jul 4, 2014 at 4:23 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: OK we are using a cluster aware router to distribute the load. This means that we have 2 clusters deployed on the same ActorSystem, is that correct? If it is the case, should we deploy each cluster in a separate ActorSystem? Ryadh On 4 July 2014 14:20, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:10 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: I mean we deployed within the same actor system: - singleton actor: scheduled task - router: the singleton distributed the work to workers using a router I presume to implement a Singleton actor, some sort of Cluster is needed. Yes The same thing applies for setting up a router. well, you can have local routers: http://doc.akka.io/docs/akka/2.3.4/java/routing.html but for cluster aware routers you need a cluster, that is right /Patrik I am totally wrong? Thanks, Ryadh On 4 July 2014 10:40, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 11:12 AM, Ryadh khsib riadh.kh...@gmail.com wrote: Hi Patrik, Reading this: An ActorSystem can only be part of one cluster, and only once. Rejoining or joining of two different clusters are not supported. Then the ActorSystem must be stopped and started again to join the cluster. /Patrik Do you confirm that for every Cluster an new ActorSytem should be created? An ActorSystem is created locally, in the JVM of each machine. We often refer to this as a cluster node, or a cluster member. A Cluster is a set of nodes (actor systems) working together. We are using a singleton and router clusters within the same ActorSystem. Would you recommend to create 2 actor systems? I don't understand what you mean with singleton and router clusters, but I assume that mean that you use Cluster Singelton http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Singleton and Cluster Aware Routers http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Aware_Routers. You can use these two features the same ActorSystem. /Patrik Thanks, Ryadh On Friday, July 4, 2014 8:38:47 AM UTC+1, Patrik Nordwall wrote: On Thu, Jul 3, 2014 at 10:28 PM, Eugene Dzhurinsky jdev...@gmail.com wrote: So you had one cluster consisting of all nodes, and then a network split caused it to be split into two separate clusters? That does not really have anything to do with seed nodes. Seed nodes are only used as initial contact points when joining new nodes. Hi! Let's assume there are 3 nodes - A, B and C. Node A is a seed node for B and C. So when cluster starts - B joins A and C joins A, then they gossip and then B knows about C and vise versa. yes, then my understanding was correct Now A is not reachable, so both B and C mark it as quarantined. After A gets online - it doesn't know neither about B nor about C, and none of the nodes B and C will even try to restore the connections to A. quarantine is because of downing: http://doc.akka.io/docs/akka/ 2.3.4/scala/cluster-usage.html#Automatic_vs__Manual_Downing If A has some actors to be deployed on node B - then it will not be able to do so. The only way to resolve this seems to make A, B and C as seed nodes, so if any of then will disconnect - then after the connection is established (and threshold is not broken yet) they will re-join. But I'm not sure if there would be a delay in startup of node B - will it be marked as inaccessible? I repeat myself, this has nothing to do with seed nodes. Please re-read my previous reply, and this section: http://doc.akka.io/ docs/akka/2.3.4/scala/cluster-usage.html#Joining_to_Seed_Nodes /Patrik -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit
Re: [akka-user] Re: Akka Cluster seed node problem
Hi Rohit, how do you reference the back-end actor from the front-end? If you hold an ActorRef, then after the back-end machine is stopped, the ActorRef still points to that non existent actor. To solve this you should use a cluster membership service (which is what Akka Cluster provides) to look-up cluster member you want to send the message to. Otherwise you can use Cluster Sharding which solves this particular issue. With Cluster Sharding you reference actors by a logical identifier and sending message to that identifier will send it to the desired actor on some node in the cluster. On Fri, Jul 4, 2014 at 7:29 PM, Rohit Kumar Gupta rohitkumargupt...@gmail.com wrote: Hi Patrik, The basic cluster things are working (as per the distributed akka workers template). But few things (may be advanced) are not working. I have akka cluster consisting of two different m/c. Each m/c hosts once master and one worker process running on different ports. When I start my frontend process (on one of the nodes), it starts submitting the jobs to the master process. First master process is picked. Master process is a singleton in the cluster so only one instance of it can run at any point of time in the cluster. First master process starts processing the jobs and sends them to workers on both m/c. There is no problem so far. Clustering is working. But when I pull down this master process (kill it), then ideally other master process running on different m/c should come into picture as this is also running and part of the cluster. But that is not happening, and frontend can no longer able to submit the job to the master process. It keeps on complaining about the original master process that it is unreachable. Could you tell me hhow to solve it ? Any help will be very much appreciated. -- 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. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- 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-cluster][version 2.3.0] Failed to write message to the transport when more than 4 nodes joined into the cluster
Hi Mint, whats the amount of messages you send from the worker nodes? Is it very high? Can you package this to a small test case and share it? On Fri, Jul 4, 2014 at 11:06 PM, Mint tangjian1...@gmail.com wrote: Hi Patrik, I've just upgraded the version of Akka from 2.3.0 to 2.3.4 for our prototype project. Still the same warn message, query failed with time out because the result of worker aggregator has not been delivered to client. When I tried to launch the test with one client node and 4 worker remote nodes I get the same message: 2014-07-04 21:55:31,865 | WARN | ult-dispatcher-4 | ReliableDeliverySupervisor | receive$1$$anonfun$applyOrElse$2 71 | 202 - com.typesafe.akka.slf4j - 2.3.4 | Association with remote system [akka.tcp://cluster@host:port] has failed, address is now gated for [5000] ms. Reason is: [Failed to write message to the transport]. I have launched the work nodes in LAN on four machines. Thanks in advance for your help, Mint 在 2014年7月4日星期五UTC+2下午5时42分41秒，Patrik Nordwall写道： First of all, use latest released version. That is 2.3.4. Then we can talk :-) /Patrik On Fri, Jul 4, 2014 at 5:05 PM, Mint tangji...@gmail.com wrote: Hi, I'm writing code using akka cluster to distribute our internal analytics tool. At the beginning things go quite well when I have one analytic client and 2 till 3 analytic remote workers. But every time I try to add one more remote nodes to the cluster(totally one client node and 4 remote worker nodes in the cluster), I get warning Association with remote system [akka.tcp:/analytics-cluster@host:port] has failed, address is now gated for [5000] ms. Reason is: [Failed to write message to the transport]. Query execution failed because result came from the 4th worker node cannot be delivered to client. So could you guys tell me how I should configure the application so that it can handle more than 4 remote workers and how can I get the internal exception stack to know what is the really reason that the message cannot be delivered(I have already enable log-received-messages= on log-sent-messages=on, with global log level to DEBUG) ? Thanks a lot and any advice can help me a lot. Mint -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- 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, clustering and eventual consistency
Hi Mario, your use case resonates to me with the Hot Standby Processor feature request https://github.com/akka/akka/issues/13938, that we have in our issue tracker. In that case you would have only one Processor which does the writes. But next to that there would be a number of Hot Views that do reads and can be promoted to the Processor if the original dies. I know this is a bit different from the idea you are proposing, but this may be easier to implement than synchronizing stores of multiple processors. On Fri, Jul 4, 2014 at 7:01 PM, Mario Camou mca...@tecnoguru.com wrote: Hi everyone, I'm in the process of thinking through a rewrite of parts of an application using Akka Persistence. After watching Endre's talk from ScalaDays (I was unable to attend the talk itself and the streaming only made me sadder about that) I was thinking, is there a plan to apply this sort of thinking to PersistentActors? I was thinking of a cluster where you have several instances of a PersistentActor, behind a Cluster-Aware Router (not using a Cluster Singleton because of scalability). The thing is (as far as I've been able to determine), each PersistentActor has its own state (and event store), so they don't have any sort of shared (eventually-consistent) view of the world. Since Akka Cluster already uses the Gossip protocol to maintain cluster state, perhaps it would be interesting to extend that so that Events get propagated too. For a little more perspective, here's what I am thinking of doing. Currently the application (running in a single server) holds state in in-memory Maps coordinated using STM. The elements in these maps are persisted to JSON files every time there's an update so that, when the system goes down and back up, it can restore them. I was thinking of changing this to use Akka Persistence. Currently a single process handles both the backend (in this case, communicating with e-bike rental stations) and frontend responsibilities (exposing the state via REST calls using Spray and allowing the web front-end to modify the state). They both access the store via a Repository object which takes care of querying and updating the Maps. I was thinking that, by using Akka to access the Repository (instead of method calls) I could then scale the system out by separating the frontend and backend into separate nodes. That, however, still leaves me with a Single Point of Failure: the Repository itself. If I could have the PersistentActors communicate amongst themselves to keep an eventually-consistent view of the world, it would allow me to replicate the Repository to several nodes, or perhaps not even having a dedicated process to hold the PersistentActors, instead hosting them in the same cluster nodes as the backend(s) and frontend(s). As I asked earlier, is this planned at some point, is there some other recommended way of going about this, or am I completely out of the ballpark? Thanks, -Mario. -- 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. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- 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 Persistence 2.3.4 and State machines
Hi, what would be your suggestion on how to persist State machines with Akka Persistence 2.3.4? The example in the documentation still uses Processor and Persistent which is not available anymore. Thanks, Hannes -- 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 2.3.4 and State machines
Hello Hannes, Well noticed - we have not yet ported this functionality over to the PersistentActor (in `2.3.4`). Progress on this task can be tracked here: https://github.com/akka/akka/issues/15279 I hope you can wait a bit for it, but we definitely would like to provide this (I like FSM a lot myself). -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io -- 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, clustering and eventual consistency
Ah, this looks very nice and I agree that it sounds easier to implement, and would perfectly cover my use case. Hopefully it will be implemented soon :) Thanks! -Mario. On 07 Jul 2014, at 14:05, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hi Mario, your use case resonates to me with the Hot Standby Processor feature request, that we have in our issue tracker. In that case you would have only one Processor which does the writes. But next to that there would be a number of Hot Views that do reads and can be promoted to the Processor if the original dies. I know this is a bit different from the idea you are proposing, but this may be easier to implement than synchronizing stores of multiple processors. On Fri, Jul 4, 2014 at 7:01 PM, Mario Camou mca...@tecnoguru.com wrote: Hi everyone, I'm in the process of thinking through a rewrite of parts of an application using Akka Persistence. After watching Endre's talk from ScalaDays (I was unable to attend the talk itself and the streaming only made me sadder about that) I was thinking, is there a plan to apply this sort of thinking to PersistentActors? I was thinking of a cluster where you have several instances of a PersistentActor, behind a Cluster-Aware Router (not using a Cluster Singleton because of scalability). The thing is (as far as I've been able to determine), each PersistentActor has its own state (and event store), so they don't have any sort of shared (eventually-consistent) view of the world. Since Akka Cluster already uses the Gossip protocol to maintain cluster state, perhaps it would be interesting to extend that so that Events get propagated too. For a little more perspective, here's what I am thinking of doing. Currently the application (running in a single server) holds state in in-memory Maps coordinated using STM. The elements in these maps are persisted to JSON files every time there's an update so that, when the system goes down and back up, it can restore them. I was thinking of changing this to use Akka Persistence. Currently a single process handles both the backend (in this case, communicating with e-bike rental stations) and frontend responsibilities (exposing the state via REST calls using Spray and allowing the web front-end to modify the state). They both access the store via a Repository object which takes care of querying and updating the Maps. I was thinking that, by using Akka to access the Repository (instead of method calls) I could then scale the system out by separating the frontend and backend into separate nodes. That, however, still leaves me with a Single Point of Failure: the Repository itself. If I could have the PersistentActors communicate amongst themselves to keep an eventually-consistent view of the world, it would allow me to replicate the Repository to several nodes, or perhaps not even having a dedicated process to hold the PersistentActors, instead hosting them in the same cluster nodes as the backend(s) and frontend(s). As I asked earlier, is this planned at some point, is there some other recommended way of going about this, or am I completely out of the ballpark? Thanks, -Mario. -- 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. -- Martynas Mickevičius Typesafe – Reactive Apps on the JVM -- 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
[akka-user] Re: Rediscala : Non-blocking, Reactive Redis driver for Scala (with Akka IO)
Hi, I am evaluating the options for a redis client. I noticed that there is no example using sentinel that has been put up.. I would like to use sentinel and have client pooling as well. Is it possible? Any tips would be useful! Regards, Shrivallabh On Thursday, 8 August 2013 16:13:21 UTC+5:30, Valérian B wrote: Hi, I am happy to announce a new driver for Redis based on Akka IO / Scala Future : https://github.com/etaty/rediscala I did some benchmark, and i reached more than 200 000 requests/second http://bit.ly/12QZsRs There is a demo project there https://github.com/etaty/rediscala-demo ready to be Akked -- 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 cluster - seed node goes down and is not discoverable afterwards
Thanks Martynas! It seems that Clusters are a higher level entity: Cluster - ActorSystem - Actor AFAIK Clusters are created by ActorSystems when configured to do so which is probably the source of confusion (lower entity creating a higher entity) . Cheers, Ryadh On 7 July 2014 12:21, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hi Ryadh, ActorSystem can only join a Cluster once. Have you seen the documentation on Cluster Usage? http://doc.akka.io/docs/akka/2.3.4/java/cluster-usage.html The relevant excerpt from that page: An actor system can only join a cluster once. Additional attempts will be ignored. When it has successfully joined it must be restarted to be able to join another cluster or to join the same cluster again. It can use the same host name and port after the restart, but it must have been removed from the cluster before the join request is accepted. So it is not the case that Cluster is deployed on ActorSystem. But rather ActorSystem joins a particular Cluster. On Fri, Jul 4, 2014 at 4:23 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: OK we are using a cluster aware router to distribute the load. This means that we have 2 clusters deployed on the same ActorSystem, is that correct? If it is the case, should we deploy each cluster in a separate ActorSystem? Ryadh On 4 July 2014 14:20, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:10 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: I mean we deployed within the same actor system: - singleton actor: scheduled task - router: the singleton distributed the work to workers using a router I presume to implement a Singleton actor, some sort of Cluster is needed. Yes The same thing applies for setting up a router. well, you can have local routers: http://doc.akka.io/docs/akka/2.3.4/java/routing.html but for cluster aware routers you need a cluster, that is right /Patrik I am totally wrong? Thanks, Ryadh On 4 July 2014 10:40, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 11:12 AM, Ryadh khsib riadh.kh...@gmail.com wrote: Hi Patrik, Reading this: An ActorSystem can only be part of one cluster, and only once. Rejoining or joining of two different clusters are not supported. Then the ActorSystem must be stopped and started again to join the cluster. /Patrik Do you confirm that for every Cluster an new ActorSytem should be created? An ActorSystem is created locally, in the JVM of each machine. We often refer to this as a cluster node, or a cluster member. A Cluster is a set of nodes (actor systems) working together. We are using a singleton and router clusters within the same ActorSystem. Would you recommend to create 2 actor systems? I don't understand what you mean with singleton and router clusters, but I assume that mean that you use Cluster Singelton http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Singleton and Cluster Aware Routers http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Aware_Routers. You can use these two features the same ActorSystem. /Patrik Thanks, Ryadh On Friday, July 4, 2014 8:38:47 AM UTC+1, Patrik Nordwall wrote: On Thu, Jul 3, 2014 at 10:28 PM, Eugene Dzhurinsky jdev...@gmail.com wrote: So you had one cluster consisting of all nodes, and then a network split caused it to be split into two separate clusters? That does not really have anything to do with seed nodes. Seed nodes are only used as initial contact points when joining new nodes. Hi! Let's assume there are 3 nodes - A, B and C. Node A is a seed node for B and C. So when cluster starts - B joins A and C joins A, then they gossip and then B knows about C and vise versa. yes, then my understanding was correct Now A is not reachable, so both B and C mark it as quarantined. After A gets online - it doesn't know neither about B nor about C, and none of the nodes B and C will even try to restore the connections to A. quarantine is because of downing: http://doc.akka.io/docs/akka/ 2.3.4/scala/cluster-usage.html#Automatic_vs__Manual_Downing If A has some actors to be deployed on node B - then it will not be able to do so. The only way to resolve this seems to make A, B and C as seed nodes, so if any of then will disconnect - then after the connection is established (and threshold is not broken yet) they will re-join. But I'm not sure if there would be a delay in startup of node B - will it be marked as inaccessible? I repeat myself, this has nothing to do with seed nodes. Please re-read my previous reply, and this section: http://doc.akka.io/ docs/akka/2.3.4/scala/cluster-usage.html#Joining_to_Seed_Nodes /Patrik -- 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
Re: [akka-user] Akka cluster - seed node goes down and is not discoverable afterwards
A cluster is just a name for cooperating ActorSystems using a specific protocol. They are not reified. On Mon, Jul 7, 2014 at 2:56 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: Thanks Martynas! It seems that Clusters are a higher level entity: Cluster - ActorSystem - Actor AFAIK Clusters are created by ActorSystems when configured to do so which is probably the source of confusion (lower entity creating a higher entity) . Cheers, Ryadh On 7 July 2014 12:21, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hi Ryadh, ActorSystem can only join a Cluster once. Have you seen the documentation on Cluster Usage? http://doc.akka.io/docs/akka/2.3.4/java/cluster-usage.html The relevant excerpt from that page: An actor system can only join a cluster once. Additional attempts will be ignored. When it has successfully joined it must be restarted to be able to join another cluster or to join the same cluster again. It can use the same host name and port after the restart, but it must have been removed from the cluster before the join request is accepted. So it is not the case that Cluster is deployed on ActorSystem. But rather ActorSystem joins a particular Cluster. On Fri, Jul 4, 2014 at 4:23 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: OK we are using a cluster aware router to distribute the load. This means that we have 2 clusters deployed on the same ActorSystem, is that correct? If it is the case, should we deploy each cluster in a separate ActorSystem? Ryadh On 4 July 2014 14:20, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:10 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: I mean we deployed within the same actor system: - singleton actor: scheduled task - router: the singleton distributed the work to workers using a router I presume to implement a Singleton actor, some sort of Cluster is needed. Yes The same thing applies for setting up a router. well, you can have local routers: http://doc.akka.io/docs/akka/2.3.4/java/routing.html but for cluster aware routers you need a cluster, that is right /Patrik I am totally wrong? Thanks, Ryadh On 4 July 2014 10:40, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 11:12 AM, Ryadh khsib riadh.kh...@gmail.com wrote: Hi Patrik, Reading this: An ActorSystem can only be part of one cluster, and only once. Rejoining or joining of two different clusters are not supported. Then the ActorSystem must be stopped and started again to join the cluster. /Patrik Do you confirm that for every Cluster an new ActorSytem should be created? An ActorSystem is created locally, in the JVM of each machine. We often refer to this as a cluster node, or a cluster member. A Cluster is a set of nodes (actor systems) working together. We are using a singleton and router clusters within the same ActorSystem. Would you recommend to create 2 actor systems? I don't understand what you mean with singleton and router clusters, but I assume that mean that you use Cluster Singelton http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Singleton and Cluster Aware Routers http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Aware_Routers. You can use these two features the same ActorSystem. /Patrik Thanks, Ryadh On Friday, July 4, 2014 8:38:47 AM UTC+1, Patrik Nordwall wrote: On Thu, Jul 3, 2014 at 10:28 PM, Eugene Dzhurinsky jdev...@gmail.com wrote: So you had one cluster consisting of all nodes, and then a network split caused it to be split into two separate clusters? That does not really have anything to do with seed nodes. Seed nodes are only used as initial contact points when joining new nodes. Hi! Let's assume there are 3 nodes - A, B and C. Node A is a seed node for B and C. So when cluster starts - B joins A and C joins A, then they gossip and then B knows about C and vise versa. yes, then my understanding was correct Now A is not reachable, so both B and C mark it as quarantined. After A gets online - it doesn't know neither about B nor about C, and none of the nodes B and C will even try to restore the connections to A. quarantine is because of downing: http://doc.akka.io/docs/akka/ 2.3.4/scala/cluster-usage.html#Automatic_vs__Manual_Downing If A has some actors to be deployed on node B - then it will not be able to do so. The only way to resolve this seems to make A, B and C as seed nodes, so if any of then will disconnect - then after the connection is established (and threshold is not broken yet) they will re-join. But I'm not sure if there would be a delay in startup of node B - will it be marked as inaccessible? I repeat myself, this has nothing to do with seed nodes. Please re-read my previous reply, and this section: http://doc.akka.io/ docs/akka/2.3.4/scala/cluster-usage.html#Joining_to_Seed_Nodes /Patrik
Re: [akka-user] Re: Akka Cluster seed node problem
Hi Martynas, Thanks for the reply. Both master and workers use distributed pub-sub to send receive messages. There is a distributed pub-sub mediator which acts as a mediator and all the messages are sent to it. Master and workers subscribe to it. So no direct ActorRef is held by anyone. Master uses the mediator and Workers use the clusterClient to send the messages. You can have a look at the akka-distributed-worker template available on Typesafe. If you see the below code, logical path have been used to send the message to master. So if one master goes down, another should kick in automatically, as I have two master processes running in the cluster. FutureObject f = ask(mediator, new Send(/user/master/active, message, false), new Timeout(Duration.create(5, seconds))); Any help will be very much appreciated. Thanks in advance, Rohit -- 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 cluster loopback and actual ip address issue
Hi Rohit, this is not akka specific and this is how IP works. If you bind to localhost IP (127.0.0.1) then you receive packets sent to that IP address, which are packets sent from the same machine. If you bind to some LAN address (ex. 192.168.1.1) then you will receive packets sent to that IP address which could be packets sent from the same machine, our from a machine in your local network. On Sat, Jul 5, 2014 at 5:21 PM, Rohit Kumar Gupta rohitkumargupt...@gmail.com wrote: Hi, Does akka treat loopback address (127.0.0.1) and actual ip address differently. If I run the cluster on the same m/c (different processes) it seems I have to use one or the other for consistency (in the akka remote configuration) else things do not work. This is causing the configuration file to be different for different m/c when I open the cluster to other boxes. Any help will be appreciated. Thanks Regards, Rohit -- 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. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- 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 cluster - seed node goes down and is not discoverable afterwards
Thanks. Your definition makes perfect sense. Could we say that a Singleton, a ClusterAwareRouter are some sort of 'applications' running on top of the cluster? In that case it should allowed to have multiple 'applications' running on the same cluster. Ryadh On 7 July 2014 14:05, √iktor Ҡlang viktor.kl...@gmail.com wrote: A cluster is just a name for cooperating ActorSystems using a specific protocol. They are not reified. On Mon, Jul 7, 2014 at 2:56 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: Thanks Martynas! It seems that Clusters are a higher level entity: Cluster - ActorSystem - Actor AFAIK Clusters are created by ActorSystems when configured to do so which is probably the source of confusion (lower entity creating a higher entity) . Cheers, Ryadh On 7 July 2014 12:21, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hi Ryadh, ActorSystem can only join a Cluster once. Have you seen the documentation on Cluster Usage? http://doc.akka.io/docs/akka/2.3.4/java/cluster-usage.html The relevant excerpt from that page: An actor system can only join a cluster once. Additional attempts will be ignored. When it has successfully joined it must be restarted to be able to join another cluster or to join the same cluster again. It can use the same host name and port after the restart, but it must have been removed from the cluster before the join request is accepted. So it is not the case that Cluster is deployed on ActorSystem. But rather ActorSystem joins a particular Cluster. On Fri, Jul 4, 2014 at 4:23 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: OK we are using a cluster aware router to distribute the load. This means that we have 2 clusters deployed on the same ActorSystem, is that correct? If it is the case, should we deploy each cluster in a separate ActorSystem? Ryadh On 4 July 2014 14:20, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:10 PM, Ryadh khsib ryadh.kh...@gmail.com wrote: I mean we deployed within the same actor system: - singleton actor: scheduled task - router: the singleton distributed the work to workers using a router I presume to implement a Singleton actor, some sort of Cluster is needed. Yes The same thing applies for setting up a router. well, you can have local routers: http://doc.akka.io/docs/akka/2.3.4/java/routing.html but for cluster aware routers you need a cluster, that is right /Patrik I am totally wrong? Thanks, Ryadh On 4 July 2014 10:40, Patrik Nordwall patrik.nordw...@gmail.com wrote: On Fri, Jul 4, 2014 at 11:12 AM, Ryadh khsib riadh.kh...@gmail.com wrote: Hi Patrik, Reading this: An ActorSystem can only be part of one cluster, and only once. Rejoining or joining of two different clusters are not supported. Then the ActorSystem must be stopped and started again to join the cluster. /Patrik Do you confirm that for every Cluster an new ActorSytem should be created? An ActorSystem is created locally, in the JVM of each machine. We often refer to this as a cluster node, or a cluster member. A Cluster is a set of nodes (actor systems) working together. We are using a singleton and router clusters within the same ActorSystem. Would you recommend to create 2 actor systems? I don't understand what you mean with singleton and router clusters, but I assume that mean that you use Cluster Singelton http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Singleton and Cluster Aware Routers http://doc.akka.io/docs/akka/2.3.4/scala/cluster-usage.html#Cluster_Aware_Routers. You can use these two features the same ActorSystem. /Patrik Thanks, Ryadh On Friday, July 4, 2014 8:38:47 AM UTC+1, Patrik Nordwall wrote: On Thu, Jul 3, 2014 at 10:28 PM, Eugene Dzhurinsky jdev...@gmail.com wrote: So you had one cluster consisting of all nodes, and then a network split caused it to be split into two separate clusters? That does not really have anything to do with seed nodes. Seed nodes are only used as initial contact points when joining new nodes. Hi! Let's assume there are 3 nodes - A, B and C. Node A is a seed node for B and C. So when cluster starts - B joins A and C joins A, then they gossip and then B knows about C and vise versa. yes, then my understanding was correct Now A is not reachable, so both B and C mark it as quarantined. After A gets online - it doesn't know neither about B nor about C, and none of the nodes B and C will even try to restore the connections to A. quarantine is because of downing: http://doc.akka.io/docs/akka/ 2.3.4/scala/cluster-usage.html#Automatic_vs__Manual_Downing If A has some actors to be deployed on node B - then it will not be able to do so. The only way to resolve this seems to make A, B and C as seed nodes, so if any of then will disconnect - then after the connection is established (and threshold is not broken
Re: [akka-user] akka cluster loopback and actual ip address issue
Martynas, Thanks for the clarification. Regards, -Rohit -- 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, clustering and eventual consistency
Drop a note in the issue so it is clear that the feature is wanted by one more user. :) On Mon, Jul 7, 2014 at 3:10 PM, Mario Camou mca...@tecnoguru.com wrote: Ah, this looks very nice and I agree that it sounds easier to implement, and would perfectly cover my use case. Hopefully it will be implemented soon :) Thanks! -Mario. On 07 Jul 2014, at 14:05, Martynas Mickevičius martynas.mickevic...@typesafe.com wrote: Hi Mario, your use case resonates to me with the Hot Standby Processor feature request https://github.com/akka/akka/issues/13938, that we have in our issue tracker. In that case you would have only one Processor which does the writes. But next to that there would be a number of Hot Views that do reads and can be promoted to the Processor if the original dies. I know this is a bit different from the idea you are proposing, but this may be easier to implement than synchronizing stores of multiple processors. On Fri, Jul 4, 2014 at 7:01 PM, Mario Camou mca...@tecnoguru.com wrote: Hi everyone, I'm in the process of thinking through a rewrite of parts of an application using Akka Persistence. After watching Endre's talk from ScalaDays (I was unable to attend the talk itself and the streaming only made me sadder about that) I was thinking, is there a plan to apply this sort of thinking to PersistentActors? I was thinking of a cluster where you have several instances of a PersistentActor, behind a Cluster-Aware Router (not using a Cluster Singleton because of scalability). The thing is (as far as I've been able to determine), each PersistentActor has its own state (and event store), so they don't have any sort of shared (eventually-consistent) view of the world. Since Akka Cluster already uses the Gossip protocol to maintain cluster state, perhaps it would be interesting to extend that so that Events get propagated too. For a little more perspective, here's what I am thinking of doing. Currently the application (running in a single server) holds state in in-memory Maps coordinated using STM. The elements in these maps are persisted to JSON files every time there's an update so that, when the system goes down and back up, it can restore them. I was thinking of changing this to use Akka Persistence. Currently a single process handles both the backend (in this case, communicating with e-bike rental stations) and frontend responsibilities (exposing the state via REST calls using Spray and allowing the web front-end to modify the state). They both access the store via a Repository object which takes care of querying and updating the Maps. I was thinking that, by using Akka to access the Repository (instead of method calls) I could then scale the system out by separating the frontend and backend into separate nodes. That, however, still leaves me with a Single Point of Failure: the Repository itself. If I could have the PersistentActors communicate amongst themselves to keep an eventually-consistent view of the world, it would allow me to replicate the Repository to several nodes, or perhaps not even having a dedicated process to hold the PersistentActors, instead hosting them in the same cluster nodes as the backend(s) and frontend(s). As I asked earlier, is this planned at some point, is there some other recommended way of going about this, or am I completely out of the ballpark? Thanks, -Mario. -- 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. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- 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
Re: [akka-user] Re: Rediscala : Non-blocking, Reactive Redis driver for Scala (with Akka IO)
Hi, you should probably direct these questions to the RedisScala project page https://github.com/etaty/rediscala. On Mon, Jul 7, 2014 at 3:09 PM, SScala user shrivall...@gmail.com wrote: Hi, I am evaluating the options for a redis client. I noticed that there is no example using sentinel that has been put up.. I would like to use sentinel and have client pooling as well. Is it possible? Any tips would be useful! Regards, Shrivallabh On Thursday, 8 August 2013 16:13:21 UTC+5:30, Valérian B wrote: Hi, I am happy to announce a new driver for Redis based on Akka IO / Scala Future : https://github.com/etaty/rediscala I did some benchmark, and i reached more than 200 000 requests/second http://bit.ly/12QZsRs There is a demo project there https://github.com/etaty/rediscala-demo ready to be Akked -- 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. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- 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-persitence 2.3.4] documentation inconsistency
Hi!
I justed played a little with the new akka-persitence (2.3.4) and I found
some minor mistakes in the documentation
(http://doc.akka.io/docs/akka/2.3.4/scala/persistence.html)...at least I
think this are mistakes ;)
In the sample the RecoverCompleted is handled in the receiveCommand. In my
sample the information is send to receiveRecover
def receiveRecover: Receive = {
case evt = //...
}
def receiveCommand: Receive = {
*case RecoveryCompleted = recoveryCompleted()*
case msg = //...
}
In the chapter Snapshot the sample still using the Processor as it is
deprecated it might be a good to have a sample using the PersistentActor
(receiveRecover, receiveCommand, no Persist msg)
Regards
Wolfgang
--
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-persitence 2.3.4] documentation inconsistency
Hello Wolfgang, thanks for reporting your findings! Yes, the 1st thing you mention is indeed a typo and has been fixed in this PR: https://github.com/akka/akka/pull/15486 The 2nd thing, snapshots, should indeed be updated, I’ve created an issue and marked it as community-contrib: https://github.com/akka/akka/issues/15508 If you’re free or someone would like to help us out time-wise, we would very much welcome a pull request to fix this :-) Thanks again for reporting, happy hakking! -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io -- 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 camel individual acknowledgements
Any help would be greatly appreciated.
On sáb 05 jul 2014 19:08:55 AST, Jorge Marizan wrote:
The sender ref is stored in an object (brokerRef) as a property and
passed to a FSM actor as a message. And the message is discarded if
the FSM actor state is timeouted.
case Event(StateTimeout, brokerRef: BrokerContainer) = {
brokerRef.broker.map(broker = broker ! Failure(new
Exception(Exception)))
goto(Idle)
}
√iktor Ҡlang wrote:
What does the code around that piece of code look like?
On Sat, Jul 5, 2014 at 7:59 PM, Jorge Marizan jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com wrote:
akka.actor.Status.Failure
√iktor Ҡlang wrote:
akka.status.Failure or scala.util.Failure?
On Jul 5, 2014 7:00 PM, Jorge Marizan jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com wrote:
like this:
sender ! Failure(new Exception(error))
√iktor Ҡlang wrote:
And how are you sending back the exception to the sender()?
On Jul 5, 2014 12:31 AM, Jorge Marizan
jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com wrote:
Yes I did.
On vie 04 jul 2014 18:08:01 AST, √iktor Ҡlang wrote:
Did you turn off autoAck as per the documentation?
On Jul 4, 2014 10:59 PM, Jorge Marizan
jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.marizan@gmail mailto:jorge.marizan@gmail.
mailto:jorge.marizan@gmail mailto:jorge.marizan@gmail.__com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com wrote:
Hi Viktor, Yes I did,
Let me briefly offer you a better explanation
of the
situation:
* The consumer actor receive a single message
from a JMS
endpoint
(ActiveMQ), there are no new messages arriving
until the
consumer
ack or report the message.
* Each successfully processed message has to be
acknowledged
independently,
* Each failed message is rejected sending an
exception to the
sender() of the consumer actor
Using the CLIENT_ACKNOWLEDGE mode on the jms
endpoint, when I
sent back an Ack message back to the sender()
on the
consumer
actor, Camel documentation says the client
application
code under
the hood explicitly calls the Message.acknowledge()
method to
acknowledge the message, but also any other
messages
in the
consumer that have already been completely
processed, and
I tried
and indeed the behavior was exactly like that. But
for a weird
reason all the previous reported messages are being
acknowledged
and not retried no matter if an exception was sent
back to the
sender() ref on the consumer actor.
I tried to use INDIVIDUAL_ACKNOWLEDGE mode on the
endpoint but
based on Camel documentation it acknowledges
only the
message on
which it is invoked and apparently there is no
way on
which I
could ack an individual message. It does not flush
acknowledgments
for any other completed messages.
Regards,
Jorge
On vie 04 jul 2014 02:58:55 AST, √iktor Ҡlang
wrote:
Hi Jorge,
did you follow these instructions?
http://doc.akka.io/docs/akka/2.3.4/scala/camel.html#Delivery_acknowledgements
http://doc.akka.io/docs/akka/__2.3.4/scala/camel.html#__Delivery_acknowledgements
http://doc.akka.io/docs/akka/__2.3.4/scala/camel.html#__Delivery_acknowledgements
http://doc.akka.io/docs/akka/2.3.4/scala/camel.html#Delivery_acknowledgements
On Fri, Jul 4, 2014 at 3:20 AM, Jorge Marizan
jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
mailto:jorge.mari...@gmail.com mailto:jorge.mari...@gmail.com
[akka-user] become(params) vs FSM
I'm considering using become(processing(params)) in some of my short-lived job actors, so that the params are available when the job completes, yet the job can be started separately from its creation. So I'm wondering about the overhead of become, and whether I should be considering the FSM stuff instead. 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.
Re: [akka-user] become(params) vs FSM
What kind of overhead? On Mon, Jul 7, 2014 at 4:54 PM, Richard Rodseth rrods...@gmail.com wrote: I'm considering using become(processing(params)) in some of my short-lived job actors, so that the params are available when the job completes, yet the job can be started separately from its creation. So I'm wondering about the overhead of become, and whether I should be considering the FSM stuff instead. 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. -- Cheers, √ -- 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-cluster][version 2.3.0] Failed to write message to the transport when more than 4 nodes joined into the cluster
Hello Martynas, I have found the problem. There's a bug in our own code of message serialization. I have debugged into the code of Akka to detect this. It's always strange that there's no explicit exception trace in the log... Now I test a cluster with 10 nodes every thing works fine. Thanks, Mint 在 2014年7月7日星期一UTC+2下午1时55分58秒，Martynas Mickevičius写道： Hi Mint, whats the amount of messages you send from the worker nodes? Is it very high? Can you package this to a small test case and share it? On Fri, Jul 4, 2014 at 11:06 PM, Mint tangji...@gmail.com javascript: wrote: Hi Patrik, I've just upgraded the version of Akka from 2.3.0 to 2.3.4 for our prototype project. Still the same warn message, query failed with time out because the result of worker aggregator has not been delivered to client. When I tried to launch the test with one client node and 4 worker remote nodes I get the same message: 2014-07-04 21:55:31,865 | WARN | ult-dispatcher-4 | ReliableDeliverySupervisor | receive$1$$anonfun$applyOrElse$2 71 | 202 - com.typesafe.akka.slf4j - 2.3.4 | Association with remote system [akka.tcp://cluster@host:port] has failed, address is now gated for [5000] ms. Reason is: [Failed to write message to the transport]. I have launched the work nodes in LAN on four machines. Thanks in advance for your help, Mint 在 2014年7月4日星期五UTC+2下午5时42分41秒，Patrik Nordwall写道： First of all, use latest released version. That is 2.3.4. Then we can talk :-) /Patrik On Fri, Jul 4, 2014 at 5:05 PM, Mint tangji...@gmail.com wrote: Hi, I'm writing code using akka cluster to distribute our internal analytics tool. At the beginning things go quite well when I have one analytic client and 2 till 3 analytic remote workers. But every time I try to add one more remote nodes to the cluster(totally one client node and 4 remote worker nodes in the cluster), I get warning Association with remote system [akka.tcp:/analytics-cluster@host:port] has failed, address is now gated for [5000] ms. Reason is: [Failed to write message to the transport]. Query execution failed because result came from the 4th worker node cannot be delivered to client. So could you guys tell me how I should configure the application so that it can handle more than 4 remote workers and how can I get the internal exception stack to know what is the really reason that the message cannot be delivered(I have already enable log-received-messages= on log-sent-messages=on, with global log level to DEBUG) ? Thanks a lot and any advice can help me a lot. Mint -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com. To post to this group, send email to akka...@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Martynas Mickevičius Typesafe http://typesafe.com/ – Reactive http://www.reactivemanifesto.org/ Apps on the JVM -- 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: become(params) vs FSM
The time-overhead of calling become is very low. (I believe it's only one allocation aside from the PF). On Mon, Jul 7, 2014 at 5:32 PM, Richard Rodseth rrods...@gmail.com wrote: I was thinking time rather than space. I'm guessing the cost of swapping is not something I should worry about, but any reassurances or caveats are welcome. Receive block as partial function is so elegant! On Mon, Jul 7, 2014 at 7:54 AM, Richard Rodseth rrods...@gmail.com wrote: I'm considering using become(processing(params)) in some of my short-lived job actors, so that the params are available when the job completes, yet the job can be started separately from its creation. So I'm wondering about the overhead of become, and whether I should be considering the FSM stuff instead. 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. -- Cheers, √ -- 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: become(params) vs FSM
Elsewhere you've said that there are performance downsides to
context.become, specifically that this is the reason sender() is a function
rather than doing something like def receive(sender: ActorRef): Receive = {
... }, which would eliminate the problem of closing over sender() in
futures within a receive.
Does the concern only come into play when calling context.become
potentially thousands of times per second? I can see how that would
probably lead to GC issues.
On Monday, July 7, 2014 9:34:56 AM UTC-6, √ wrote:
The time-overhead of calling become is very low. (I believe it's only one
allocation aside from the PF).
On Mon, Jul 7, 2014 at 5:32 PM, Richard Rodseth rrod...@gmail.com
javascript: wrote:
I was thinking time rather than space. I'm guessing the cost of swapping
is not something I should worry about, but any reassurances or caveats are
welcome. Receive block as partial function is so elegant!
On Mon, Jul 7, 2014 at 7:54 AM, Richard Rodseth rrod...@gmail.com
javascript: wrote:
I'm considering using become(processing(params)) in some of my
short-lived job actors, so that the params are available when the job
completes, yet the job can be started separately from its creation.
So I'm wondering about the overhead of become, and whether I should be
considering the FSM stuff instead.
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+...@googlegroups.com javascript:.
To post to this group, send email to akka...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Cheers,
√
--
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: ANNOUNCE: First akka-http-core preview and updated akka-stream preview
I've been experimenting with akka-http in akka 2.3.4 with little luck --
evidently I am missing something (+ I'm an Akka newbie - which doesn't help
:( )
I'm coming at this from the Java API (via Groovy -- doubt if that is my
problem though - Akka has worked marvelously with Groovy so far) and I have
the following (tucked inside an Actor so an Akka system etc is all set up
..)
import akka.http.model.japi.HttpMethods
import akka.http.model.japi.Http
import akka.http.model.japi.HttpRequest
import akka.http.model.japi.Uri
import akka.pattern.Patterns
import scala.concurrent.Await
import scala.concurrent.duration.Duration
import scala.concurrent.Future
try {
HttpRequest foo = HttpRequest.create()
foo.withUri(Uri.create(http://spray.io/;))
foo.withMethod(HttpMethods.GET)
final ActorRef http = Http.get(context.system()).manager()
Future f = Patterns.ask(http, foo, 15000)
println ${Await.result(f, Duration.apply(15000L, millis))}
} catch (Exception e) {
e.printStackTrace()
}
All goes swimmingly until the Await.result() which eventually times out:
Error |
akka.pattern.AskTimeoutException: Ask timed out on
[Actor[akka://jcore/user/IO-HTTP#396415378]] after [15000 ms]
Error |
at
akka.pattern.PromiseActorRef$$anonfun$1.apply$mcV$sp(AskSupport.scala:333)
Error |
at akka.actor.Scheduler$$anon$7.run(Scheduler.scala:117)
Error |
at
scala.concurrent.Future$InternalCallbackExecutor$.scala$concurrent$Future$InternalCallbac
kExecutor$$unbatchedExecute(Future.scala:694)
Error | .
Which I interpret to mean that the Request message got to the HTTP manager
but no reply was forthcoming. Evidently I am misunderstanding something
here and I'm hoping someone can set me straight :)
Tnx
Alan
--
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: ANNOUNCE: First akka-http-core preview and updated akka-stream preview
Hi Alan,
Akka-http works together with akka-stream, so it does work differently than
you tried. Since this is an early technical preview the docs are quite a
bit sketchy, but there are some examples already here:
http://doc.akka.io/docs/akka-stream-and-http-experimental/0.4/scala/http-core-server.html
-Endre
On Mon, Jul 7, 2014 at 6:11 PM, alan...@gmail.com wrote:
I've been experimenting with akka-http in akka 2.3.4 with little luck --
evidently I am missing something (+ I'm an Akka newbie - which doesn't help
:( )
I'm coming at this from the Java API (via Groovy -- doubt if that is my
problem though - Akka has worked marvelously with Groovy so far) and I have
the following (tucked inside an Actor so an Akka system etc is all set up
..)
import akka.http.model.japi.HttpMethods
import akka.http.model.japi.Http
import akka.http.model.japi.HttpRequest
import akka.http.model.japi.Uri
import akka.pattern.Patterns
import scala.concurrent.Await
import scala.concurrent.duration.Duration
import scala.concurrent.Future
try {
HttpRequest foo = HttpRequest.create()
foo.withUri(Uri.create(http://spray.io/;))
foo.withMethod(HttpMethods.GET)
final ActorRef http = Http.get(context.system()).manager()
Future f = Patterns.ask(http, foo, 15000)
println ${Await.result(f, Duration.apply(15000L, millis))}
} catch (Exception e) {
e.printStackTrace()
}
All goes swimmingly until the Await.result() which eventually times out:
Error |
akka.pattern.AskTimeoutException: Ask timed out on
[Actor[akka://jcore/user/IO-HTTP#396415378]] after [15000 ms]
Error |
at
akka.pattern.PromiseActorRef$$anonfun$1.apply$mcV$sp(AskSupport.scala:333)
Error |
at akka.actor.Scheduler$$anon$7.run(Scheduler.scala:117)
Error |
at
scala.concurrent.Future$InternalCallbackExecutor$.scala$concurrent$Future$InternalCallbac
kExecutor$$unbatchedExecute(Future.scala:694)
Error | .
Which I interpret to mean that the Request message got to the HTTP manager
but no reply was forthcoming. Evidently I am misunderstanding something
here and I'm hoping someone can set me straight :)
Tnx
Alan
--
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] Why does akka-persistence not provide an API to read a specific entry from a journal?
Hello Moiz,
an event detached from it’s lineage does not make much sense for building
up state - which is how persistent actors are designed to be used.
An persistent actor’s state, and your “domain state”, should be built up
from such series of events (and snapshots).
We do support playback “until” a given sequence number, you can achieve
this via:
class Peter extends PersistentActor {
override def preStart() {
self ! Recover(toSequenceNr = 20)
}
def receiveCommand = { }
def receiveRecover = {
case m if lastSequenceNr == 15 = // ...
case _ = // ...
}
If you only want one of these items, you can just ignore the others like
shown in the example above.
But reading out one specific event is not something we will want to support
(we are actively removing methods that target “one message” in favour of
ranged operations (see deprecated deleteMessage vs.
deleteMessages(toSequenceNr)).
May I ask why you need to read exactly one event?
It would help to understand your use case, and then advice. :-)
On Mon, Jul 7, 2014 at 7:00 PM, Moiz Raja moizr...@gmail.com wrote:
I am using akka-persistence and I have a need to read a specific journal
entry but I do not see a way in akka-persistence to do that.
Is there any reason why an API has not been provided for this? Are there
any plans to provide this in an upcoming release?
Thanks,
-Moiz
--
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
hAkker @ Typesafe
http://typesafe.com
--
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] Why does akka-persistence not provide an API to read a specific entry from a journal?
Hi Konrad,
So I want to create a distributed state machine based on RAFT which I know
you're pretty familiar with. I want to use this facility when reconciling
logs. My understanding is that when an AppendEntries fails the Leader tries
to send the Follower a previous entry from the log till we reach the point
where the previous term and sequence match in the two logs. I want to use
the read facility in that scenario.
I'm not sure reading until a certain sequence number will be performant.
I know you must have done more thinking on this since you have worked both
on akka-persistence and akka-raft :) so I would appreciate your input.
Thanks,
-Moiz
On Monday, 7 July 2014 10:18:31 UTC-7, Konrad Malawski wrote:
Hello Moiz,
an event detached from it’s lineage does not make much sense for building
up state - which is how persistent actors are designed to be used.
An persistent actor’s state, and your “domain state”, should be built up
from such series of events (and snapshots).
We do support playback “until” a given sequence number, you can achieve
this via:
class Peter extends PersistentActor {
override def preStart() {
self ! Recover(toSequenceNr = 20)
}
def receiveCommand = { }
def receiveRecover = {
case m if lastSequenceNr == 15 = // ...
case _ = // ...
}
If you only want one of these items, you can just ignore the others like
shown in the example above.
But reading out one specific event is not something we will want to
support (we are actively removing methods that target “one message” in
favour of ranged operations (see deprecated deleteMessage vs.
deleteMessages(toSequenceNr)).
May I ask why you need to read exactly one event?
It would help to understand your use case, and then advice. :-)
On Mon, Jul 7, 2014 at 7:00 PM, Moiz Raja moiz...@gmail.com javascript:
wrote:
I am using akka-persistence and I have a need to read a specific journal
entry but I do not see a way in akka-persistence to do that.
Is there any reason why an API has not been provided for this? Are there
any plans to provide this in an upcoming release?
Thanks,
-Moiz
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups
Akka User List group.
To unsubscribe from this group and stop receiving emails from it, send an
email to akka-user+...@googlegroups.com javascript:.
To post to this group, send email to akka...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe
http://typesafe.com
--
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] [Java 2.3.x] How do I reply to a failure?
Hi,
I am trying to understand how to get the sender of the failed message in a
supervisor. In this sample, there is a service that changes a string to
upper case. I would like to return a FailureToUpResponse when the worker
throws an exception. The service itself is being called from an ask from a
play controller. Instead of getting the above class, I get a timeout. The
line that I know is wrong is: context().sender().tell(new
FailureToUpResponse(), self()); - which returns the worker class and not
the controller, but I cannot figure out the correct syntax. Here is the
full class:
public class ServiceActor extends AbstractActor {
private int count = 0;
public ServiceActor() {
receive(
ReceiveBuilder.match(ServiceActor.ToUpperRequest.class,
request - {
Logger.debug(About service: + self().toString() +
Thread: + Thread.currentThread().getName());
count++;
final ActorRef worker =
context().actorOf(Props.create(Worker.class, count));
worker.forward(request, context());
}).build()
);
}
private SupervisorStrategy strategy =
new OneForOneStrategy(10, Duration.create(1 minute),
DeciderBuilder.
match(IllegalArgumentException.class, e - {
Logger.debug(E: + e);
context().sender().tell(new FailureToUpResponse(),
self());
return stop();
}).
matchAny(o - escalate()).build());
@Override
public SupervisorStrategy supervisorStrategy() {
return strategy;
}
public static class Worker extends AbstractActor {
public Worker(int count) {
receive(
ReceiveBuilder.match(ServiceActor.ToUpperRequest.class,
request - {
Logger.debug(About me: + self().toString() +
Thread: + Thread.currentThread().getName());
if(request.input.equals(error)) throw new
IllegalArgumentException(Cannot handle the word error!);
Thread.sleep(5000);
Logger.debug(Did the work: +
request.input.toUpperCase() + - + count);
final ToUpperResponse response = new
ToUpperResponse(request.input, request.input.toUpperCase() + - + count);
sender().tell(response, self());
context().stop(self());
}).build()
);
}
}
public static class ToUpperRequest {
public final String input;
public ToUpperRequest(String input) {
this.input = input;
}
}
public static class ToUpperResponse {
public final String input;
public final String output;
public ToUpperResponse(String input, String output) {
this.input = input;
this.output = output;
}
}
public static class FailureToUpResponse {
}
}
--
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] Play and Akka in one Cluster
Hi, I'm currently starting to learn more about akka's cluster feature. My goal is to have separate frontend and backend which are part of the same cluster, so I can - Start jobs on backend akka-nodes from the play frontend-nodes - Monitor my cluster status (nodes up/down, jobs running) - Update backend and frontend independently That being said, I'm struggling what is the best way to achieve this. 1. Should I create two ActorSystems in my play application. The internal, play managed one, which is harder to configure (e.g. name is static to *play*) 2. Should I use remoting instead of clustering? I tried solution number 1, but the websocket actors couldn't be created, because *ActorRefClusterProvider* wasn't configured (but it's in the config, when I log it via system.logConfiguration). thanks for any advice, Muki -- 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 Cluster seed node problem
Hi Rohit, Just a thought, as you mentioned earlier Each m/c hosts once master and one worker process running on different ports. What about running a test, such as running master in one m/c and running worker in other m/c. Thanks Rahat On Monday, July 7, 2014 11:07:17 PM UTC+10, Rohit Kumar Gupta wrote: Hi Martynas, Thanks for the reply. Both master and workers use distributed pub-sub to send receive messages. There is a distributed pub-sub mediator which acts as a mediator and all the messages are sent to it. Master and workers subscribe to it. So no direct ActorRef is held by anyone. Master uses the mediator and Workers use the clusterClient to send the messages. You can have a look at the akka-distributed-worker template available on Typesafe. If you see the below code, logical path have been used to send the message to master. So if one master goes down, another should kick in automatically, as I have two master processes running in the cluster. FutureObject f = ask(mediator, new Send(/user/master/active, message, false), new Timeout(Duration.create(5, seconds))); Any help will be very much appreciated. Thanks in advance, Rohit -- 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] work pull pattern and autoscalling workers
I'm using the working pull pattern and wanted to be able to spawn and reap workers while the application is running. Spinning up new workers is trivial but I had some questions about terminating current workers. Currently I'll send a worker a PoisonPill to get it to shut down but when I do this I can't discriminate between a worker that just crashed and one that I sent a PoisonPill to. The master could just keep a Set of worker that where sent a PoisonPill, that would at least tell me if it was a crash or a request to shut down. I wanted to know if there is another way of terminating a child node without sending it a PoisonPill or if there is just a better way to do all this. Thanks, Greg -- 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: work pull pattern and autoscalling workers
You could call context.unwatch(worker) and then context.stop(worker) from your supervisor actor. Then you won't get the Terminated message, though you also won't find out about a crash if the actor were the die for whatever reason before being stopped. For the reason I might lean towards just keeping track of stopped actors and checking if a Terminated message is for one that's already been stopped, though I suppose that could suffer from the same flaw. On Monday, July 7, 2014 5:24:32 PM UTC-6, Greg Flanagan wrote: I'm using the working pull pattern and wanted to be able to spawn and reap workers while the application is running. Spinning up new workers is trivial but I had some questions about terminating current workers. Currently I'll send a worker a PoisonPill to get it to shut down but when I do this I can't discriminate between a worker that just crashed and one that I sent a PoisonPill to. The master could just keep a Set of worker that where sent a PoisonPill, that would at least tell me if it was a crash or a request to shut down. I wanted to know if there is another way of terminating a child node without sending it a PoisonPill or if there is just a better way to do all this. Thanks, Greg -- 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.
