28 jun 2014 kl. 22:05 skrev Michael Frank syntaxjoc...@gmail.com:
from a quick skim of the scaladoc, it looks like akka-stream is still based
off of reactive streams 0.3, not 0.4.0.M1, correct?
Yes
is there any plan to update akka-stream to use the 0.4.0.M1 API in the near
future?
Bindning to hostname 0.0.0.0 is not supported.
/Patrik
28 jun 2014 kl. 16:19 skrev Eugene Dzhurinsky jdeve...@gmail.com:
0.0.0.0:3323
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
`Future[Option[T]] pipeTo self` sounds like a bad idea because there is no
context to the message for the actor (it just gets a None, it doesn't even
know what Option[T] it was since the T is erased.)
What's the use-case?
On Sun, Jun 29, 2014 at 3:34 AM, Richard Rodseth rrods...@gmail.com
Hi Viktor
The use case is an actor that processes commands, creating jobs. But
first it has to look up something in the database to send to the job along
with the other job parameters. The Option comes from the fact that the
thing being looked up may not exist.
As I mentioned, I first mapped the
Hi Richard,
since you are using Futures you'll have to deal with the case where the
Future fails anyway, so why not represent the failed lookup as a
NoSuchElementException? It's either that or expose the absence of value in
the algebra (which I'd prefer).
On Sun, Jun 29, 2014 at 3:40 PM,
That's a good point - I could map to an exception like that. I assume you
mean the algebra of the reply message from the look up actor:
trait UserInfo
case class AvailableUserInfo(firstName:String, lastName:String)
case object MissingUserInfo
That's an interesting idea too. Thanks.
On Sun, Jun
On Sun, Jun 29, 2014 at 4:18 PM, Richard Rodseth rrods...@gmail.com wrote:
That's a good point - I could map to an exception like that. I assume you
mean the algebra of the reply message from the look up actor:
trait UserInfo
case class AvailableUserInfo(firstName:String, lastName:String)
Great, happy hAkking
On Sun, Jun 29, 2014 at 4:35 PM, Eugene Dzhurinsky jdeve...@gmail.com
wrote:
On Sun, Jun 29, 2014 at 09:42:59AM +0200, Patrik Nordwall wrote:
Bindning to hostname 0.0.0.0 is not supported.
It looks like if several hosts will bind to the cluster and fail because of
On Sun, Jun 29, 2014 at 04:35:18PM +0200, √iktor Ҡlang wrote:
Great, happy hAkking
Thanks :)
It seems that everything works well, still need to do some testing - but
probably it's worth mentioning that the Akka Cluster could be launched on a
cluster of couple Raspberry Pi with latest Oracle
That's great—tiny machines working together with big ones.
On Sun, Jun 29, 2014 at 4:43 PM, Eugene Dzhurinsky jdeve...@gmail.com
wrote:
On Sun, Jun 29, 2014 at 04:35:18PM +0200, √iktor Ҡlang wrote:
Great, happy hAkking
Thanks :)
It seems that everything works well, still need to do some
I'm not sure I understand your problem. You should used something like this:
Node 1:
akka.remote.netty.tcp.hostname = 127.0.0.1
akka.remote.netty.tcp.port = 2551
akka.cluster.seed-nodes = [akka.tcp://ClusterSystem@127.0.0.1:2551
, akka.tcp://ClusterSystem@127.0.0.1:2552]
Node 2:
On Sun, Jun 29, 2014 at 2:16 AM, Richard Rodseth rrods...@gmail.com wrote:
I see here that I can do context.child(name)
+1
http://grokbase.com/t/gg/akka-user/138x5t8xbz/referencing-actor-from-map-string-actorref-vs-referencing-from-path
On Sat, Jun 28, 2014 at 4:08 PM, Richard Rodseth
I see the problem now - I was thinking too single-threaded-ly.
Even if I use Await(actorRefFuture) after your code, this will succeed
before the onComplete (callback/thread) has a chance to do anything. I've
put in a Thread.sleep(3) before doing the Await, now I get consistent
success.
13 matches
Mail list logo
