Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:04
    nagytech opened #4148
  • Jan 17 14:08
    IgorFedchenko commented #4126
  • Jan 17 14:07
    IgorFedchenko synchronize #4126
  • Jan 17 01:36
    dependabot-preview[bot] synchronize #3985
  • Jan 17 01:36

    dependabot-preview[bot] on nuget

    Bump FsCheck.Xunit from 2.9.0 t… (compare)

  • Jan 17 01:36
    dependabot-preview[bot] edited #3985
  • Jan 17 01:36
    dependabot-preview[bot] synchronize #4066
  • Jan 17 01:36

    dependabot-preview[bot] on nuget

    Bump FSharp.Quotations.Evaluato… (compare)

  • Jan 17 01:36
    dependabot-preview[bot] synchronize #3986
  • Jan 17 01:36

    dependabot-preview[bot] on nuget

    Bump NUnit from 3.6.1 to 3.12.0… (compare)

  • Jan 17 01:36
    dependabot-preview[bot] edited #4066
  • Jan 17 01:36
    dependabot-preview[bot] edited #3986
  • Jan 17 01:35
    dependabot-preview[bot] edited #3986
  • Jan 17 01:35
    dependabot-preview[bot] edited #3985
  • Jan 17 01:35
    dependabot-preview[bot] edited #4066
  • Jan 17 01:34

    dependabot-preview[bot] on nuget

    (compare)

  • Jan 17 01:34

    dependabot-preview[bot] on dev

    Bump System.Configuration.Confi… (compare)

  • Jan 17 01:34
    dependabot-preview[bot] closed #4131
  • Jan 17 00:01
    dependabot-preview[bot] synchronize #4131
  • Jan 17 00:01
    dependabot-preview[bot] synchronize #4066
Roger Johansson
@rogeralsing
  1. because of friction, json.net is pretty much the only serializer that allows serializing messages of any shape or form by default w/o altering constructors, adding attributes or interfaces
and for surrogates, surrogate support is mandatory as ActorRef needs special handling to be resolved into a real actorref.. and it can be embedded deeply inside another message
I do want to get rid of Json.NET, but most other serializers lack some features
e.g. polymorphic serialization
Bartosz Sypytkowski
@Horusiath
and what about 2nd? Don't you think we should add a globally configurable HOCON option for this? I think it's very risky that now we don't have any kind of timeout configured by default. It's not safe, if user forgot at any point to set receive timeout, his/her service could possibly hang forever
Roger Johansson
@rogeralsing
Im not following here, you mean a timeout for the receive method? I thought you were talking about ReceiveTimeout, the callback feature for actors
if you mean a way to ensure that no receive method runs forever.. I have looked into this, but there is no fast way to deal with it. there would need to be some supervisor thread that polls that no thread have been executing a receiveblock for too long
Roger Johansson
@rogeralsing
there is a dispatcher setting "deadlinetime" which decides for how long each mailbox run may run, but that does not deal with frozen/zombie threads. it only decied when the mailbox run should exit a batch op
During the very early stages of akka.net, I put together this: https://gist.github.com/rogeralsing/8472797 it does what you want, but expensive, and the implementation would beed to be cleaned
Bartosz Sypytkowski
@Horusiath
it think that the most common case is Ask - AFAIK it doesn't have any timeout by default
Michal Franc
@michal-franc
there is no default timeout i just crashed my VS because of that, due to infinite ncrunch test running and running :)
Roger Johansson
@rogeralsing
thats pretty much the same as for any code. you cant make a function break after x time in oop either
Dave Bettin
@dbettin
I plan on using Akka.net; Is it a terrible idea to read Akka in Action? I am concerned it will lead me down a path of confusion.
Roger Johansson
@rogeralsing
No, its a great book, actually I'm reading it right now, halfway through and everything applies except for the special Scala specific stuff like their Future library
Dave Bettin
@dbettin
Perfect! Thanks!
Bartosz Sypytkowski
@Horusiath
is there any way to override actor system settings after it's created?
Bartosz Sypytkowski
@Horusiath
I've got a lot freakin problems with persistence specs, when I run them one by one, it's all ok, when I run then all at once, a random failures occurs almost everytime
Roger Johansson
@rogeralsing
Depends on what settings you want to change. the core settings are parsed only once at start up, but you can inject top level fallbacks (you do that in f# module, right?)
Bartosz Sypytkowski
@Horusiath
@rogeralsing nope, just for some specs (I've noticed that one of my tests using TestLatches was hanging when message serialization was turned on)
but eventually I just moved it to separate spec class
Roger Johansson
@rogeralsing
I've seen a similar problem before, back then, it was that some static resources, like NoRouter or DefaultDeploy or whatver, was overwritten by the serializer .. e.g. some primitives took a static resource as an input argument, then the serializer overwrote the properties of the primitive, which was backed by the static resource, and tada , the static resource was corrupted
could that be a similar problem here?
e.g. public Props() : this(Some.Static.Resource) {} then when the deserializer tried to deserialize an object with such ctor, the injected resource would be corrupted
Bartosz Sypytkowski
@Horusiath
I know that test latch uses System.Threading.CountdownEvent so I supose it may be not safe to try to serialize/deserialize it
Roger Johansson
@rogeralsing
were you passing a testlatch object as a message?
Bartosz Sypytkowski
@Horusiath
I have to for test verification ;)
Roger Johansson
@rogeralsing
and if so, shouldnt that be marked with the INoSerializationNeeded or whatever the name
NoSerializationVerificationNeeded
that will ofc not help if the testlatch is part of a bigger message, but if it is the root, that would make it bypass serialization in inproc systems
Bartosz Sypytkowski
@Horusiath
it worked, I didn't know about that interface
Roger Johansson
@rogeralsing
its in the scala version too
neat :) so for persistence, we just need to start making providers? and follow typesafes lead on how to take it out of beta (?)
Bartosz Sypytkowski
@Horusiath
not all of exisiting tests are passing yet (6 out of 82 total are marked to be skipped, I need to fix them probably)
beside that, I'm currently during writing some tutorial about how to write custom persistence plugins
Roger Johansson
@rogeralsing
So what probiders do you think are the most important ones? SqlServer, different Azure storages, flat file?
Bartosz Sypytkowski
@Horusiath
also I'm in midway of creating Akka.Persistence.SqlServer plugin
Roger Johansson
@rogeralsing
:+1:
Bartosz Sypytkowski
@Horusiath
those two definitely yes, snapshot store for local file system already exists (I've rewritten it <not pushed yet>). I don't know if some other providers should be included to akka.net core repository
but I think, that @Aaronontheweb or @jcwrequests may want to try to implement Cassandra plugins for Akka.Persistence
I also hope, that when it will be ready to drop -Pre flag, RavenDB and EventStore creators will want to integrate their services too
jcwrequests
@jcwrequests
@horusiath
jcwrequests
@jcwrequests
@horusiath is your SQL code on your Akka fork? I think it would be a good idea to write them for Cassandra, mongo, postgres and maybe foundation db. I think that the focus should be on the high write throughput DBs. @arronontheweb might have some during opinions about ravendb 😊.
Bartosz Sypytkowski
@Horusiath
@jcwrequests if you want to start, my sqlserver fork is not what you want (at least for now). Right now I'm hardening Akka.Persistence.Tests (they are randomly failing right now, mostly due to timeouts) and making an Akka.Persistence.TestKit to work easier with. If everything goes right, they could be released soon and then I'll prepare tutorial about how to start persistence plugin development - right now I already have sample code, but it's not commented.
Natan Vivo
@nvivo
@all, general question: in which cases Akka doesn't own the threads it uses for actors? And are these scenarios recommended for production or just for testing?
Roger Johansson
@rogeralsing
By default we execute on the threadpool, so we don't own those threads.. we can also execute on the GUI thread with the synchronization context dispatcher if you want an actor that updates GUI elements. we dont own that thread either... then we have cases like the new threadpool, that can be used to give some actors a higher priority than the others, those threads are owned by whatever threadpool we use under the hood, but yes you could consider those owned threads I guess.. so we can execute ontop of whatever the current dispatcher decides to run the work on
but in short, akka never does anything to the threads, it just executes the mailbox run on whatever scheduling mechanism is there
Natan Vivo
@nvivo
@rogeralsing got it. thanks!
jcwrequests
@jcwrequests
@Horusiath Got it.
Stefan Sedich
@stefansedich
When using PipeTo and an exception is raised in the Task is it possible to get that to propogate up to an unhandled actor exception so that it goes to supervision?
Stefan Sedich
@stefansedich
@Aaronontheweb answered the above for me, it was too late in the day and I was derping a bit.