search

akkadotnet / akka.net

Canonical actor model implementation for .NET with local + distributed actors in C# and F#.
http://getakka.net
Other
4.7k stars 1.04k forks source link

Interop with Akka for java ? #1629

Closed mmc41 closed 8 years ago

mmc41 commented 8 years ago

Does Akka.Net use the same protocols "standards" as Akka for Java so it is possible to use both together in a heterogeneous environment with some actors written in java, some in C# (using akka.net) etc ?

rogeralsing commented 8 years ago

No, and there are a few reasons for this; Currently Akka.NET uses a network library called Helios, which isn't wire compatible with Netty that the JVM Akka uses. things like endianness and framing headers etc differ. This part could potentially be fixed now that there is a DotNetty transport in the making.

But, the real issue is really serialization. We need to carry a lot of type information around for sub typing to work in messages or remote deployments, so we can not just rely on plain JSON or any such schema free format. Type names will differ from .NET and JVM, e.g. how a fully qualified type name is formatted etc. That could also potentially be solved using a strict format like Protobuf.

Still, there are some internal features that are not designed for that, e.g. remote deployment will serialize an Akka HOCON config and that is not just translated to a string which one might think (neither on JVM or .NET)

On top of all this, there are also fine tuning how heart beats and fault detectors behave that needs to be 100% in sync for things to work correctly.

TLDR; in theory, some of it can be solved, but it requires changes on both .NET and JVM, and we on the .NET side have no control or mandate over JVM Akka. But realisticly, it would probably be a massive undertaking and require huge amounts of debugging to make it stable even if those changes are made.

The best bet is to either integrate using HTTP, some standard message queue or Akka IO using TCP or UDP. and simply abstract away all the Akka specific parts.

mmc41 commented 8 years ago

ok, thank you very much for the details explanation.

dzmitry-lahoda commented 8 years ago

Another option to run Akka via IKVM (very robust JVM implementation on .NET).

rogeralsing commented 8 years ago

@asd-and-Rizzo people have tried that already and the performance is horrid when trying to run JVM Akka on IKVM.

dzmitry-lahoda commented 8 years ago

Could you please point me to source code so I may run tests on latest IKVM and .NET if any source of benchmarks available?

I was not found any for latest 2 years.. For these years IKVM really improved as I read updates in their blog..

Let consider next:

  1. I want communicate with Akka from Akka .NET.
  2. I use some HTTP to do integration instead of direct communication.
  3. I add all infrastructure for HTTP to work (HTTP will need tools as actors has).
  4. I end up layer of indirection of HTTP and all infrastructure for HTTP running along with actor stuff (essentially 2 actors stuff).
  5. I end up in bad system performance and poor maintainability.

Solution: Run Akka via IKVM also it may be of not so ideal performance, but we do not get better anyway.

dzmitry-lahoda commented 8 years ago

My interest steams from fact we have adhoc actors with all related stuff build into (supervisors, resilience, error handling, persistence, events, tcp communication, strongly typed messages) and these compatible on CLR and JVM. But this adhoc stuff is really hard to maintain and has very bad api. What is option to replace it for?