-
-
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
GraalJS and runner and reporter improvements - performance, streams, config #1281
Comments
Thanks for raising this Peter, You've noted everything I had in mind. In case it helps I have crafted a simple example similar to what I had used in a project. Checking task manager in windows it consumes 4.2gb of memory with 2000 elements in the dynamic scenario. I had also noticed something weird with the xml report, but for the life of me I can't get the xml report to get generated now that I am at my home windows pc, if I manage to reproduce it I will update this comment. Cheers |
@KostasKgr XML report maybe it is this problem someone just reported: https://stackoverflow.com/q/63747415/143475 - I've added it to the master list |
introduced processor and subscriber interfaces based on the java reactive streams / spi much better parallel exec only one executor service is needed instead of two no more flaky countdown-latch, using completable-future and try-catch blocks to avoid runner hang todo: fix dynamic scenario to return proper lazy iterator, but now we have the foundation for that todo: simplify the feature-execution-unit and scenario-execution-unit since now the parallel-processor does more of the async orchestration also todo: make runner-options --> feature-context --> heirarchy more sane
this even handles dynamic scenario-oulines and sets us up for un-bounded data-sources
a huge step forward for dynamic data driven scenarios
if you are reading this - there is a lot of interesting stuff in this start of moving to graal for the js engine and armeria for server, possibly client also including thymeleaf for html templating, and a proof-of-concept of an html server-side framework with demo temporarily using a karate-core2 maven module to manage the extreme changes in flight pretty much re-creating karate from scratch - the core is coming together most of the complex match logic is done, and way better designed than how it was
todo graal function context switching
based om the learnings from the past
now it is simpler, using the http-client-factory, and avoiding js
reverted cookie expiry checks, felt karate should allow any kinds of bad cookies, as a testing tool karate-jersey is done previous commit has breaking changes to mock-servlet of course http client in case anyone has extended is also a breaking change now the remaining part is karate-ui which is not part of the maven build as tests
one of the hardest things I've ever done, this was even harder than re-writing cucumber now the satisfaction of deleting code begins
and we will maven-shade it so that there will not be library conflicts in the wild which means we can remove karate-jersey, it is not needed any more we can focus on the one true http client and also look at armeria for the future and async the build time has come down and the number of directories can be reduced in git next we can try remove the karate-netty module, but the readme may have to remain the size of the karate-core jar is around 10 mb now, but I think in this day and age it is ok
so now the fatjar and the maven module is unified
now the http client abstraction for ui driver etc is based on this, and log appender swapping
driver.dialog api changed to driver.dialogText so as to not collide with getters :( switch frames seems broken, putting it as a todo investigate and one checkbox test
see previous commit for diff also improved junit 4 to properly handle one time init
now using the io.github.classgraph lib, for performance we try to use the default classloader but now we should be able to load from jars and other non-file locations
made sure that vs code karate-runner plugin will still be backwards compatible, which applies only for the combination of vs-code and a maven / gradle project cc @kirksl
system property any more, added -w flag to set working directory guessing it may be useful for karate-runner ide support in future cc @kirksl other improvement is even when using file-system, karate will attempt to use relative paths in reports etc, just to reduce clutter / maybe better security as well
and brought it back from previous commits, but now the suite-init is quite clean more unification across cli - standalone - maven - junit one big change is reports, json, xml etc will now go into <build-dir>/[karate-reports] it is about time
I'm going to declare this as done ! have updated the first comment with the 2 pieces we didn't get to. but very happy with all that we were able to accomplish. we are on GraalJS, karate runs on JDK 16 and the code has been cleaned up very effectively |
That's wonderful news, thank you! Is there an ETA for the changes to be released in a new version? |
@dersvenhesse please see https://github.com/intuit/karate/wiki/1.0-upgrade-guide - so right now you can test 0.9.9.RC3 |
this is an "umbrella" issue and I may close some of the existing issues as duplicates. there is a refactoring that will go along with this,
perhapsthe graal migrationScenario Outline
take a stream as the data-source ? may be hardcall
argumentkarate-runner
VS Code plugin projectEmbed
design to store files and not hold all the bytes of large images in memorykarate.abortAll()
api to stop the entire test-suiteResult
instances, so you can use theRunner
multiple times in a "suite" but have a single report Merging two results objects into one object #1263@todo
tag@smoke @module=one @module=two
etcThe text was updated successfully, but these errors were encountered: