These are chat archives for akkadotnet/akka.net

18th
Dec 2016
dandago
@dandago
Dec 18 2016 09:21
Aaron wrote: "all of our Win32 messaging clients work via HTTP polling since there’s a number of tricky permissions issues related to keeping an open socket in the background on each version of Windows (a subject for a separate blog-post.)" -- in this blog post: http://www.aaronstannard.com/markedup-akkadotnet/
any idea what he's talking about?
Arjen Smits
@Danthar
Dec 18 2016 17:24
@dandago you would have to ask @Aaronontheweb about that
@helmerm Why are you creating your actors on a background thread ?
why not create one coordinator actor on the synchronized-dispatcher, send your messages there, and let the coordinator create your UI actors where needed ?
or create your UI actors on system startup if they are basically top level actors that are meant to always be there ?
Aaron Stannard
@Aaronontheweb
Dec 18 2016 18:49
@dandago that was literally a messaging system I developed for Win32
based on what MarkedUp's business did
Tamir Dresher
@tamirdresher
Dec 18 2016 19:13
Hi @Aaronontheweb do you have any clue what could be causing the problem i described here: https://gitter.im/akkadotnet/akka.net?at=5855028b7a3f79ef5d68c890
?
Aaron Stannard
@Aaronontheweb
Dec 18 2016 19:14
@tamirdresher weird, no idea why - probably has nothing to do with Ask
keep an eye on whether or not IIS is restarting the process - had issues at application startup when I'm using SignalR + ASP.NET + IIS where the process restarts within the first ~20 seconds of application startup
and this is an IIS issue
the reason you're seeing that error is because the transport thread is being aborted
Tamir Dresher
@tamirdresher
Dec 18 2016 19:15
Thanks. I'll check
Aaron Stannard
@Aaronontheweb
Dec 18 2016 19:15
can only happen if the thread is killed as part of a process restart or the Actor system is shutting down
Tamir Dresher
@tamirdresher
Dec 18 2016 19:18
The ActorSystem is running or a dedicated process
Sorry, meant to say: on a dedicated process
to11mtm
@to11mtm
Dec 18 2016 19:44
@tamirdresher What about the call itself from the ASP net app to said actorsystem? how is that being done?
I know I've sen that at some point, trying to remember the how/why
Tamir Dresher
@tamirdresher
Dec 18 2016 19:46
@to11mtm the ActorSystem is created when the application boots, and then upon the user action, it sends a message by using ActorSystem.ActorSelection(...)
to11mtm
@to11mtm
Dec 18 2016 19:47
so typical Static actorsystem instantiated on application_start or similar?
Tamir Dresher
@tamirdresher
Dec 18 2016 19:47
all the other messages that are sent are handled without a problem, but somehow, for some reason, this specific message causes the system to fault.
yes
exactly
to11mtm
@to11mtm
Dec 18 2016 19:51
and -same- message works fine on on first try, fails on second?
Tamir Dresher
@tamirdresher
Dec 18 2016 19:52
yes
and what i did find is that the message is being forwarded to another actor
unlike the others
to11mtm
@to11mtm
Dec 18 2016 19:53
Interesting. one other question for a good picture; are you using Json or Wire for serialization?
Tamir Dresher
@tamirdresher
Dec 18 2016 19:54
Wire
to11mtm
@to11mtm
Dec 18 2016 19:58
I'd suggest MAYBE trying Json.NET, if only because once in a while I've had some issues with the current version of wire still has some edge cases that come up. I've seen errors like that when we send types over that Wire can't handle, but usually there's more stack trace to go with it. Can't say with much confidence given the amount of data I'm looking at, but it's easy to try right? =)
Tamir Dresher
@tamirdresher
Dec 18 2016 19:58
right :-) i'll try that and then update. Thanks!
to11mtm
@to11mtm
Dec 18 2016 19:58
NP. also curious about the 'forwarded to another actor' part
I'm bored on a sunday, may as well try to help somebody lol
Tamir Dresher
@tamirdresher
Dec 18 2016 20:01
@to11mtm After changing to Json, everything works as expected
to11mtm
@to11mtm
Dec 18 2016 20:02
YAY I WAS HELPFUL!
Tamir Dresher
@tamirdresher
Dec 18 2016 20:03
Absolutely :-)
to11mtm
@to11mtm
Dec 18 2016 20:05
You may want to place a ticket describing some of the issue (a test or even sample is immeasurably helpful) at https://github.com/akkadotnet/Hyperion/issues
Hyperion is the fork of Wire that will be used in further Akka releases, so that's the best place to have the issue tracked.
generally speaking however, Make sure anything you serialize is concrete-typed if you can (i.e. don't use Interfaces on messages, don't slam an arbitrary IEnumerable<> into an object field; instead do a ToList() on it first so there's a well known type on both ends)
(Because -that's- how I've seen that error before =D)
to11mtm
@to11mtm
Dec 18 2016 20:14
Someone who knows more than me please confirm: There's an option in HOCON to serialize all messages. IFF I understand that correctly, that can help detect some serialization errors before they go across remoting and that can help troubleshoot, they will get published to the eventstream.
Keep in mind that you're going to have a perf penalty when doing that, so it's best used for trobleshooting scenarios.
Tamir Dresher
@tamirdresher
Dec 18 2016 20:18
i think you mean this: akka { actor { serialize-messages = on } }
i'll check
to11mtm
@to11mtm
Dec 18 2016 20:20
I think that's the one, you can see where it pushes errors to eventstream in the catch of this region: https://github.com/akkadotnet/akka.net/blob/dev/src/core/Akka/Actor/ActorCell.cs#L310
also note that if the serialization 'fails' things will still work local, so the eventstream is still the go to
Arjen Smits
@Danthar
Dec 18 2016 22:02
@to11mtm you are correct about the serialize-messages option. That is a good way to detect serialization issues.
to11mtm @to11mtm is just glad he learned something from the groking