Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove akka from runtime #8953

Merged
merged 36 commits into from
Feb 19, 2024

Conversation

Akirathan
Copy link
Member

@Akirathan Akirathan commented Feb 2, 2024

Closes #8222

Pull Request Description

There are two projects transitively required by runtime, that have akka dependencies:

  • downloader
  • connected-lock-manager

This PR replaces the akka-http dependency in downloader by HttpClient from JDK, and splits connected-lock-manager into two projects such that there are no akka classes in runtime.jar.

Important Notes

  • Simplify the downloader project - remove akka.
  • Add HTTP tests to the downloader project that uses our http-test-helper that is normally used for stdlib tests.
  • It required few tweaks so that we can embed that server in a unit test.
  • Split connected-lock-manager project into two projects - remove akka from runtime.
  • Native image build fixes and quality of life improvements:

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@hubertp
Copy link
Collaborator

hubertp commented Feb 2, 2024

Are you aware of #8934? You can probably more or less revert the commit that introduced it.

@Akirathan Akirathan force-pushed the wip/akirathan/8222-remove-akka-from-downloader branch from c59bffc to bd71fd9 Compare February 9, 2024 13:46
@Akirathan
Copy link
Member Author

Are you aware of #8934? You can probably more or less revert the commit that introduced it.

Thanks for pointing that out. Let's first try to use only JDK. I think that the HttpClient provided by the JDK is more than capable of handling few requests. There is no need to add yet another dependency.

@Akirathan Akirathan added the CI: No changelog needed Do not require a changelog entry for this PR. label Feb 9, 2024
@Akirathan Akirathan changed the title Remove akka from downloader and from runtime Remove akka from downloader Feb 13, 2024
Seems like some leftover.
public void noAkkaDependencies() {
try {
Class.forName("akka.actor.ActorSystem$");
fail("akka.actor.ActorSystem should not be on the classpath");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is a bit clumsy. If akka.actor.ActorSystem is not on the class-path, it only means that runtime/test does not have akka dependency, it does not check that there are no akka classes in runtime.jar. However, I still think that this test is useful. Moreover, I have manually checked that runtime.jar does not contain any akka classes.

@Akirathan Akirathan added the CI: Clean build required CI runners will be cleaned before and after this PR is built. label Feb 14, 2024
@@ -1,6 +1,6 @@
package org.enso.downloader.http

import akka.http.scaladsl.model.HttpRequest
import java.net.http.HttpRequest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using class from JDK is a great step forward!

Comment on lines +12 to +19
/**
* This utility class adds support for {@code multipart/form-data} content-type as there is no such
* support in {@code java.net.http} JDK.
*
* <p>Inspired by <a href="https://stackoverflow.com/a/56482187/4816269">SO</a>.
*/
public class FilesMultipartBodyPublisher {
public static HttpRequest.BodyPublisher ofMimeMultipartData(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like us implementing such utilities ourselves instead of using existing well-tested solutions.

This works nicely for simple cases, but how do we guarantee that it will work well in general? Should we try testing it as well as an existing solution would? That adds a lot of maintenance burden on us.

Example 1: the boundary.

I see it is generated as a UUID. I guess it is extremely unlikely that the same UUID would appear inside of the contents of one of the parts submitted as part of this form, but it is not 100% guaranteed.

I'm a bit nitpicky here as indeed it is going to be very unlikely to run into this kind of collision. But was this even considered when this code was written?

This is a seemingly simple operation but it may raise many uncertainities like the example above. IMO relying on an existing solution is better as it does not put the maintenance burden of ensuring this solution is bug free, on us.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The downloader project makes only a very specific kind of HTTP requests and expects a very specific and narrow set of HTTP responses. We are in a full control over these reqs and responses. This project is only used for library uploading and downloading, which is also covered by tests.

Implementing a very simple handling of multipart/form-data is a minimal price we have to pay here. Please keep in mind that we are trying very hard, in general, to reduce the number of classes that will eventually get into runtime.jar.

Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

I'm a bit worried about rolling our own URI and Multipart body handling - these seem like they are simple, but there are traps hidden there.

But I don't want to be complaining too much - we should be fine with these for now and they are not heavily used anyway.

I'd appreciate if we put a comment for future maybe, so that once we start using these more, we could revisit and see if any 'reinforcements' are needed there.

@hubertp
Copy link
Collaborator

hubertp commented Feb 15, 2024

@radeusgd Didn't you mention that at some point you moved from JDK to Apache because of some bug in the former? Is that fixed now?

@radeusgd
Copy link
Member

@radeusgd Didn't you mention that at some point you moved from JDK to Apache because of some bug in the former? Is that fixed now?

IIRC that was this bug https://bugs.openjdk.org/browse/JDK-8231449 it seems to indeed be fixed in Java 14 (we've been using Java 11 back then and I think it was never backported to versions <13).

@Akirathan Akirathan force-pushed the wip/akirathan/8222-remove-akka-from-downloader branch from 891587a to c5cc2dc Compare February 16, 2024 13:20
@Akirathan Akirathan force-pushed the wip/akirathan/8222-remove-akka-from-downloader branch from 3e12343 to ba0a69d Compare February 19, 2024 12:33
@Akirathan Akirathan mentioned this pull request Feb 19, 2024
1 task
…oader

# Conflicts:
#	tools/legal-review/engine/report-state
#	tools/legal-review/launcher/report-state
#	tools/legal-review/project-manager/report-state
@Akirathan Akirathan added the CI: Ready to merge This PR is eligible for automatic merge label Feb 19, 2024
@mergify mergify bot merged commit 96082c3 into develop Feb 19, 2024
25 of 29 checks passed
@mergify mergify bot deleted the wip/akirathan/8222-remove-akka-from-downloader branch February 19, 2024 16:39
mergify bot pushed a commit that referenced this pull request Feb 26, 2024
In PR #8953, in commit ba0a69d, I have introduced argument files to the `native-image`. In this PR, let's try to upload these argfiles as artifacts on GH, so that we can inspect them later.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Clean build required CI runners will be cleaned before and after this PR is built. CI: No changelog needed Do not require a changelog entry for this PR. CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove akka dependencies from runtime project
4 participants