Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 20:17
    Aaronontheweb synchronize #4154
  • 20:09
    Aaronontheweb synchronize #4154
  • 19:31
    Aaronontheweb commented #4128
  • 19:27
    Aaronontheweb synchronize #4128
  • 19:05
    Aaronontheweb synchronize #4128
  • 18:45
    Aaronontheweb commented #3893
  • 18:44
    Aaronontheweb closed #3893
  • 18:32

    Aaronontheweb on git-ignore-api-approval

    (compare)

  • 18:32

    Aaronontheweb on dev

    Add unneeded API Approval outpu… (compare)

  • 18:32
    Aaronontheweb closed #4155
  • 18:16
    Aaronontheweb synchronize #4128
  • 18:15
    Aaronontheweb opened #4155
  • 18:15

    Aaronontheweb on git-ignore-api-approval

    Add unneeded API Approval outpu… (compare)

  • 17:56
    Aaronontheweb synchronize #4154
  • 17:45
    Aaronontheweb synchronize #4154
  • 17:40
    Aaronontheweb synchronize #4154
  • 17:33
    Aaronontheweb synchronize #4154
  • 17:32
    Aaronontheweb opened #4154
  • 16:15
    Aaronontheweb commented #4126
  • 15:12
    IgorFedchenko opened #4153
Tamir Dresher
@tamirdresher
i can't figure out why. i tried using Tell() instead of Ask() but it still fails
Martin Helmer
@helmerm

Hi. I have problems with the synchronized-dispatcher. I want to create UI actors dynamically from a background thread. However the TaskSchedulerExecutor uses the TaskScheduler.FromCurrentSynchronizationContext() which is not available in the background thread and causes a "The current SynchronizationContext may not be used as a TaskScheduler." exception.

I tried to create my own Dispatcher implementation, so that I can just safe the TaskScheduler at startup. However, it seems like the necessary stuff is internal and I can not do what I want.

Any suggestions, how I can set the TaskScheduler at startup?

dandago
@dandago
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
@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
@dandago that was literally a messaging system I developed for Win32
based on what MarkedUp's business did
Tamir Dresher
@tamirdresher
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
@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
Thanks. I'll check
Aaron Stannard
@Aaronontheweb
can only happen if the thread is killed as part of a process restart or the Actor system is shutting down
Tamir Dresher
@tamirdresher
The ActorSystem is running or a dedicated process
Sorry, meant to say: on a dedicated process
to11mtm
@to11mtm
@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
@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
so typical Static actorsystem instantiated on application_start or similar?
Tamir Dresher
@tamirdresher
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
and -same- message works fine on on first try, fails on second?
Tamir Dresher
@tamirdresher
yes
and what i did find is that the message is being forwarded to another actor
unlike the others
to11mtm
@to11mtm
Interesting. one other question for a good picture; are you using Json or Wire for serialization?
Tamir Dresher
@tamirdresher
Wire
to11mtm
@to11mtm
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
right :-) i'll try that and then update. Thanks!
to11mtm
@to11mtm
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
@to11mtm After changing to Json, everything works as expected
to11mtm
@to11mtm
YAY I WAS HELPFUL!
Tamir Dresher
@tamirdresher
Absolutely :-)
to11mtm
@to11mtm
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
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
i think you mean this: akka { actor { serialize-messages = on } }
i'll check
to11mtm
@to11mtm
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
@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