>  Does the Flink team have any documentation on the alternatives to Akka that you're looking at?

We are / I am currently working a prototype based on gRPC.
Functionality-wise it looks promising and we're nearly there; but there's still a lot to be done w.r.t. testing & hardening the entire thing over the coming months of course.

Really anything that allows us to ship some binary blob from A to B with some ordering guarantees pretty much does the trick for us. But this willy vary significantly between companies, depending on which of the many parts of Akka they're actually using; there's afaict no one-size-fits-all replacement.
(Which makes me wonder whether Akka just does too many different things?)

We used very little functionality of Akka; our only real dependencies are akka-actor and akka-remote. In a way Akka was just providing a thread pool + one-active-thread-per-component-guarantees + shipping of messages.
That's not _that_ difficult to replace.

Our stack is also a bit out-dated; still stuck on Netty 3 for example instead of Artery. That's another thing that makes switching attractive; the alternative isn't "stick with Akka" but "stick with Akka and fix these things _eventually_".

> Would the Flink team consider helping to get Pekko up and running?
> It may be that there is less effort involved in getting Pekko released than rewriting a large part of Flink.

That's of course a fair point, however releasing Pekko isn't the problem at hand though; it's maintaining it for several months/years. That's a huge commitment over picking another library that /is/ already being maintained.

I can't speak for the entire project but I doubt that we have the capacity or knowledge to really help out in a significant way; we're busy enough working on Flink as is, and those who introduced Akka into Flink are no longer active.

At least so far rewriting our Akka integration appears to require less effort.

On 06/10/2022 16:41, PJ Fanning wrote:
Thanks Chesnay for clarifying the Flink team's position on this.
Since many companies and OSS projects are in a similar position, does
the Flink team have any documentation on the alternatives to Akka that
you're looking at?

Feel free to ignore the suggestion but the volunteers for the Pekko
include a number of major Akka contributors but would the Flink team
consider helping to get Pekko up and running? It may be that there is
less effort involved in getting Pekko released than rewriting a large
part of Flink.

Regards,
PJ

On Wed, 5 Oct 2022 at 15:45, Chesnay Schepler<ches...@apache.org>  wrote:
Hello,

since Flink is mentioned several times in the proposal I feel the need to point 
out that we're actively looking into outright replacing Akka.

We need something that is guaranteed to work once the 2.6.x support provided by 
Lightbend ends next year, and with Akka being used in the very core of Flink 
this transition has to start early.
We can't really take a gamble on this fork still being active/useful in a year.

My current expectation is that we'd only use Pekko as an emergency replacement 
for older releases when the Lightbend support ends and a critical issue was 
found (which is quite unlikely to be honest).

On 2022/09/29 14:57:56 "Claude Warren, Jr" wrote:
Greetings,

I would like to propose Pekko [1]  as a new Apache Incubator project.

Pekko is a toolkit that brings the actor model (popularised by Erlang) to
the JVM, providing the basis for building both locally and distributed
concurrency. On top of this Pekko provides a rich set of libraries built on
top of Actors to solve modern problems, including:


    - Streams: Fully bi-directional backpressured streams following the
    Reactive manifesto
    - HTTP: A fully streamed HTTP client/server built on top of streams that
    also provides expected tools (such as connection pooling) necessary for
    highly available web services
    - connectors: A rich set of connectors for various databases, messaging,
    persistent services built on top of streams
    - grpc: A gRPC server/client
    - projection: Provides abstractions necessary for CQRS pattern such as
    envelope, necessary for systems such as Kafka.



Controversially Pekko is a fork of the Akka project just prior to its
licence changed from Apache 2 to Business Source License 1.1.

I look forward to your feedback and discussions,

Thank you,
Claude Warren
[1]https://cwiki.apache.org/confluence/display/INCUBATOR/PekkoProposal

---------------------------------------------------------------------
To unsubscribe, e-mail:general-unsubscr...@incubator.apache.org
For additional commands, e-mail:general-h...@incubator.apache.org

Reply via email to