apache / incubator-pekko Goto Github PK
View Code? Open in Web Editor NEWBuild highly concurrent, distributed, and resilient message-driven applications using Java/Scala
Home Page: https://pekko.apache.org/
License: Apache License 2.0
Build highly concurrent, distributed, and resilient message-driven applications using Java/Scala
Home Page: https://pekko.apache.org/
License: Apache License 2.0
The query view implementation we use need access to certain Actor internals and therefore has to reside within the akka/pekko package.
As we want to use our persistence serializer for snapshots, this normally generates a warning which we want to ignore by using a whitelist to mark those serializers as accepted.
We need to produce a Pekko equivalent for samples
or start
guides and fix up the docs references to https://developer.lightbend.com/start/?group=
With #91 we have managed to replace the sbt-paradox-akka
theme with the standard one from paradox however it was just done by manually putting in all of the sbt-paradox-*
plugins. Ideally however we would like to create our own sbt-paradox-pekko
sbt plugin akin to sbt-paradox-akka
. This will become especially important when we actually want to create our own bespoke pekko doc theme which we will share within all of our pekko modules.
The only slightly complicating factor is that currently pekko core sbt build enforces JDK 1.8 (sbt doesn't even load unless SBT is its run with JDK 1.8 on the path). The problem here is due to the design of one of sbt-paradox
's core dependencies parboiled, you can only use specific versions of parboiled on JDK 1.8 versus later. In summary, pekko core only only use an outdated set of sbt-paradox-*
dependencies where as other pekko modules which are built with newer JDK's will only support the newer sbt-paradox-*
dependencies.
Thankfully I have managed to resolve this issue, assuming you have sbt-paradox-pekko
with the newer sbt-paradox-*
dependencies you can do this in pekko core's build.sbt
// We have to deliberately use older versions of sbt-paradox because current Pekko sbt build
// only loads on JDK 1.8 so we need to bring in older versions of parboiled which support JDK 1.8
addSbtPlugin("org.apache.pekko" % "sbt-paradox-pekko" % "HEAD+20230107-1453" excludeAll(
"com.lightbend.paradox","sbt-paradox",
"com.lightbend.paradox" % "sbt-paradox-apidoc",
"com.lightbend.paradox" % "sbt-paradox-project-info"
))
addSbtPlugin("com.lightbend.paradox" % "sbt-paradox" % "0.9.2" force())
addSbtPlugin("com.lightbend.paradox" % "sbt-paradox-apidoc" % "0.10.1" force())
addSbtPlugin("com.lightbend.paradox" % "sbt-paradox-project-info" % "2.0.0" force())
I already have a prototype sbt-paradox-pekko
plugin locally, it doesn't implement any theme but at least it brings in the sbt-paradox-*
dependencies and will allow us to enforce a consistent theme.
sbt-paradox-pekko
sbt plugin from local git repo to a temporary orgincubator-sbt-paradox-pekko
git reposbt-paradox-pekko
sbt plugin to the apache maven repo so it can be used in pekko repos. Can also use this simple project as a test bed for #85We need to produce a Pekko equivalent and fix up the docs
references to https://developer.lightbend.com/guides/akka-quickstart-scala/
Likewise for akka-quickstart-java
If we don't produce new g8 templates for pekko, we need to ensure that the docs either remove the refs to the g8 templates or we keep the refs to the akka g8 templates but ensure the text about them is correct (including mentioning the need to migrate the code generated for the generated projects).
Currently, lazyFuture
and lazySingle
is implemented with lazySource
which require a sub materialization, which can be avoid by composing or providing a dedicated graphstage.
The podling scan at https://incubator.apache.org/clutch/pekko.html currently reports a long list of errors. This seems to be because the project site at http://pekko.apache.org/ is currently missing.
docs/src/main/paradox/index.md
Currently the README and CONTRIBUTING files contain references to akka and lightbend. While it may be correct and proper to reference them as original sources for the code base, other uses seem inappropriate. This change should removed most of the akka and lightbend phrases from the documentation.
There are many classes that use Akka
in their names in the public API—like AkkaException
, AkkaClusterTypedSerializer
, AkkaJacksonModule
, etc.—as well as many tests that start with Akka
. The Akka
name should either renamed to Pekko
or removed entirely. In several cases these names are used in configuration as well.
This will also complicate the code migration for Akka projects, so we should take note of which classes have changed names.
Please document the CLA requirement, and explain how to fulfil it.
CONTRIBUTING.md line 91 mentions "Sign the CLA", but I can't find the CLA. There should be a link to the CLA and details of how to sign it.
Is the required CLA https://www.apache.org/licenses/contributor-agreements.html ? If so, does that process have to be followed (i.e., send a signed PDF to Apache) or is there bot assistance?
Separately - how does the project validate that CLAs have been signed by all contributors?
Thanks.
We don't yet want to remove deprecated code. Not for v1.0.0 anyway.
The @deprecated
annotations have Akka versions in them. We should probably fix the annotations to highlight that the version is an Akka version.
Classic remoting (old, hard to diagnose bugs, another axis in difficult remoting test suite)
Originally posted by @jrudolph in https://github.com/mdedetrich/akka-apache-project/discussions/8#discussioncomment-3904101
It's currently using Netty 3
There were probably be a number of iterations.
In projects/Publish.scala:
override lazy val projectSettings = Seq(
publishTo := Some(akkaPublishTo.value),
publishRsyncHost := "[email protected]",
credentials ++= akkaCredentials,
organizationName := "Lightbend Inc.",
organizationHomepage := Some(url("https://www.lightbend.com")),
sonatypeProfileName := "com.typesafe",
startYear := Some(2009),
developers := List(
Developer(
"akka-contributors",
"Akka Contributors",
"[email protected]",
url("https://github.com/akka/akka/graphs/contributors"))),
publishMavenStyle := true,
pomIncludeRepository := { x =>
false
},
defaultPublishTo := target.value / "repository")
The copyright header checks will need to be changed to allow Lightbend/Typesafe licenses and Apache licenses. The Lightbend/Typesafe licenses will remain on the old files but new files should have Apache licenses.
Scala 2.12 support (e.g. ByteString has forked sources for 2.12 and 2.13 that lead to various bugs in the past), see also https://github.com/mdedetrich/akka-apache-project/discussions/27
Originally posted by @jrudolph in https://github.com/mdedetrich/akka-apache-project/discussions/8#discussioncomment-3904101
And now JDK 21 is released too.
In #67 we renamed all of the classes that contain Akka
in the name to Pekko
. We should prune these renamed classes and figure out which ones are relevant for the migration script.
If you look at any ASF jar, you will find these 2 files.
We should change our config loading and reference.conf
to use pekko
everywhere rather than akka
. It looks like the config loading is mostly in the Settings
class, but that also exposes the raw Config
instance, which is used directly to load akka.*
configs in other classes.
It makes sense to have a way to support the akka
configuration prefix instead of or in addition to the pekko
prefix, but I know there was some question about whether to do it for 1.0. Given that config loading is mostly centralized it should be relatively simple to do.
Update README.md
and CONTRIBUTING.md
to clearly describe the current state of the project and how best to contribute to it.
We want to encourage people to help get Pekko to v1.0, and ensure it's clear that this is being actively worked on. We don't want to discourage people with inaccurate docs, or by appearing to claim Pekko is ready for use now when it's not.
I'm keen to hear other folks' thoughts, but here are some things I think we could do to improve the situation:
incubator-pekko
first and not touching any of the other repos. This is quite important and not immediately obvious.milestone:1.1.0
for things that don't belong in the initial release; I think we should use blocked
for issues that are blocked, e.g., #101. I wonder if there's a way we can label priorities or classes of issues to make the list more manageable?I also think we should try to get the complete list of things needed to reach v1.0 raised as issues, rather than relying on memory and mailing lists. That way we have an accurate work list, and we can tell folks "check GitHub for the current list of open issues, read the discussion, and dive in".
Feedback welcome - I'm new to this project and am probably missing important context. Thanks!
As discussed in #104 (comment), due to a current limitation in sbt, when doing a cross publish amongst Scala versions using the +
prefix it generates a separate timestamp for each Scala version where as ideally we should have a unique timestamp for an entire single publish operation.
A workaround as described in https://stackoverflow.com/a/21062454/1519631 is to pre-save the unique timestamp to a file and then read that timestamp along with a custom command alias.
Create a migration guide explaining to a user of Akka how to migrate their project to Pekko.
We hope to automate as much of this as possible under #22 but first we need to determine the steps and lay them out so early adopters can follow them and gain experience.
This should be documented in docs/src/main/paradox/project/migration-guide-akka-pekko.md
, linked from migration-guides.md
in the same location, and also linked prominently from the GitHub homepage README.md
and the project homepage docs/src/main/paradox/index.md
.
Steps include:
"com.typesafe.akka"
-> "org.apache.pekko"
akka-actor_2.13.jar
-> pekko-actor_2.13.jar
import akka.actor
-> import org.apache.pekko; import pekko.actor
- see #58Akka*
to Pekko*
- see #67akka
-> org.apache.pekko
, if the codebase inserts code into the Akka namespacepekko
key - see #63Under ASF guidelines, projects deliver source releases. Binaries like jars are a convenience.
See https://logging.apache.org/log4j/2.x/download.html for an idea of what the official downloads are meant to look like.
We will deliver jars to Maven Central too - but we also need to these source and binary distributions - typically in tgz and zip formats.
https://github.com/apache/daffodil appears to use sbt-native-packager plugin to create these. Release are downloaded from https://daffodil.apache.org/releases/3.4.0/
https://github.com/apache/incubator-nlpcraft also has a sbt build (not many ASF projects do) - but it also has a maven build and it isn't immediately clear how they package their distros.
There are other sbt plugins that may be a better fit - https://index.scala-lang.org/xerial/sbt-pack is one worth looking at
The source archive will probably just be a snapshot of the files in the git repo at release time - possibly with some stuff pruned. We should probably have a separate markdown file that describes the sbt commands to build the jars and docs.
The binary archive is a bit more problematic. For an app like Apache Spark, the bin archive provides a 1 stop solution for getting all the jars and the shell scripts to run spark-submit, the Spark REPL, etc.
A Pekko binary archive would include all the Pekko jars built for this Git repo and all the dependency jars. We should probably aim to have one or more sample apps and the shell (or sbt) scripting necessary to run those sample apps. These sample apps can be very simple examples that just prove that the jars all work together.
In #60 we managed to get nightly builds published to the Apache directory. While this is the official place to publish Apache nightlies, its technically not a maven repository (its just a directory where you rsync the contents).
Apache does have an official maven where you can publish snapshots too (see https://repository.apache.org/content/groups/snapshots/, https://repository.apache.org/ and https://infra.apache.org/publishing-maven-artifacts.html), so in addition to rsyncing our nightlies we should also publish this as an a snapshot to Apache's maven repo.
aim is that all the akka-*
jars will become pekko-*
jars
As a quick way to remove the akka branding, lets replace akka-paradox plugin with paradox basic theme. We can make better with more Pekko branding later.
Using this issue to gather some feedback before posting the proposal to the Apache legal JIRA
Current proposal (will be updated, based on feedback)
/*
* Copyright (C) 2009-2022 Lightbend Inc. <https://www.lightbend.com>
*
* Updates since 2022-10-24 are licensed to the Apache Software Foundation (ASF) under
* one or more contributor license agreements. See the NOTICE file distributed with this
* work for additional information regarding copyright ownership.
*
* Lightbend and ASF license this file to you under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software distributed under
* the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
* ANY KIND, either express or implied. See the License for the specific language
* governing permissions and limitations under the License.
*/
Next to including the Lightbend notice, changes form the default header text are
Updates since 2022-10-24 are
Lightbend and ASF license
So I noticed that when publishing Pekko we are doing so using JDK 11. While there is no problem with this, at the same time the current sbt build will refuse to load with a JDK that is newer than 1.8.
We should either pubilsh using JDK 1.8 (at least for the 1.0.x branch) or just remove the sbt check?
Artery UDP based on Aeron (hard to deploy, little used, one extra dimension in hard to stabilize remoting (and everything above like cluster, persistence etc) tests)
Originally posted by @jrudolph in https://github.com/mdedetrich/akka-apache-project/discussions/8#discussioncomment-3904101
The design blog: https://akka.io/blog/article/2016/12/02/streams-in-artery & https://akka.io/blog/article/2016/12/05/aeron-in-artery
Apache has certain requirements for releasing a public version. We should strive for as much automation as possible. This ticket should be an overview over all steps necessary and the progress on those items. Please add items as needed.
Let's only consider public releases like RCs and GAs here (but not snapshots).
(Please add your name and/or PRs and issues to the items as needed)
References:
In this PR #53 (comment) to get CI running we ended up having to use sbtx instead of plain sbt due to having to upgrade a github action. It turns out that the change to sbtx was that in the older versions of the github action, it was aliasing sbt
to sbtx
(see https://discord.com/channels/632150470000902164/922600050989875282/1042858091387043872). We should investigate into using pure sbt rather than sbtx since sbtx isn't really supported that much anymore
https://github.com/apache/incubator-pekko/actions/runs/3898732569
Will look into it soon, on meeting
Currently its possible to merge a PR even if the status checks fail or even in the small span of time before they get triggered. Now that we have CI running properly, we should update the Require status checks to pass before merging
under Branch Protection Rules
for the main branch so that people cannot easily merge PR's if one of the status checks fail.
@pjfanning I am not sure if this is to be done directly under github actions or whether it needs to be organised with an INFRA ticket/.asf.yaml
?
Remove any remaining references to Lightbend or Akka in the documentation (including logos)
Remove external links to Akka books, blog articles, etc.
While looking at #103 I noticed that the pekko project already happens to have infrastructure setup to publish nightlies (aka snapshots) to an rsync directory in the exact same manner that was implemented in #60.
This is done by using https://github.com/lightbend/sbt-publish-rsync and you can see the details at https://github.com/apache/incubator-pekko/blob/main/project/Publish.scala.
We should either investigate using the sbt-publish-rsync plugin or remove it entirely from pekko since https://github.com/apache/incubator-pekko/blob/main/.github/actions/sync-nightlies/action.yml exists. My own personal preference would be to use sbt-publish-rsync since its far simpler (due to it being done by sbt the command to publish would be quite trivial especially when combined with publishing to Maven snapshots directory, see #103) and I like reducing the direct dependance on shell scripts. From a cursory glance of looking at https://github.com/lightbend/sbt-publish-rsync/blob/master/src/main/scala/com/lightbend/sbt/publishrsync/PublishRsyncPlugin.scala#L45-L49 it shouldn't be problematic however there is a risk that changes might need to be done to sbt-publish-rsync plugin for Apache's use, if needed this does present an opportunity to create an sbt-publish-rsync-apache plugin.
@seglo @pjfanning Thoughts?
There is a performance issue for Java users when using jackson-module-scala v2.13.x. Not too many users have reported issues but it might be best to update any v2.13 dependency to v2.14.1 (or newer version). We can keep the v2.11.4 dependency for Scala 2.x. We can upgrade to jackson v2.14.x for all Scala versions after Pekko's initial release.
Upgrade Jackson dependency to 2.13.4 for
1: CVE-2020-36518
2: CVE-2022-42004
3: CVE-2022-42003
We still have the old Akka for templates when issues/pull requests are made (see https://github.com/apache/incubator-pekko/tree/main/.github/ISSUE_TEMPLATE), should remove/replace them as necessary.
The github rules should not allow merging of pull requests when there are
I am not certain how to configure this on the Apache git system.
As discussed in https://github.com/mdedetrich/akka-apache-project/discussions/28, pekko core will need to handle wire incompatibility issues arising from the change in the akka://
address prefix to pekko://
. There may also be other wire incompatibility changes, for example if we decide to change the default 2552
port and anything else that we may have missed.
The solution will also need to play with the release strategy that we decide for pekko. Since the previous discussion I have done some thinking about it and at least to me the most amicable solution would be to make these fields configurable with typesafe config with different default values depend on the pekko release branch, i.e.
For pekko 1.0.x we would have
acceptPrefix = ["akka", "pekko"] // The prefix's to use when checking against incoming requests
sendPrefix = "pekko" // The prefix to use when making send requests
And for pekko 1.1.x (on the assumption that we don't want to accept migrating current Akka clusters to this Pekko branch by default)
acceptPrefix = ["pekko"] // The prefix's to use when checking against incoming requests
sendPrefix = "pekko" // The prefix to use when making send requests
(Note that the same strategy can also be applied to the port 2552`.
This means that when doing a rolling upgrade from an existing akka cluster to pekko 1.0.x you would temporarily change sendPrefix
to "akka"
(so that currently existing Akka clusters don't refuse connections from new pekko nodes) and once the rolling upgrade is complete then you would change sendPrefix
to "pekko"
. After that point you are then free to upgrade to pekko 1.1.x with acceptPrefix
as ["pekko"]
without any problems and making this configurable with typesafe config means that if users have bespoke update requirements its relatively easy for them to handle it.
This also leaves the door open to first deprecating the acceptPrefix
/sendPrefix
settings later down the Pekko 1.1.x release cycle and then at some point in the future hardcoding it as pekko
.
We should provide some automated migration that users of akka can use that adapts their codebase to use pekko.
This migration should automatically
These docs are Lightbend specific.
https://lists.apache.org/thread/8orjtlx2w42y3j45pswmf9nbtf64gp77
Change to
Now that we have github discussions enabled in incubator pekko, we should try to see if its possible to migrate relevant discussions from https://github.com/mdedetrich/akka-apache-project/discussions to https://github.com/apache/incubator-pekko/discussions.
On the right hand side there is a "Transfer this Discussion" link, I tried doing it myself but since I don't have write permissions to this repo I cannot move it. @pjfanning I just added you as a collaborator to https://github.com/mdedetrich/akka-apache-project, let me know if this ends up working out. If it doesn't I think we will just have to start from scratch again.
I think only Akka is there, but not pekko.
Which will help reviewing.
demo: real-logic/agrona#268
https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/
We need to rename the package from akka
to either pekko
or org.apache.pekko
(this is still being decided). One thing to note is that this will break some tests, i.e. https://github.com/apache/incubator-pekko/blob/6680c47dcc2305906a44d7794081682211d7ee0b/akka-actor-tests/src/test/scala/akka/util/ByteStringSpec.scala#L983-L995 is dependant on the fully qualified class name so it will also need to be updated when the package changes (there may be other examples of this as well).
Building the project on windows using sbt compile fails with the following exception:
[info] welcome to sbt 1.7.1 (Temurin Java 1.8.0_332) [info] loading settings for project incubator-pekko-build from plugins.sbt ... [info] loading project definition from C:\Entwicklung\incubator-pekko\project [info] loading settings for project pekko from build.sbt ... [info] resolving key references (62652 settings) ... java.util.regex.PatternSyntaxException: Unexpected internal error near index 1 \ at java.util.regex.Pattern.error(Pattern.java:1969) at java.util.regex.Pattern.compile(Pattern.java:1708) at java.util.regex.Pattern.<init>(Pattern.java:1352) at java.util.regex.Pattern.compile(Pattern.java:1028) at java.lang.String.split(String.java:2380) at java.lang.String.split(String.java:2422) at org.apache.pekko.PekkoValidatePullRequest$$anonfun$$nestedInanonfun$buildSettings$1$1.applyOrElse(ValidatePullRequest.scala:49) at org.apache.pekko.PekkoValidatePullRequest$$anonfun$$nestedInanonfun$buildSettings$1$1.applyOrElse(ValidatePullRequest.scala:47) at scala.PartialFunction.$anonfun$runWith$1$adapted(PartialFunction.scala:145) at scala.collection.Iterator.foreach(Iterator.scala:943) at scala.collection.Iterator.foreach$(Iterator.scala:943) at scala.collection.AbstractIterator.foreach(Iterator.scala:1431) at scala.collection.IterableLike.foreach(IterableLike.scala:74) at scala.collection.IterableLike.foreach$(IterableLike.scala:73) at scala.collection.AbstractIterable.foreach(Iterable.scala:56) at scala.collection.TraversableLike.collect(TraversableLike.scala:407) at scala.collection.TraversableLike.collect$(TraversableLike.scala:405) at scala.collection.AbstractTraversable.collect(Traversable.scala:108) at org.apache.pekko.PekkoValidatePullRequest$.$anonfun$buildSettings$1(ValidatePullRequest.scala:47)
The problem is caused by using the file.separator system property as regular expression in ValidatePullRequest.scala:49. On Windows this is the backslash which is not a valid regular expression.
The problem can be fixed by using a hardcoded slash as splitting regular expression. This also works on windows.
https://github.com/apache/incubator-pekko/blob/main/cluster/jmx-client/pekko-cluster
akka
refs in the scriptManifestInfo(this).checkSameVersion("Akka", allModules, logWarning = true)
Need to work out what to replace this with
part of #16
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.