The following code works fine with a single thread:
* def validateAricle = 'file:features/Articles.feature#validateArticle'
* def articles = {"id": 12}
* call read(validateArticle) articles
but having more than one thread I get the following error
Multi threaded access requested by thread Thread[pool-5-thread-1,5,main] but is not allowed for language(s) js.
This error can be reproduced from version 1.0.1 (it also happens to me in version 1.0.0). Before updating to version 1.0.0 I had no problems reusing features
Yes, we hope we have fixed this in the develop branch: https://github.com/intuit/karate/issues/1558
The best thing you can do now (and to help expedite a release) is to follow the developer guide, build from source and then verify that it works for your edge case: https://github.com/intuit/karate/wiki/Developer-Guide
If not, it is very important that you follow this process to replicate: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
And I hope that this can be a reminder to everyone that please test the RC versions that we spend so much time on releasing (a few months for 1.X).
Related
I'm running a big campaign with about 500 tests targeting the API of an orchestration tool using both a parallel and a sequential runner for some of the tests which need to be executed in sequence.
This works fine using the Karate version 0.9.6.
As soon as I upgrade the Karate version to anything higher than v0.9.6, the results of the tests in the parallel runner always consists of a significant portion of failing tests. The sequential runner does not have any issues. Also the parallel runner seems to work fine only if I set it's threadCount = 1.
If the threadCount is higher than 1, the runner seems always to start well but after some time there are quite some failed transactions without any further details like this: http call failed after 55 milliseconds for url: http://...
This is all the error log I have as there is not more than this entry for each failed test (around 40% of the full campaign).
As soon as one thread starts with an issue like that, basically all other threads follow to do the same and make their tests fail for the same reason (only with a slightly different number of milliseconds). While investigating the problem I was not able to identify a common pattern (like always starting with the same test failing, etc.).
Did anybody else face similar issues with Multithreading using a higher version than v0.9.6?
Is there a way to get more detailed logs? I use the value DEBUG in the logback-test.xml
Is there any recommendation of what to try to make it work?
Please don't hesitate in case you need more information.
I would be happy for any kind of help regarding this as I would like to benefit of the new karate-gatling facilities for Performance Testing which is only available in the latest versions of Karate.
Many Thanks for your reply!
we run 8 threads on karate 1.1.0 with no issues at all. Do you have some extra logs? So you don't get same timeout error http call failed after 55 milliseconds for url: http://... in lower version the running multithreads ?
Shot in the dark here, but do some of your scenarios have the same title? If so, try making them all unique and see if that solves the issue.
More logs will be useful. Its very little information here.
I am not sure of the exact error but I faced similar issues sometime ago but that was caused due to race conditions especially if you are trying to use variables set by java methods. Are you using Java interop in your tests? If so worth checking how these are being used. A test may be trying to execute with a variable/parameter that is still in use by other tests when running in parallel. This wouldn't be an issue in sequential.
I am running into a MOCHA problem in reference to the book, Chapter 1, during the first run of MOCHA test. it saying that my /heartbeat is undefined and not a function. I have copied the book, and I have even backed dependencies back down to what the book used (not what is most current) and still having a failure. I have my development upto the point of the failure in the book on github here (https://github.com/EnergeticPixels/expressWebAppDev_packt.git). Can anyone help point me out my mistake??? It has to be something simple.
totally my fault. I missed a darn comma following the function name in the express/index.js file. Told ya it was a simple mistake.
I have created a POC program to exercise the JCR version handling with ModeShape on both 4.0.0.Alph4 and 3.8.0.Final. The version number is increased from 1.0, 1.1, 1.2 1.3, 1.4, and etc. Then I restored the version 1.2 and made changes to it. But I noticed that the new version number is 1.3.0 now. Should the new version number be 1.2.0 (since it is based on the original 1.2) or am I missing something from the program? Thanks!
I would have expected 1.2.1, so it looks like it might be a bug. Please report the issue in the project's bug tracker. ModeShape is an open source project, we'll likely look at the issue much more quickly if you provide a simple test case.
But what we really love is a pull-request that adds to a test class one or more test methods that replicates the problem. We can get that pull-request, run the tests (which would fail), and then fix the problem. This really saves us a lot of time, and it us know that we're fixing the exact problem you see. And you'll know that the fix will be included in the next release.
Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.
I am trying to use core plot with an ios app I am writing, but I am unable to build after following the instructions to set up the library for use. I am getting the following message.
'CorePlot0' does not contain a valid pid
Sorry the tutorial I used is here http://recycled-parts.blogspot.com/2011/07/setting-up-coreplot-in-xcode-4.html
This has been asked (and answered) a number of times on this site alone. The most helpful suggestion on those (many) similar questions that reference the blog post you mentioned says you should read that post's comments since the post refers to older code.
If all else fails, create a new test project and try following the (comment-updated) instructions again. If it still doesn't work, update your question with much more detail regarding what you tried and where it went wrong. Include build logs, run logs, etc. - we're not mind readers.