InvocationTargetException with java.net.http.HttpClient on v1.2+ #1621
Comments
|
Does this only happen inside kubectl? Are you able to provide a repro using just Docker that I can run locally? I don't have kubectl on my machine. |
|
It only happens when running inside this specific Kubernetes Cluster, that's the problem. The command I provided is just the shortest self-contained command that evaluates I just tried it inside another cluster and it works just fine. I have not found any other environment, be it containerized, directly on my machine or otherwise where it fails. It's just this specific cluster. Given the nature of the exception, is this even something where Babashka itself could be at fault or is the root problem almost certainly inside GraalVM and we can't do much more than track it here? |
|
Hard to say. You could try the JVM version of babashka.http-client in the cluster and perhaps it will give a better error message? Does httpkit work for the same request? babashka.http-client is based on java.net.http. |
|
I found oracle/graal#7182 now, and can confirm that the environment in question has lines with more than 2 I will try to narrow it down with the JVM version tomorrow. |
succeeds with temurin-{20,17,11}-bullseye, fails temurin-8-bullseye with Even Docker tags from over a year ago ( Interestingly, httpkit has the same problem in the same versions: The good news is that with your hint in the direction of To reproduce locally one would likely need to find a way to start a process so that it sees lines with more than 2 My next thought was trying to rebuild the babashka image with a newer GraalVM but Anything I can do to clear this up further or do we just wait for a new GraalVM release and that graal issue? |
hxtmdev
changed the title
|
Please try to reproduce this with a JVM as well, to exclude the possibility that this is a bb issue. |
|
The first repro in my last message was all JVM, no Babashka. The I could not reproduce with JVM on I now also tried the direct HttpClient repro and could not reproduce that on |
|
Failure with JDK8 is expected since java.net.http wasn't there at the time. Try the linux static binary instead to see if that helps. This should be the same binary that goes into the alpine image. You can download it from Github releases as well. Also invoke bb with |
|
|
|
Rearranged things so Clojure gives a reflection warning without the type hint but does not with the hint, results are the same |
|
Tossing the currently advertised GraalVM version's
big stacktraceSo it appears that while the problem also occurs in Babashka, it's not specific to Babashka's use of GraalVM but rather a general GraalVM issue. Do you want to keep this open until a working GraalVM version is used or close it? |
|
Currently afk but try to invoke the constructor via reflection api
…On Wed, 6 Sep 2023 at 12:56, Daniel Höxtermann ***@***.***> wrote:
Tossing the currently advertised <https://www.graalvm.org/downloads/#>
GraalVM version's native-image at a plain Java
public static void main(String[] args) throws Exception {
System.out.println(
HttpClient.newHttpClient()
.send(HttpRequest.newBuilder().uri(URI.create("https://babashka.org/")).build(),
HttpResponse.BodyHandlers.ofString()));
}
works for the "17" and the "20" versions.
—
Reply to this email directly, view it on GitHub
<#1621 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACFSBU5BVUV77RLAMVBW63XZBJFRANCNFSM6AAAAAA4MHTLNE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
In case you don't get edits via mail: I tested that wrong, it can be reproduced with plain Java+GraalVM. The stacktrace looks similar to the GraalVM issue. |
Let's keep it open but I recommend submitting your repro to the Graal issue (oracle/graal#7182) as well. |
|
bb is compiled using GraalVM 21 nowadays, can you check if this was fixed? |
|
I'll re-open if you confirm this needs attention again. |
|
Confirmed working starting from |
version
Docker image, works up to
1.1.173, fails from1.1.174-SNAPSHOTonwardplatform
Linux 5.4.0-149-generic Kubernetes pod, nodes run Ubuntu
problem
I am working with a Kubernetes cluster where
babashka.http-client/getthrows anInvocationTargetExceptioninside pods (no access to the bare node).babashka/babashka:1.1.173worksbabashka/babashka:1.1.174-SNAPSHOTdoes notbabashka/babashka:1.3.184does notbabashka/babashka:1.3.185-SNAPSHOTdoes notbabashka/babashka:1.3.185-SNAPSHOT-alpinedoes notSo my first guess would be GraalVM 22.3.1.
The new versions work locally and in a Docker container on my dev machine.
The cluster can run other code like
(+ 1 2)just fine, even with the new versions. It's just the combination of whateverhttp-clientdoes, newer versions, and this environment that seems to be the problem. That's why I'm reporting it here, thehttp-clientcode does what it should in other environments so I figured it's probably something in babashka itself.repro
kubectl run -ti --rm --image babashka/babashka:1.3.185-SNAPSHOT bb -- sh -c "sleep 2; bb '(babashka.http-client/get \"https://babashka.org/\")'"expected behavior
kubectl run -ti --rm --image babashka/babashka:1.1.173 bb -- sh -c "sleep 2; bb '(babashka.http-client/get \"https://babashka.org/\")'"The text was updated successfully, but these errors were encountered: