These are chat archives for akkadotnet/akka.net

17th
Aug 2015
Boban
@bobanco
Aug 17 2015 00:19
@Horusiath what's the status of the Cluster Singleton and Sharding?
James Andrew-Smith
@james-andrewsmith
Aug 17 2015 03:18

Hey everyone, I'm a total n00b question here (but I've tried to do some research first, the bootcamp was awesome).

I've got a etag system backed by redis at the moment which needs refactoring. It seems like a nice and simple system to try out as an akka.net microservice.

Is a recieve timeout the right way to implement an actor which deletes itself? Kind of like a cache timeout?

Also, does akka ever cleanup actors which are completely idle or is this completely left to the developer? (I'm still wrapping my head around the lifecycle, as much as I'm told to ignore the idea of actors being active I want make sure I'm not doing something wrong).

Thanks for your help!
James

Bartosz Sypytkowski
@Horusiath
Aug 17 2015 06:09
@bobanco still in progress. It's hard to tell, when it'll be ready, but if #1196 gets done, it will speed up the development.
@RenEvo nothing to worry about. Process of shutting down the actor system and it's actors is asynchronous, so sometimes there still may be pending messages, when actor gets killed.
Bartosz Sypytkowski
@Horusiath
Aug 17 2015 06:24
In this case it's a /user, it's a system actor, so it's messages won't affect your business logic consistency
Tom Anderson
@RenEvo
Aug 17 2015 06:59
thanks @Horusiath just wanted to double check on that one :)
Joe Flood
@jfloodnet
Aug 17 2015 10:33
Hi all - quick question - in what scenarios could Sender be deadletters?
I'm replying to an Ask - and passing Self to Tell, and getting deadletters as the Sender when handling the reply
Ryan Davis
@rdavisau
Aug 17 2015 10:41
@jfloodnet I have seen it be deadletters if you send from outside the context of an actor
e.g. if you create an actorsystem, then deploy an actor to it, then Tell/Ask the actorref directly
Joe Flood
@jfloodnet
Aug 17 2015 11:51
hm.. this is within a single system - but i only noticed it within a test
Ryan Davis
@rdavisau
Aug 17 2015 11:51
are you able to share the test?
Joe Flood
@jfloodnet
Aug 17 2015 11:52
ill try to write a smaller sample that reproduces it
simonpetty
@simonpetty
Aug 17 2015 11:55
Hi guys, i need help with monitoring (performance counters). my timings and gauges are only showing up under _total. Anything obvious i should try?
simonpetty
@simonpetty
Aug 17 2015 12:04
ah don't worry. I think it's because my actor base class is timing how long it takes to register a receive method (not the actual receive)!
Aaron Stannard
@Aaronontheweb
Aug 17 2015 16:05
@simonpetty ah, that would do it
@Horusiath I haven't started actively working on that issue yet - although it's important!
this is super cool - the guy who posted that is a .NET developer who works on Battle.NET for Blizzard
obviously it's not like he's endorsing Akka.NET for work or anything, but still - I can only dream of seeing Akka.NET used in a software product I personally use often :p
Graeme Bradbury
@GraemeBradbury
Aug 17 2015 16:15
You never know, Orleans got Halo. So maybe Akka will get Battle :-)
Aaron Stannard
@Aaronontheweb
Aug 17 2015 16:17
yep, you never know!
Arjen Smits
@Danthar
Aug 17 2015 17:07
hah that would be cool. "fires up starcraft"
Roger Johansson
@rogeralsing
Aug 17 2015 17:14
World of Warcraft.NET
btw. version tolerance in serialization, we havent really discussed this before, how much do we need? should things break if one client have an older version of a message assembly ?
adding properties ? removing properties, changing property type, changing casing of property names. what is bare minimum an what is totally not needed?
Aaron Stannard
@Aaronontheweb
Aug 17 2015 17:20
IMHO, the only breaking change to a message should be if the constructors have different signatures
or changing the type of the property
adding or removing properties shouldn't be a big deal
actually... now that I think about it
if I depend on an older version of a mesage
and someone removes a property
on the newer version of the message being serialized
I'd want to know that on the read-side
rather than have it silently fail by passing in a null / default value
an explicit exception would be preferable
Roger Johansson
@rogeralsing
Aug 17 2015 17:23
exactly, and there really isnt much you can do about it on the read side except log it and maybe throw
Aaron Stannard
@Aaronontheweb
Aug 17 2015 17:23
throwing an exception, loudly, is probably the right thing to do
fail fast, right?
Roger Johansson
@rogeralsing
Aug 17 2015 17:23
ye
Im making my own serializer :D its 15 times faster than the json.net setup we have in akka.net atm
The migrant guys are also making some progress, but I got carried away and made my own too
Aaron Stannard
@Aaronontheweb
Aug 17 2015 18:04
@rogeralsing somehow I am not surprised :p, re > but I got carried away and made my own too
Ryan Davis
@rdavisau
Aug 17 2015 21:11
@rogeralsing :laughing:
Christian Palmstierna
@cpx86
Aug 17 2015 21:12
@rogeralsing Will you put it on GH so we all can see? :) Sounds like it could be interesting to compare the code to json.net
Ryan Davis
@rdavisau
Aug 17 2015 21:13
Are you going to be the one to debunk the current .NET serializer conundrum?
"Fast, Discriminated Unions, FSharpOptionType - Pick any two" :triangular_ruler:
Aaron Stannard
@Aaronontheweb
Aug 17 2015 22:12
@rdavisau this is why we can't have nice things
:p
Joe Flood
@jfloodnet
Aug 17 2015 22:27
@rogeralsing @Aaronontheweb agree - "adding" properties should not be a breaking change
id argue, by that reasoning, adding constructor parameters should not be breaking either
i believe json.net will supply default value if it can't match a ctor param.
Aaron Stannard
@Aaronontheweb
Aug 17 2015 22:29
@jfloodnet I disagree with that about the constructor... the unintended side effects of that could be really nasty potentially
I can imagine a scenario where all of the sudden an eCommerce app starts reporting lots of 0.00 sales because a "best fit" constructor algorithm didn't let the developers know during dev and test that there was an issue
probably best to be explicit and fail fast when it comes to that stuff, rather than try to think on the behalf of the end-user
Joe Flood
@jfloodnet
Aug 17 2015 22:34
I suppose so.. a user can still add non breaking change, by adding a property and not changing the constructor - in that sense it is explicit that the property is "optional"
Aaron Stannard
@Aaronontheweb
Aug 17 2015 22:35
a user can still add non breaking change, by adding a property and not changing the constructor
yep, I agree with that
that's the only way to version messages, really
extend-only design
(or best-fit serialization, which is how ASP.NET MVC model binding works)
Joe Flood
@jfloodnet
Aug 17 2015 22:36
yea i guess the constructor is really a way of declaring "mandatory" fields
Aaron Stannard
@Aaronontheweb
Aug 17 2015 22:36
yeah, exactly
it's also because you don't necessarily know what those fields are being used for
Joe Flood
@jfloodnet
Aug 17 2015 22:37
sadly - i think MVC requires default constructors
Aaron Stannard
@Aaronontheweb
Aug 17 2015 22:37
the can be assigned to private setters for properties, sure
Joe Flood
@jfloodnet
Aug 17 2015 22:37
:P
Aaron Stannard
@Aaronontheweb
Aug 17 2015 22:37
but they can also be used in things like calculated properties
yeah, that doesn't surprise me about ASP.NET MVC
models are short-lifetime objects in MVC
whereas messages in Akka.NET can be forwarded around, accumulated as some piece of state, etc...
the immutability requirement you have to impose often means not having public setters
and having to go through the constructor to set those fields
Aaron Stannard
@Aaronontheweb
Aug 17 2015 23:16
working on integrating Akka.NET into an ASP.NET 5 app today!
finally upgraded my system to VS15 and Windows 10 on Friday