Re: [akka-user] TCP Stream and Request Strategy
On Tue, Jan 27, 2015 at 1:35 PM, Björn Antonsson
bjorn.antons...@typesafe.com wrote:
Hi Thomas,
There is a recipe for chunking up bytestrings in the stream docs
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-cookbook.html#Chunking_up_a_stream_of_ByteStrings_into_limited_size_ByteStrings
Aaaand of course there is one recipe for parsing frames with a terminator
sequence (for example text lines):
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-cookbook.html#Parsing_lines_from_a_stream_of_ByteStrings
-Endre
Maybe you could use that as a starting point to chunk up the bytestring
into the header bytestring and payload bytestring.
B/
On 26 January 2015 at 12:09:57, Thomas Zimmer (t...@turtle-entertainment.de)
wrote:
Hi,
i have a question regarding TCP Streams and request strategies. Lets say i
have a TCPStream build upon the ReactiveStream Framework. I have a
Subscriber to consume the incoming data as a Sink using the
ActorSubscriber. Now my problem is that i have a binary network protocol
that looks like this:
protocol = headerbody
header = LengthField (4 bytes), Type(4 bytes),
body= Length and content is dynamic
So my approach was creating a own request - strategy like this:
class IncomingDataActor extends ActorSubscriber with RequestStrategy {
val HEADER_SIZE: Int = 8
var expectedBodyLength: Int = 0
override def requestDemand(remainingRequested : scala.Int) : Int = {
if (parsingBody) {
expectedBodyLength
} else {
HEADER_SIZE
}
}
override def receive: Actor.Receive = {
case OnNext(data: ByteString) =
expectedBodyLength = readHeaderSize(data)
parsingBody = true
context.become(parseBody, false)
}
def parseBody: Actor.Receive = {
case OnNext(data: ByteString) =
parseBodyAndProcessData();
parsingBody = false
context.unbecome()
}
}
The problem that i receive all available data in the non parse body
state. Is there a way to deal with that or do i have to implement some
buffer mechanism on my own?
Regards,
Thomas
--
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.
--
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.
--
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,
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
ka://svarut/system/endpointManager#1220933312],Actor[akka://svarut/system/endpointManager/endpointWriter-akka.tcp%3A%2F%2Fsvarut%40193.161.171.182%3A45000-1#1403595424])
2015-01-24 03:30:27,666 [svarut-akka.actor.default-dispatcher-31] ERROR
a.c.ClusterCoreDaemon - Cluster Node [akka.tcp://svarut@193.161.171.181:45000]
- Marking node(s) as UNREACHABLE [Memb
er(address = akka.tcp://svarut@193.161.171.182:45000, status = Up)]
2015-01-24 03:30:28,504 [svarut-akka.actor.default-dispatcher-17] INFO
Cluster(akka://svarut) - Cluster Node [akka.tcp://svarut@193.161.171.181:45000]
- Leader is marking unreachable node
[akka.tcp://svarut@193.161.171.182:45000] as [Down]
2015-01-24 03:30:28,506 [svarut-akka.actor.default-dispatcher-25] INFO
Cluster(akka://svarut) - Cluster Node [akka.tcp://svarut@193.161.171.181:45000]
- Leader is removing unreachable node
[akka.tcp://svarut@193.161.171.182:45000]
Node2:
2015-01-24 03:30:02,040 [svarut-akka.actor.default-dispatcher-12] WARN
n.k.e.DeadLetterLogger - Dead letter:
[akka-user] [Akka-2.3.7][Scala] - akka.remote.EndpointWriter
Hi All, I recently upgraded my application Akka version from 2.2.4 to 2.3.7. Since then I started seeing messages like this: akka.remote.EndpointWriter Drained buffer with maxWriteCount: 50, fullBackoffCount: 1, smallBackoffCount: 1, noBackoffCount: 0 , adaptiveBackoff: 2000 Google-ing about this subject sent me to a couple of articles in chineese. Can anyone shed some light on this EndpointWriter or the scenarios for getting the above message? Thanks, Yarden -- 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-2.3.7][Scala-2.11] - akka.remote.EndpointWriter
Hi all, I've recently upgraded from Akka 2.2.4 to 2.3.7. Since then, I started getting the following message: akka.remote.EndpointWriter Drained buffer with maxWriteCount: 50, fullBackoffCount: 1, smallBackoffCount: 1, noBackoffCount: 0 , adaptiveBackoff: 2000 Google-ing for this EndpointWriter sent me to a couple of articles in Chineese (which I can't read, yet :). Can anyone explain this message: Thanks, Yarden -- 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-2.3.7][Scala] - akka.remote.EndpointWriter
Hi Thanks for the SUPER fast reply. I'll upgrade as you suggested. I also use Play framework, and the latest version is 2.3.7, will I have compatibility issues? Thanks, On Tuesday, January 27, 2015 at 10:10:33 AM UTC+2, √ wrote: Hi Yarden, please upgrade to the latest bugfix release for the given major version (2.3.9 for 2.3 for instance). http://akka.io/news/2015/01/19/akka-2.3.9-released.html On Tue, Jan 27, 2015 at 8:50 AM, Yarden Bar ayash@gmail.com javascript: wrote: Hi All, I recently upgraded my application Akka version from 2.2.4 to 2.3.7. Since then I started seeing messages like this: akka.remote.EndpointWriter Drained buffer with maxWriteCount: 50, fullBackoffCount: 1, smallBackoffCount: 1, noBackoffCount: 0 , adaptiveBackoff: 2000 Google-ing about this subject sent me to a couple of articles in chineese. Can anyone shed some light on this EndpointWriter or the scenarios for getting the above message? Thanks, Yarden -- 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] Send message from netty code to actor system
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+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] Simple, local, garbage collected actors
Hi Arek,
Thanks for your effort! I read through your impl and would like to share a
few hints:
Please do not ever rely on java finalization – ever.
For one thing, it's unreliable – no-one guarantees that these will ever be
called. [60]
https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L60
Also, just by having a finalizer defined you put a way larger burden on the
collector as it has to track those in a similar way it does with
java.lang.ref.* references (putting in reference queues etc instead of just
reclaiming space).
You should never block in your Actors when working with Akka. Remember the
never block mantra :-)
Calling Await inside actor code is a big no-no – this will cause your
entire application (everyone on that dispatcher) to suffer for it. [36]
https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L36
Please refer to the documentation about actor systems
http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#actor-best-practices
to read more about this.
In general I would not recommend wrapping Akka in such way and simply
embracing the asynchronous nature of it.
You'll get better performance and fully-embracing these concepts instead of
hiding it here and there will get you to cleaner code by the end of the day
too.
On Tue, Jan 27, 2015 at 10:07 AM, Arkadiusz Burdach arek.burd...@gmail.com
wrote:
Hi all.
What do you think about an idea of module providing possibility to create
actor by *new* operator eg.
val actor = new SimpleActor {
override def receive: Receive = {
case _ = sender() ! OK
}
}
Those actors would be garbage collected so there will be no need to send
PoisonPIll them.
I've prepared proof of concept: https://github.com/arkadius/akka-simple
It will be usefull? Or maybe there is already other way to use this kind
of syntax of actors?
Arek
--
Cheers,
Konrad 'ktoso' Malawski
Akka http://akka.io @ Typesafe http://typesafe.com
--
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-2.3.7][Scala] - akka.remote.EndpointWriter
Hi Yarden, On Tue, Jan 27, 2015 at 9:58 AM, Yarden Bar ayash.jor...@gmail.com wrote: Hi Thanks for the SUPER fast reply. I'll upgrade as you suggested. The upgrade will not change the message though. This is a status message that is useful to debug if you send remote messages much faster than the network can take it. If such event happens you will see the numbers growing, that's it in a nutshell. -Endre I also use Play framework, and the latest version is 2.3.7, will I have compatibility issues? Thanks, On Tuesday, January 27, 2015 at 10:10:33 AM UTC+2, √ wrote: Hi Yarden, please upgrade to the latest bugfix release for the given major version (2.3.9 for 2.3 for instance). http://akka.io/news/2015/01/19/akka-2.3.9-released.html On Tue, Jan 27, 2015 at 8:50 AM, Yarden Bar ayash@gmail.com wrote: Hi All, I recently upgraded my application Akka version from 2.2.4 to 2.3.7. Since then I started seeing messages like this: akka.remote.EndpointWriter Drained buffer with maxWriteCount: 50, fullBackoffCount: 1, smallBackoffCount: 1, noBackoffCount: 0 , adaptiveBackoff: 2000 Google-ing about this subject sent me to a couple of articles in chineese. Can anyone shed some light on this EndpointWriter or the scenarios for getting the above message? Thanks, Yarden -- 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. -- 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-2.3.7][Scala] - akka.remote.EndpointWriter
Hi Yarden, please upgrade to the latest bugfix release for the given major version (2.3.9 for 2.3 for instance). http://akka.io/news/2015/01/19/akka-2.3.9-released.html On Tue, Jan 27, 2015 at 8:50 AM, Yarden Bar ayash.jor...@gmail.com wrote: Hi All, I recently upgraded my application Akka version from 2.2.4 to 2.3.7. Since then I started seeing messages like this: akka.remote.EndpointWriter Drained buffer with maxWriteCount: 50, fullBackoffCount: 1, smallBackoffCount: 1, noBackoffCount: 0 , adaptiveBackoff: 2000 Google-ing about this subject sent me to a couple of articles in chineese. Can anyone shed some light on this EndpointWriter or the scenarios for getting the above message? Thanks, Yarden -- 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] akka http 1.0-M2 thread pegs a CPU core until connection closes on Windows
Hi, There is a setting akka.io.tcp.windows-connection-abort-workaround-enabled setting that is known to be causing this. It is a workaround for Windows to get connection abort events reliably, but unfortunately has this side-effect. You can disable the workaround from the config, currently it is automatically enabled for Windows, see: http://doc.akka.io/docs/akka/2.3.9/general/configuration.html#akka-actor -Endre On Mon, Jan 26, 2015 at 11:02 PM, huynhjl huyn...@gmail.com wrote: Hi, I am trying akka HTTP and seeing odd behavior with a thread keeping a core busy until the client connection closes. That seems to only happen on Windows. A minimized example is there: https://github.com/huynhjl/cpu-peg/blob/0.1/src/main/scala/HttpTest.scala The stack dump of the thread that is busy is in the README at : https://github.com/huynhjl/cpu-peg/tree/0.1 And a screenshot of visualvm showing CPU is busy is here: https://github.com/huynhjl/cpu-peg/blob/0.1/profiler.png My environment is JDK 1.8.0_31 or 1.7.0_71 on Windows 7 Enterprise SP1. To reproduce, I start the program, then request http://localhost:8080 in chrome. Then a core is busy until I close the browser. Has anybody else seen that? Is this a known issue? -- huynhjl -- 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. -- 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] Simple, local, garbage collected actors
Hi Arkadiusz, 27 jan 2015 kl. 15:21 skrev Arkadiusz Burdach arek.burd...@gmail.com: Hi Konrad, Thanks for reply. More inlined. W dniu wtorek, 27 stycznia 2015 11:01:58 UTC+1 użytkownik Konrad Malawski napisał: Please do not ever rely on java finalization – ever. For one thing, it's unreliable – no-one guarantees that these will ever be called. [60] https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L60 Also, just by having a finalizer defined you put a way larger burden on the collector as it has to track those in a similar way it does with java.lang.ref.* references (putting in reference queues etc instead of just reclaiming space). It's true. In fact this finalize behaviour was only a hint for Actor. I could provide other way to clenup internal actors for example repeated job checking if SimpleActor was released. And also it is in't a core thing for this implementation to cleanup an internal Actor. Core memory part will be declared in SimpleActors which will be normally cleaned up by jvm. No matter how you implement this, it will always involve either WeakReference or finalizers, both of which are the devil. There is no other way—if there were then we’d already implemented this :-) You should never block in your Actors when working with Akka. Remember the never block mantra :-) Calling Await inside actor code is a big no-no – this will cause your entire application (everyone on that dispatcher) to suffer for it. [36] https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L36 Please refer to the documentation about actor systems http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#actor-best-practices to read more about this. Yes, I know this. Shortcut for Await was only added for purpose of quicker Actor tests and it is minor think. I know that the best is to keep your code as much async as it possible. But I think that it could be helpful to just check how Actor will reply on request without using additional tools like Await. In general I would not recommend wrapping Akka in such way and simply embracing the asynchronous nature of it. You'll get better performance and fully-embracing these concepts instead of hiding it here and there will get you to cleaner code by the end of the day too. Ok, but what do you think about shortcut for creating Actors by new operator with auto-gc? I don't think about it as a subistitution but just like a nice addition :-) I think that in many cases people use akka actors for small applications that will be never used in cluster. For this simple use case it is a little inconvenience to declare ActorSystem, provide specialized ExecutionContext depend on situation, and keep thinking if actors memory was released. I know background of all this things but tools should be selected depend on situation :-) Auto-GC comes at too big a cost, but the main reason I would recommend against this approach is that supervision is neglected: by only being able to create top-level actors most of the advantages of the Actor model are removed. If you are after a smaller syntax footprint you might want to check out the ActorDSL https://github.com/akka/akka/blob/v2.3.9/akka-actor/src/main/scala/akka/actor/ActorDSL.scala which uses an implicit ActorRefFactory for creation. It has been provided for quickly sketching actor programs in the Scala REPL. Regards, Roland Cheers, Arek -- 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
Re: [akka-user] TCP Stream and Request Strategy
Hi Thomas,
On Tue, Jan 27, 2015 at 3:32 PM, Thomas Zimmer t...@turtle-entertainment.de
wrote:
Thank you so much guys! You definitely rock :)
I think Björn link was excatly what I was loooking for. Is there a way to
influence the demanded chunk-size dynamically?
No, the ByteStrings are of arbitrary size. You need to buffer up as much as
you need to parse the packet, then remove the parsed part from the buffer
and keep the remaining bytes for the next parsing round. Look at the sample
I posted (which is more complex given that it needs to search for a
terminator byte sequence). The point of these recipes is to use them as
inspiration and adapt them to your needs.
-Endre
Regards,
Thomas
On Tuesday, January 27, 2015 at 1:42:15 PM UTC+1, drewhk wrote:
On Tue, Jan 27, 2015 at 1:35 PM, Björn Antonsson bjorn.a...@typesafe.com
wrote:
Hi Thomas,
There is a recipe for chunking up bytestrings in the stream docs
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/
stream-cookbook.html#Chunking_up_a_stream_of_ByteStrings_
into_limited_size_ByteStrings
Aaaand of course there is one recipe for parsing frames with a terminator
sequence (for example text lines): http://doc.akka.io/
docs/akka-stream-and-http-experimental/1.0-M2/scala/
stream-cookbook.html#Parsing_lines_from_a_stream_of_ByteStrings
-Endre
Maybe you could use that as a starting point to chunk up the bytestring
into the header bytestring and payload bytestring.
B/
On 26 January 2015 at 12:09:57, Thomas Zimmer (
t...@turtle-entertainment.de) wrote:
Hi,
i have a question regarding TCP Streams and request strategies. Lets say
i have a TCPStream build upon the ReactiveStream Framework. I have a
Subscriber to consume the incoming data as a Sink using the
ActorSubscriber. Now my problem is that i have a binary network protocol
that looks like this:
protocol = headerbody
header = LengthField (4 bytes), Type(4 bytes),
body= Length and content is dynamic
So my approach was creating a own request - strategy like this:
class IncomingDataActor extends ActorSubscriber with RequestStrategy {
val HEADER_SIZE: Int = 8
var expectedBodyLength: Int = 0
override def requestDemand(remainingRequested : scala.Int) : Int = {
if (parsingBody) {
expectedBodyLength
} else {
HEADER_SIZE
}
}
override def receive: Actor.Receive = {
case OnNext(data: ByteString) =
expectedBodyLength = readHeaderSize(data)
parsingBody = true
context.become(parseBody, false)
}
def parseBody: Actor.Receive = {
case OnNext(data: ByteString) =
parseBodyAndProcessData();
parsingBody = false
context.unbecome()
}
}
The problem that i receive all available data in the non parse body
state. Is there a way to deal with that or do i have to implement some
buffer mechanism on my own?
Regards,
Thomas
--
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+...@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.
--
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.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
Re: [akka-user] TCP Stream and Request Strategy
Thank you so much guys! You definitely rock :)
I think Björn link was excatly what I was loooking for. Is there a way to
influence the demanded chunk-size dynamically?
Regards,
Thomas
On Tuesday, January 27, 2015 at 1:42:15 PM UTC+1, drewhk wrote:
On Tue, Jan 27, 2015 at 1:35 PM, Björn Antonsson bjorn.a...@typesafe.com
javascript: wrote:
Hi Thomas,
There is a recipe for chunking up bytestrings in the stream docs
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-cookbook.html#Chunking_up_a_stream_of_ByteStrings_into_limited_size_ByteStrings
Aaaand of course there is one recipe for parsing frames with a terminator
sequence (for example text lines):
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-cookbook.html#Parsing_lines_from_a_stream_of_ByteStrings
-Endre
Maybe you could use that as a starting point to chunk up the bytestring
into the header bytestring and payload bytestring.
B/
On 26 January 2015 at 12:09:57, Thomas Zimmer (
t...@turtle-entertainment.de javascript:) wrote:
Hi,
i have a question regarding TCP Streams and request strategies. Lets say
i have a TCPStream build upon the ReactiveStream Framework. I have a
Subscriber to consume the incoming data as a Sink using the
ActorSubscriber. Now my problem is that i have a binary network protocol
that looks like this:
protocol = headerbody
header = LengthField (4 bytes), Type(4 bytes),
body= Length and content is dynamic
So my approach was creating a own request - strategy like this:
class IncomingDataActor extends ActorSubscriber with RequestStrategy {
val HEADER_SIZE: Int = 8
var expectedBodyLength: Int = 0
override def requestDemand(remainingRequested : scala.Int) : Int = {
if (parsingBody) {
expectedBodyLength
} else {
HEADER_SIZE
}
}
override def receive: Actor.Receive = {
case OnNext(data: ByteString) =
expectedBodyLength = readHeaderSize(data)
parsingBody = true
context.become(parseBody, false)
}
def parseBody: Actor.Receive = {
case OnNext(data: ByteString) =
parseBodyAndProcessData();
parsingBody = false
context.unbecome()
}
}
The problem that i receive all available data in the non parse body
state. Is there a way to deal with that or do i have to implement some
buffer mechanism on my own?
Regards,
Thomas
--
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.
--
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+...@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.
--
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] Simple, local, garbage collected actors
W dniu wtorek, 27 stycznia 2015 15:36:05 UTC+1 użytkownik rkuhn napisał: Hi Arkadiusz, 27 jan 2015 kl. 15:21 skrev Arkadiusz Burdach arek.b...@gmail.com javascript:: Hi Konrad, Thanks for reply. More inlined. W dniu wtorek, 27 stycznia 2015 11:01:58 UTC+1 użytkownik Konrad Malawski napisał: Please do not ever rely on java finalization – ever. For one thing, it's unreliable – no-one guarantees that these will ever be called. [60] https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L60 Also, just by having a finalizer defined you put a way larger burden on the collector as it has to track those in a similar way it does with java.lang.ref.* references (putting in reference queues etc instead of just reclaiming space). It's true. In fact this finalize behaviour was only a hint for Actor. I could provide other way to clenup internal actors for example repeated job checking if SimpleActor was released. And also it is in't a core thing for this implementation to cleanup an internal Actor. Core memory part will be declared in SimpleActors which will be normally cleaned up by jvm. No matter how you implement this, it will always involve either WeakReference or finalizers, both of which are the devil. There is no other way—if there were then we’d already implemented this :-) I'm not a specialist in usage of WeakReferences. In a simple cases it looks like they are usable (I've done performance tests). There are plans to remove them from JRE? If they are bad at all maybe we should create a ticket to remove them? According to second part of your answer it does mean that all realizable and usable features are already implemented? So mabye we should close possibility to create an enhancements in request tracker? ;-) Even if garbage collection won't work in all situations, you always could use PoisonPill which would be forwared to internal actor. You should never block in your Actors when working with Akka. Remember the never block mantra :-) Calling Await inside actor code is a big no-no – this will cause your entire application (everyone on that dispatcher) to suffer for it. [36] https://github.com/arkadius/akka-simple/blob/master/src/main/scala/akka/actor/simple/SimpleActor.scala#L36 Please refer to the documentation about actor systems http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#actor-best-practices to read more about this. Yes, I know this. Shortcut for Await was only added for purpose of quicker Actor tests and it is minor think. I know that the best is to keep your code as much async as it possible. But I think that it could be helpful to just check how Actor will reply on request without using additional tools like Await. In general I would not recommend wrapping Akka in such way and simply embracing the asynchronous nature of it. You'll get better performance and fully-embracing these concepts instead of hiding it here and there will get you to cleaner code by the end of the day too. Ok, but what do you think about shortcut for creating Actors by new operator with auto-gc? I don't think about it as a subistitution but just like a nice addition :-) I think that in many cases people use akka actors for small applications that will be never used in cluster. For this simple use case it is a little inconvenience to declare ActorSystem, provide specialized ExecutionContext depend on situation, and keep thinking if actors memory was released. I know background of all this things but tools should be selected depend on situation :-) Auto-GC comes at too big a cost, but the main reason I would recommend against this approach is that supervision is neglected: by only being able to create top-level actors most of the advantages of the Actor model are removed. If you are after a smaller syntax footprint you might want to check out the ActorDSL https://github.com/akka/akka/blob/v2.3.9/akka-actor/src/main/scala/akka/actor/ActorDSL.scala which uses an implicit ActorRefFactory for creation. It has been provided for quickly sketching actor programs in the Scala REPL. I've checked it out. It is nice syntax for some constructions. But as far as I know it has only a factories - you can't declare a new class, extend it and than new instances wouldn't be an Actors. Thank you for feedback, Arek -- 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
Re: [akka-user] Simple, local, garbage collected actors
Hi Arek,
We used to do it like that about 5 years ago:
https://github.com/akka/akka/blob/v0.8.1/akka-core/src/main/scala/actor/Actor.scala#L105
:)
On Tue, Jan 27, 2015 at 10:07 AM, Arkadiusz Burdach arek.burd...@gmail.com
wrote:
Hi all.
What do you think about an idea of module providing possibility to create
actor by *new* operator eg.
val actor = new SimpleActor {
override def receive: Receive = {
case _ = sender() ! OK
}
}
Those actors would be garbage collected so there will be no need to send
PoisonPIll them.
I've prepared proof of concept: https://github.com/arkadius/akka-simple
It will be usefull? Or maybe there is already other way to use this kind
of syntax of actors?
Arek
--
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] Acceptable Limits for Actor Creation and Destruction?
Paul, The child will tell the Parent to supervise it by sending the Parent a system message. B/ On 26 January 2015 at 19:10:50, Paul Cleary (pclear...@gmail.com) wrote: Thanks Victor? Is the handshake through messages sent back and forth? On Monday, January 26, 2015 at 12:29:42 PM UTC-5, √ wrote: Hi Paul, you may want to put the parent on a different dispatcher than the children, since the creation process is a handshake. (so both parent and child needs CPU time) On Mon, Jan 26, 2015 at 5:49 PM, Paul Cleary pcle...@gmail.com wrote: Victor, Yes, they are spawned under the same parent (same actual actor ref). The parent is long-lived, i.e. intended to hang around for the lifetime of the process. On Monday, January 26, 2015 at 11:14:40 AM UTC-5, √ wrote: Hi Paul, There's also the question if they are spawned under the same parent or not. On Mon, Jan 26, 2015 at 5:07 PM, Paul Cleary pcle...@gmail.com wrote: Thank your for the reply, These machines are typically 4 core / 8 GB machines with only our app running. The only JVM settings are CMS and Parallel Young Generation. Also Java 1.7, Scala 2.11, Play 2.3. We have not benchmarked the actors themselves, as there are several actors in the system. The other actors are more permanent, with the FSM actor being the short lived one. My question was more of, is there guidance (JVM or Akka tuning, vm specs) in this scenario w.r.t. to VM sizing / JVM args based on a 50,000 or 100,000 actor per second kind of model? The benchmark is an interesting idea. I could write an alternative implementation that did not use FSMs are actors at all, and then run our perf tests to see what the impact would be. On Monday, January 26, 2015 at 8:24:54 AM UTC-5, Björn Antonsson wrote: Hi Paul, There are a lot of moving parts in creating an actor, and the associated costs. What is a lot of garbage? It's a completely subjective question. Also, depending on the size of your machine, 5 actors per second might be easy, or not possible. Have you tried to benchmark the creation of your actors? B/ On 21 January 2015 at 14:35:53, Paul Cleary (pcle...@gmail.com) wrote: I have an application where we are creating and destroying a lot of actors. The amount of actors that are created is tied to the volume of requests on the application. I am using FSM for the Actor in question here. I do not fully understand what is involved with the setup / teardown of an individual actor, so that is part of the motivation for the question. Is it reasonable to be creating 10s of thousands of these FSM instances per second (say 50,000 actors create and destroyed every second)? Is there an upper limit that I should look at? Will this result in a lot of garbage? Thanks for the help! -- 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 – Reactive Apps on the JVM twitter: @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+...@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+...@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
Re: [akka-user] TCP Stream and Request Strategy
Hi Thomas,
There is a recipe for chunking up bytestrings in the stream docs
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-cookbook.html#Chunking_up_a_stream_of_ByteStrings_into_limited_size_ByteStrings
Maybe you could use that as a starting point to chunk up the bytestring into
the header bytestring and payload bytestring.
B/
On 26 January 2015 at 12:09:57, Thomas Zimmer (t...@turtle-entertainment.de)
wrote:
Hi,
i have a question regarding TCP Streams and request strategies. Lets say i have
a TCPStream build upon the ReactiveStream Framework. I have a Subscriber to
consume the incoming data as a Sink using the ActorSubscriber. Now my problem
is that i have a binary network protocol that looks like this:
protocol = headerbody
header = LengthField (4 bytes), Type(4 bytes),
body = Length and content is dynamic
So my approach was creating a own request - strategy like this:
class IncomingDataActor extends ActorSubscriber with RequestStrategy {
val HEADER_SIZE: Int = 8
var expectedBodyLength: Int = 0
override def requestDemand(remainingRequested : scala.Int) : Int = {
if (parsingBody) {
expectedBodyLength
} else {
HEADER_SIZE
}
}
override def receive: Actor.Receive = {
case OnNext(data: ByteString) =
expectedBodyLength = readHeaderSize(data)
parsingBody = true
context.become(parseBody, false)
}
def parseBody: Actor.Receive = {
case OnNext(data: ByteString) =
parseBodyAndProcessData();
parsingBody = false
context.unbecome()
}
}
The problem that i receive all available data in the non parse body state. Is
there a way to deal with that or do i have to implement some buffer mechanism
on my own?
Regards,
Thomas
--
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.
--
Björn Antonsson
Typesafe – Reactive Apps on the JVM
twitter: @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] distributed pub sub
Hi Matteo, 1) The distributed pub sub extension only works in the setting of an akka cluster. You can connect to the cluster from the outside via the cluster client, which actually use distributed pub sub inside the cluster. 2) It uses gossip to disseminate the subscriptions, but the actual message send is direct, via the mediator of course. 3) There is no wait when you send messages. B/ On 24 January 2015 at 12:53:42, Matteo Cusmai (cusmaimat...@gmail.com) wrote: Hi all, I have some questions about the distributed pub sub akka extension: 1. Does it work only in cluster environment? 2. Does it use gossip protocol for both subscriptions and publishing? 3. If so, does the system wait about 1 s to send messages to subscriptors? Thanks in advance, Matteo. -- 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. -- Björn Antonsson Typesafe – Reactive Apps on the JVM twitter: @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] Acceptable Limits for Actor Creation and Destruction?
The parent doesn't wait for the child to get started. It goes about its own business doing other stuff, maybe creating other children, until it gets the Supervise message byt the child. This is fully asynchronous, but you can still starve the parent by creating a huge number of children that registers and deregisters with it. The system messages are treated specially, and are processed before other messages. As I said, doing some benchmarking is the only real answer to your questions about how many actors are ok. B/ On 27 January 2015 at 13:49:06, Paul Cleary (pclear...@gmail.com) wrote: This is very useful information. So, in essence, does the parent block until the system message is received by the newly created child? Or, does the system message get put at the top of the mailbox, and the parent essentially receives it immediately? Thanks again for everyone's help, this is great. On Tuesday, January 27, 2015 at 5:27:08 AM UTC-5, Björn Antonsson wrote: Paul, The child will tell the Parent to supervise it by sending the Parent a system message. B/ On 26 January 2015 at 19:10:50, Paul Cleary (pcle...@gmail.com) wrote: Thanks Victor? Is the handshake through messages sent back and forth? On Monday, January 26, 2015 at 12:29:42 PM UTC-5, √ wrote: Hi Paul, you may want to put the parent on a different dispatcher than the children, since the creation process is a handshake. (so both parent and child needs CPU time) On Mon, Jan 26, 2015 at 5:49 PM, Paul Cleary pcle...@gmail.com wrote: Victor, Yes, they are spawned under the same parent (same actual actor ref). The parent is long-lived, i.e. intended to hang around for the lifetime of the process. On Monday, January 26, 2015 at 11:14:40 AM UTC-5, √ wrote: Hi Paul, There's also the question if they are spawned under the same parent or not. On Mon, Jan 26, 2015 at 5:07 PM, Paul Cleary pcle...@gmail.com wrote: Thank your for the reply, These machines are typically 4 core / 8 GB machines with only our app running. The only JVM settings are CMS and Parallel Young Generation. Also Java 1.7, Scala 2.11, Play 2.3. We have not benchmarked the actors themselves, as there are several actors in the system. The other actors are more permanent, with the FSM actor being the short lived one. My question was more of, is there guidance (JVM or Akka tuning, vm specs) in this scenario w.r.t. to VM sizing / JVM args based on a 50,000 or 100,000 actor per second kind of model? The benchmark is an interesting idea. I could write an alternative implementation that did not use FSMs are actors at all, and then run our perf tests to see what the impact would be. On Monday, January 26, 2015 at 8:24:54 AM UTC-5, Björn Antonsson wrote: Hi Paul, There are a lot of moving parts in creating an actor, and the associated costs. What is a lot of garbage? It's a completely subjective question. Also, depending on the size of your machine, 5 actors per second might be easy, or not possible. Have you tried to benchmark the creation of your actors? B/ On 21 January 2015 at 14:35:53, Paul Cleary (pcle...@gmail.com) wrote: I have an application where we are creating and destroying a lot of actors. The amount of actors that are created is tied to the volume of requests on the application. I am using FSM for the Actor in question here. I do not fully understand what is involved with the setup / teardown of an individual actor, so that is part of the motivation for the question. Is it reasonable to be creating 10s of thousands of these FSM instances per second (say 50,000 actors create and destroyed every second)? Is there an upper limit that I should look at? Will this result in a lot of garbage? Thanks for the help! -- 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 – Reactive Apps on the JVM twitter: @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+...@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
Re: [akka-user] Acceptable Limits for Actor Creation and Destruction?
This is very useful information. So, in essence, does the parent block until the system message is received by the newly created child? Or, does the system message get put at the top of the mailbox, and the parent essentially receives it immediately? Thanks again for everyone's help, this is great. On Tuesday, January 27, 2015 at 5:27:08 AM UTC-5, Björn Antonsson wrote: Paul, The child will tell the Parent to supervise it by sending the Parent a system message. B/ On 26 January 2015 at 19:10:50, Paul Cleary (pcle...@gmail.com javascript:) wrote: Thanks Victor? Is the handshake through messages sent back and forth? On Monday, January 26, 2015 at 12:29:42 PM UTC-5, √ wrote: Hi Paul, you may want to put the parent on a different dispatcher than the children, since the creation process is a handshake. (so both parent and child needs CPU time) On Mon, Jan 26, 2015 at 5:49 PM, Paul Cleary pcle...@gmail.com wrote: Victor, Yes, they are spawned under the same parent (same actual actor ref). The parent is long-lived, i.e. intended to hang around for the lifetime of the process. On Monday, January 26, 2015 at 11:14:40 AM UTC-5, √ wrote: Hi Paul, There's also the question if they are spawned under the same parent or not. On Mon, Jan 26, 2015 at 5:07 PM, Paul Cleary pcle...@gmail.com wrote: Thank your for the reply, These machines are typically 4 core / 8 GB machines with only our app running. The only JVM settings are CMS and Parallel Young Generation. Also Java 1.7, Scala 2.11, Play 2.3. We have not benchmarked the actors themselves, as there are several actors in the system. The other actors are more permanent, with the FSM actor being the short lived one. My question was more of, is there guidance (JVM or Akka tuning, vm specs) in this scenario w.r.t. to VM sizing / JVM args based on a 50,000 or 100,000 actor per second kind of model? The benchmark is an interesting idea. I could write an alternative implementation that did not use FSMs are actors at all, and then run our perf tests to see what the impact would be. On Monday, January 26, 2015 at 8:24:54 AM UTC-5, Björn Antonsson wrote: Hi Paul, There are a lot of moving parts in creating an actor, and the associated costs. What is a lot of garbage? It's a completely subjective question. Also, depending on the size of your machine, 5 actors per second might be easy, or not possible. Have you tried to benchmark the creation of your actors? B/ On 21 January 2015 at 14:35:53, Paul Cleary (pcle...@gmail.com) wrote: I have an application where we are creating and destroying a lot of actors. The amount of actors that are created is tied to the volume of requests on the application. I am using FSM for the Actor in question here. I do not fully understand what is involved with the setup / teardown of an individual actor, so that is part of the motivation for the question. Is it reasonable to be creating 10s of thousands of these FSM instances per second (say 50,000 actors create and destroyed every second)? Is there an upper limit that I should look at? Will this result in a lot of garbage? Thanks for the help! -- 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+...@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,
