Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 07:55
    ismaelhamed commented #3284
  • Sep 13 16:35
    Aaronontheweb commented #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3905
  • Sep 13 16:35
    Aaronontheweb labeled #3914
  • Sep 13 16:34
    Aaronontheweb commented #3914
  • Sep 13 01:50
    Aaronontheweb synchronize #3914
  • Sep 13 01:45
    Aaronontheweb commented #3914
  • Sep 12 14:10
    Aaronontheweb synchronize #3914
  • Sep 12 14:10

    Aaronontheweb on dev

    name AzureDevops artifacts per … (compare)

  • Sep 12 14:10
    Aaronontheweb closed #3915
  • Sep 12 13:57
    Aaronontheweb synchronize #3915
  • Sep 12 13:37
    Aaronontheweb opened #3915
  • Sep 12 06:43
    Horusiath commented #3628
  • Sep 12 05:57
    Horusiath synchronize #3628
  • Sep 12 02:05
    Aaronontheweb synchronize #3901
  • Sep 12 02:04
    Aaronontheweb commented #3914
  • Sep 12 02:03
    Aaronontheweb synchronize #3914
  • Sep 12 01:11
    Aaronontheweb commented #3105
  • Sep 12 01:10
    Aaronontheweb closed #3105
Bartosz Sypytkowski
@Horusiath
i.e. you could persist your events with protocol buffers serializer - since they use explicit proto schemas, as long as your mapped classes satisfy schema (which depends only on fields order and type, not even names) they're good to go
Nikita Tsukanov
@kekekeks
Well, I'm usually against using human-inreadable formats for persistence
Aaron Stannard
@Aaronontheweb
the serialization layer is fully pluggable
Nikita Tsukanov
@kekekeks
And with protobuf you can't switch data types (eg. from int to double, string, etc)
Aaron Stannard
@Aaronontheweb
the strong typing protobufs introduces is where all of the serialization performance benefits come from
Bartosz Sypytkowski
@Horusiath
but you can change field names, and protobuf is faster and more compact
Nikita Tsukanov
@kekekeks
Protobuf is great for transfering data on the wire, but for something that will be stored for years? Probably not.
Aaron Stannard
@Aaronontheweb
yep, I agree with that
serialization overhead isn't something that matters much in the context of durable stores
Aaron Stannard
@Aaronontheweb
alrighty, meeting time
Joshua Benjamin
@annymsMthd
Is the meeting in here?
Natan Vivo
@nvivo
@Aaronontheweb, @rogeralsing about the dispatchers. From what I understood, the main use cases to set a dispatcher are a) specify a thread model for performance reasons, so your actor is bound to one or more specific threads, or b) to limit the damage area in case too much work is being done, so you don't starve the rest of the system. Is that right? Are other common use cases?
Nikita Tsukanov
@kekekeks
To limit the number of concurrent connections to something like Postgres (which really doesn't like when you have >100 connections to it)
David Smith
@smalldave
sorry guys. as you might have gathered I'm not going to make the meeting tonight
@annymsMthd sounds good. we did discuss using appdomains instead of processes before. somebody came up with what I remember being a good reason not to. possibly @rogeralsing. certainly not against the idea though. would make things a lot easier.
Arjen Smits
@Danthar
@skotzko interesting email
Bartosz Sypytkowski
@Horusiath

To limit the number of concurrent connections to something like Postgres

@kekekeks This doesn't sound like a job for a dispatcher, rather the matter of design constrained pool of actors managing the connections

Nikita Tsukanov
@kekekeks
Do you use database from a single actor type?
Natan Vivo
@nvivo
@Horusiath I'm looking for things to write in the dispatcher documentation. like "reasons you might want to do this". if you have more recommendations, I'd be glad to hear
Nikita Tsukanov
@kekekeks
I. e. one can have a ton of different actors that act like a repository
Natan Vivo
@nvivo
@kekekeks you can restrict concurrent connections to a database with routers, I have been doing with actors only
Bartosz Sypytkowski
@Horusiath
@kekekeks you may wrap database access layer in actor
Nikita Tsukanov
@kekekeks
And lose access to ORM?
nope
Natan Vivo
@nvivo
you don't need to lose ORM
Nikita Tsukanov
@kekekeks
You lost me here
You can't use one pool since actors are actually of different types
i. e. UsersRepository, MessageRepository and so on
and even have pools for groups of actors of one type
Natan Vivo
@nvivo
it all depends on how you see the problem
Nikita Tsukanov
@kekekeks
In this case you'll have a lot of actors that do exclusively DB operations but are limited by DB connection pool
Arjen Smits
@Danthar
Besides leveraging the supervision capabilities, and perhaps error handling. Why would you want your data access, which is already abstracted into repositories. abstracted behind an Actor?
Natan Vivo
@nvivo
if you want to restrict all queries to a database, you could create an actor that routes or executes only 5 queries a time for example (an idea)
if you want to abstract per repository, then you can use all your ORM inside that actor
Nikita Tsukanov
@kekekeks
in this case I'll have to do everything in one god-class
Arjen Smits
@Danthar
@nvivo true. but if you are using an ORM, access to that level, for that kind of manipulation is abstracted away
Natan Vivo
@nvivo
the point is that there is not a single way to do it. akka don't require you to stop using an orm
depends on the orm right?
Arjen Smits
@Danthar
true
Joshua Benjamin
@annymsMthd
One of the main things to note here is the Actor Model != OOP. There are fundamental differences in the way things are modeled and architected.
Nikita Tsukanov
@kekekeks
I mean, different types of actors can share a single resource
jcwrequests
@jcwrequests
Get rid of the ORM and use Event Sourcing :)
Natan Vivo
@nvivo
=)
jcwrequests
@jcwrequests
Or use a micro ORM
Nikita Tsukanov
@kekekeks
Well, show me how to do full text search with event sourcing effectively
Bartosz Sypytkowski
@Horusiath
there are plenty ways to do it. I've got idea, when db connections are distributed using token pattern - there is an actor which holds pool of tokens/db connections, and passes them on demand to other actors inside the same actor system, actors which needs a db access, ask provider wth token request and release the token after their job is done
however it's only an idea, I didn't test it yet
Natan Vivo
@nvivo
@kekekeks what @annymsMthd said is completely true. the thing to realize is: Akka has 5 years of battle tested implementation working for lots of people in most varied environments. It's more about understanding how you can do it than anything else. the model itself doesn't restrict much, but you need to change your application architecture to embrace it.
Nikita Tsukanov
@kekekeks
I don't see why it can't be done with a dispatcher that just limits the number of threads
Arjen Smits
@Danthar
@nvivo Thats very true