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
actual line of Scala code I need to translate is
config.getConfig(path).root.unwrapped
ok, sorry I see it in our impl :P
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
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.
@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)
if we can get it to twice as slow, I think we should give it a go
@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
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
@rogeralsing @Aaronontheweb two questions:
- 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?
- 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.
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.
from the docs - "Message ordering is guaranteed on a per-sender basis."
(i.e. that's a good thing)
e.g. sender A goes first, sender B goes second, always.
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."
but I'm not a distributed systems expert either