These are chat archives for akkadotnet/akka.net

4th
Aug 2016
Boban
@bobanco
Aug 04 2016 00:41
@DELUXEnized Thanks man, it worked.
Corneliu
@corneliutusnea
Aug 04 2016 05:28
guys, should I try to intermix Akka processing with Tasks or should I try to stick to Akka and block when I have some longer op (e.g. network, sql calls) ?
I find it hard to mix Tasks and keep doing .ContinueWith() .. and most importantly it feels that my actors will might start other work thus a pool for 10 actors might process more than 10 messages at a time as they are stuck through Tasks
Vagif Abilov
@object
Aug 04 2016 05:44
@corneliutusnea that's a very interesting topic.
Initially I started with actors performing long operations synchronously, but I don't like actors being unresponsive. And what if I want to cancel that operation? No way until the actor completes it.
Vagif Abilov
@object
Aug 04 2016 05:51
So now I run long operations in a task. The only thing that doesn't work is detecting the mailbox queue. Smallest mailbox strategy doesn't work because I stash all new messages while the actor has a task to be completed, and stashed messages don't count when computing mailbox queue.
Corneliu
@corneliutusnea
Aug 04 2016 05:52
I agree, you can't easily cancel an operation (which with a Task you can) but I think it allows you to know exactly what each Actor does vs having actors "free" while they actually wait for heaps of Tasks to finish.
though question to answer: do I fill the mailbox queues or the Task Manager's queue with Tasks?
I guess I could make the actor have a pending state in which it waits for the Task to finish while still accepting a cancel so the actor looks busy. Just feels like an overdesign
Vagif Abilov
@object
Aug 04 2016 05:54
This is what I do.
Such actor has Idle and Pending state. In Idle state it accepts messages, in Pending state it stashes them and unstashes when the operation completes.
Doesn’t sound like overdesign to me but of course this is so common pattern that I'd rather have it baked in the fx. Which Akka kind of does but not in fully satisfactory way (because of actors losing responsiveness while being busy).
Aaron Stannard
@Aaronontheweb
Aug 04 2016 05:59
@object @corneliutusnea this is something I'm looking at Akka.Streams for myself
for something like web crawler, where I have lots of asynchronous tasks
namely I/O related ones
I like the idea of being able to buffer 10 at a time into a stream
and to act as a kind of throttle - it might be feasible to put a circuit breaker step inside the stream that can start cancelling tasks if a stop or kill signal is given
haven't looked into it enough yet, but I feel your pain
Vagif Abilov
@object
Aug 04 2016 06:02
@Aaronontheweb Didn't know that stream might address cancelation challenge.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:03
@object it might require a custom step to do it
which you can encapsulate into an actor
but your "task manager" in this instance
Vagif Abilov
@object
Aug 04 2016 06:03
Even with a custom step it would be worth it.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:03
would queue work onto a materialized stream instance that belongs exclusively to it
so it wouldn't be "blocking" while the work is done
since the stream is actually running in another actor
Vagif Abilov
@object
Aug 04 2016 06:04
Because currently I am reinventing the wheel every once in a while.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:04
I'd take a look at streams for that - a custom graph stage might be the right tool for that job
Vagif Abilov
@object
Aug 04 2016 06:05
But is this something that is possible to try out now?
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:05
yep
if you want a working streams example
here's the one I'm still working on
Vagif Abilov
@object
Aug 04 2016 06:06
Yes I do!
that's in my personal branch of WebCrawler
not quite done with it yet
but I'm basically getting rid of a bunch of routers and child actors
and expressing that workload as a stream
it runs slower than my old router setup did in terms of raw throughput, but I think that's because I set my throttle too aggressively
and it does all of that work with something like 1/20th the code I had before
Vagif Abilov
@object
Aug 04 2016 06:07
Cool! I definitely need to study this example.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:08
going to try to get it published next week
I'm in Australia at NDC Sydney this week
and my access to the Internet has been poor
Vagif Abilov
@object
Aug 04 2016 06:08
Because I feel I might also be able to get rid of bunch of utilizing code.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:09
finally caved and bought a prepaid SIM card on my phone; using that to try to upgrade our TeamCity instance now so @maxim-s and @annymsMthd can start playing around with using Docker to run our build agents (for Mono, Core CLR, and Akka.Persistence support)
yeah, Akka.Streams is very succinct
I am a big fan of it thus far
Vagif Abilov
@object
Aug 04 2016 06:09
How was NDC btw? Roger's Akka talk at NDC Oslo was very well received.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:09
we had a full house for the Akka.NET talk
very well received
Phil Laureano and his team at domain.au also gave a talk about how they're using Akka.NET in production to do grid computing
which was well-attended too
my NBench talk was less well-attended (gave it right after the Akka.NET one) but got great questions and feedback
Vagif Abilov
@object
Aug 04 2016 06:11
Great! I ran an Akka workshop at BuildStuff in Odessa, lots of interest.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:11
oh that's awesome!
I've heard great things about BuildStuff
that's Greg Young's conference right?
Vagif Abilov
@object
Aug 04 2016 06:11
Yes
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:12
were most of the people attending your workshop using Akka.NET already or were they totally new to it?
Vagif Abilov
@object
Aug 04 2016 06:12
Very good conference, just stuff no fluff :-)
Most of them were totally new. We ran overtime, almost 5 hours instead of 4. Programming in both C# and F# and comparing results in two languages.
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:17
very cool
I'm looking to build my next thing in F# with Akka.NET
time I learned how to do something other than edit a FAKE file
Corneliu
@corneliutusnea
Aug 04 2016 06:19
@Aaronontheweb you in Sydney? Nice. How long? I had plans to make it to NDC but I was in holidays until yesterday
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:19
I'm here through Saturday
Vagif Abilov
@object
Aug 04 2016 06:21
In fact use of Tasks in Akka.NET looks more smooth in F# than it is in C#.
But I hope that @Horusiath will merge his Akkling experimental branch into Akka.FSharp.
He has some great stuff there like message type checking.
Marc Piechura
@marcpiechura
Aug 04 2016 06:36
@object if you want to write some custom stages in streams you can take a look at my Azure stages https://github.com/Silv3rcircl3/Akka.Streams.Azure Only source and sink but you get an idea how you can use tasks within a stage and what you need to consider to not violate the reactive streams rules
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:43
@corneliutusnea you should definitely come by if you get the chance
Ricky Blankenaufulland
@ZoolWay
Aug 04 2016 06:44
Do you guys have any hints on debugging Akka.Cluster? My main problem is: When a breakpoint is hit, the nodes start to disassociate. Can I have them wait longer for that when a debugger is attached?
Kris Schepers
@schepersk
Aug 04 2016 06:45
Anyone an idea about the cause of a massive amount of errors like these?
2016-08-03 14:18:17.9634|ERROR|ARClass|Persistence failure when replaying events for persistenceId [ARClass@80bd0d47-eb9f-4a61-9671-64cc71fe3074]. Last known sequence number [0]|Akka.Pattern.OpenCircuitException: Circuit Breaker is open; calls are failing fast
at Akka.Pattern.Open.InvokeT
at Akka.Pattern.CircuitBreaker.<WithCircuitBreaker>d__32`1.MoveNext()
No persistence users in the house? :-)
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:45
which impl are you using?
Kris Schepers
@schepersk
Aug 04 2016 06:45
Sql Server
Vagif Abilov
@object
Aug 04 2016 06:46
@Silv3rcircl3 thanks Marc! I will certainly do!
Kris Schepers
@schepersk
Aug 04 2016 06:46
Right now we're thinking it could be that there is to much concurrent writing and reading going on..
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:47
just pushed the 1.1.1 bits for SQL Server now
Kris Schepers
@schepersk
Aug 04 2016 06:47
awesome!
many changes?
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:49
yeah, definitely
support for Akka.Persistence.Query
is the big one
Kris Schepers
@schepersk
Aug 04 2016 06:49
and the reloading of events uses that i guess?
Aaron Stannard
@Aaronontheweb
Aug 04 2016 06:49
let me check rq
list of fixes in 1.1
I would file a bug for this just in case
because it sounds like a concurrency issue in our end
i.e. trying to do something while the circuit breaker is open
Kris Schepers
@schepersk
Aug 04 2016 06:59
still using 1.0.8 where this error is occuring..
we're trying to reproduce this in a DEV environment, but getting hold of all the data is not that easy
Aaron Stannard
@Aaronontheweb
Aug 04 2016 07:07
definitely open an issue for it
include the error message and if at all possible let us know when / roughly how often it occurs
Kris Schepers
@schepersk
Aug 04 2016 07:16
Owkay, will do that later today!
Aaron Stannard
@Aaronontheweb
Aug 04 2016 07:22
rebooted the build server
having some trouble RDP-ing into it
and Azure isn't making it easy for me to recover my credentials
Kris Schepers
@schepersk
Aug 04 2016 07:24
Hmm, it seems that Sql Persistence has received a complete overhaul?
We're using a custom journal table now, but is that still possible?
Aaron Stannard
@Aaronontheweb
Aug 04 2016 07:24
yeah the 1.1 changes were significant
should be but I'm not 100% sure
cc @alexvaluyskiy @Horusiath
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:15
finally - got the migration running on our TeamCity box
migrating all of our data to an external SQL Azure database
going to do that followed by an upgrade to TeamCity 10
build server will be offline until the migration is finished
might take a few hours
pretty excited for TeamCity 10 - the docker support in it seems pretty neat
have a new ARM resource group which is going to act as a Docker driver
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:20
lol the table for all of our unit test records has 3.2 million records in it that need to be exported
hope I don't run into a throttling problem with SQL Azure
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:34
Not really an Akka.NET question, but I have some general concerns about event sourcing as a concept that maybe someone has some input on. In my use case I will have a lot of events to store if going with event sourcing. I just ran some relatively small load tests with Akka.Persistence hooked up to a Redis Cache in Azure and filled up a small basic cache of 250 MB really quick. So I wonder what approaches others use were the number of events to persist are expected to be large. Are snapshots + clearing old events a way to go? I haven't used event sourcing before and I am quite new to the concept, but it feels like at some point storing all events gets infeasible? Any thoughts on this from people who are using event sourcing in combination with transaction intense systems?
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:35
Are snapshots + clearing old events a way to go? I haven't used event sourcing before and I am quite new to the concept, but it feels like at some point storing all events gets infeasible?
yep
at some point you don't want to rebuild an object from its entire history
so you compress a portion of the history into a snapshot
and discard the old events
since they're not needed any longer
it comes down to this
what's faster? rebuilding an object from 10 million 10 byte events or rebuilding that object from 1 100mb event?
Kris Schepers
@schepersk
Aug 04 2016 08:37
Hmm, when using event sourcing in it's purest way, NEVER EVER delete events..
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:37
in truth snapshots typically compress that data set
Kris Schepers
@schepersk
Aug 04 2016 08:37
Unless you really don't need them ever again
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:37
the event doesn't really get "deleted"
it just gets materialized into a snapshot of the current state of the object
Kris Schepers
@schepersk
Aug 04 2016 08:38
When you delete "old" events your will never be able to e.g. rebuild a projection or create a new projection
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:38
it eliminates your ability to fully travel back to each possible state that object could have ever been in
Arjen Smits
@Danthar
Aug 04 2016 08:39
discarding the old events, as @Aaronontheweb explained it was a misnomer. By creating an snapshot in akka.net you dont delete the old events.
So you dont lose the ability to replay the entire stream.
Kris Schepers
@schepersk
Aug 04 2016 08:40
indeed, snapshotting doest not mean deleting events..
Arjen Smits
@Danthar
Aug 04 2016 08:40
he meant the same thing though ;)
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:40
if space were a concern I would delete events that were already materialized into a snapshot
Kris Schepers
@schepersk
Aug 04 2016 08:41
but I thought @peter-bannerflow was suggesting just that
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:41
You mean that the snapshot is created, while still retaining all the events prior to the snapshot?
Since that wouldn't clear up any space, which is the issue...
Arjen Smits
@Danthar
Aug 04 2016 08:41
@peter-bannerflow yes that is was happens.
Kris Schepers
@schepersk
Aug 04 2016 08:41
@peter-bannerflow indeed, events should never be deleted (or changed)
but that's exactly your issue :-)
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:42
I disagree @schepersk - it totally depends on what your read model allows
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:42
So I guess it wouldn't really be "pure" eventsourcing but for practical reasons it could be considered..
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:42
if you have a purely monotonic model, i.e. you can't go back in time
deleting events that are already included in a snapshot is safe and fine
(obviously that limits a bunch of the value you get from event sourcing in the first place though)
Kris Schepers
@schepersk
Aug 04 2016 08:43
@Aaronontheweb agreed, but that totally depends on your domain model..
true!
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:44
Yeah, I guess it would take away some of the nice features but in my use case I don't think it ever will be practical to store all events from the beginning of time in the system
Kris Schepers
@schepersk
Aug 04 2016 08:44
maybe CRUD is better suited for those domains
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:45
I'm a bit of a pragmatist Peter, so what I'd do in this case is exactly what you proposed
even if it's not "pure" event sourcing
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:45
Right
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:45
I'd wait for the SaveSnapshotSuccess message to arrive
after you save a snapshot
and you can check the SeqNo on that message to see how far along in the message history you traveled
and just delete anything up to that value
that will clear the journal up until that snapshot
Kris Schepers
@schepersk
Aug 04 2016 08:47
@peter-bannerflow Maybe you should ask yourself why your are doing ES in the first place?
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:47
@Aaronontheweb thanks, I will have a look at that approach
Alex Valuyskiy
@alexvaluyskiy
Aug 04 2016 08:48
@peter-bannerflow are you using this package? https://www.nuget.org/packages/Akka.Persistence.Redis/0.1.0-beta
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:52

@schepersk Yes, thats what I am thinking about right now. I wanted to try it out since I never used Akka.Persistence before, and to me it seems like most of the documentation around it is focusing on ES. But I am considering leaving ES for my own persistance implementation, basically just storing state snapshots with some intervals. I guess ES would really only be needed if I have requirements for state reply and going back in time to a particular state...

And yes, I am using the 0.1.0-beta package

Alex Valuyskiy
@alexvaluyskiy
Aug 04 2016 08:56
if you have some issues with the module, just create an issue on github. This module is in active development stage
Peter Bergman
@peter-bannerflow
Aug 04 2016 08:57
@alexvaluyskiy I don't think that I have faced any issues with the module itself, its more a design issue with my use case I guess :)
Aaron Stannard
@Aaronontheweb
Aug 04 2016 08:57
turning the build server back on
migration completed
Alex Valuyskiy
@alexvaluyskiy
Aug 04 2016 08:57
But Azure Redis instances are to expensive to store a lot of issues. SqlServer is much cheaper for his cases
@peter-bannerflow if you really want to use Redis with Persistence, you should use IaaS
Peter Bergman
@peter-bannerflow
Aug 04 2016 09:00
@alexvaluyskiy Yeah, that would proably be cheaper, but I still need to sort out the underlaying concern of my use case, which is if ES really is needed :P
Aaron Stannard
@Aaronontheweb
Aug 04 2016 09:03
sweet, fully migrated to SQL Azure
everything working normally
build server is back online
Kris Schepers
@schepersk
Aug 04 2016 12:49
Why was the timestamp column type in the event journal changed from datetime2(7) to bigint (ticks) ?
Alex Valuyskiy
@alexvaluyskiy
Aug 04 2016 16:25
has anyone tried the new Akka.Persistence.SqlServer 1.1.1.5-beta or Akka.Persistence.MongoDb 1.1.0.3-beta package?
Daniel Söderberg
@raskolnikoov
Aug 04 2016 17:29
How do I use dependecy injection for my actors when using Akka.Cluster?
The first node of my actor outputs logging events from my serilog setup. But when I start a new intance (start new debug instance of the console application) the logging event's never appears in the new instance.
Vagif Abilov
@object
Aug 04 2016 17:35
@alexvaluyskiy yes, I upgraded today to new SQL Server plugin, it works fine.
Daniel Söderberg
@raskolnikoov
Aug 04 2016 17:55
Im using AutoFac for my DI's
and when I start a new instance the cluster crashes :(
Arjen Smits
@Danthar
Aug 04 2016 18:40
@raskolnikoov are you using remote deployment ? in the form of clustered routing ?
DI only works for the local actor system.
Daniel Söderberg
@raskolnikoov
Aug 04 2016 19:40
@Danthar no I use local actors. I solved it by calling the resolver in my "Recieve" method and fetch the ILogger inside there. Maybe it's not the right way to do it?
Jared Lobberecht
@Jared314
Aug 04 2016 20:08
does Akka.DI.CastleWindsor need to be updated for 1.1?
Aaron Stannard
@Aaronontheweb
Aug 04 2016 23:52
working on the next phase of the TeamCity upgrade
kicking off a backup of the existing TC installation
and downloading TC 10
also working on getting a docker engine up and running in our new ARM resource group
Aaron Stannard
@Aaronontheweb
Aug 04 2016 23:59
build server will be offline for a bit - kicking off the upgrade to 10