These are chat archives for akkadotnet/akka.net

24th
Jun 2015
Aaron Stannard
@Aaronontheweb
Jun 24 2015 00:34
got Mono CI to work for Helios
Andrew Skotzko
@skotzko
Jun 24 2015 00:34
w00t
Aaron Stannard
@Aaronontheweb
Jun 24 2015 00:34
unfortunately F# crashes, hard, on Mono whenever I try to create a NuGet package
[00:25:38][Step 1/1] Stacktrace:
[00:25:38][Step 1/1]
[00:25:38][Step 1/1]
[00:25:38][Step 1/1] at <unknown> <0xffffffff>
[00:25:38][Step 1/1] at FSI_0001.Build.removeDir@162 (string) <0x00027>
[00:25:38][Step 1/1] at FSI_0001.Build.createNugetPackages<a> (a) <0x00aff>
[00:25:38][Step 1/1] at FSI_0001.Build/clo@273-13.Invoke (Microsoft.FSharp.Core.Unit) <0x00013>
[00:25:38][Step 1/1] at Fake.TargetHelper/targetFromTemplate@145.Invoke (Microsoft.FSharp.Core.Unit) <0x00023>
[00:25:38][Step 1/1] at Fake.TargetHelper.runTarget@314 (string) <0x00182>
[00:25:38][Step 1/1] at Fake.TargetHelper/runTarget@314-1.Invoke (string) <0x00013>
[00:25:38][Step 1/1] at Microsoft.FSharp.Primitives.Basics.List.iter<T> (Microsoft.FSharp.Core.FSharpFunc2<T, Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Collections.FSharpList1<T>) <0x00049>
[00:25:38][Step 1/1] at Microsoft.FSharp.Collections.ListModule.Iterate<T> (Microsoft.FSharp.Core.FSharpFunc2<T, Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Collections.FSharpList1<T>) <0x0002f>
[00:25:38][Step 1/1] at Fake.TargetHelper.runTarget@314 (string) <0x000e7>
[00:25:38][Step 1/1] at Fake.TargetHelper.run (string) <0x00193>
[00:25:38][Step 1/1] at Fake.AdditionalSyntax.RunTargetOrDefault (string) <0x0004b>
[00:25:38][Step 1/1] at <StartupCode$FSI_0001>.$FSI_0001_Build$fsx.main@ () <0x00b3f>
[00:25:38][Step 1/1] at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
[00:25:38][Step 1/1] at <unknown> <0xffffffff>
[00:25:38][Step 1/1] at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&) <0xffffffff>
[00:25:38][Step 1/1] at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) <0x000d7>
[00:25:38][Step 1/1] at System.MonoType.InvokeMember (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[],System.Reflection.ParameterModifier[],System.Globalization.CultureInfo,string[]) <0x0043d>
[00:25:38][Step 1/1] at System.Reflection.Emit.TypeBuilder.InvokeMember (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[],System.Reflection.ParameterModifier[],System.Globalization.CultureInfo,string[]) <0x00069>
[00:25:38][Step 1/1] at System.Type.InvokeMember (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[],System.Globalization.CultureInfo) <0x0005c>
[00:25:38][Step 1/1] at Microsoft.FSharp.Compiler.AbstractIL.ILRuntimeWriter/execEntryPtFun@2116-1.Invoke (Microsoft.FSharp.Core.Unit) <0x00093>
[00:25:38][Step 1/1] at Microsoft.FSharp.Compiler.Interactive.Shell/clo@1026-248.Invoke (Microsoft.FSharp.Core.FSharpFunc2<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Core.FSharpOption1<System.Exception>>) <0x00022>
[00:25:38][Step 1/1] at Microsoft.FSharp.Primitives.Basics.List.iter<T> (Microsoft.FSharp.Core.FSharpFunc2<T, Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Collections.FSharpList1<T>) <0x00049>
[00:25:38][Step 1/1] at Microsoft.FSharp.Collections.ListModule.Iterate<T> (Microsoft.FSharp.Core.FSharpFunc2<T, Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Collections.FSharpList1<T>) <0x0002f>
[00:25:38][Step 1/1] at Microsoft.FSharp.Compiler.Interactive.Shell.arg10@1025 (Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompiler,Microsoft.FSharp.Collections.FSharpList1<Microsoft.FSharp.Core.FSharpFunc2<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Core.FSharpOption`1<System.Exception>>>,Microsoft.FSharp.Core.Unit) <0x00067>
[00:25:38][Step 1/1] at Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompiler.ProcessInputs (Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompilerState,Microsoft.FSharp.Collections.FSharpList1<Microsoft.FSharp.Compiler.Ast/ParsedInput>,bool,bool,bool,Microsoft.FSharp.Collections.FSharpList1<Microsoft.FSharp.Compiler.Ast/Ident>) <0x0084f>
[00:25:38][Step 1/1] at Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompil
crashed the mono runtime itself and created a core dump
pretty impressive
Roger Johansson
@rogeralsing
Jun 24 2015 07:07
Do we still have code that is monospecific?
except for cluster perfcounters
Marc Piechura
@marcpiechura
Jun 24 2015 09:33
@Aaronontheweb thx, I have moved the code from my akka port to the persistence fork. I could now create a pull request but maybe someone would like to take a look at the code before? This is my first contribution so I'm not so familiar with the procedure ;)
Bartosz Sypytkowski
@Horusiath
Jun 24 2015 09:37
@Silv3rcircl3 you could PR here, I could review it for you
Marc Piechura
@marcpiechura
Jun 24 2015 09:51
@Horusiath Great, I created the PR. Thx.
Geert Van Laethem
@GeertVL
Jun 24 2015 12:40
Hi all. I work the last few days with Akka.net and I probably have to look at Akka (and if so please point me in the right direction), I have a problem with my context. I have ActorA that searches for ActorB in his constructor with the Indentify(). ActorA and ActorB are created by using ActorOf on system level. When the constructor of ActorA has been done I do ActorA.Tell and in the Receive I do an Ask() on ActorB ==> Result = ActorA.Tell comes before Identify of ActorB and so it crashes. Is there a way to create both Actors and be sure all constructor events are done before a tell or something else is done?
Bartosz Sypytkowski
@Horusiath
Jun 24 2015 12:52
@GeertVL could you describe your intent a little bit more? I find hard to understand what you're trying to achieve
Arjen Smits
@Danthar
Jun 24 2015 12:54
@GeertVL dont do the receptionist.Tell(new Identify("111"), Self); in the constructor of the Guest actor. Do it in the part where you handle the enter message
Geert Van Laethem
@GeertVL
Jun 24 2015 12:55
Well the system creates ActorA and ActorB. ActorA selects ActorB. ActorA sends BadgeRequest to ActorB. ActorB sends Badge back to ActorA.
@Danthar do I need to put it in a task and wait for the result?
Arjen Smits
@Danthar
Jun 24 2015 12:56
it would help if you use the same names as you use in your gist. :P
Geert Van Laethem
@GeertVL
Jun 24 2015 12:56
ok
Arjen Smits
@Danthar
Jun 24 2015 12:56
so drop the ActorA and ActorB reference, its confusing
but why would you want to await that?
Geert Van Laethem
@GeertVL
Jun 24 2015 12:57
Well the system creates Guest and Receptionist. Guest selects Receptionist. Guest sends BadgeRequest to Receptionist. Receptionist sends Badge back to Guest.
like that?
Arjen Smits
@Danthar
Jun 24 2015 12:57
much better
bullocks was written here
Its better to identify yourselve with the receptionist in response to some action
Bartosz Sypytkowski
@Horusiath
Jun 24 2015 13:00
I'll try to make some simplified gist for that, a lot of your code seems to be unnecessary
Arjen Smits
@Danthar
Jun 24 2015 13:00
in this case, the "enter" message
and what @Horusiath says. There is alot of wierd stuff in that gist, that makes me wonder if you have done the bootcamp (?)
Geert Van Laethem
@GeertVL
Jun 24 2015 13:01
@Danthar mmm the documentation does it in the constructor. So that was confusing.
bootcamp?
Bartosz Sypytkowski
@Horusiath
Jun 24 2015 13:01
Arjen Smits
@Danthar
Jun 24 2015 13:01
where in the docs did you see that?
Bartosz Sypytkowski
@Horusiath
Jun 24 2015 13:03
you could to that in constructor eventually, but you should have clear reason to do so
paragraph Identifying Actors via Actor Selection
thanks for pointing me to the bootcamp I will do that.
Arjen Smits
@Danthar
Jun 24 2015 13:04
ah the follower thing.
corrected my previous statement
Bartosz Sypytkowski
@Horusiath
Jun 24 2015 13:07
@GeertVL with great simplification https://gist.github.com/Horusiath/e860791d298874f0f7db
Geert Van Laethem
@GeertVL
Jun 24 2015 13:08
thank you
Stuart Blackler
@sblackler
Jun 24 2015 14:25
Hey all, I'm experiencing a bit of a strange problem with my actor. It appears the mailbox backs up for a period of time before the actor begins processing. Any ideas on what could cause this? I have a receive time out that pumps a message to the said mailbox every 500ms. I have just witnessed this reach over 400 messages before beginning to process.
/cc @BenGale
Natan Vivo
@nvivo
Jun 24 2015 14:37
@sblackler this sounds like you have too much going on in your app and not enough threads. When messages have these jumps in processing time, it's because the scheduler cannot schedule that actor to run for some reason.
Stuart Blackler
@sblackler
Jun 24 2015 14:40
Hmm I would be very surprised if that is the case as this is happening before the core of our app has started. What makes it a pain is it happens intermittently so will see if I can get it to happen again and count the threads
Natan Vivo
@nvivo
Jun 24 2015 14:41
This may happen for a number of reasons and there are many solutions. But in essence, .net should spin a thread per core and akka by defaults uses that threadpool. if you have more actors than threads doing things simultaneously, some have to wait until the threadpool starts more threads and this causes these bumps. Another reason is that you're blocking too much and the threadpool is hitting the limit of threads, so work is piling up.
something I hit here ocasionally is that when debugging, by default VS uses 32bit processes. and that limits the # of threads to 1023
in 64bit, the number is much higher... so some problems happen only when debugging. you can change that in vs, but the default is 32bit
please note this is a very generic answer, but is the way to understand why this is happening
you can try to set specific dispatchers for some actors and see in the profiler is some actors are blocking. some things can be resolved by switching to async or pipeto
Stuart Blackler
@sblackler
Jun 24 2015 14:44
Currently have a messily 19 threads running
Natan Vivo
@nvivo
Jun 24 2015 14:45
how many cores do you have?
Stuart Blackler
@sblackler
Jun 24 2015 14:46
4 - 8 logical
Natan Vivo
@nvivo
Jun 24 2015 14:47
it's not a general rule, but if your app is not started and you already have 19 threads, you probably have a lot of blocking code. my experience is that this can easily scalate to thousand of threads under load, and that causes this kind of behavior
try using some custom dispatchers and limiting the # of messages some actors can handle per turn.
Stuart Blackler
@sblackler
Jun 24 2015 15:02
So i've just had quick look with regards any blocking that we are doing. 95% of our system is non-blocking using actor.tell. We do have a single section of code that runs actor.Ask().ContinueWith() but have confirmed that this section of code hasn't been hit during the current sessions as the preceding messages required to cause this to trigger have not been hit.
Would that TPL cause any weird behaviour before its ever hit? If it was after it had been hit i could understand the blocking etc
Natan Vivo
@nvivo
Jun 24 2015 16:02
@sblackler when I say blocking, I'm not talking about non-akka code. I'm talking about any code that holds the thread for more time than it requires.
if you do a database request or open a file, it blocks the thread for ages. Those things can be changed to use either async/await or pipe to. it doesn't matter which, as long as you avoid blocking. it has nothing to do with akka.
The way akka works is really simple. You send a message to an actor, and the dispathcer schedules that actor to run in the threadpool. if it is taking too long for it to run, it's because the threadpool is busy and things are being queued.
it's just a matter of adjusting the parameters. either make your code block less, or create custom dispatchers to isolate work that blocks for too long. or do both
it doesn't have to do with TPL. but any tasks you run will also run in the threadpool, so if you're starting lots of tasks, it will impact actors
Natan Vivo
@nvivo
Jun 24 2015 16:08
there are some docs explaining how to do that, it's quite simple actually: http://getakka.net/docs/working-with-actors/Dispatchers
Stuart Blackler
@sblackler
Jun 24 2015 16:17
Thanks for the information. Brain's completely fried trying to juggle multiple things at once, will re-read the above and review with my lead in the morning. Thanks again :)
Aaron Stannard
@Aaronontheweb
Jun 24 2015 18:02
AZURE question - I have not been able to RDP into any of my custom Windows VM images, including a custom image I made last night. This includes images that I've been able to re-hydrate onto IaaS VMs in the past and successfully RDP into. Has anything changed with the Azure platform recently that would stop me from being able to connect to custom windows images via RDP?
trying to resume work on my custom Akka.Persistence build server image, but now I can't get access to it to modify it :\
Aaron Stannard
@Aaronontheweb
Jun 24 2015 18:18
there we go, started randomly working again
Sean Gilliam
@sean-gilliam
Jun 24 2015 18:45

This was probably discussed during the exposing internal classes discussion months back, but I'm currently documenting the api-doc namespaces and noticed two very similar namespaces (Akka.Actor.Internal and Akka.Actor.Internals)

Internals only has two items (ActorSystemImpl and IInitializableActor) in the namespace. Just wondering if that was intentional or an oversight.

Aaron Stannard
@Aaronontheweb
Jun 24 2015 18:45
it's an oversight - anything in the Internals namespace is public but it's "use at your own risk"
i.e. we may change this without notice
well, not everything in the namespace is public - some of it is marked as internal
Sean Gilliam
@sean-gilliam
Jun 24 2015 18:47
that's what i gathered. thx. now back to documenting :)
Aaron Stannard
@Aaronontheweb
Jun 24 2015 18:47
@Horusiath LocalDB is not a feasible option for running CI for Akka.Persistence.SQLServer
all of the permissions stuff I set to make it run gets immediately blown away each time a new CI instance is brought online
going to rewrite the fixture to use a SQL express instance on the fly
Bartosz Sypytkowski
@Horusiath
Jun 24 2015 18:50
:+1: My gf took control over my comp. Bartek cannot into akka right now ;P
Aaron Stannard
@Aaronontheweb
Jun 24 2015 18:51
haha
no worries
I'm getting CI setup for MongoDB, PostGres, Cassandra, and SQL Server
Alex Achinfiev
@aachinfiev
Jun 24 2015 21:36
Hi. I have a question regarding increasing maximum-frame-size & send/receive-buffer-size values. Is there a limit on how high they can go? I am passing a large chunk of data into the system (say 20mb) which is then used to compute some results and return back. Setting above parameters at 100mb results in messages being dropped. The largest chunk that I could pass before this happens is about 5mb. I have tried to increase timeouts for connection and ack but it doesn't seem to make a difference. Any help is appreciated. Thank you.
Aaron Stannard
@Aaronontheweb
Jun 24 2015 22:42
@aachinfiev I recommend breaking up your messages into smaller chunks and accumulating them in an actor before you start your operation
sockets don't support arbitrarily large packet sizes, and even though TCP will break up a byte buffer into individual messages and sequence them this can cause problems at the OS and application level
it's kind of like doing this to the socket: http://farm1.staticflickr.com/200/493771942_10265ee799_z.jpg
that's a python eating an entire pig
better off breaking up messages into smaller chunks, apply your own sequencing and ordering onto them, and then reconstitute those objects on the read-side of the remote connection into whatever your final "ready to be processed" object looks like
Aaron Stannard
@Aaronontheweb
Jun 24 2015 22:48
as far as what the system can tolerate
Helios, the underlying socket server, is tested for 4MB payloads (that's considered to be a "large" socket message)
the other reason why it's a good idea to constrain the size of your messages at the application level - some transports have built-in maximum frame sizes
like UDP
if you try to write a 100mb datagram to a UDP socket the OS will just give you an error immediately
and never even attempt to send the message
TCP will write out the message as an array of bytes and sequence it out, but it can be difficult for the OS to reconstitute large payloads. On top of that Helios, the socket server, has to elastically expand its in-memory buffer to accommodate large messages
once it's seen a single 100mb message, it's going to always retain 100mb worth of buffer space in case it sees a second one that size
it uses a buffer growth algorithm that gradually expands the size of the buffer
at the moment it doesn't have any buffer implementations that reduce the buffer size during periods of lower use