Hi Prakhyat,
This has been explained a few times recently, for example here:
https://groups.google.com/forum/#!topic/akka-user/FBUn7g3b564 or here:
https://groups.google.com/forum/#!topic/akka-user/3JYHqg2nO6Y
We're working on it and it should be available soon – see the other
discussions for
13 okt 2014 kl. 11:51 skrev sifi mohamed amine mohamedaminesif...@gmail.com:
Hello ,
Trying to to lauch the example in this tutorial :
http://alvinalexander.com/scala/scala-akka-actors-ping-pong-simple-example
and more importantly configuring it work for Ipv6 , I got this exception .
Hi Konrad,
I am aware of these posts.
Since we are in stage of planning for rest player. I was looking feedbacks
on which is the the best way to create REST layer when working with apps
having akka persistence.
I had three options play,akka http and spring. To decide which one to use,
i was
Thanks for the answers.
For now I went with taking most significant bits of java UUID and computing
modulus value of it. I created the test to see how this scheme behaves in
terms of distribution and for now it is good enough for me.
I have one more question. Assuming I will do something like
14 okt 2014 kl. 12:51 skrev Andrzej Dębski andrzejdebsk...@gmail.com:
Thanks for the answers.
For now I went with taking most significant bits of java UUID and computing
modulus value of it. I created the test to see how this scheme behaves in
terms of distribution and for now it
Thanks, it looks like it works as I expected.
--
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
Spray / akka-http and Play address two different use cases.
Spray/akka-http is an HTTP framework; as such it's great for building pure
REST services if all of your semantics can be cleanly expressed in terms of
plain HTTP. I wrote an HTTP proxy using spray and it was perfect for the
job.
Whereas
I think he's considering Play even for pure REST, because he can use it
from Java, and Akka-HTTP is not ready.
On Tue, Oct 14, 2014 at 7:40 AM, Daniel Armak danar...@gmail.com wrote:
Spray / akka-http and Play address two different use cases.
Spray/akka-http is an HTTP framework; as such it's
Hi Muthu,
I'm not sure if I got your question properly, but Roles are set on an actor
system basis (one actod system can have multiple roles, yes).
Actors do not have roles, it's the actor system's property.
Maybe if you'd dig in more into an example use-case I could help more.
Hope this helps
Right, I forgot spray doesn't have a Java API. Sorry about not making that
clearer.
Daniel Armak
On Tue, Oct 14, 2014 at 5:46 PM, Richard Rodseth rrods...@gmail.com wrote:
I think he's considering Play even for pure REST, because he can use it
from Java, and Akka-HTTP is not ready.
On Tue,
I have Spring MVC controller class in my application which creates top
level Akka actor (via Spring). When this actor throws an exception I expect
it to be handled by the controller, but in my case the actor simply times
out after 5 sec. I tried to implement my
own
Hi,
I have created Distributed Akka Workers/Master cluster in java and exactly
followed this typesafe
template. https://github.com/typesafehub/activator-akka-distributed-workers
I have the following configurations:
One master and one backup master - each running on a separate node - node1
Hi,
I'm trying to use akka-stream and struggling to understand how conflate
works. Here a snippet of code I'm using:
object ConflateDemo extends App {
import scala.concurrent.duration._
implicit val system = ActorSystem(demo)
implicit val fm = FlowMaterializer()
case object Tick
Hi,
I'm using mukis.de
http://mukis.de/pages/akka-cluster-with-docker-containers/ example of
Akka cluster application using docker. Here are the steps:
1. Created and published the docker image to docker hub.
2. Created two EC2 instances inside a VPC, running docker using these
This is not how things work in Akka-land :) Exceptions thrown in an Actors
receive method are reported to it's supervisor actor which may choose to
escalate it (among other choices), but that means that the supervisor
itself terminates abnormally throwing an exception that is passed in turn
to
The problem arises because the IP where actor system binds itself and the
IP where the messages actually arrives from the other node differ.
Here's a merged but yet unreleased change that will provide easy workaround
for this problem: https://github.com/akka/akka/pull/15610
Another workaround
Hi, all
When
reading
http://doc.akka.io/docs/akka/snapshot/general/message-delivery-reliability.html,
I was told that completely fair locks do not exist on the JVM,
With my understanding, we can implement a fair lock with new
ReentrantLock(true), what does the document mean by completely
17 matches
Mail list logo
