Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 16:19
    valdisz synchronize #3904
  • 14:58
    Aaronontheweb synchronize #3924
  • 14:58
    Aaronontheweb commented #3922
  • 14:45
    valdisz synchronize #3904
  • 14:43
    valdisz synchronize #3904
  • 14:35
    Aaronontheweb commented #3925
  • 09:51
    cptjazz opened #3925
  • 09:11
    cptjazz opened #3924
  • Sep 20 23:30

    Aaronontheweb on dev

    added ability to support custom… (compare)

  • Sep 20 23:30
    Aaronontheweb closed #3923
  • Sep 20 23:30
    Aaronontheweb closed #3861
  • Sep 20 23:26
    Aaronontheweb opened #3923
  • Sep 20 23:01
    Aaronontheweb commented #3922
  • Sep 20 22:59
    Aaronontheweb closed #3890
  • Sep 20 22:59
    Aaronontheweb commented #3890
  • Sep 20 22:58
    Aaronontheweb synchronize #3922
  • Sep 20 22:58
    Aaronontheweb opened #3922
  • Sep 20 22:21
    Aaronontheweb commented #3905
  • Sep 20 22:21

    Aaronontheweb on dev

    Fixed Akka.Remote.ResendUnfulfi… (compare)

  • Sep 20 22:21
    Aaronontheweb closed #3914
Anthony Brown
@bruinbrown
Either, xunit needing a VS package for a test runner seems a bit wat, I was wondering if there was anything in the build script to run it
Aaron Stannard
@Aaronontheweb
@bruinbrown not offhand - but I'd accept a PR for the FAKE script to make that easier
need to help out our friends on Mono, right? ;)
@rogeralsing btw, got some love from Vaugh Vernon today: https://twitter.com/VaughnVernon/status/632235346588143617
Roger Johansson
@rogeralsing
oh, nice!
Aaron Stannard
@Aaronontheweb
I want to read his book
Andrew Skotzko
@skotzko
that is awesome
@rogeralsing saw your msg from earlier. currently, ready label is the issues assigned for the next release (corresponds to that column in waffle)
Roger Johansson
@rogeralsing
ah ok
Roger Johansson
@rogeralsing
@Horusiath I've made some fixes to Migrant, now its "just" 5 times slower than Json.NET.. but its a lott better than those 24 times difference that it was at first
Bartosz Sypytkowski
@Horusiath
if you can make it 5x faster in hour of work, I feel a little afraid what you end up with on Monday :p
I've almost finished with the event adapters for akka.persistence, but I'm missing some of the HOCON methods, that are present in the JVM version
Roger Johansson
@rogeralsing
Ok, any specifics ? Ill try to add them
Bartosz Sypytkowski
@Horusiath
can we somehow achieve behavior similar to this? ConfigObject.unwrapped
actual line of Scala code I need to translate is config.getConfig(path).root.unwrapped
ok, sorry I see it in our impl :P
Roger Johansson
@rogeralsing
var unwrapped = ConfigurationFactory.ParseString(hocon).Root.GetObject().Unwrapped;
its a bit hidden :)
and do note, that the values, that is, strings and arrays and such, are still HoconValues that you have to do .GetString or GetInt on.. Im not sure if that is the case in the scala version
Bartosz Sypytkowski
@Horusiath
test suite will show ;>
Roger Johansson
@rogeralsing
The way that Akka handles serialization is really stupid, first of all, it always requires a byte array result, even if the backing serializer can write directly to a stream. and secondly, we always serialize individual messages, there is no way to do batch serialization.
Bartosz Sypytkowski
@Horusiath
there are many lessons to be learned
Roger Johansson
@rogeralsing
turns out that when using batch serialization, migrant is 4 times faster than json.net, but we cannot leverage that due to how jvm Akka handles serialzation
Bartosz Sypytkowski
@Horusiath
hmm, but this could be potentially used in one case in persistence (and maybe in remote)
Arjen Smits
@Danthar
@rogeralsing wouldn't sending multiple messages in one batch, cause a conceptual disconnect higher up the stack? Cause instead of sending 1 messages your sending multiple messages. So wouldn't that also force you to change the way how message delivery guarantee's are handled ? (not conceptually perhaps, but technically)
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