-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
JS / Multi threaded access error when using karate.callSingle() #1515
Comments
@JoshSchreuder well, it would have been nice if you tested the last RC as requested. I'm going to wait on this as windows is difficult for me to troubleshoot :| anyone reading this is welcome to submit a PR it is quite likely that if you prefix |
note to all - this appears to be a very un-conventional way of deriving paths: karate.callSingle(karate.properties['karate.config.dir'] + '/features/auth/auth.feature'); quite likely there are alternate / better ways such as not using the edit: I would even try omitting the |
@ptrthomas yeah my apologies, I didn't have anything setup to build a new JAR off the source at the time. Anyway, switching to |
@JoshSchreuder awesome - thanks ! yes, I'll close this and not add a note to the release-notes as the likelihood of others running into this is really low later - do consider suggesting any tips we can add for windows users using the stand-alone - that we can add to the docs as to how to better structure projects. |
Got it working with a combination of custom argument, and My usecase is admittedly a bit unusual perhaps, I am running the JAR file from the VS Code extension via command. A couple more things I found that I didn't spot in the breaking changes, not sure if bugs or intentional changes but I can put a repro up if you want:
|
use headers should propagate, so I'll need more details |
That was my first thought, but that didn't work either:
I'll put up a repro case for this. |
cc @kirksl to be aware of VS Code extension usage actually we prefer |
Oh I worked out the length thing, needed to change to |
Oh and finally... getting an exception when running in multi threaded mode with my
I'll try and repro this minimally also. |
ugh yes, that's an edge case with the just for completeness, this should work (long story): and the exception is very bad news :| cc @joelpramos if your callSingle is setting up functions, try removing those and stick to pure data. else well. we need to dig |
My callSingle runs a feature that does a bunch of auth calls to grab user tokens for the pending test run. I guess it's probably reproducible with an API call inside callSingle but I will give it a go and see if I can minimally repro it. |
that tries to simulate edge cases that the graal engine dont like ref: https://stackoverflow.com/q/66651979/143475 and #1515
@JoshSchreuder & @joelpramos - we have another report of the I've asked the OP to comment in this thread. and meanwhile I tried my best to replicate the situation of a callSingle + feature + HTTP call in our "parallel" test that already mixes a and it still seems to work fine. but hopefully y'all will be able to see what's that extra bit in your tests that causing this problem. |
@JoshSchreuder do you have a karate-config.js / karate-base.js with functions and are you using those inside the feature called by callSingle()? @ptrthomas I might only be able to look at this on the weekend or later but was something that I don't think your additional tests included. |
reopening and making sure @aleruz is part of the conversation :) |
My karate-config, minimally, is basically what's in https://github.com/JoshSchreuder/karate-repro in terms of callSingle. The results of the callSingle get stored and reused across test runs (basically a authenticated token cache). karate-config.js callSingle -> auth.feature -> karate.config.js store variable |
@JoshSchreuder I'm on a mac and I made this one change to function fn() {
karate.callSingle('file:features/auth/auth.feature');
} and ran this command. btw karate has some improvements, it will look for
and everything ran fine for karate 1.0. which brings me to ask cc @aleruz by any chance are you both on windows ? EDIT: I made sure to add a second scenario to ensure they run in parallel. note that you get a |
@ptrthomas I am on Mac as well. I am trying to debug right now, and found two things which seems to change the result of my test making it pass. But I need a bit more time to test it. At the moment, my suspicion is on two parallel runners which I created with different tags but which may be interfering in some tests (that was an experiment I did and that did not create issue with 0.9.6). Removing one of the two, seems to let the test pass now. But, I want to be sure. Will keep you posted here. |
So, the
as said, with "1" it works. With more, it fails. In the feature called with |
FYI the single line of code with which I was able to reproduce: 43d8bf7#diff-6365020418ae2a40912aa4f001d49d2bbf988410171accd760333fea2b5b98acR3 |
Seems in my use case this is making no difference. :-( |
@aleruz that doesn't help at all. I'm proposing to set a rule that |
@aleruz question on your scenario, you said your feature called by callSingle() does a call twice to the same feature with different parameters. Few questions on that - are those parameters reused within that call and how does that loop work? Any chance you can drop a screenshot here of that piece only and take out any private names / paths you might have? |
here added a second callSingle which uses results of the first callSingle and the first callSingle includes a function in the results
problem 1: very bad bug in initMagicVariables where we were setting __arg to a wrapper not the raw object problem 2: we had completely missed hydrating / re-attaching magic variables hopefully that explains the randomness, the incoming __arg may contain nested objects etc
okay one more time, my last commit is again a simple one but with one critical fix for "magic variables" that I really hope is the end of it would be great if everyone here can try this version |
Tested the scenarios I had with that additional fix and works great. Thanks @ptrthomas , will check in a few things on top of that test for completeness that I tried in my local. @aleruz keep us posted on your results. |
sorry I can't make sense of what @aleruz is saying. is that a runnable example ? can someone translate all that above into a simple example which I can use to replicate the problem ? can anybody else run the latest and confirm the results ? |
@ptrthomas : I did run my code in my environment with the commits you and @joelpramos did. This did not fix my specific case. Then @joelpramos asked me for screenshots or code examples to understand the structure, and I committed my tests, which of course won't work because they miss all the configurations. As I said, I found a workaround and can work with that (explained in my comment above). I tried to reproduce this structure in the examples in https://github.com/aleruz/karate-call-single-bug/tree/main/src/test/java/examples/users
but still no luck. Will try further tomorrow. |
@aleruz okay no worries ! sorry I'm just keen to get this solved. myself and @joelpramos are confident that the latest version solves all issues, so I really hope you haven't missed any step when building. maybe we can take this offline and get on a call next week if you are okay with that. meanwhile I'm thinking of releasing over the next 2 days, there are a few important fixes, and we can hopefully reduce the cases where there are issues. one thing would help. if you change all your |
@ptrthomas I'll get another try tomorrow. For building, I did remove the 2.0.0 package in the local maven, then fetched your commit (exactly the commit ID), built as suggested in the "development" page, run the test again. |
@aleruz one more thing - and this is important. are you calling any Java code that returns Java objects that contain data coming from karate and/or JS. in that case, ALL BETS ARE OFF :) |
…1515 and also make sure that cached result if an exception is detached from the js engine
one more try and a small code-change again: 4bac49c#diff-12a620743447978c823403798f5740cacc1eb990fb5603d015760002e5096431R175 I realized that line 175 (before this commit) could be entered by multiple threads (after a callSingle result was cached) anyone who can test this and report back would help !! I know I keep saying this - but this time I think it should work ... |
when we re-attach a callSingle result into the context explanation: when we detach, we just patch any js functions and replace them with JsFunction but we leave parent maps and lists as it which means when we attach and update existing object references - the cache gets corrupted the next time we try an attach we will encounter a stale graal value etc where we expected a JsFunction solution is to deep-clone when we attach and this should be required only for a callSingle
@ptrthomas 🎉 seems this time is THE time 🎉 In my case no more issue! 👏🏻 Sad I could not reproduce it in an own separate example. |
thank you @aleruz ! I think we are ready to release |
- make sure that when we detach, it is always a deep-clone - use the same attach routine for a callonce - make sure that the async scenario-listener that occsionally sees that js thread issue in ci does a detach-deep - some defensive programming for the attach deep routine
dont un-necessarily attach for callonce now we dont need the extra synchronize for callsingle
1.0.1 released |
I mentioned this issue here:
#1373 (comment)
Thought it might be fixed in #1480 in 1.0 but it appears not having tried the release version this morning.
Here is a minimal repro repo:
https://github.com/JoshSchreuder/karate-repro
0.9.6
java "-Dkarate.config.dir=C:\Temp\karaterepro" -jar "C:\temp\karate0.9.6.jar" "C:\Temp\karaterepro\demo\api"
is working with no issues
1.0.0
java "-Dkarate.config.dir=C:\Temp\karaterepro" -jar "C:\temp\karate1.0.jar" "C:\Temp\karaterepro\demo\api"
fails with
It looks like it's appending the test directory to the start of the
callSingle
call? Couldn't find anything in the breaking changes about this, so not sure if it's intentional or a bug.I'm on Windows 10 x64 21H1.
Java:
The text was updated successfully, but these errors were encountered: