Think I can probably do a workaround by defining a javascript object and then defining individual functions on that javascript object to simulate static method interop, only doing Java.type inside the function call
Still, an interesting race condition, and a crying shame that graal has such a ridiculous default without a flag to turn it off.

thanks, this helps cc @joelpramos

@ericdriggs so - this is a won't fix. I've added this below to the documentation. given the way graal js behaves today there is no way we can get a java instance created on one thread to work across threads. anybody is welcome to find a way.

I've tweaked our existing parallel troublemaker test to replicate this if you comment out one line in the offending karate-config.js.

@ptrthomas far from me to say this solves everything (cause you know, Graal) but either of lines added in the catch in the screenshot below solves the specific reproduce unit test you added (either this.JS.context.asValue(value) or the commented line Value.asValue(value.asHostObject()), both work).

I think it's worth adding Value.asValue(value.asHostObject()) (avoids access to JS.context) on the catch and/or slightly modify the logic / catch method (and warn message).

@joelpramos that's a neat trick and I'm still not sure how it works, and glad I had the tests lined up. do review !

@ptrthomas
Still seeing this issue when using karate 1.1.0-RC1

ericdriggs/karate-parallel-runner-concurrent-access@81003b0

mvn clean test

...
[ERROR] Failures: 
[ERROR]   ParallelRunnerTest.testParallel:18 classpath:examples/parallel-runner-always-fails.feature:9
karate-config.js
Multi threaded access requested by thread Thread[pool-1-thread-1,5,main] but is not allowed for language(s) js.
.....

not planning to look at this immediately. any help welcome

@joelpramos the second point (init()) is no longer going to lock with the latest changes as far as I can tell - but you can confirm

the rest - you are welcome to prove there is a significant impact (I think not, all the processing is in-memory, and based on the build run-time) and make changes. this has not been easy to work on

Like you I'm not too fussed about it. The one on the init() raised more one of my eyebrows. I think the other logging / naming comments are still valid.

Hopefully the battle is over.

@joelpramos tried to remove the sync on recurseAndAttach() but couldn't. so over to you now :) I'm done for today

tried a few more things as you can see in the prev commit

a tip: running this can replicate the problem easily on local

mvn test -f karate-core/pom.xml -Dtest=Parallel*Test

Thanks for your continued work on this.

Thanks for your continued work on this.

indeed!

@ptrthomas I added a few comments in the commits but it's mostly to wrap my head around the changes you are doing so that when I have some time to fetch the code and iterate on this I'm not totally lost

just released 1.1.0.RC4 - I request everyone to re-test this once cc @aleruz

Pass - Validated on RC4 for MVC project and my own projects.

all please see this comment on the other related issue. it is possible to use java functions (not just classes) safely and work around some of the graal limitations: #1633 (comment)

@ptrthomas
My sample project is still passing unchanged on both RC4 and a local build of the latest develop.
Can you please clarify if the function recommendation is recommended means of java interop in callOnce? The additional boilerplate isn't pretty since it requires duplicate interface at both the class and js level but if that's what's required I understand.

@ericdriggs reco is only if you

a) use java functions ("use" means you actually call the function in parallel scenarios)
b) and callonce or callsingle
c) you really want to "save some typing" by referring to functions instead of passing a Java.type() around and using that at point-of-need

I also feel the extra code is only in the Java side. the JS side is the same one or two lines