Re: [akka-user] ActorSelection and Identify wildcard issue
I see, but why ForwardingActor is not matched? Another question - imagine that I have some different paths and I only care about finding a leaf, like this: /user/someActor/someotheActor/*someImportantActor* I have *someImportantActor* known and don't care about it's parents - is it possible to lookup and skip parent levels? Or wildcard only used for partial search in names? On Tuesday, March 18, 2014 4:48:24 PM UTC+2, Patrik Nordwall wrote: The wildcard in /user/*/ChildActor will match 2 actors, both ChildCreationActor and LookingActor. The second path will not match and you get ActorIdentity with ref null. The first path will match your expected ChildActor. You will receive two ActorIdentity but you happen to use only the first. The order of these messages are undefined. Regards, Patrik On Tue, Mar 18, 2014 at 2:18 PM, Anatoliy Kaverin a.ka...@gmail.comjavascript: wrote: Greetings, I've been using Akka in my Java based backend and faced some issue related to ActorSelection API if it is used from ActorContext (from inside Actor). For some reason I cannot find existing Actors via Identify message for specific paths. Imagine, that I have such Actor hierarchy: USER - Parent Actor - Child Actor USER - WorkerActor And let's assume that I would like to locate Child Actor via actor selection and use wildcard for the purpose. So, I'm building such path: /user/*/ChildActor For some reason - if this path is used for lookup via global Akka system context - ActorIdentity provides me ActorRef But, if I will perform the same lookup but from inside WorkerActor via ActorContext - Identify ActorRef is null. For me it seems like a bug and inconsistent behavior. I've provided code with different scenarios and the correct one. JUnit code with the issue https://gist.github.com/Anatolik/9619710 Another one point - for some reason if I call actorSelection.tell from inside Worker Actor - messages got delivered to the target ChildActor. But, I see some errors in dead letters office: 15:08:21.916 INFO [default-akka.actor.default-dispatcher-3] a.a.EmptyLocalActorRef - Message [java.lang.String] from TestActor[akka://default/user/$$a] to Actor[akka://default/user/$$a/ForwardingActor] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. Any ideas? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.comjavascript: . 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.
[akka-user] PersistentChannel wired behavior
hi, in my test system I have 2 processors, A, and B. In the logs below reflects this message flow: *Send persistent message DoDepositCash to A* *Send persistent message DoSubmitOrder to A,* *A receives DoSubmitOrder message and yields OrderCashLocked to a channel X and delivers to B* *B receives OrderCashLocked message and yields OrderSubmitted to a channel Y and delivers back to A.* Below are logs printed when the system is initially up: Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,Collections(),Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,Collections(),Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,Collections(),DeliveredByPersistentChannel(X,2,1,Actor[akka://mysys/user/X/$a#1241560331]),Actor[akka://mysys/system/deletion-batch-layer#940984408],Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,Collections(),DeliveredByPersistentChannel(Y,1,1,Actor[akka://mysys/user/Y/$a#1653209817]),Actor[akka://mysys/system/deletion-batch-layer#940984408],Actor[akka://mysys/user/market_processor_btc_rmb/singleton#1752194582]) Then I got those during the first replay (no snapshoting): Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,List(),Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,List(X),Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,List(Y),null,null,Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,List(),null,null,Actor[akka.tcp://mysys@192.168.0.103:50354/user/market_processor_btc_rmb/singleton#1752194582]) Processor B-A @seq=2 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),2,mysys_mp_btc_rmb,false,0,Collections(),DeliveredByPersistentChannel(X,2,1,Actor[akka://mysys/user/X/$a#669702344]),Actor[akka://mysys/system/deletion-batch-layer#1382334128],Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=4 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212250415)),0,0,Pending,None),List()),4,mysys_ap,false,0,Collections(),DeliveredByPersistentChannel(Y,2,1,Actor[akka://mysys/user/Y/$a#-117955869]),Actor[akka://mysys/system/deletion-batch-layer#1382334128],Actor[akka://mysys/user/market_processor_btc_rmb/singleton#288803418]) And these during 2nd reply: Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,List(),Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,List(X),Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,List(Y),null,null,Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,List(),null,null,Actor[akka.tcp://mysys@192.168.0.103:50354/user/market_processor_btc_rmb/singleton#1752194582]) Processor B-A @seq=2 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),2,mysys_mp_btc_rmb,false,0,List(Y),null,null,Actor[akka.tcp://mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=4 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212250415)),0,0,Pending,None),List()),4,mysys_ap,false,0,List(),null,null,Actor[akka.tcp://mysys@192.168.0.103:50364/user/market_processor_btc_rmb/singleton#288803418]) Processor B-A @seq=3
Re: [akka-user] Re: Reconnect Remote Actor
On Tue, Mar 18, 2014 at 7:12 PM, Rob S rms...@gmail.com wrote: Is the problem because I can't reconnect? When I kill the connection between two remotes on one side I can't reestablish the same connection (ip and port). Would I need to restart the apps on both systems to resort communications? This is supposed to work with Akka 2.3.0. We have had similar problems when connecting with same host/port in earlier versions, but they should have been solved. It could still be some bug left in there. I will look more at this at the end of the week. Let me know if you find anything else. Perhaps try with the LookupApp also. Additional log output can be seen with akka.remote.log-sent-messages=on akka.remote.log-received-messages=on Thanks /Patrik Rob On Monday, March 17, 2014 3:42:01 PM UTC-4, Rob S wrote: Hi all, I am starting out with remote actors and I have run into an issue I can't seem to find an answer for. I have setup an application that performs distributed work on remote systems. Simply I have an actor system on one computer that sends a work request to a remote actor, the remote performs the work and returns the result. This process works perfectly. My issue comes in when I shutdown the requesting actor system and trying to start it up again. I get a connection refused on the remote system and I can not pass any messages to the remote system anymore. When I restart both applications everything works fine. I am using Akka 2.3.0 1. System A starts up 2. System B starts up and sends request to System A 3. System A sends a reply to System B 4. System B shutsdown 5. System B starts up and sends request to System A 6. System A outputs connection refused Rob -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Cluster failover: preloaded actors
You're welcome. Anyway, I have created a ticket for the hot standby processor: https://www.assembla.com/spaces/akka/tickets/3938 That doesn't mean that we will implement it, but we will take it into consideration. Thanks for the feedback. Cheers, Patrik On Tue, Mar 18, 2014 at 8:52 PM, Eduardo Fernandes edu...@gmail.com wrote: Many thanks Patrik for your post. Good shot. We could consider sending commands simultaneously to two processors (the main and a standby) and in case of timeout talking to the first we could talk to the second. After the main recovering we could return to the original situation. Maybe we could create both actors in different clusters in different machines to avoid single point of failure in case of machine crash. Many thanks again for your time and for any comment. Regards. El martes, 18 de marzo de 2014 17:12:43 UTC+1, Patrik Nordwall escribió: I see what you are looking for, and it is not supported with current tools. It would be something that is periodically replaying the event stream like a view, but can then be changed into a normal writing processor. Have you thought about using an active standby? It would do the exact same thing as the primary, but the output (external side effects) would be ignored/filtered on the standby. It depends very much on your domain if that is a good or bad idea. Regards, 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+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] ActorSelection and Identify wildcard issue
On Wed, Mar 19, 2014 at 7:37 AM, Anatoliy Kaverin a.kave...@gmail.comwrote: I see, but why ForwardingActor is not matched? What do you mean? You will get 2 ActorIdentity replies, one matching and one not matching. If you are thinking about the deadletter String I guess it is similar if you send the String to a wildcard. LookingActor is matching the wildcard, but it doesn't have a child named ForwardingActor. Another question - imagine that I have some different paths and I only care about finding a leaf, like this: /user/someActor/someotheActor/*someImportantActor* I have *someImportantActor* known and don't care about it's parents - is it possible to lookup and skip parent levels? no Or wildcard only used for partial search in names? yes, you must know the levels /user/*/*/someImportantActor /Patrik On Tuesday, March 18, 2014 4:48:24 PM UTC+2, Patrik Nordwall wrote: The wildcard in /user/*/ChildActor will match 2 actors, both ChildCreationActor and LookingActor. The second path will not match and you get ActorIdentity with ref null. The first path will match your expected ChildActor. You will receive two ActorIdentity but you happen to use only the first. The order of these messages are undefined. Regards, Patrik On Tue, Mar 18, 2014 at 2:18 PM, Anatoliy Kaverin a.ka...@gmail.comwrote: Greetings, I've been using Akka in my Java based backend and faced some issue related to ActorSelection API if it is used from ActorContext (from inside Actor). For some reason I cannot find existing Actors via Identify message for specific paths. Imagine, that I have such Actor hierarchy: USER - Parent Actor - Child Actor USER - WorkerActor And let's assume that I would like to locate Child Actor via actor selection and use wildcard for the purpose. So, I'm building such path: /user/*/ChildActor For some reason - if this path is used for lookup via global Akka system context - ActorIdentity provides me ActorRef But, if I will perform the same lookup but from inside WorkerActor via ActorContext - Identify ActorRef is null. For me it seems like a bug and inconsistent behavior. I've provided code with different scenarios and the correct one. JUnit code with the issue https://gist.github.com/Anatolik/9619710 Another one point - for some reason if I call actorSelection.tell from inside Worker Actor - messages got delivered to the target ChildActor. But, I see some errors in dead letters office: 15:08:21.916 INFO [default-akka.actor.default-dispatcher-3] a.a.EmptyLocalActorRef - Message [java.lang.String] from TestActor[akka://default/user/$$a] to Actor[akka://default/user/$$a/ForwardingActor] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. Any ideas? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/ current/additional/faq.html Search the archives: https://groups.google.com/ group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@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. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Akka persistent messages sent to two destinations thru one channel?
Does the following answer your question? If a processor emits more than one outbound message per inbound Persistent message it *must* use a separate channel for each outbound message to ensure that confirmations are uniquely identifiable, otherwise, at-least-once message delivery semantics do not apply. This rule has been introduced to avoid writing additional outbound message identifiers to the journal which would decrease the overall throughput. It is furthermore recommended to collapse multiple outbound messages to the same destination into a single outbound message, otherwise, if sent via multiple channels, their ordering is not defined. Regards, Patrik On Wed, Mar 19, 2014 at 5:00 AM, Daniel Wang dan...@coinport.com wrote: Can I use 'withPayload' to send the same persistent message to two destinations using one channel? as below: case p @ Persistent(payload, seq) = val p2 = p.withPayload(newPayload) channel forward Deliver(p2, path1) channel forward Deliver(p2, path2) If not, what's the solution then? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Too many open files
Hi Rohit, 19 mar 2014 kl. 01:36 skrev Rohit Gupta greatroh...@gmail.com: Hi Roland, you mention a “potential leak” and “getting similar stack traces”. How and why exactly are these stack traces emitted? Due to a crash? These stack traces were seen in thread dumps when the application was running. We suspect the number of threads with this trace accumulate over time/load. The thing we are worried about is the theads for netty connections, there are 456 similar threads. [Attached file] Another thing: have you made certain that you don’t create ActorSystems other than during application start-up? (we had reports of this kind where someone had used `def` where `val` was meant—it happens to the best!) We create actorSystem only during start-up and use 'def' From the log it is clear that you have currently three instances of the same actor system name running (and possibly had more before): make sure that you really only create the ActorSystem once, e.g. by making it a `val`. In any case, we would need to see the thread dump and the akka config from a failing system in order to be certain. We are using the akka default configuration for our application, just changing the host/port and logging properties. I am attaching the thread dumps. I gave it a quick glance and what I see does not point towards a defect it Akka (you do seem to have Netty instances running on that server without properly capping its worker pools; I would guess that the machine has a lot of cores, right?). We cannot debug production issues on this mailing list for free—we simply don’t have the bandwidth—but we can certainly help you on commercial terms; in that case just ping me off-list. Regards, Roland Thanks, -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. dump.txp Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] Cluster failover: preloaded actors
Thanks for the new ticket! This kind of behavior is extremely useful in some cases. In our case we're moving huge Redis/HBase structures to multiple java/scala maps and the result is thousand of times faster and simple and faster to implement. We think, after reading the docs, that Akka is a half step away of this. Thanks again for your help and time! El miércoles, 19 de marzo de 2014 09:30:15 UTC+1, Patrik Nordwall escribió: You're welcome. Anyway, I have created a ticket for the hot standby processor: https://www.assembla.com/spaces/akka/tickets/3938 That doesn't mean that we will implement it, but we will take it into consideration. Thanks for the feedback. Cheers, Patrik On Tue, Mar 18, 2014 at 8:52 PM, Eduardo Fernandes edu...@gmail.comjavascript: wrote: Many thanks Patrik for your post. Good shot. We could consider sending commands simultaneously to two processors (the main and a standby) and in case of timeout talking to the first we could talk to the second. After the main recovering we could return to the original situation. Maybe we could create both actors in different clusters in different machines to avoid single point of failure in case of machine crash. Many thanks again for your time and for any comment. Regards. El martes, 18 de marzo de 2014 17:12:43 UTC+1, Patrik Nordwall escribió: I see what you are looking for, and it is not supported with current tools. It would be something that is periodically replaying the event stream like a view, but can then be changed into a normal writing processor. Have you thought about using an active standby? It would do the exact same thing as the primary, but the output (external side effects) would be ignored/filtered on the standby. It depends very much on your domain if that is a good or bad idea. Regards, 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 javascript:. To post to this group, send email to akka...@googlegroups.comjavascript: . Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. -- Patrik Nordwall Typesafe http://typesafe.com/ - Reactive apps on the JVM Twitter: @patriknw -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] ActorSelection and Identify wildcard issue
Hi Anatoliy, in general it is much easier to reason about the system if you explicitly introduce the actors to each other instead of relying on String-based lookups (which tie down your hierarchy as you now learnt). You can do that by passing an ActorRef to the constructor of a new actor or within a message sent to that actor. Regards, Roland 19 mar 2014 kl. 07:37 skrev Anatoliy Kaverin a.kave...@gmail.com: I see, but why ForwardingActor is not matched? Another question - imagine that I have some different paths and I only care about finding a leaf, like this: /user/someActor/someotheActor/someImportantActor I have someImportantActor known and don't care about it's parents - is it possible to lookup and skip parent levels? Or wildcard only used for partial search in names? On Tuesday, March 18, 2014 4:48:24 PM UTC+2, Patrik Nordwall wrote: The wildcard in /user/*/ChildActor will match 2 actors, both ChildCreationActor and LookingActor. The second path will not match and you get ActorIdentity with ref null. The first path will match your expected ChildActor. You will receive two ActorIdentity but you happen to use only the first. The order of these messages are undefined. Regards, Patrik On Tue, Mar 18, 2014 at 2:18 PM, Anatoliy Kaverin a.ka...@gmail.com wrote: Greetings, I've been using Akka in my Java based backend and faced some issue related to ActorSelection API if it is used from ActorContext (from inside Actor). For some reason I cannot find existing Actors via Identify message for specific paths. Imagine, that I have such Actor hierarchy: USER - Parent Actor - Child Actor USER - WorkerActor And let's assume that I would like to locate Child Actor via actor selection and use wildcard for the purpose. So, I'm building such path: /user/*/ChildActor For some reason - if this path is used for lookup via global Akka system context - ActorIdentity provides me ActorRef But, if I will perform the same lookup but from inside WorkerActor via ActorContext - Identify ActorRef is null. For me it seems like a bug and inconsistent behavior. I've provided code with different scenarios and the correct one. JUnit code with the issue Another one point - for some reason if I call actorSelection.tell from inside Worker Actor - messages got delivered to the target ChildActor. But, I see some errors in dead letters office: 15:08:21.916 INFO [default-akka.actor.default-dispatcher-3] a.a.EmptyLocalActorRef - Message [java.lang.String] from TestActor[akka://default/user/$$a] to Actor[akka://default/user/$$a/ForwardingActor] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. Any ideas? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@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 - 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] ActorSelection and Identify wildcard issue
Thanks for your help. I found a way to resolve my problem. On Wednesday, March 19, 2014 11:15:01 AM UTC+2, rkuhn wrote: Hi Anatoliy, in general it is much easier to reason about the system if you explicitly introduce the actors to each other instead of relying on String-based lookups (which tie down your hierarchy as you now learnt). You can do that by passing an ActorRef to the constructor of a new actor or within a message sent to that actor. Regards, Roland 19 mar 2014 kl. 07:37 skrev Anatoliy Kaverin a.ka...@gmail.comjavascript: : I see, but why ForwardingActor is not matched? Another question - imagine that I have some different paths and I only care about finding a leaf, like this: /user/someActor/someotheActor/*someImportantActor* I have *someImportantActor* known and don't care about it's parents - is it possible to lookup and skip parent levels? Or wildcard only used for partial search in names? On Tuesday, March 18, 2014 4:48:24 PM UTC+2, Patrik Nordwall wrote: The wildcard in /user/*/ChildActor will match 2 actors, both ChildCreationActor and LookingActor. The second path will not match and you get ActorIdentity with ref null. The first path will match your expected ChildActor. You will receive two ActorIdentity but you happen to use only the first. The order of these messages are undefined. Regards, Patrik On Tue, Mar 18, 2014 at 2:18 PM, Anatoliy Kaverin a.ka...@gmail.comwrote: Greetings, I've been using Akka in my Java based backend and faced some issue related to ActorSelection API if it is used from ActorContext (from inside Actor). For some reason I cannot find existing Actors via Identify message for specific paths. Imagine, that I have such Actor hierarchy: USER - Parent Actor - Child Actor USER - WorkerActor And let's assume that I would like to locate Child Actor via actor selection and use wildcard for the purpose. So, I'm building such path: /user/*/ChildActor For some reason - if this path is used for lookup via global Akka system context - ActorIdentity provides me ActorRef But, if I will perform the same lookup but from inside WorkerActor via ActorContext - Identify ActorRef is null. For me it seems like a bug and inconsistent behavior. I've provided code with different scenarios and the correct one. JUnit code with the issue https://gist.github.com/Anatolik/9619710 Another one point - for some reason if I call actorSelection.tell from inside Worker Actor - messages got delivered to the target ChildActor. But, I see some errors in dead letters office: 15:08:21.916 INFO [default-akka.actor.default-dispatcher-3] a.a.EmptyLocalActorRef - Message [java.lang.String] from TestActor[ akka://default/user/$$a] to Actor[akka://default/user/$$a/ForwardingActor] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. Any ideas? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@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.comjavascript: . Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout. *Dr. Roland Kuhn* *Akka Tech Lead* Typesafe http://typesafe.com/ – Reactive apps on the JVM. twitter: @rolandkuhn http://twitter.com/#!/rolandkuhn -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to
Re: [akka-user] ActorSelection and Identify wildcard issue
I see, thanks for replies!!! It looks I didn't really get how wildcard actor selection look up works, but now I got a clear picture. I have loosely coupled Actors, some of them are dynamic and later addressed by already existing ones. So, sending ActorRef is not an option. Original problem I've faced is related to UT. Let's imagine, that I have next 2 Actors in production: */user/WatchActor/DoCoolStuffActor/DynamicGuidActor* and another one: */user/WatchActor/DoAnotherStuffActor* When I cover *DoAnotherStuffActor* with UT - one of the cases is to mock DynamicGuidActor, as by workflow I need to find it via Identify message. The problem as in UT I have one level less: */user/DoAnotherStuffActor* and */user/DoCoolStuffActor/DynamicGuidActor* DoAnotherStuffActor is testd in isolation (no Spring context) and all dependencies wired manually with stubs and mocks. For that I need - TestActorRef for DoAnotherStuffActor. So, I cannot create same hierarchy as in production. Thankfully after you comments it became clear that wildcard cannot help me - I wanted a universal actor selection path to cover both production and UT scenario. Sibling search resolved my needs so far (search via *../DoCoolStuffActor/DynamicGuidActor* path ) On Wednesday, March 19, 2014 11:15:01 AM UTC+2, rkuhn wrote: Hi Anatoliy, in general it is much easier to reason about the system if you explicitly introduce the actors to each other instead of relying on String-based lookups (which tie down your hierarchy as you now learnt). You can do that by passing an ActorRef to the constructor of a new actor or within a message sent to that actor. Regards, Roland 19 mar 2014 kl. 07:37 skrev Anatoliy Kaverin a.ka...@gmail.comjavascript: : I see, but why ForwardingActor is not matched? Another question - imagine that I have some different paths and I only care about finding a leaf, like this: /user/someActor/someotheActor/*someImportantActor* I have *someImportantActor* known and don't care about it's parents - is it possible to lookup and skip parent levels? Or wildcard only used for partial search in names? On Tuesday, March 18, 2014 4:48:24 PM UTC+2, Patrik Nordwall wrote: The wildcard in /user/*/ChildActor will match 2 actors, both ChildCreationActor and LookingActor. The second path will not match and you get ActorIdentity with ref null. The first path will match your expected ChildActor. You will receive two ActorIdentity but you happen to use only the first. The order of these messages are undefined. Regards, Patrik On Tue, Mar 18, 2014 at 2:18 PM, Anatoliy Kaverin a.ka...@gmail.comwrote: Greetings, I've been using Akka in my Java based backend and faced some issue related to ActorSelection API if it is used from ActorContext (from inside Actor). For some reason I cannot find existing Actors via Identify message for specific paths. Imagine, that I have such Actor hierarchy: USER - Parent Actor - Child Actor USER - WorkerActor And let's assume that I would like to locate Child Actor via actor selection and use wildcard for the purpose. So, I'm building such path: /user/*/ChildActor For some reason - if this path is used for lookup via global Akka system context - ActorIdentity provides me ActorRef But, if I will perform the same lookup but from inside WorkerActor via ActorContext - Identify ActorRef is null. For me it seems like a bug and inconsistent behavior. I've provided code with different scenarios and the correct one. JUnit code with the issue https://gist.github.com/Anatolik/9619710 Another one point - for some reason if I call actorSelection.tell from inside Worker Actor - messages got delivered to the target ChildActor. But, I see some errors in dead letters office: 15:08:21.916 INFO [default-akka.actor.default-dispatcher-3] a.a.EmptyLocalActorRef - Message [java.lang.String] from TestActor[ akka://default/user/$$a] to Actor[akka://default/user/$$a/ForwardingActor] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. Any ideas? -- Read the docs: http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups Akka User List group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+...@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:
Re: [akka-user] ActorSelection and Identify wildcard issue
Hi Anatoliy, 19 mar 2014 kl. 12:49 skrev Anatoliy Kaverin a.kave...@gmail.com: I see, thanks for replies!!! It looks I didn't really get how wildcard actor selection look up works, but now I got a clear picture. I have loosely coupled Actors, some of them are dynamic and later addressed by already existing ones. So, sending ActorRef is not an option. Nope, there is always a way: in this case the dynamic actors introduce themselves to the existing ones, preferably because they received the needed ActorRefs in their constructor. Original problem I've faced is related to UT. Unreal Tournament? ;-) (beware of the TLAs) Let's imagine, that I have next 2 Actors in production: /user/WatchActor/DoCoolStuffActor/DynamicGuidActor and another one: /user/WatchActor/DoAnotherStuffActor When I cover DoAnotherStuffActor with UT - one of the cases is to mock DynamicGuidActor, as by workflow I need to find it via Identify message. The problem as in UT I have one level less: /user/DoAnotherStuffActor and /user/DoCoolStuffActor/DynamicGuidActor DoAnotherStuffActor is testd in isolation (no Spring context) and all dependencies wired manually with stubs and mocks. For that I need - TestActorRef for DoAnotherStuffActor. So, I cannot create same hierarchy as in production. Thankfully after you comments it became clear that wildcard cannot help me - I wanted a universal actor selection path to cover both production and UT scenario. Sibling search resolved my needs so far (search via ../DoCoolStuffActor/DynamicGuidActor path ) A better way is to not use lookups at all, precisely because they make the hierarchy inflexible and unit testing hard. Now you might ask: why does Akka support them at all? The reason is remote interaction, where the first contact between two systems needs to be established somehow. If you want to test such an actor, you would need to inject the lookup path and use a local one during the test (e.g. `testActor.path`) Regards, Roland On Wednesday, March 19, 2014 11:15:01 AM UTC+2, rkuhn wrote: Hi Anatoliy, in general it is much easier to reason about the system if you explicitly introduce the actors to each other instead of relying on String-based lookups (which tie down your hierarchy as you now learnt). You can do that by passing an ActorRef to the constructor of a new actor or within a message sent to that actor. Regards, Roland 19 mar 2014 kl. 07:37 skrev Anatoliy Kaverin a.ka...@gmail.com: I see, but why ForwardingActor is not matched? Another question - imagine that I have some different paths and I only care about finding a leaf, like this: /user/someActor/someotheActor/someImportantActor I have someImportantActor known and don't care about it's parents - is it possible to lookup and skip parent levels? Or wildcard only used for partial search in names? On Tuesday, March 18, 2014 4:48:24 PM UTC+2, Patrik Nordwall wrote: The wildcard in /user/*/ChildActor will match 2 actors, both ChildCreationActor and LookingActor. The second path will not match and you get ActorIdentity with ref null. The first path will match your expected ChildActor. You will receive two ActorIdentity but you happen to use only the first. The order of these messages are undefined. Regards, Patrik On Tue, Mar 18, 2014 at 2:18 PM, Anatoliy Kaverin a.ka...@gmail.com wrote: Greetings, I've been using Akka in my Java based backend and faced some issue related to ActorSelection API if it is used from ActorContext (from inside Actor). For some reason I cannot find existing Actors via Identify message for specific paths. Imagine, that I have such Actor hierarchy: USER - Parent Actor - Child Actor USER - WorkerActor And let's assume that I would like to locate Child Actor via actor selection and use wildcard for the purpose. So, I'm building such path: /user/*/ChildActor For some reason - if this path is used for lookup via global Akka system context - ActorIdentity provides me ActorRef But, if I will perform the same lookup but from inside WorkerActor via ActorContext - Identify ActorRef is null. For me it seems like a bug and inconsistent behavior. I've provided code with different scenarios and the correct one. JUnit code with the issue Another one point - for some reason if I call actorSelection.tell from inside Worker Actor - messages got delivered to the target ChildActor. But, I see some errors in dead letters office: 15:08:21.916 INFO [default-akka.actor.default-dispatcher-3] a.a.EmptyLocalActorRef - Message [java.lang.String] from TestActor[akka://default/user/$$a] to Actor[akka://default/user/$$a/ForwardingActor] was not delivered. [1] dead letters encountered. This logging can be turned off or adjusted with configuration settings 'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'. Any ideas? -- Read the docs:
Re: [akka-user] PersistentChannel wired behavior
Patrik, I'll try to provide a test for you :) Thank you for looking into this. On Wednesday, March 19, 2014 9:54:19 PM UTC+8, Patrik Nordwall wrote: Hi Daniel, That looks strange. I tried to reproduce it, but couldn't. Please provide a minimized sample/test that we can run. Regards, Patrik On Wed, Mar 19, 2014 at 8:30 AM, Daniel Wang dan...@coinport.comjavascript: wrote: hi, in my test system I have 2 processors, A, and B. In the logs below reflects this message flow: *Send persistent message DoDepositCash to A* *Send persistent message DoSubmitOrder to A,* *A receives DoSubmitOrder message and yields OrderCashLocked to a channel X and delivers to B* *B receives OrderCashLocked message and yields OrderSubmitted to a channel Y and delivers back to A.* Below are logs printed when the system is initially up: Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,Collections(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,Collections(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,Collections(),DeliveredByPersistentChannel(X,2,1,Actor[akka://mysys/user/X/$a#1241560331]),Actor[akka://mysys/system/deletion-batch-layer#940984408],Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,Collections(),DeliveredByPersistentChannel(Y,1,1,Actor[akka://mysys/user/Y/$a#1653209817]),Actor[akka://mysys/system/deletion-batch-layer#940984408],Actor[akka://mysys/user/market_processor_btc_rmb/singleton#1752194582]) Then I got those during the first replay (no snapshoting): Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,List(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,List(X),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,List(Y),null,null,Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,List(),null,null,Actor[akka.tcp:// mysys@192.168.0.103:50354/user/market_processor_btc_rmb/singleton#1752194582 ]) Processor B-A @seq=2 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),2,mysys_mp_btc_rmb,false,0,Collections(),DeliveredByPersistentChannel(X,2,1,Actor[akka://mysys/user/X/$a#669702344]),Actor[akka://mysys/system/deletion-batch-layer#1382334128],Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=4 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212250415)),0,0,Pending,None),List()),4,mysys_ap,false,0,Collections(),DeliveredByPersistentChannel(Y,2,1,Actor[akka://mysys/user/Y/$a#-117955869]),Actor[akka://mysys/system/deletion-batch-layer#1382334128],Actor[akka://mysys/user/market_processor_btc_rmb/singleton#288803418]) And these during 2nd reply: Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,List(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,List(X),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,List(Y),null,null,Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,List(),null,null,Actor[akka.tcp:// mysys@192.168.0.103:50354/user/market_processor_btc_rmb/singleton#1752194582 ]) Processor B-A @seq=2
Re: [akka-user] PersistentChannel wired behavior
Patrik, I forgot to mention that the actorPath of my channel destination is actually the path of a cluster-aware router who knows where exactly the remote target processor is. Maybe that's the cause? On Wednesday, March 19, 2014 9:54:19 PM UTC+8, Patrik Nordwall wrote: Hi Daniel, That looks strange. I tried to reproduce it, but couldn't. Please provide a minimized sample/test that we can run. Regards, Patrik On Wed, Mar 19, 2014 at 8:30 AM, Daniel Wang dan...@coinport.comjavascript: wrote: hi, in my test system I have 2 processors, A, and B. In the logs below reflects this message flow: *Send persistent message DoDepositCash to A* *Send persistent message DoSubmitOrder to A,* *A receives DoSubmitOrder message and yields OrderCashLocked to a channel X and delivers to B* *B receives OrderCashLocked message and yields OrderSubmitted to a channel Y and delivers back to A.* Below are logs printed when the system is initially up: Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,Collections(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,Collections(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,Collections(),DeliveredByPersistentChannel(X,2,1,Actor[akka://mysys/user/X/$a#1241560331]),Actor[akka://mysys/system/deletion-batch-layer#940984408],Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,Collections(),DeliveredByPersistentChannel(Y,1,1,Actor[akka://mysys/user/Y/$a#1653209817]),Actor[akka://mysys/system/deletion-batch-layer#940984408],Actor[akka://mysys/user/market_processor_btc_rmb/singleton#1752194582]) Then I got those during the first replay (no snapshoting): Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,List(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,List(X),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,List(Y),null,null,Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,List(),null,null,Actor[akka.tcp:// mysys@192.168.0.103:50354/user/market_processor_btc_rmb/singleton#1752194582 ]) Processor B-A @seq=2 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),2,mysys_mp_btc_rmb,false,0,Collections(),DeliveredByPersistentChannel(X,2,1,Actor[akka://mysys/user/X/$a#669702344]),Actor[akka://mysys/system/deletion-batch-layer#1382334128],Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=4 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212250415)),0,0,Pending,None),List()),4,mysys_ap,false,0,Collections(),DeliveredByPersistentChannel(Y,2,1,Actor[akka://mysys/user/Y/$a#-117955869]),Actor[akka://mysys/system/deletion-batch-layer#1382334128],Actor[akka://mysys/user/market_processor_btc_rmb/singleton#288803418]) And these during 2nd reply: Processor A @seq=1 PersistentImpl(DoDepositCash(1878387908787379106,Btc,1),1,mysys_ap,false,List(),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$e]) Processor A @seq=2 PersistentImpl(DoSubmitOrder(MarketSide(Btc,Rmb),Order(1878387908787379106,1395212275401,2000,Some(500.0),None,None)),2,mysys_ap,false,List(X),Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor B-A @seq=1 ConfirmablePersistentImpl(OrderCashLocked(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,None)),1,mysys_mp_btc_rmb,false,0,List(Y),null,null,Actor[akka.tcp:// mysys@192.168.0.107:46804/temp/$j]) Processor A-B @seq=3 ConfirmablePersistentImpl(OrderSubmitted(OrderInfo(MarketSide(Btc,Rmb),Order(1878387908787379106,1,2000,Some(500.0),None,Some(1395212230304)),0,0,Pending,None),List()),3,mysys_ap,false,0,List(),null,null,Actor[akka.tcp:// mysys@192.168.0.103:50354/user/market_processor_btc_rmb/singleton#1752194582 ])
Re: [akka-user] Re: Akka persistentChannel does not delete message from Journal upon confirm
Hi Martin, I have a process that is running since last Sunday evening using the above code base(Given herehttp://stackoverflow.com/questions/22315418/akka-persistentchannel-does-not-delete-message-from-journal-upon-confirm) . The journal space has grown to be around 24 GB so far. I am still continuing my run to see when the compaction will happen and the marked deleted messages will be physically deleted. The only way my code is different than your example is that my message has the size of 8 MB. Could that be playing some role? Thanks Manas On Wednesday, March 12, 2014 1:09:38 PM UTC-4, Manas Kar wrote: Thanks Martin. That explains what I am seeing. On Wednesday, March 12, 2014 12:15:15 PM UTC-4, Martin Krasser wrote: On 11.03.14 19:22, Manas Kar wrote: Hi Martin, I observed something that kind of contradicts my previous statement. It would be correct to say that the size of journal folder is approximately half the size of SumOf(messages). My messages don't get replayed after the configurable times from the channels. But the journal's are not physically deleted amounting to large disk usage. Please find my modified scala code that follows the example you provided and still leaves residues in journal folder. LevelDB doesn't delete entries immediately, it rather marks them as deleted and physically deletes them during compactions. Details at http://leveldb.googlecode.com/svn/trunk/doc/impl.html. Thanks ...Manas On Tuesday, March 11, 2014 2:19:51 AM UTC-4, Manas Kar wrote: Hi, I am very excited about the latest and the biggest feature of Akka2.3.0 that is Persistence. I have posted a question about Akka persistentChannel here.http://stackoverflow.com/questions/22315418/akka-persistentchannel-does-not-delete-message-from-journal-upon-confirm Basically I have a persistentChannel that sends some IOWork to a destination actor. Destination actor tries to do the work and when successfully completes the work or the deadline has no time left it sends a confirm on the ConfirmablePersistent message. My expectation after reading the documentation was that my message will be deleted from the journal after I confirm the message but it does not. Am I doing something wrong here? my requirement is simple persist the message and delete it after the corresponding IO work is done for the message. Please help. ...Manas -- 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. -- Martin Krasser blog:http://krasserm.blogspot.com code:http://github.com/krasserm twitter: http://twitter.com/mrt1nz -- 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] Is the default leveldb production ready?
Thanks Patrik for the reply. For some reason I thought it used the java version. Good to know though its only intended for testing. Eric On Wednesday, March 19, 2014 1:47:15 AM UTC-7, Patrik Nordwall wrote: On Wed, Mar 19, 2014 at 5:00 AM, Eric Weise ewe...@gmail.comjavascript: wrote: I noticed that there is a java version of Leveldb included as the default persistence support for Akka. Is this recommended for production? Default is to use the native driver. You can configure it to use the pure java driver, but that is only intended for tests, not production. Regards, Patrik Anyone have experience using it in production? Thanks Eric Weise -- 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.comjavascript: . 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.
[akka-user] akka ants without STM
Hey everyone! I've been reading through the akka docs, looking at some of the example projects, and am interested in how it might help me run a large scale wildlife simulation. Without elaborating too much, I'd like to simulate a massive world that potentially is scalable across machines, with all sorts of animals moving around, eating each other etc. There are a couple old Akka sample projects that show a simple simulation of Ants, all represented as actors. I was looking at them, but they're heavily tied to the now removed STM framework. I'm trying to jump in and right a new version of Ants using the latest Akka code, but am not sure how best to migrate away from all the deprecated STM code. The original projects are https://github.com/pvlugter/ants and https://github.com/azzoti/ScalaAkkaAnts Any guidance would be appreciated :) Thanks, -Kal -- 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] Multi-jvm test property settings when using sbt test
Hi,
I'm using the settings below for a multi-jvm test. After upgrading to
Akka-2.3.0,
I got an error stating that I needed to define the *multinode.max-nodes *
system property.
I added that below and now it works when I run sbt multi-jvm:test, but I
can't figure out how to add the setting
so that it is used with sbt test as well. Any tips?
lazy val multiJvmSettings = SbtMultiJvm.multiJvmSettings ++ Seq(
// make sure that MultiJvm test are compiled by the default test
compilation
compile in MultiJvm = (compile in MultiJvm) triggeredBy (compile in
Test),
// Required system property
jvmOptions in MultiJvm += -Dmultinode.max-nodes=2,
// Next line fixes missing source folder in idea project
unmanagedSourceDirectories in Test += baseDirectory { _ / src /
multi-jvm / scala },
parallelExecution in Global := false,
executeTests in Test =
(executeTests in Test, executeTests in MultiJvm) map {
case ((testResults), (multiJvmResults)) =
val overall =
if (testResults.overall.id multiJvmResults.overall.id)
multiJvmResults.overall
else testResults.overall
Tests.Output(overall,
testResults.events ++ multiJvmResults.events,
testResults.summaries ++ multiJvmResults.summaries)
}
)
Thanks,
Allan
--
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: Multi-jvm test property settings when using sbt test
Correction: The *multinode.max-nodes *property does not need to be set if
sbt multi-jvm:test is run, but if I run sbt test, I get:
java.lang.IllegalStateException: need system property
multinode.max-nodes to be set
On Wednesday, March 19, 2014 10:29:13 PM UTC+1, Allan Brighton wrote:
Hi,
I'm using the settings below for a multi-jvm test. After upgrading to
Akka-2.3.0,
I got an error stating that I needed to define the *multinode.max-nodes *
system property.
I added that below and now it works when I run sbt multi-jvm:test, but I
can't figure out how to add the setting
so that it is used with sbt test as well. Any tips?
lazy val multiJvmSettings = SbtMultiJvm.multiJvmSettings ++ Seq(
// make sure that MultiJvm test are compiled by the default test
compilation
compile in MultiJvm = (compile in MultiJvm) triggeredBy (compile in
Test),
// Required system property
jvmOptions in MultiJvm += -Dmultinode.max-nodes=2,
// Next line fixes missing source folder in idea project
unmanagedSourceDirectories in Test += baseDirectory { _ / src /
multi-jvm / scala },
parallelExecution in Global := false,
executeTests in Test =
(executeTests in Test, executeTests in MultiJvm) map {
case ((testResults), (multiJvmResults)) =
val overall =
if (testResults.overall.id multiJvmResults.overall.id)
multiJvmResults.overall
else testResults.overall
Tests.Output(overall,
testResults.events ++ multiJvmResults.events,
testResults.summaries ++ multiJvmResults.summaries)
}
)
Thanks,
Allan
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
[akka-user] Cluster/remote pipeline strategy
Hi all. We have a system where we've implemented a pipeline strategy as follows: 1) If the number of messages pending for all actors to a remote host is more than N we flush the message queue to the net 2) If the total number of blocked threads waiting for reading is more then N we flush the message queue to the net 3) We flush the queue also after X milliseconds if we have some message in the queue The idea is move our current architecture to Akka. Taking into consideration that the Akka cluster technology abstracts almost everything related to where the actors are and how many pending messages exist to a particular physical host, etc. my question is: Is the internal Akka net pipeline more or less equivalent to our one or, in case of not, could I plug in something similar our current pipeline into Akka? We've found that the three criteria aforementioned enabled us to adjust our current technology to a wide range of customer requirements. I couldn't find the right way to go on after reading the docs Dispatchers, Routers, and mailboxes, (and also I'm a novice Akka user). Many thanks for your help and suggestions. Best regards, Eduardo. -- 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] Replay Intro to Akka persistence with Patrik Nordwall
I missed the live, is this going to be available on Yotube? -- 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.
