Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:22
    Aaronontheweb milestoned #4720
  • 14:22
    Aaronontheweb labeled #4720
  • 14:22
    Aaronontheweb labeled #4720
  • 14:22
    Aaronontheweb opened #4720
  • Jan 14 15:53
    object opened #190
  • Jan 14 08:10
    object commented #4265
  • Jan 14 08:04
    object commented #4265
  • Jan 13 16:35

    Aaronontheweb on 1.4.14

    (compare)

  • Jan 13 16:31

    Aaronontheweb on master

    Bump Mongo2Go from 2.2.14 to 2.… Bump MongoDB.Driver from 2.11.4… Bump Microsoft.NET.Test.Sdk fro… and 4 more (compare)

  • Jan 13 16:31
    Aaronontheweb closed #176
  • Jan 13 16:30
    Aaronontheweb opened #176
  • Jan 13 16:30

    Aaronontheweb on 1.4.14

    (compare)

  • Jan 13 16:30

    Aaronontheweb on dev

    Added v1.4.14 release notes (#1… (compare)

  • Jan 13 16:30
    Aaronontheweb closed #175
  • Jan 13 16:16

    Aaronontheweb on dev

    ensure that all recovered Times… (compare)

  • Jan 13 16:16
    Aaronontheweb closed #174
  • Jan 13 16:06
    Aaronontheweb synchronize #174
  • Jan 13 15:52
    Aaronontheweb opened #175
  • Jan 13 15:52

    Aaronontheweb on 1.4.14

    Added v1.4.14 release notes (compare)

  • Jan 13 15:50
    Aaronontheweb opened #174
Aaron Stannard
@Aaronontheweb
@Danthar is correct - it may be less performant to do things 1 at time at the framework level, but it makes it easier to have guarantees all the way down the stack
Roger Johansson
@rogeralsing
@Horusiath got Migrant down to 3 times slower than json.net.. sent them a PR for that
if we can get it to twice as slow, I think we should give it a go
Bartosz Sypytkowski
@Horusiath
agree
Bartosz Sypytkowski
@Horusiath
I'm finishing porting event adapters
Filippo Mariotti
@barambani
@stefansedich Hi, I'm trying to build akka.net on Mono (Mac OSX and Xamarin) and I have some trouble with some of the latest changes. The PREBUILDSTEP of Akka.MultiNodeTestRunner.csproj cannot run on my stack (it uses xcopy). Do I have any workaround there ? Thanks for the help
Anthony Brown
@bruinbrown
@willieferguson I remember you saying you'd managed to get most of the replicator messages sorted to get around CLR and JVM generics differences, I've got almost everything else done, do you have a link to that anywhere?
Kamil Wojciechowski
@aph5nt
Question: i know that there is an inmemory journal store, but is it possible to also store snapshots in memory? I need it for my testing scenario.
I can not find snapshots on disk to remove them....
are they hidden or sth?
ok, found it - I can configure the snap dir
with hocon
Bartosz Sypytkowski
@Horusiath
@rogeralsing @Aaronontheweb two questions:
  1. How do we synchronize (or want to synchronize) changes in Akka.Persistence.Sql.Common with depending libraries? I want to provide few new features in this lib: unify extraction of connection string from config and extending journals to be able to be queried for events on custom rules. But this will require consecutive changes in other repositories. How we could sync them?
  2. Does anyone started working on visualizer for multinode test runner? It's a cumbersome work to debug cluster stuff, and I guess this would be very helpful.
Nathan Ridley
@axefrog
hey, not sure if anyone's around, but if you are... as long as i'm careful to stick to side-effect-free code, is akka.net completely deterministic in terms of the order in which messages are processed, even when distributed? I'm designing a system in which determinism is critical. I understand that floating point precision differences between machines can cause issues in this regard, but i'm not concerned about that right now.
Ryan Davis
@rdavisau
@axefrog I believe that order is guaranteed between any given pair of communicators, but not broadly
Nathan Ridley
@axefrog
Ok. In the mean time since I wrote that message I thought of a slightly different approach to reduce my dependence on perfect determinism... nevertheless I appreciate the response :)
Ryan Davis
@rdavisau
no problem :star2:
Nathan Ridley
@axefrog
Ah hang on, guaranteed on a per-sender basis; doesn't that mean if you have a thousand actors each sending a message, that "per-sender" means that each sender will always be invoked in the same order?
(i.e. that's a good thing)
e.g. sender A goes first, sender B goes second, always.
Ryan Davis
@rdavisau
that's not quite what I was thinking, but I may be wrong
Nathan Ridley
@axefrog
The Akka (Java) documentation says "Akka implements Oz-style dataflow concurrency by using a special API for Futures that enables a complementary way of writing synchronous-looking code that in reality is asynchronous." ... I know Akka.net is a port, but I know it's not exactly the same either.
"The benefit of Dataflow concurrency is that it is deterministic; that means that it will always behave the same. If you run it once and it yields output 5 then it will do that every time, run it 10 million times - same result. If it on the other hand deadlocks the first time you run it, then it will deadlock every single time you run it. Also, there is no difference between sequential code and concurrent code. These properties makes it very easy to reason about concurrency. The limitation is that the code needs to be side-effect free, i.e. deterministic."
Ryan Davis
@rdavisau
yes, I was looking there too -> Message Ordering
Nathan Ridley
@axefrog
I can't imagine how they could work over multiple machines given that clocks can get out of sync...
but I'm not a distributed systems expert either
Ryan Davis
@rdavisau
Yeah, I guess there are many non-deterministic influences at play once you go beyond a single process
Nathan Ridley
@axefrog
Ah, the order guarantee being "per sender" means that if A sends multiple messages to B, they will always be received in the correct order.
Ryan Davis
@rdavisau
but no guarantee about the broader correctness if both A & C are sending "simultaneously" to B, I suppose
Nathan Ridley
@axefrog
yeah
Ryan Davis
@rdavisau
anyway some of the core team will probably be past in the next few hours with more insight - it's :zzz: time for me!
Nathan Ridley
@axefrog
heh, seeya
Steven van der Merwe
@SaberZA
Hi @Horusiath . I'm trying to decide on how I should be separating out specific system components. So my problem is that I have some arbitrary Web Service called by a client and I need to make a choice on how that Web Service interacts with my ActorSystem. My preliminary choice is that the Web Service will post messages onto a Message Queue, like RabbitMQ, which then has my ActorSystem subscribed to message notifications on that queue. The ActorSystem then would essentially understand how to process messages from that MessageQueue. This gives me the benefit of unified cross-platform interface to my ActorSystem. Would you agree with this? or have a opinion on solving this another way?
Bartosz Sypytkowski
@Horusiath
@SaberZA message queues are quite common pattern, when you need reliability of your messsage delivery on the boundary of actor system and another external service. Also they're good option, when you need unified access point for messages (i.e. you don't want to bound your actor system with knowledge about every particular WS). So if these are your cases, then yes, it's a good way to go.
Steven van der Merwe
@SaberZA
@Horusiath Great. Thanks very much! I'm going to be introducing Akka.Net as a solution in a technical review tomorrow. From what I've experienced so far it gives a very robust base for distributed applications within a DDD/CQRS contextualized solution.
Tom Anderson
@RenEvo
Hello :)
Trying a really super simple console app, (system named MyAkka) when i run system.shutdown() then system.awaittermination() i get an info log about Message DeathWatchNotification was not delivered to akka://MyAkka/user
any clue?
Steven van der Merwe
@SaberZA
Hey @RenEvo. It's a debug info log message. From what I've seen is this is outputted if an actor wasn't shutdown within the system. Try sending your actor a PoisonPill then shutdown your system.
Tom Anderson
@RenEvo
is it normal to send a poison pill before app shutdown?
Steven van der Merwe
@SaberZA
In future I think you would want to close down actors gracefully. That poison pill is just an example of having an actor process all its messages in it's mailbox then close gracefully
Tom Anderson
@RenEvo
the message is from the user guardian, not from my code
[INFO][8/16/2015 10:35:51 PM][Thread 0008][akka://MyAkka/user] Message DeathWatchNotification from akka://MyAkka/user to akka://MyAkka/user was not delivered. 1 dead letters encountered.
Steven van der Merwe
@SaberZA
I would like to hear from someone with more experience on this notification too. I don't think I have enough to offer a really insightful answer
Tom Anderson
@RenEvo
thanks for the help anyway, hopefully someone chimes in, it is just an "info" but, getting this with a simple iteration makes me feel like i am doing something wrong
Tom Anderson
@RenEvo
oddly... not having the Console.ReadLine after the tester.Tell doesn't have this issue...
Boban Pavloski
@bobanco
@Horusiath what's the status of the Cluster Singleton and Sharding?
James Andrew-Smith
@james-andrewsmith

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