Multi-threaded access not allowed when define Java.type and javascript function in karate-config.js on karate 1.3.0+

[ericdriggs]

Minimal viable example:
https://github.com/ericdriggs/karate-multi-threaded-access-bug

Versions effected: 1.3.0, 1.4.0.RC1

Versions not effected: 1.2.0

Steps to reproduce:

• karate 1.3.0
• java 11
• define Java.type and java functions in karate-config.js using karate.callSingle
• multi-threaded access to javascript function

Mitigations:

• use karate 1.2.0 or 1.4.0.RC1
• use karate.call instead of karate.callOnce

Test machine:

• Mac m1

[ptrthomas]

@ericdriggs thanks ! was able to replicate this in our local test suite, refer attached commit

we now synchronize in one more place to make sure the graal function evaluation for config-js is single-threaded

[ptrthomas]

1.3.1 released

[ptrthomas]

@ericdriggs turns out the extra "global lock" we added to fix this may have been overkill and would lock every evaluation of karate-config.js. and we got a report in #2222 which I suspect is a consequence

so I have just removed the lock. instead, we post process any JS functions that a karate.callSingle() may attempt to return. I think this is a reasonable compromise. more details in this commit: 8cd5a78

would be great if you can check if your use of karate.callSingle() is ok

[ericdriggs]

@ptrthomas
Yeah I've noticed that when I tried bumping to 1.4 the tests took 2x as long, so we're still on 1.2 for now.
Glad to hear you removed the lock -- multi-threaded access to a shared context in graal is certainly a pain.
Don't fully grok changes you linked -- in general seems that some sort of copying to prevent shared access without mutexes needed. Hope that's the change you've made.

Is there a new RC to test?

[ptrthomas]

@ericdriggs yes you are right. I will release an RC next week