Hi,
If anyone has any ideas/suggestions regarding the above issue, that would > be great. I can share my test code if it will help. > Unfortunately in these kind of integration tests sometimes long timeouts are needed. It is btw good to be aware of these since these timing issues are relevant in production, too. One option though is to tweak timing parameters of clustering, for example you can set up a shorter gossip period for tests. > a) If I use runOn(node1), the enclosed code is executed in the > corresponding node and its jvm - ok. If in my base spec, there is no other > code specified for node1, does this mean that the node will be shut down > even if other code is still being executed on other nodes? > It is sufficient to put a barrier after the block if you want to ensure that the node exists only after other nodes reached that barrier. > As a more specific example, if I have one node acting as my cluster client > and other nodes as part of my cluster, do I have to do anything extra to > keep them up in the background since I will be using runOn(client) only? > Adding a barrier will definitely work. > b) Is there any way to make all my test cases dependent on my singleton > being started? If I need to implement this myself, how do I go about it? I > guess I can listen to the cluster for some event that signifies that the > singleton is up, but I still don’t know enough. For example, does the > singleton start itself automatically or is it initiated in a lazy manner? > The singleton will start up on the oldest member as soon as the oldest member has been found. > Which event should I listen for? > Looking at the code I couldn't find any explicit events published, what we usually do in tests is sending pings periodically to the singleton until it replies. If more fancy events are needed you might want to use a cluster PubSub topic to publish Singleton events (this might add some delay of course, and now you have an extra subsystem added). > c) Is it possible to use enter barriers to control both of the above? Yet, > I could not find any documentation at all regarding enter barriers. How do > they work? Is there any difference between placing them inside or outside a > runOn block? > enterBarrier(*barrierName*) calls mean that all nodes reaching that point will: - send a message to the test coordinator that they have reached *barrierName* - they wait until all other nodes have been reported that they have reached *barrierName*, too In other words every code on every node defined before a barrier *barrierName *globally happens before every code on every node after the barrier *barrierName*. -Endre > Thanks a lot, > > Sinan > > > -- > >>>>>>>>>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
