Re: [akka-user] Does akka support fiber/coroutine? (do not modify source code)
Hi Chansey, What would you look to gain by switching to coroutines? On Fri, Feb 6, 2015 at 7:44 PM, chanse...@gmail.com wrote: Hello, Does akka support fiber/coroutine? I found that all akka's dispatchers rely on JVM threads now. Is there any way to config dispatchers which could run actor on fiber/coroutine? (do not modify the akka source code) Like StubFiber in retLang which use ExecuteAllPendingUntilEmpty to run dispatcher schedule instead of actual JVM thread. PS: I maybe could make akka support it, but need modify some akka code... I am using akka.NET now. Very thanks. Br, Chansey -- 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. -- Cheers, √ -- 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] Does akka support fiber/coroutine? (do not modify source code)
Hi Because my application is running on one thread now. (It maybe extend to multi-thread in the future) To be frank, I get benefit from akka by using actor model programming paradigm instead of its concurrency. Br, Chansey 在 2015年2月7日星期六 UTC+8上午2:58:10，√写道： Hi Chansey, What would you look to gain by switching to coroutines? On Fri, Feb 6, 2015 at 7:44 PM, chan...@gmail.com javascript: wrote: Hello, Does akka support fiber/coroutine? I found that all akka's dispatchers rely on JVM threads now. Is there any way to config dispatchers which could run actor on fiber/coroutine? (do not modify the akka source code) Like StubFiber in retLang which use ExecuteAllPendingUntilEmpty to run dispatcher schedule instead of actual JVM thread. PS: I maybe could make akka support it, but need modify some akka code... I am using akka.NET now. Very thanks. Br, Chansey -- 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. -- Cheers, √ -- 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 Cluster Actor Failover and Rebalancing, is it possible?
Hi, I’m looking to see if Akka can be used as a cluster manager instead of say Mesos for my use case. Simply put, my use case is as following: 1. I have 10 physical machines. 2. I need to have 10 *singleton* stateless actors running on each one of these machines. 1 actor per server. 3. If one of the servers crashes, I need to be able to launch the actor that was on that server, on another server (that specific server will have two actors running on there). 4. Once the failed server recovers, I need to move the actor back to that server, so again I would have 1 actor per server. Can I use plain Akka to achieve this of I need to use Mesos/Marathon? If so, are there any docs/examples for this use case? Thanks, Drew -- 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] Does akka support fiber/coroutine? (do not modify source code)
Hello, Does akka support fiber/coroutine? I found that all akka's dispatchers rely on JVM threads now. Is there any way to config dispatchers which could run actor on fiber/coroutine? (do not modify the akka source code) Like StubFiber in retLang which use ExecuteAllPendingUntilEmpty to run dispatcher schedule instead of actual JVM thread. PS: I maybe could make akka support it, but need modify some akka code... I am using akka.NET now. Very thanks. Br, Chansey -- 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] Does akka support fiber/coroutine? (do not modify source code)
On Fri, Feb 6, 2015 at 8:24 PM, chanse...@gmail.com wrote: Hi Because my application is running on one thread now. (It maybe extend to multi-thread in the future) To be frank, I get benefit from akka by using actor model programming paradigm instead of its concurrency. You can use an Akka Dispatcher with a single thread and then make it non-daemonic and exit your main thread and your Akka application will be single-threaded? Br, Chansey 在 2015年2月7日星期六 UTC+8上午2:58:10，√写道： Hi Chansey, What would you look to gain by switching to coroutines? On Fri, Feb 6, 2015 at 7:44 PM, chan...@gmail.com wrote: Hello, Does akka support fiber/coroutine? I found that all akka's dispatchers rely on JVM threads now. Is there any way to config dispatchers which could run actor on fiber/coroutine? (do not modify the akka source code) Like StubFiber in retLang which use ExecuteAllPendingUntilEmpty to run dispatcher schedule instead of actual JVM thread. PS: I maybe could make akka support it, but need modify some akka code... I am using akka.NET now. Very thanks. Br, Chansey -- 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. -- Cheers, √ -- 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. -- Cheers, √ -- 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] Recovering from the Quarantined state
You should probably also look into why they are quarantined. It can be two reasons: 1) The nodes are removed from the cluster, which will happen if failure detection triggers, you use auto-downing and they don't become reachable again within the configured akka.cluster.auto-down-unreachable-after timeout. You might want to increase the auto-down timeout? 2) Overflow of the system message delivery buffer, because of many remote watch or remote deployments. You might want to increase the akka.remote.system-message-buffer-size, or adjust your design? Cheers, Patrik On Fri, Feb 6, 2015 at 10:58 AM, Akka Team akka.offic...@gmail.com wrote: Hi Mark, On Tue, Feb 3, 2015 at 5:13 PM, Mark Kegel mark.ke...@gmail.com wrote: We are using akka 2.3.4, but I don't think this is an issue with a specific version of akka. In fact the docs explicitly state that you have to restart the akka node after its been Quarantined. I'm looking for some way to detect that my node has been quarantined so that I can force an exit, so that our puppet system can restart it, or just restart the akka system programmatically without exiting the process. This seems like basic error handling and recovery but I see nothing in the docs on how a person is supposed to handle this, or how they can even be notified of the issue. I agree that we can improve the documentation around this. The remoting publishes events that you can subscribe to: http://doc.akka.io/docs/akka/2.3.9/scala/remoting.html#Remote_Events One of those published events notifies of quarantine: http://doc.akka.io/api/akka/2.3.9/#akka.remote.QuarantinedEvent -Endre Is there any kind of exception that bubbles back to user code, or a cluster state message that I can receive, for when my local akka instance can't rejoin the cluster? Is there any way a supervisor hierarchy can help solve this problem? If someone can point me to code that is able to respond and recover from such failures intelligently, and using akka approved idioms, that would be most appreciated. Mark On Tuesday, February 3, 2015 at 6:32:20 AM UTC-6, Patrik Nordwall wrote: What version of Akka are you using? We fixed some issue related to quarantining in 2.3.9. /Patrik On Mon, Jan 26, 2015 at 5:20 PM, Mark Kegel mark@gmail.com wrote: We are using akka in a clustered configuration at work. Its a very simple cluster with just three node types: an admin node, live nodes, and preview nodes. The admin node will manage nodes of the other two types, and ask for things like status and uptime. Every so often one of the live/preview nodes will become unresponsive to requests from the admin node. The only way we've been able to fix this is to restart the node. From reading the akka docs this seems to correspond to the node becoming Quarantined. While I appreciate that this state is necessary to maintain consistency, I'm at a loss in finding docs that show how to respond in code when this happens. On our admin node we'll know that some other live/preview node has failed and will require a restart, but what would work best is if we could have a service watching locally on the failed live/preview node that could force a restart of that nodes' JVM. Is there any kind of exception that bubbles back to user code, or a cluster state message that I can receive, for when my local akka instance can't rejoin the cluster? Is there any way a supervisor hierarchy can help solve this problem? If someone can point me to code that is able to respond and recover from such failures intelligently, and using akka approved idioms, that would be most appreciated. Mark -- 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. -- Akka Team
[akka-user] 2.4-SNAPSHOT and sbt-assembly :(
Hello. I tried to build a fat jar using sbt-assembly plugin and got the following error: [error] (robot/*:assembly) deduplicate: different file contents found in the following: [error] /home/eax/.ivy2/cache/org.iq80.leveldb/leveldb-api/jars/leveldb-api-0.7.jar:org/iq80/leveldb/DB.class [error] /home/eax/.ivy2/cache/org.fusesource.leveldbjni/leveldbjni-all/bundles/leveldbjni-all-1.7.jar:org/iq80/leveldb/DB.class If I'm not mistaken both packages are dependencies of akka-persistent (which is a dependency of akka-contrib which is used in our project). Here is an output of sbt-dependency-graph plugin: [info] org.iq80.leveldb:leveldb-api:0.7 [info] +-org.fusesource.leveldbjni:leveldbjni:1.7 [info] | +-org.fusesource.leveldbjni:leveldbjni-all:1.7 [info] | | +-com.typesafe.akka:akka-persistence-experimental_2.10:2.4-SNAPSHOT [S] [info] | | +-com.typesafe.akka:akka-contrib_2.10:2.4-SNAPSHOT [S] There is no such issue with Akka 2.3.9. As far as I can see corresponding bug is not reported at github so far. I wonder: 1. Is it really a bug in Akka or maybe I'm just doing something wrong? 2. Is it OK that akka-contrib depends on an experimental package? -- Best regards, Eax Melanhovich http://eax.me/ -- 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] AtLeastOnceDelivery - mapping my own messageId to deliveryId possible?
Hi Pawel,
What is the exact problem here? I am a bit slow today, so I might just have
missed the obvious, but explaining in detail would help :)
-Endre
On Wed, Feb 4, 2015 at 10:32 AM, Paweł Kaczor pablo.kac...@gmail.com
wrote:
According to
http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#Relationship_between_deliver_and_confirmDelivery
: A function can be created to map your own messageId to deliveryId,
which may come from your own domain model. This function must keep track of
which messageId have been acknowledged. Alternatively, the Persistence
module provides a default sequence number implementation which can also be
used as the deliveryId for messages. The default sequence increases
monotonically, without gaps.
I would like to be able to use my own deliveryId. It is not possible with
current implementation (see code below).
trait AtLeastOnceDelivery {
private def nextDeliverySequenceNr(): Long = {...}
def deliver(): Unit = {
...
val deliveryId = nextDeliverySequenceNr()
...
}
}
Pawel
--
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 cluster unreachable
Hi Idar,
Happy to hear that, and thanks for the confirmation.
-Endre
On Wed, Feb 4, 2015 at 9:08 AM, Idar Borlaug idar.borl...@gmail.com wrote:
I have upgraded to 2.3.9 it have now been running for 5 days, without any
problems.
On 28 January 2015 at 11:50, Idar Borlaug idar.borl...@gmail.com wrote:
I know, we have a few problems with upgradeing to 2.3.9. (we might wait
until eventstore has a cluster connector for java)
The only thing i can see is that the nodes have been almost idle for a
good while. But there are a few requests coming in. It dosen work fine for
2-3 days.
Will the state actor die if say a firewall cuts the tcp connection
because its been alive too long?
I will see if operations can monitor more data, and consider upgrading to
2.3.9 again.
On 27 January 2015 at 14:27, Björn Antonsson
bjorn.antons...@typesafe.com wrote:
Hi Idar,
A lot of things have been fixed in akka since 2.2.4. Would it be
possible to upgrade to 2.3.9?
From the log that you pasted it seems like the akka protocol state actor
for the connection to node 2 has died on node 1, before your log starts. Is
there something unusual going on on the machines, like GC or something else
that would consume resources at the time of the failure? Are you monitoring
other health metrics like disk space and swap usage?
B/
On 26 January 2015 at 12:31:19, Idar Borlaug (idar.borl...@gmail.com)
wrote:
Hi
I have a 2 node akka cluster, which looses connection once every two
days. Often when the server i almost idle. We are still on akka 2.2.4,
using oracle java 1.8_25. Its a virtual servers running on vmware esx.
The application have been running fine for 3 years, but started with
this a few weeks ago.
Anyone have any ideas on were to start troubleshooting this?
My clusterconfig:
remote {
log-sent-messages = on
log-received-messages = on
log-remote-lifecycle-events = off
netty.tcp {
port = 45000
}
watch-failure-detector.threshold = 15
}
cluster {
log-info = on
auto-down = on
auto-join = on
failure-detector {
threshold = 15
min-std-deviation = 500 ms
acceptable-heartbeat-pause = 20 s
}
heartbeat-request {
grace-period = 20 s
expected-response-after = 10 s
time-to-live = 60 s
}
use-dispatcher = cluster-dispatcher
}
}
cluster-dispatcher {
type = Dispatcher
executor = fork-join-executor
fork-join-executor {
parallelism-min = 2
parallelism-max = 4
}
}
logoutput:
node1:
2015-01-24 03:30:02,242 [svarut-akka.actor.default-dispatcher-25] WARN
n.k.e.DeadLetterLogger - Dead letter:
DeadLetter(Timer(heartbeat-timer,HeartbeatTimer,true,0),Actor[akka://svarut/dea
dLetters],Actor[akka://svarut/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fsvarut%40193.161.171.182%3A53119-2#-1998086621])
2015-01-24 03:30:02,242 [svarut-akka.actor.default-dispatcher-25] WARN
n.k.e.DeadLetterLogger - Dead letter:
DeadLetter(Disassociated(Unknown),Actor[akka://svarut/deadLetters],Actor[akka:/
/svarut/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fsvarut%40193.161.171.182%3A53119-2#-1998086621])
2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
n.k.e.DeadLetterLogger - Dead letter:
DeadLetter(DisassociateUnderlying(Unknown),Actor[akka://svarut/deadLetters],Act
or[akka://svarut/system/transports/akkaprotocolmanager.tcp0/akkaProtocol-tcp%3A%2F%2Fsvarut%40193.161.171.182%3A53119-2#-1998086621])
2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
n.k.e.DeadLetterLogger - Dead letter:
DeadLetter(Timer(AckIdleTimer,AckIdleCheckTimer,true,0),Actor[akka://svarut/dea
dLetters],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
n.k.e.DeadLetterLogger - Dead letter:
DeadLetter(Timer(AckIdleTimer,AckIdleCheckTimer,true,0),Actor[akka://svarut/dea
dLetters],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
n.k.e.DeadLetterLogger - Dead letter:
DeadLetter(Timer(AckIdleTimer,AckIdleCheckTimer,true,0),Actor[akka://svarut/dea
dLetters],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
2015-01-24 03:30:02,312 [svarut-akka.actor.default-dispatcher-24] WARN
n.k.e.DeadLetterLogger - Dead letter:
DeadLetter(TakeOver(akka.remote.transport.AkkaProtocolHandle@40711a86
),Actor[ak
Re: [akka-user] Re: Send message from netty code to actor system
Few things to take care of using a router at InboundHandler - ensuring that routees are available before the connections are being accepted - ensuring that ChannelContextHandler - passed in message, is not stored by routee actor internally for any purposes. This should be sufficient for pure req/reply pattern Regards Muthu On Thursday, 5 February 2015 03:39:18 UTC+5:30, Jabbar Azam wrote: After alot of head scratching I came to same conclusions as you. It's good to see somebody else having the same ideas. On Wednesday, 4 February 2015 21:06:11 UTC, Ngoc Dao wrote: Generally there are 2 ways to design for this problem: Once you have an actor reference, you can send things to it. So you can simply do this: targetActorRef ! myThing When the actor is done with the processing, it will call: myThing.myMethod This design is OK when the target actor is very reliable and it lies in the same node with myThing. Another way, is to use an actor to wrap around myThing. This wrapper actor will communicate with targetActorRef. It may watch targetActorRef to handle the case when targetActorRef dies, targetActorRef doesn't respond after some timeout etc. On Wednesday, February 4, 2015 at 10:09:19 PM UTC+9, Jabbar Azam wrote: I found some nice example showing integration of netty with akka on github. This is what I'm looking at https://github.com/gibffe/fuse specifically https://github.com/gibffe/fuse/blob/master/src/main/java/com/sulaco/fuse/netty/FuseChannelHandler.java Its embarrassingly simple :) On Tuesday, 3 February 2015 13:48:47 UTC, Jabbar Azam wrote: Oops I meant channel handler. On Tuesday, 3 February 2015 13:32:21 UTC, Jabbar Azam wrote: Hello, Sorry for the late reply. For some reason the forum messages didn't get forwarded to my email. I was thinking of using typedactors because I am trying to integrate non actor code(cloudhopper SMPP which uses netty) into an actor system. Netty does use callbacks so I can use asynchronous behaviour. Do you think I could encapsulate a netty channel inside an actor? A netty channel can call callbacks whenever something changes in the channel. On Friday, 30 January 2015 12:38:14 UTC, Björn Antonsson wrote: Hi, Are you sure that you need to block the sending code while the actor does its work? Is there an asynchronous API in netty that you can use where the actor would invoke a callback when it has finished processing the packet? B/ On 27 January 2015 at 11:03:26, Jabbar Azam (aja...@gmail.com) wrote: I think I need to look at typedactors. On Tuesday, 27 January 2015 09:29:43 UTC, Jabbar Azam wrote: Hello, How do I send a message from java non actor based code into an actor system? The code will be running on the same node and will be part of the same source code. So netty will be running, receiving packets, which will send any received packets into an actor system. The actor system will process the packets and then send the response payload back to the netty code. -- 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. -- Björn Antonsson Typesafe http://typesafe.com/ – Reactive Apps on the JVM twitter: @bantonsson http://twitter.com/#!/bantonsson -- 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-streams 1.0-M2]: opportunistic FlattenStrategy
Hi Paul, On Thu, Feb 5, 2015 at 10:50 PM, Paul Kinsky pkin...@gmail.com wrote: I would like to flatten a Source[Source[T]] opportunistically, emitting elements of type T as they arrive from any of the inner Sources. This is conceptually similar to a merge vertex http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-M2/index.html#akka.stream.scaladsl.Merge, with the added ability to add new input Sources on the fly. I would like to use the flatten method as defined on Source[T] http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-M2/index.html#akka.stream.scaladsl.Source to do this, but currently the only FlattenStrategy available is Concat, which, to quote the comments in FlattenStrategy.scala https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/FlattenStrategy.scala : * Strategy that flattens a stream of streams by concatenating them. This means taking an incoming stream * emitting its elements directly to the output until it completes and then taking the next stream. This has the * consequence that *if one of the input stream is infinite, no other streams after that will be consumed from*. There is a ticket for this missing strategy that will be called FlattenStrategy.merge. This strategy will be in 1.0 latest. Since the class it extends, abstract class FlattenStrategy[-T, U], has no abstract methods, I assume there's no way to create custom flatten strategies. Yes, unfortunately it is not easy to write a good and safe dsl for flattening yet, so this was not yet pursued. We will provide a few built-in strategies in the beginning, hopefully we can add the possibility for customization later. -Endre How would you recommend writing an opportunistic flatten step? -- 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.
[akka-user] Best way to write unit tests on an Akka actor
I am a relative newbie to testing Akka actors.
What I am trying to accomplish is: How do I unit test the following Actor
whose description I have laid out below:
*Description:*
I am trying to test an Actor class that is peering into a directory, and
inspecting the files inside of it. This action of the actor, I call it, a
task.
The class extends an Actor with a FileActionable trait
This class field variables a follows:
1) A val taskID
2) An ActorRef
3) an anonmymous function that takes takes into in a parameter - a val of
type FileMetaDataInfo, and returns a
Future[MetaDataAssociatedWithActionsTakenOnFile] which is stored in a val
that I call: postActionsTakenOnFileFunction
Note: MetaDataAssociatedWithActionsTakenOnFile is a case class and
represents a few things like, when the file was last worked on, what is the
file path,
a flag to indicate something was detected in the file, no of characters in
the file, etc]
There are methods in the class as follows:
def postActionsTakenOnFile(a file, report) =
postActionsTakenOnFileFunction
def initializeActionsTakenOnFile(filesList:List[FileMetaDataInfo ) :
Option[Int] = { some code, that basically checks the List.headOption to
explicitly handle the case of an empty list, does some logic that basically
decides if the Actor how it would decide to exercise actions on the files
based on some prior load metric or something.
[Note: filesList represents a List of case class entities representing
metadata like file path, when the file was last modified, the length of the
file
Then of course, we have a receive method that basically goes through some
cases and has a case message to log an error reporting something it cant
handle..
-
I would like to know what testcases I can possibly write and how a test
case or case code will look. I am studying up on the ScalaTest site and
also the Akka documentation on testing actors.* I would like to write
testcases using ScalaTest.*
Any pointers are appreciated. Thanks in advance.
--
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] Location transparency - not clear
Hi – We have been using Akka for some time now as part of our online service (www.sickly.org) and overall have been very happy with it. Having started with creating and running actors locally, on a single server instance, a few months back we started scaling up by moving some actors out onto a separate instance. This has all worked pretty well. We're now looking at scaling up still further and at this point, finding the documentation unclear as to how location transparency is really meant to work. Let's say you start with Actors A, B and C, all running on Instance 1. You create them using actorOf and send messages between them using the ActorRefs that are returned, as per the Akka documentation. Fine. Now let's say you want to deploy your codebase across Instance 1 and Instance 2. You configure things so Actors A and B are running on Instance 1, and Actor C is running on Instance 2. Actor B is a shared service (in our case a persistent message queue that we have implemented in Akka) which is accessed from Actor A and Actor C. When Actor A sends a message to Actor B, it can do so using an ActorRef as before, because it's communicating locally. But when Actor C sends a message to Actor B, it's doing so remotely so needs to look up an ActorSelection. But Actor A and Actor C are communicating with Actor B using the same shared code, and as ActorRef and ActorSelection don't share a useful common base class, the upshot is you no longer have the location transparency promised by Akka. We could at this point: 1. Switch to using ActorSelection everywhere, but it seems there's going to be a performance penalty (considering many uses of it will be local) which could be significant and surely could be avoided, or 2. Implement our own mechanism for resolving ActorSelections to ActorRefs, caching ActorRefs to cut down on lookups, and handling any lifecycle errors appropriately (e.g. if Instance 2 is restarted, the ActorRef will need to be refreshed). But this seems like hard work and the sort of thing that would surely be part of Akka if it was really necessary; and besides, we'd end up with Future[ActorRef] instead of ActorRef, meaning we'd have to re-code every usage we have of those ActorRefs - which again seems to fly in the face of location transparency, or 3. Implement some kind of wrapper for Either[ActorRef, ActorSelection] that we can send messages to using ! and that passes them to the underlying ActorRef or ActorSelection - but this really does seem like the sort of thing we shouldn't have to be doing, or 4. ... ? How are we meant to handle this? Many thanks, Jeremy -- 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] ANNOUNCE: Akka Streams HTTP 1.0-M3
And in the rush of course I forgot one thing: Thanks a lot to Greg Beech for adding the “Age” and “Expires” headers to our HTTP model! 6 feb 2015 kl. 15:56 skrev Roland Kuhn goo...@rkuhn.info: Dear hakkers, it has been over a month, so we figured that another milestone of our Streams HTTP projects is in order. The Christmas break was a bit longer on the HTTP side (i.e. not so many changes there), so most of the work went into streams: consistently use the word “failure” instead of “error” in the API (see here http://www.reactivemanifesto.org/glossary#Failure for the definitions) rename all materializing actions such that they start with “run” (e.g. “runForeach”) to distinguish them from non-materializing ones rename ActorBasedFlowMaterializer to ActorFlowMaterializer (which now uses ActorFlowMaterializerSettings) make use of DeadLetterSuppression to avoid pointless warning messages, also sanitize failure logging in stream stages to avoid duplicates fix a few issues with StreamTcp concerning connection termination last but certainly not least: translate the Scala reference documentation to Java (cookbook still missing at this point) What next? When starting to work on the integration for our SslTlsStage we encountered some difficulties with the current internal design—in fact this reminded us that we had not yet implemented some of the semantics of reusing flow topology blueprints within larger graphs. This triggered a rewrite of the internal representation of FlowGraph that is currently under way. While doing this we discovered another difficulty related to extracting materialized values (like the local socket address for a server binding, or a completion future for a Sink) when reusing the same blueprint multiple times within a larger graph, and the solution for this needs an API change: version 1.0-M4 (to be released in two weeks time) will introduce one more type parameter for all graph elements that materialize to a value, namely the type of that value. Composition operators and graph constructors (like Source(), FlowGraph() and Sink()) will require explicit functions that describe how these materialized values are composed, and overall materialization of a RunnableFlow will then yield only the overall (composed) value instead of a MaterializedMap. This should be safer and more intuitive to use than what we have currently. After this change we plan on keeping the API stable (with the caveat that future enlightenment might reveal flaws yet unknown). On the HTTP front the next task is to start the implementation of WebSockets, and once TLS is available on the Streams layer we will hook that up into HTTP as well. All your feedback (on this list and on github) has been very helpful in pushing Akka Streams HTTP forward, please stay awesome :-) Regards, 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/ http://akka.io/docs/ Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html http://doc.akka.io/docs/akka/current/additional/faq.html Search the archives: https://groups.google.com/group/akka-user 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout 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 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] ANNOUNCE: Akka Streams HTTP 1.0-M3
Dear hakkers, it has been over a month, so we figured that another milestone of our Streams HTTP projects is in order. The Christmas break was a bit longer on the HTTP side (i.e. not so many changes there), so most of the work went into streams: consistently use the word “failure” instead of “error” in the API (see here http://www.reactivemanifesto.org/glossary#Failure for the definitions) rename all materializing actions such that they start with “run” (e.g. “runForeach”) to distinguish them from non-materializing ones rename ActorBasedFlowMaterializer to ActorFlowMaterializer (which now uses ActorFlowMaterializerSettings) make use of DeadLetterSuppression to avoid pointless warning messages, also sanitize failure logging in stream stages to avoid duplicates fix a few issues with StreamTcp concerning connection termination last but certainly not least: translate the Scala reference documentation to Java (cookbook still missing at this point) What next? When starting to work on the integration for our SslTlsStage we encountered some difficulties with the current internal design—in fact this reminded us that we had not yet implemented some of the semantics of reusing flow topology blueprints within larger graphs. This triggered a rewrite of the internal representation of FlowGraph that is currently under way. While doing this we discovered another difficulty related to extracting materialized values (like the local socket address for a server binding, or a completion future for a Sink) when reusing the same blueprint multiple times within a larger graph, and the solution for this needs an API change: version 1.0-M4 (to be released in two weeks time) will introduce one more type parameter for all graph elements that materialize to a value, namely the type of that value. Composition operators and graph constructors (like Source(), FlowGraph() and Sink()) will require explicit functions that describe how these materialized values are composed, and overall materialization of a RunnableFlow will then yield only the overall (composed) value instead of a MaterializedMap. This should be safer and more intuitive to use than what we have currently. After this change we plan on keeping the API stable (with the caveat that future enlightenment might reveal flaws yet unknown). On the HTTP front the next task is to start the implementation of WebSockets, and once TLS is available on the Streams layer we will hook that up into HTTP as well. All your feedback (on this list and on github) has been very helpful in pushing Akka Streams HTTP forward, please stay awesome :-) Regards, 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 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.
