I am following the trader's demo, writing a similar one (my project on Github) with same flows.
But when hitting "flow list" command in node's jvm, there is nothing like "Sellerflow". Please explain this.
You need to annotate any flows that you want to start from the shell with the #InitiatingFlow annotation. Only these will show up here, because only these can be started directly.
Related
I am new to bitbake and i am trying to learn it.
I am going through below link for getting a basic understanding
https://a4z.gitlab.io/docs/BitBake/guide.html
Here either through inheritance or directly i see a do_build is always executed.
this might seem a basic question but your answer would really help me.
I read a line like this "build is the task BitBake runs per default if no other task is specified".
Does it mean build is mandatory in bitbake.Is it like main function in c and c+= codes?
Thanks
When no task is specified on the commandline to bitbake, "build" is assumed. This can be overridden with the BB_DEFAULT_TASK variable to some other task. If a task isn't defined and you try and run it, an error will occur that the task can't be found. As such, a build task isn't absolutely required but you will likely run into errors without it in most common usages.
Xterm is used when running Corda locally on one computer using gradle.
Is there a way to specify your terminal editor when running as suggested by the following issue?
https://github.com/corda/corda/issues/2605
I completely share your pain on this. The way that runnodes has its tooling baked in makes it impossible for you to customize how the cordform plugin runs the nodes without digging into the internals.
Some other ideas for you
one thing you could do would be to stop using cordform altogether and run your corda network using dockerform (example here: https://github.com/corda/samples-java/blob/master/Features/dockerform-yocordapp/build.gradle#L93) so that the plugin doesn't need to actually create new terminals.
the much harder way would be to actually download the corda gradle plugins (https://github.com/corda/corda-gradle-plugins#installing-locally) and install it locally with your edits to the cordform task so that it opens the terminal of your choice. You may be able to PR them as the cordform task that's usually used to generate the runnodes script comes from here as far as I know.
As a separate note, I saw your github issue and I was disappointed by how that got handled. I'm sorry you had that experience and I'm going to dig into that issue internally to find out what's happening with that.
feel free to reach out to me (David Awad) on slack.corda.net and I can let you know what's going on there.
Thanks as always
Context
I'm trying to implement a sort-of orchestrator pattern for our applications.
Basically, we have three different and independent applications developped in Qt that communicate with each other using Web Socket. We'll call them "core", "business" and "ui". This is a flexibility aim as we can simply develop a new application in a more suiting technology and connect it to the others via the same communication protocole.
Now the idea is to have a simple launcher that allows us to specify which part to start. We launch this "orchestrator-like" application and it starts all required processes from a configuration file.
Everything is done in Qt currently (QML for the UI interfaces).
Initial Issue
I've made a custom class oriented towards reading the configuration file, preparing the processes, and starting them with their respective arguments.
This uses a std::map of QProcess related to their name in the configuration file and launch them using QProcess::start(<process_path>) method.
The catch is that everything went smoothly until recently. The sub processes are started and runs perfectly ; everything goes on as normal until we reach some point were the "ui" part crashes (usually an LLVM memory error or vector:: length error).
At first we thought about a memory leak or a code error but after much debugging we found that the application had no error whatsoever when we ran each part individually (without using the custom orchestrator class).
Question / Concerns
So, our question is: could it be that the QProcess:start() method actually shares the same stack with its parent? Three processes having the same parent, it would not be surprising than a vector of ~500 elements stored in each application can exceed the stack size when returned.
Information
We use MacOS Big Sur, IDE is Qt Creator, using Qt 5.15.0 and C++11.
Tried using valgrind but as read here and here, this seems a dead-end for now. The errors below were seen in the .crash file following the application exit.
libc++abi: terminating with uncaught exception of type std::length_error: vector
ui(2503,0x108215e00) malloc: can't allocate region :*** mach_vm_map(size=140280206704640, flags: 100) failed (error code=3) ui(2503,0x108215e00) malloc: *** set a breakpoint in malloc_error_break to debug LLVM ERROR: out of memory
Also tried to redirects or completly remove the application's output. First changing the setProcessChannelMode when starting the application, then with startDetached instead of start. Then, commented my Log method dumping log info into the corresponding Qt output (info/warning/critical/fatal/debug).
As suggested by #stanislav888, we could rewrite the application manager part in bash scripts and it would probably do the trick but I'd like to understand the root issue to avoid future mistakes.
It looks like a bad design. Application running and orchestrating through bash or PowerShell script looks much more better.
But anyway.
You could try to suppress orchestrated applications output and see what happen. The programs output might flood memory and make crash.
You must check what particular trouble cause the crash. Use memory "coredump" and system error messages to understand the all problem details.
I sure the community need that details. Because "оut of memory", "stack depth exceeded" and same errors make big difference.
Try to write bash or PowerShell script which does the same workflow as the Qt application. Hope it is not hard. But it will help you to figure out the issue.
At least you can run this script from the application.
I'm new here. I'm trying to manage my all actions using oozie actions. can anyone show me a proper example by running simple "HelloWorld.java" using oozie action ?
it's really a great help for me. good and running answer will be appreciated.
This link is helpful for running an oozie job -> http://www.thecloudavenue.com/2013/10/executing-oozie-workflow-with-pig-hive.html
but for sqoop,pig and hive action
Replace this three action in workflow.xml with java action. see this link -> https://oozie.apache.org/docs/3.2.0-incubating/WorkflowFunctionalSpec.html#a3.2.7_Java_Action
In the java code, if you are trying to print the output, then it will be there in yarn application log
My initial tests have shown that Robot won't work without an active, visible desktop. For example, while a scheduled task (or executed command from the continuous integration server) may be able to start robot as a command-line process, Robot will actually fail to execute the recorded script.
Logging into the build machine to allow it an "active desktop" is not an acceptable solution.
Am I missing something? Is it possible to run a pre-recorded Rational Robot script on a continuous integration server in a manner that doesn't require the machine to be physically logged into?
Unfortunately, Robot does require that you are logged on to the machine and that the desktop is not locked.
So, no, you are not missing something.
Depending on your situation, though, you may be able to work around the issue. Can you clarify what type of application you are trying to test? If it is a web app, or a client app that is easily installed/copied, you might be able to have Robot run on a vmware image, rather than directly on the build server itself.
You can run Rational Robot from the command line, so you should be able to set up a scheduled task to run a .BAT file to do this for you. The command is something like:
[path to Rational Robot]\rtrobo [script file] /user "user name" /project [project file] /play /build "build name" /nolog /close
The Robot documentation will have other arguments you can pass in, depending on your situation.
If a simple scheduled task doesn't work, then you can try setting up a STAF (http://staf.sourceforge.net/index.php) environment and create a job to run this.
Good luck :)