Re: [akka-user] AKKA cluster remoting taking time
Hi there,
firstly - remoting does not like such large messages, it's effectively
cloging the pipe.
You should rather try to send more smaller messages to keep the system
responsive - sending a large message will take more time to serially
serialize it etc.
Concerning the speed... You're using the default java serialization - it's
slow.
If you care about performance - as it looks you do - you should serialize
the messages using Kryo, ProtoBuf or CapNproto etc.
See here http://doc.akka.io/docs/akka/snapshot/scala/serialization.html
On Thu, Nov 20, 2014 at 8:39 AM, neeraj negi negi.neerajn...@gmail.com
wrote:
Hi,
I have two node system one running on 2551 port and other running on 2552
port on single machine right now.
I am sending object containing 1 records from 2551 to 2552 and the
payload size is less then 1 Mb and it's taking around 60 to 70 millisecond
for transfer from one node to another
and if I increase the records i.e. 7 and payload becomes around 6 Mb
then it start taking 300 to 400 ms for transfer from one node to another
my application conf is:-
akka {
event-handlers = [akka.event.slf4j.Slf4jEventHandler]
loggers = [akka.event.slf4j.Slf4jLogger]
loglevel = debug
actor {
provider = akka.cluster.ClusterActorRefProvider
}
remote {
log-remote-lifecycle-events = off
netty.tcp {
hostname = 127.0.0.1
port = 0
maximum-frame-size = 52428800
send-buffer-size = 52428800
receive-buffer-size = 52428800
}
}
cluster {
seed-nodes = [
akka.tcp://ClusterSystem@127.0.0.1:2551,
akka.tcp://ClusterSystem@127.0.0.1:2552]
auto-down-unreachable-after = 300s
}
}
How can i increase my transfer speed?
am i missing something in Application.conf?
--
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 Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
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 KRYO causing cluster node unregister
Are both nodes configured to use kryo? What's the error you're getting? Try `default` id generation strategy, like mentioned in another thread this week. --konrad On Thu, Nov 20, 2014 at 7:06 PM, neeraj negi negi.neerajn...@gmail.com wrote: Hi, I have two node system which was working fine till i have added the kryo. Attached file is the application.conf that i am using. KRYO causing the other node unregistered. do i need to change something in the configuration -- 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 Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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] Confusion about durable mailboxes superseded by akka-persistence?
Just use persist() to persist messages. Snapshotting should not be used for every message - it should be used once in a while. — konrad On Fri, Nov 21, 2014 at 7:40 AM, Karthik Chandraraj ckarthi...@gmail.com wrote: Hi, As per the suggestion, I implemented a QueueActor, which will saveSnapshot for every message it receives or removed. And then a ProcessActor, which will read the message from the QueueActor to process it. Is this the right way to implement durable mailbox with akka-persistence? Problem I see with this approach is, for every message, the data is written to the file. Can we achieve durability only with this performance hit? Thanks, C.Karthik On Thursday, November 13, 2014 7:58:01 PM UTC+5:30, Martynas Mickevičius wrote: Hi Karthik, akka-persistence does not replace but supersede durable mailboxes. That means if one wants to have an Actor that does not loose messages upon being killed then sender must use AtLeastOnce delivery trait (or some other means of durability with akka-persistence or not) to deliver messages to that Actor. Let me know if that helped. On Wed, Nov 12, 2014 at 2:03 PM, Karthik Chandraraj ckart...@gmail.com wrote: Consider there are 100 messages in the mailbox and the actor is processing the first. If the process is killed, what happens to the 99 messages? When I was searching about this, I came across durable mailboxes, but the doc says 'durable mailboxes superseded by akka-persistence'. When I went though akka persistence, it said the actor state can be persisted, it doesn't talk about mailboxes? using akka-persistence, actors state can be stored, but what about messages that are in the mailbox and not received? can someone please explain? -- 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. -- 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 Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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] Design question on with akka persistence
Yeah this is one way to do this - to use the view as the read side. On the other hand, you could use the view to put it into some query optimised database or journal - this is also a good way to use akka-persistence, but for your case it seems persistent view may just be enough. PS: Just making sure that you're aware of our upcoming read side rewrite: letitcrash.com/post/96687159512/akka-persistence-on-the-query-side-the-conclusion -- konrad On Fri, Nov 21, 2014 at 9:08 AM, vin...@indix.com wrote: I am trying to build a system to manage configuration values with akka-persistence. I would like to view all changes that has happened to a particular value in the configuration. I have the entire configuration as state in a PersistentActor and when someone queries for changes. I create a new PersistentView with what configuration key i need in the props and replay history on it to filter out the changes not needed and then query the filter changes and kill it with PoisonPill. All these happens in the query part of PersistentActor. Is this rightway to do it? Is there any simpler way to create a view out of the history in akka-persistence -- 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 Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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 allocates new socket for each unsuccessful connection attempt to a quarantined system.
Thanks for reporting! We'll look into it. refs https://github.com/akka/akka/issues/16346 -- konrad On Thu, Nov 20, 2014 at 1:08 PM, Sergii Vozniuk ser...@vozniuk.com wrote: Here https://github.com/svozniuk/akka-sockets-issue Четвер, 20 листопада 2014 р. 13:04:52 UTC+1 користувач Sergii Vozniuk написав: Sorry I don't know why google thinks there is a virus, or why it didn't allow the zip. I'll try to share it in some other way. Четвер, 20 листопада 2014 р. 12:48:31 UTC+1 користувач Konrad Malawski написав: I'm also unable to download the reproducer (415 error from google drive). Would you be able to share it some other way (git repo?) -- Konrad -- 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 Team Typesafe - The software stack for applications that scale Blog: letitcrash.com Twitter: @akkateam -- 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: Using in-memory journal for persistent actors in production
AtLeastOnceDelivery requires the host actor to be a persistent actor. Regards, Patrik On Sun, Nov 9, 2014 at 6:41 PM, Burak Emre Kabakcı emrekaba...@gmail.com wrote: The documentation assumes that we need PersistentActor so I didn't know such option is available. However what I want to do is similar to what you suggest. Instead of fire-and-forget, do not release the memory region of that message until being sure that it's delivered and send the message recursively with timeout interval. On Sunday, November 9, 2014 2:57:04 PM UTC+2, 何品 wrote: The issue seems that you want using the AtLeastOnceDelivery Only,but not the PersistentActor right? I think it should be handy that only minxin the AtLeastOnceDelivery to the normal actor,I haven't try that. 在 2014年11月9日星期日UTC+8下午7时59分41秒，Burak Emre Kabakcı写道： I use persistent actors in order to accomplish at-least-once message guarantee and it seems Akka uses Leveldb for persisting events to disks. However I'm not actually satisfied with default journal implementation because while it has the obvious performance drawbacks, I couldn't really understand what the real benefit is. I have a web server in front of Akka and the persistent actor lives in the same JVM with web server. Therefore if the JVM crashes, users will be aware that the server couldn't process the event so JVM failures is not a big deal for me. I see that people are suggesting in-memory journals for unit testing so I assume that using it in production is considered as a bad practice. I know that Apache Storm also has at-least-once message guarantee and it doesn't persist each event on disk but many companies uses Storm in production without worrying too much about this issue. Can anyone explain why Akka persist messages on disk and what are the other drawbacks of using in-memory journal? -- 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] Shared cluster shard allocation strategy
Hi Moritz, On Wed, Nov 19, 2014 at 3:27 PM, Moritz Schallaböck moritz.schallabo...@agido.com wrote: Hello fellow hAkkers, we have multiple persistent actor types distributed using cluster sharding. Some of them logically belong together, lets say they're customers and their orders. Customers never talk to orders of other customers, and vice versa. Thus it makes sense to us to have these actors reside on the same cluster shard (and consequently, in the same VM). We implemented this by returning identical ShardIds for the customer c123 and its orders c123-o0, c123-o1, etc. But of course, this doesn't work like we thought it would. :) The ShardResolvers of two instances of ShardRegion operate independently, and we just end up with two shards -- one for customers and one for orders -- which share a name but not necessarily a cluster host. I have seen this misunderstanding crop up a few times before on this list, which makes it slightly less embarrasing to admit the mistake. ;) We could stop using cluster sharding for the orders completely, and instead route all messages for the orders through the customers, which would restart the actors on demand. But that sounds like a lot of extraneous code: many other actors talk to the orders[0], and the customers shouldn't need to route these messages or worry about them, the customer actors need not even be alive for them. And we'd also have to worry about the other things that cluster sharding does: support for passivation of orders, gracefully handling rebalances of customers (killing all order actors when it happens, I guess), maybe other things. [0] I realize that this will lead to the question: if many other actors talk to the orders without involving the customers, why do you want them on the same host? Lets just assume for the sake of argument that circumstances make this a reasonable requirement, unless you're saying it's not a reasonable requirement under any circumstances. The alternative would involve writing a custom ShardAllocationStrategy that's shared among the customer and order ShardRegions. I suppose it would involve the following: - maintain the associations between ShardRegion actorRef and ShardIds for each entity type; 1. for a new requested allocation for entity type X: 2. check if the same shardId is already allocated for any other entity type Y, yielding (at least one) associated shardRegionActorRefY 3. if so, determine if there is any shardRegionActorX for entity type X that's on the same host as shardRegionActorRefY 4. if so, allocate the shardId to shardRegionActorX (ie. return it; optionally balance between several candidates) 5. otherwise, fallback to any other ShardAllocationStrategy (updating the associations based on its return value) Eugh. I feel dirty now. Apart from the general horrificness, I imagine step 3 is fraught with peril. And of course, the whole thing would need to be thread-safe because it will be accessed and modified concurrently by several ShardRegions. (Time to dust off ye olde ConcurrentHashMap.) The more I look at it, the more fragile and less feasible it seems. Yes, there are a lot of pitfalls in that approach One more that you perhaps didn't think of is that the shardRegionActorX for entity type X might have been allocated and then later shardRegionActorY for entity type Y is to be allocated by a coordinator running in a different JVM (because of a crash). Then the shared ShardAllocationStrategy has no information about the previous shardRegionActorX. The design of cluster sharding is based on that each entity type can be managed independent of other entity types. If Customer and Order have a tight coupling I think they should be modelled as one aggregate type. At the same time, having this sort of control over the clustering of several entity types does not seem particularly outrageous. Are we missing something? You could do a best effort co-location of associated customer and order shards by using consistent hashing in the ShardAllocationStrategy. I can explain more if you find that interesting. Cheers, Patrik Thanks as always for your thoughts, Moritz -- 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:
Re: [akka-user] Re: how to implement the state migration with consistent hashing routing
Hi Nan, On Fri, Nov 21, 2014 at 1:53 PM, Nan Zhu zhunanmcg...@gmail.com wrote: the only way is to replicate what cluster -sharding does? use a singleton instance to maintain everything? (but that is contrast with the discipline of DHT which is essentially a de-centralized design?) Best, Nan On Friday, November 21, 2014 7:10:42 AM UTC-5, Nan Zhu wrote: Hi, all I have a question about consistent hashing routing in akka in my system, all actors are stateful, specifically: all the actor maintains one or more lists as their state, the message is indexed by a key. The router then forward the message according to the key to one of the actors which in turn save the message to the corresponding list (i.e. the list is bind with a key)... when a new node is added to the cluster, the router will update the hash function, and the future messages with the keys falling in the certain range will be forwarded to this new node *The problem, I also need to query the saved message...according to my understanding on the Akka implementation, the messages saved in the old routee will not be automatically migrated to the new joined one, so my query will only get partial result* is that true? if yes, how to implement this function? it seems that cluster-sharding can do this naturally, but just curious about if we can do with consistent hashing schema Wouldn't cluster sharding be used instead of a consistent hashing router? I'm not sure I understand your question. Regards, Patrik Thanks Nan -- 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.
[akka-user] DynamoDB Streams for maintaining CQRS read models?
I was pretty fascinated to read about the introduction of Amazon's DynamoDB Streams http://aws.amazon.com/blogs/aws/dynamodb-streams-preview/. Given there are DynamoDB based community journal/snapshot store plugins for akka-persistence, I was wondering whether anyone else was thinking that the new Streams feature could offer a way to construct CQRS style read models from events being journaled to DynamoDB? We obviously have PersistentView to play with, although it's still very much work in progress with regard to having a CQRS/DDD compatible implementation of it. I've seen mention on the mailing list (from Martin K) of maintaining read models via a Cassandra - Spark - Read Model workflow. Am I right in thinking that the use of DynamoDB - DynamoDB Stream - Read Model is essentially analogous to this? I think this could be interesting to people who, for example, aren't able to practically or financially afford to run and maintain a Cassandra cluster. Would be interested in others' opinions on this. -- 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: how to implement the state migration with consistent hashing routing
yes, I have refactored system as using cluster sharding now, just curious about if we can implement state migration with consistent hashing Best, -- Nan Zhu http://codingcat.me On Saturday, November 22, 2014 at 11:19 AM, Patrik Nordwall wrote: Hi Nan, On Fri, Nov 21, 2014 at 1:53 PM, Nan Zhu zhunanmcg...@gmail.com (mailto:zhunanmcg...@gmail.com) wrote: the only way is to replicate what cluster -sharding does? use a singleton instance to maintain everything? (but that is contrast with the discipline of DHT which is essentially a de-centralized design?) Best, Nan On Friday, November 21, 2014 7:10:42 AM UTC-5, Nan Zhu wrote: Hi, all I have a question about consistent hashing routing in akka in my system, all actors are stateful, specifically: all the actor maintains one or more lists as their state, the message is indexed by a key. The router then forward the message according to the key to one of the actors which in turn save the message to the corresponding list (i.e. the list is bind with a key)... when a new node is added to the cluster, the router will update the hash function, and the future messages with the keys falling in the certain range will be forwarded to this new node The problem, I also need to query the saved message...according to my understanding on the Akka implementation, the messages saved in the old routee will not be automatically migrated to the new joined one, so my query will only get partial result is that true? if yes, how to implement this function? it seems that cluster-sharding can do this naturally, but just curious about if we can do with consistent hashing schema Wouldn't cluster sharding be used instead of a consistent hashing router? I'm not sure I understand your question. Regards, Patrik Thanks Nan -- 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 (mailto:akka-user+unsubscr...@googlegroups.com). To post to this group, send email to akka-user@googlegroups.com (mailto: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 a topic in the Google Groups Akka User List group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/akka-user/a7mw5bCUh8E/unsubscribe. To unsubscribe from this group and all its topics, send an email to akka-user+unsubscr...@googlegroups.com (mailto:akka-user+unsubscr...@googlegroups.com). To post to this group, send email to akka-user@googlegroups.com (mailto: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] dependency between tests when using ImplicitSender and forget to consume a response with any of the expect-methods
We actually often find this rather useful - for example, if there comes a response from the previous test case which I did not expect, it could fail the 2nd test as an unexpected message may come in. This helps to make sure there’s no spurious and additional messages sent around. So yes, when using ImplicitSender, the assumption is that you want to make sure you expect all messages. If however you want to have the tests separated completely - don’t use implicit sender and use test probes instead: http://doc.akka.io/docs/akka/snapshot/scala/testing.html#using-multiple-probe-actors Both styles make complete sense and come down to your personal testing style - we use both styles to test Akka itself actually. — ktoso On 21 November 2014 at 22:41:24, Florian Witteler (florian.witte...@googlemail.com) wrote: Hi! I was bitten by some special behaviour when testing my actorSystem with the help of the ImplicitSender trait. I have two testmethods. In each of them, I send a message to an actor wrapped in a TestActorRef. In the first testcase, I don't consume the answer of the actor with one of TestKit's expect-Methods, because I check its state directly (testActorRef.underlyingActor) This causes the 2nd testcase to fail, because the first message was still in the receiving mailbox. Here is an example. https://gist.github.com/FloWi/55572324f2d3adb3d51b Do you have any suggestion on how to make the tests independent of each other? Or am I just using the ImplicitSender in a wrong way? (every answer must be consumed) Any insights are appreciated! Regards, Florian -- 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. -- 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] dependency between tests when using ImplicitSender and forget to consume a response with any of the expect-methods
Makes sense to mix both styles. Thanks for the insight from inside the akka-team ;-) Keep up the good work! Am Sonntag, 23. November 2014 00:51:52 UTC+1 schrieb Konrad Malawski: We actually often find this rather useful - for example, if there comes a response from the previous test case which I did not expect, it could fail the 2nd test as an unexpected message may come in. This helps to make sure there’s no spurious and additional messages sent around. So yes, when using ImplicitSender, the assumption is that you want to make sure you expect all messages. If however you want to have the tests separated completely - don’t use implicit sender and use test probes instead: http://doc.akka.io/docs/akka/snapshot/scala/testing.html#using-multiple-probe-actors Both styles make complete sense and come down to your personal testing style - we use both styles to test Akka itself actually. — ktoso On 21 November 2014 at 22:41:24, Florian Witteler ( florian@googlemail.com javascript:) wrote: Hi! I was bitten by some special behaviour when testing my actorSystem with the help of the ImplicitSender trait. I have two testmethods. In each of them, I send a message to an actor wrapped in a TestActorRef. In the first testcase, I don't consume the answer of the actor with one of TestKit's expect-Methods, because I check its state directly (testActorRef.underlyingActor) This causes the 2nd testcase to fail, because the first message was still in the receiving mailbox. Here is an example. https://gist.github.com/FloWi/55572324f2d3adb3d51b Do you have any suggestion on how to make the tests independent of each other? Or am I just using the ImplicitSender in a wrong way? (every answer *must* be consumed) Any insights are appreciated! Regards, Florian -- 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. -- 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] dependency between tests when using ImplicitSender and forget to consume a response with any of the expect-methods
Thanks; you too! Happy hakking! — konrad On 23 November 2014 at 00:51:45, Konrad 'ktoso' Malawski (konrad.malaw...@typesafe.com) wrote: We actually often find this rather useful - for example, if there comes a response from the previous test case which I did not expect, it could fail the 2nd test as an unexpected message may come in. This helps to make sure there’s no spurious and additional messages sent around. So yes, when using ImplicitSender, the assumption is that you want to make sure you expect all messages. If however you want to have the tests separated completely - don’t use implicit sender and use test probes instead: http://doc.akka.io/docs/akka/snapshot/scala/testing.html#using-multiple-probe-actors Both styles make complete sense and come down to your personal testing style - we use both styles to test Akka itself actually. — ktoso On 21 November 2014 at 22:41:24, Florian Witteler (florian.witte...@googlemail.com) wrote: Hi! I was bitten by some special behaviour when testing my actorSystem with the help of the ImplicitSender trait. I have two testmethods. In each of them, I send a message to an actor wrapped in a TestActorRef. In the first testcase, I don't consume the answer of the actor with one of TestKit's expect-Methods, because I check its state directly (testActorRef.underlyingActor) This causes the 2nd testcase to fail, because the first message was still in the receiving mailbox. Here is an example. https://gist.github.com/FloWi/55572324f2d3adb3d51b Do you have any suggestion on how to make the tests independent of each other? Or am I just using the ImplicitSender in a wrong way? (every answer must be consumed) Any insights are appreciated! Regards, Florian -- 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. -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io -- 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.
