These are chat archives for akkadotnet/akka.net

5th
Aug 2016
Aaron Stannard
@Aaronontheweb
Aug 05 2016 00:03
specifically: the server upgrade shouldn't take long at all
but if our agent images can't interop with TC10
then it might take me a day to get those back up and running
Aaron Stannard
@Aaronontheweb
Aug 05 2016 00:36
looks like the upgrade went through - also installed TeamCity.Virtual but haven't turned it on yet
bah, the Azure plugin broke with the upgrade
I'll need to take care of that later today
about to head out for a bit here in Sydney
but other than that everything was smooth
Aaron Stannard
@Aaronontheweb
Aug 05 2016 07:40
updating the teamcity Azure plugin with the latest now
Aaron Stannard
@Aaronontheweb
Aug 05 2016 08:01
plugin is working but I don't see the build agents registering
hrmph
Arjen Smits
@Danthar
Aug 05 2016 08:10
@Jared314 yes. We currently have some failing tests in the di testkit due to a bug. Which we resolved in dev, but is not in any release yet.
rsinohara
@rsinohara
Aug 05 2016 08:40
I'm at a loss in an ASP MVC app and akka. I have a static class that handles back and forth calls between signalr and the actor system. I just don't know if I should create one single actor and pass every message going to the client to it (so only this actor will call the static class) or if I let every actor directly call the static class.
I hope I'm being clear enough :)
Arjen Smits
@Danthar
Aug 05 2016 08:45
Your talking about having one actor acting as a gateway to signalr, or letting all your actors directly talk to signalr, via your static class. Do i understand that correctly ?
rsinohara
@rsinohara
Aug 05 2016 08:50
yes
well, I'm trying it out on a test branch, and as it turns to make that work I need that class to not be static.... but yeah you're right
Arjen Smits
@Danthar
Aug 05 2016 08:55
Well. The correct way, would be to use a separate actor for that. But it really depends on what your goal is. Having a separate actor that acts as a gateway allows you to move your business actors to a remoting / clustering setting. Without having to change your communication patterns in code. Since if you move your business actors to a seperate node. They could still communicate with your signalr gateway actor.
rsinohara
@rsinohara
Aug 05 2016 08:56
interesting
although this is a portfolio game, so I don't think it will ever scale... I was thinking having one actor would bottleneck calls to signalr... I could obviously use routers so your point sets it.
Thanks a lot, I was doing it this way (gateway actor), but thought it wasn't good :)
Arjen Smits
@Danthar
Aug 05 2016 08:59
Well your thought about it being a bottleneck is certainly valid
And you can alleviate that with routers. But how many would you need ?
Only way to know is by testing :)
Also, i believe calls to signalr are async
rsinohara
@rsinohara
Aug 05 2016 09:01
Oh, in truth, for this app, even that won't be a problem. I'm not expecting users on this - maybe occasionally one user with a few tabs (since it's multiplayer).
But I like to do it right, or at least not in a way I cannot fix later (routers are good because I can easily add them later if need be)
This right now is just a portfolio app... But questions like this are so great, to me :) thanks for the help.
Arjen Smits
@Danthar
Aug 05 2016 09:04
then you probably only need one actor. Like you said, you can always add more. But with my remark about signalr calls to be async. I mean that because they are async, your doing minimal blocking in your actor. So messages will be processed really fast. I dont think you'd get alot of performance increase by using a router in this case.
rsinohara
@rsinohara
Aug 05 2016 09:07
you're right
:)
Arjen Smits
@Danthar
Aug 05 2016 09:09
Performance increase would be minimal, and adding to many might hurt performance, as the cost of context switching that goes on in the dispatcher for each mailbox would start to show.
Peter Bergman
@peter-bannerflow
Aug 05 2016 09:13
@Danthar I have a scenario somewhat similar to that, where I handle short lived requests and create a new actor for each request. I then terminate the actor once its finished. But do you mean that in general for those kind of scenarios, it would be better to actually use a pool of actors to handle all requests?
I realize that it might be hard to answer such a broad question without "it depends".... :)
rsinohara
@rsinohara
Aug 05 2016 09:17
@peter-bannerflow Yeah, I think the only way to know is to test both approaches
Peter Bergman
@peter-bannerflow
Aug 05 2016 09:18
Yes, my tests so far tend to favor the "one actor per request" approach
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 13:51

@schepersk regarding:

Why was the timestamp column type in the event journal changed from datetime2(7) to bigint (ticks) ?

Kris Schepers
@schepersk
Aug 05 2016 13:53
Yes? :-)
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 13:53
In general timestamp is a property present only in sql journals and should be obsoleted in the future - mostly because usually a specific type of persistence backend should remain an implementation detail, and timestamps are not so useful in for example distributed databases
And regarding why it has been changed:
  1. Every SQL database differs in details about the way it understands what a datetime is. This was a reason for some special cases and fluctuations in the past.
  2. Long is more universal than date time - because the reason for timestamp column was to have a global ordering of events (unlike sequenceNr, which is scoped to persistenceId). You don't need to use date here, only some value globaly increasing for the next events persisted. With those constraints in mind, longs are more elastic to use than dates.
Kris Schepers
@schepersk
Aug 05 2016 14:00
Hmm, owkay, seems reasonable..
But this makes it much harder to select events for e.g. a time range
Lets say you want to reply events from the last 2 months for a new projection.. How would you do this?
replay events..
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 14:02
from within .net framework?
Alex Valuyskiy
@alexvaluyskiy
Aug 05 2016 14:03
Just use Persistent.Query and filter your data
Kris Schepers
@schepersk
Aug 05 2016 14:03
in this case, yes..
this can be done with Persistent.Query?
Kris Schepers
@schepersk
Aug 05 2016 14:05
@Horusiath @alexvaluyskiy Now that you are both here, I've got an issue with the SQL Server persistence plugin..
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 14:05
no, unless you've included timestamp into events themselves - which is recommended approach afaik
Kris Schepers
@schepersk
Aug 05 2016 14:05
I need to be able to configure it twice, once for normal persistence, once for sharding persistence.. same DB, different schemas and tables..
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 14:06
with the latest version of sql server plugin for akka you should be able to do so
Kris Schepers
@schepersk
Aug 05 2016 14:06
but for this you need to be able to alter the journal config path
can you point me in the right direction ?
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 14:13
you just need to set up one config path for default persistence and one for cluster sharding, then set the path to default one and point the journal path for the cluster sharding, i.e:
# HOCON path to cluster sharding settings
akka.cluster.sharding.journal-plugin-id = "akka.persistence.journal.my-sharding"

# HOCON path to common settings
akka.persistence.journal.plugin = "akka.persistence.journal.my-standard"

akka.persistence.journal {
  # cluster sharding settings
  my-sharding {
    ...
  }

  # common settings
  my-standard {
    ...
  }
}
Kris Schepers
@schepersk
Aug 05 2016 14:17
Hmm, I've never been able to get it to work like that.. It seems the only way that the extension is able to load itself is to use the "akka.persistence.journal.sql-server" path in hocon configuration
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 14:17
yes, that was in the previous versions of sql-server plugin
Kris Schepers
@schepersk
Aug 05 2016 14:17
but when looking at the source code, I can't notice any difference in this?
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 14:17
I've fixed that (I hope <fingers crossed>)
Kris Schepers
@schepersk
Aug 05 2016 14:18
maybe I'm just looking in the wrong place
Bartosz Sypytkowski
@Horusiath
Aug 05 2016 21:14
it looks like I've managed to get to interop F# Async with actor { ... } computation expression in Akkling :D
Daniel Söderberg
@raskolnikoov
Aug 05 2016 23:57
Maybe a dumb question, but do I have to stop my actors if they are never going to be used again?
or will they "clean up" themselfs