Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 03 22:24
    huzaifak opened #4367
  • Apr 03 21:45
    Aaronontheweb commented #4344
  • Apr 03 05:55
    Lutando commented #4344
  • Apr 02 17:23
    huzaifak commented #4303
  • Apr 02 17:23
    huzaifak closed #4303
  • Apr 02 02:13
    ShawnYun commented #4366
  • Apr 01 17:18
    huzaifak commented #4303
  • Apr 01 14:30
    Aaronontheweb commented #4366
  • Apr 01 14:29
    Aaronontheweb closed #4360
  • Apr 01 14:29
    Aaronontheweb commented #4360
  • Apr 01 06:43

    dependabot-preview[bot] on nuget

    (compare)

  • Apr 01 06:43
    dependabot-preview[bot] closed #151
  • Apr 01 06:43
    dependabot-preview[bot] commented #151
  • Apr 01 06:43
    dependabot-preview[bot] labeled #152
  • Apr 01 06:43
    dependabot-preview[bot] opened #152
  • Apr 01 06:43

    dependabot-preview[bot] on nuget

    Bump AkkaVersion from 1.4.1 to … (compare)

  • Apr 01 06:43

    dependabot-preview[bot] on nuget

    (compare)

  • Apr 01 06:43
    dependabot-preview[bot] closed #125
  • Apr 01 06:43
    dependabot-preview[bot] commented #125
  • Apr 01 06:43
    dependabot-preview[bot] labeled #127
Weston
@ronnyek
Eg are schedules for the send repeatedly persisted... Or just per session of actor system
Bartosz Sypytkowski
@Horusiath
@ronnyek they are not persisted. This can be done using 3rd party libs like Quartz.NET
Weston
@ronnyek
OK yeah I just didn't know if that sort of thing was advisable.... I've got a system I want to build that would go out and talk to web services po n regular scheduled intervals
Bartosz Sypytkowski
@Horusiath
akka scheduler is designed to frequent small intervals, but if you need something more specialized, quartz will be good (there is actually akka-quartz-scheduler extension on JVM side AFAIK)
Kevin McFarlane
@kevinmcfarlane
Guys, why am I getting a timeout failure with this NUnit test?
var actor = Sys.ActorOf(Props.Create(() => new ZipActor()));
string path = "some path";

actor.Tell(new ZipMessage(path));

var message = ExpectMsg<ZipMessage>();
Tom Rathbone
@chillitom
..
mph911
@mph911
@skotzko :clap: for the TestKit Stuff
John Nicholas
@MrTortoise
@kevinmcfarlane ask on stack overflow. You would need to post the code of zip actor also (or face the wrath of vote downs) ... The only answer anyone here can give from what you have posted is ... because your expect fails.
Tom Rathbone
@chillitom
with PersistentViews is there any progress on the "reactive streams" front? Be great to have event triggered views.
Weston
@ronnyek
so schedulers are somewhat pluggable? Eg, I could write an equivalent akkaquartsscheduler for the .net side?
Aaron Stannard
@Aaronontheweb
@Horusiath happy birthday buddy
Aaron Stannard
@Aaronontheweb
and thanks for the PR -taking a look at it
I'll do a test publish on my local machine with our MyGet credentials and see if it aligns with what we currently do
Aaron Stannard
@Aaronontheweb
@ronnyek yep, they're pluggable - the Akka.TestKit stuff we published last Friday shows an example of how to swap out a scheduler
however, it should be noted that schedulers are intended to be temporal and local in Akka.NET
it's meant for regularly recurring short jobs
not for long-running, durable jobs
i.e. the weekly ETL
the Akka.NET scheduler is meant for "send a copy of this message once every 100ms"
https://petabridge.com/blog/akka-testkit-introduction/ - scroll to the very bottom for an example
"How do I test scheduled messages?"
Bartosz Sypytkowski
@Horusiath
@kevinmcfarlane if I'm right you're trying to check if ZipMessage has reached ZipActor, right?
If so, you need to know, that this is not what ExpectMsg is made for. What it's made for is testing if messages reach mailbox of the TestActor, not your custom actors
@chillitom we need reactive streams first ;)
Kevin McFarlane
@kevinmcfarlane
Bartosz Sypytkowski
@Horusiath
@kevinmcfarlane just like I said, you didn't quite understood what ExpectMsg is made for
don't test if message has reached an actor - if you do, you actually test the framework, not your code ;)
Bartosz Sypytkowski
@Horusiath
instead test behavior of actor itself - activate it's behavior trough message and assert side effects or messages, it generated in return. This is what ExpectMsg was made for
Amon-Ra Mackie
@nevaenuf
Got a question concerning supervisor strategies. Does anyone know how to get access to the message that causes a failure without creating a wrapper exception and trapping the message?
Bartosz Sypytkowski
@Horusiath
@nevaenuf you probably can't unless you pack it inside message itself. Parent actor doesn't need to be aware of every message coming to it's children. What do you need it for?
Amon-Ra Mackie
@nevaenuf
@Horusiath the message contains information that I use for logging when a child actor fails. Also, the child actor represents a unit of work that I need to report on to give the user an opportunity to restart if they so desire. I could trap the exception, tell to sender, and throw as well, but didn't know if that's the best strategy.
Aaron Stannard
@Aaronontheweb
@nevaenuf hmm... you could design a custom SupervisionStrategy that reads state from the exception object, and you could include the message that triggered the exception as part of that state
Bartosz Sypytkowski
@Horusiath
In general supervision strategies are used solely to tell child, what to do.
You can log error on actor level itself. When it comes to restarts, you can order actor to send back some dedicated failure message in PreRestart or PostStop method.
Amon-Ra Mackie
@nevaenuf
@Horusiath, that seems to conflict with the advice @Aaronontheweb just gave. Should we not be logging or performing
Bartosz Sypytkowski
@Horusiath
i.e. PreRestart has access to both exception and message
Amon-Ra Mackie
@nevaenuf
@Horusiath , rat's i just hit enter instead...
Cool. That's what I wanted to know. So if I wanted to stop the child, I should send a poison pill to the child in the PreRestart after logging the exception?
Bartosz Sypytkowski
@Horusiath
I shared my opinion ;) usually there is more than one way to solve the problem, and it's up to you to figure out what is working
Amon-Ra Mackie
@nevaenuf
Yeah, I'm new to this system, so I'm trying to go for best practices. But I appreciate the help!
Bartosz Sypytkowski
@Horusiath
PreRestart is called when child will be restarted, but not stopped.
Amon-Ra Mackie
@nevaenuf
@Horusiath @Aaronontheweb Thanks guys. I'm going with the simple approach and packing the message inside an exception. Seems the easiest way and more importantly, the most expected way to use the framework for a bunch of newbies.
Darren Ford
@4deeptech
@trbngr I'm interested in your ARM templates for the EventStore cluster. Do you have those out somewhere?
Bartosz Sypytkowski
@Horusiath
I feel, that I need to show off my new version of API for Akkling (my fork of Akka F# API, that adds new style and compile type checking for messages passed through actor refs) - examples are here and they look pretty sweet. I'm esspecially proud of totally new API for persistence.
Weston
@ronnyek
I feel like f# could have been better with a better syntax
Aaron Stannard
@Aaronontheweb
off-topic - anyone know somebody at JetBrains? Spent 10 hours today re-imaging our build agents over and over again when this was the issue the entire time: https://devnet.jetbrains.com/thread/473684
can't run more than 1 cloud agent at a time with VS2015 until that issue gets fixed - looks like the agent is reading the build server ID out of the build image and not the actual instance metadata
Tom Rathbone
@chillitom
@Horusiath Akkling examples look good, being a fork can I assume it implements all the features of the existing F# api?
Bartosz Sypytkowski
@Horusiath
@chillitom I'm not sure if all of them were necessary. In general it should allow for everything, that original F# API allowed (at least in Akka.NET context), but it's done differently in many cases. After my yesterday changes next version of Akkling won't be API-compatible with Akka.FSharp
in case of persistence, Akkling.Persistence it's both a lot simpler and allows to do a lot more than original Akka.FSharp.Persistence