I'm using Talend build Project option to build my ETL job. It will Generate a zip file with following .sh file.
MainJob.sh
"cd `dirname $0`
ROOT_PATH=`pwd`
java -Xms256M -Xmx1024M"
Is it possible to change this -Xmx1024M value to some other value from Talend Project properties? I want to get a build file with following properties
"cd `dirname $0`
ROOT_PATH=`pwd`
java -Xms512M -Xmx2048M"
Talend allows you to provide JVM arguments to a specific job or to the client Studio. These are then used when running directly in the Studio, built as binaries or ran from the Talend Administration Centre (with an Enterprise licence).
To edit the JVM arguments for a job go to the Advanced settings pane of the Run tab:
This job will then be ran with those JVM arguments but it will also be exported/built with the JVM arguments specified in your shell/batch script.
It's also possible to set the JVM arguments of the client Studio by going to Window -> Preferences -> Talend -> Run/Debug:
I thought there was a way to set project default JVM arguments but I can't find it anywhere in the Project properties so either I imagined it or it's since been removed.
Related
I have an application. I run it via
gradlew run-app
Or debug
gradlew debug-app
It works. How do I pass '-Xmx' argument into the application which I run (debug)?
Is it possible to do so without edditing build.gradle file?
I found this
Gradle unknown command-line option '-X'
I get a similar error when I try
gradlew debug-app -Xmx2000m
Error
FAILURE: Build failed with an exception.
* What went wrong:
Problem configuring task :debug-app from command line.
> Unknown command-line option '-X'.
I tried to create a file gradle.properties in GRADLE_USER_HOME directory (by default, it is USER_HOME/.gradle).
org.gradle.jvmargs=-XX\:MaxHeapSize\=4256m -Xmx4256m -Xms2000m
I also tried to org.gradle.jvmargs=-Xmx2000m in project folder gradle.properties.
And even then when I run an application, I see Commited Memory size is < 520 MiB
And this is when I run it as a normal Java App
In the second case, when I run the application as a normal Java app with -Xms, -Xmx, Commited Memory size is about 3.5 GiB because I passed -Xmx4512m -Xms2512m parameters.
Add this in your gradle.properties file :
org.gradle.jvmargs=-Xmx2000m
From here
org.gradle.jvmargs
Specifies the jvmargs used for the daemon process. The setting is
particularly useful for tweaking memory settings. At the moment the
default settings are pretty generous with regards to memory.
edit : my answer what about the gradle daemon jvm, not the app jvm. You have to use the jvmArgs property
The extra arguments to use to launch the JVM for the process. Does not
include system properties and the minimum/maximum heap size.
Firstly, thanks #ToYonos for leading me to the right direction.
Secondly, I found the solution here https://stackoverflow.com/a/9648945/4587961.
I ran my app from command line.
set GRADLE_OPTS=-Xms1724m -Xmx5048m
gradlew debug-app
Note, CMD Windows command SET works locally, so if you close your terminal, GRADLE_OPTS will not be set. For Linux, you can use
export GRADLE_OPTS=WHATEVER
This is what I wanted to achieve.
Using application plugin one can use applicationDefaultJvmArgs property
apply plugin: 'application'
applicationDefaultJvmArgs = ["-Xms1024m", "-Xmx2048m"]
The arguments will be applied to run task and to start script of your application
more info
In my case Invalidate cache and restart the android studio(which is automatically restarted) then the error will be gone after restarting the android studio
then
As I know when AEM is started in debug mode from the console using the -debug option, the JVM will be forced to fork, but what will be the result if the AEM is started with the -debug -nofork options? e.g:
java -jar aem6-author-p4502.jar -debug 8000 -nofork
Fork or nofork does not matter. aem6 will decide based on the available memory. if you want to debug, using following command
java.exe -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=9669,suspend=n -XX:+PrintGC -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar aem-quickstart-6.2.1.jar
then in intellj or eclipse connect it with remote debug. you can only debug the code in osgi bundles. you can't debug the jsp code.
What works for me is to double-click the server instance in Eclipse. It opens up the details. Near the right bottom corner, there is an option for "Debug". Expand it and uncheck the "Resolve sources when connecting".
This stops Eclipse from comparing your Eclipse code with the code running inside the server. This isn't an ideal answer. Ideally, we want to sync the Eclipse code with the server code, otherwise debugging has no meaning -- assume you're off by even one line of code when debugging.
I'm answering your specific question. For a broader answer on this, please see:
Eclipse java debugging: source not found
Sometimes our system OS generates multiple java forks in that case -nofork added at the end of the command will resolve the issue.
I have some jobs maje with Talend Open Studio and I want use maven to export jobs in zip file to do automatic build.
Can I found an existing maven plugin to do that?
Can I build job with command line ?
Talend CommandLine is only available in Talend Enterprise Subscription Version. There is no job script in Talend open studio products.
For more information about how to use command line to build the job, please visit this link.
It's possible but complex !
You will have to change pom settings.
Change the file maven_user_setting.xml and settings.xml
Check Offline in maven preferences.
Then with command line like following you can build your project :
mvn -B -s C:\Talend\TOS_DI-Win32-20200219_1130-V7.3.1\configuration\maven_user_settings.xml install -l C:/Talend/lastGenerated.log -P default-settings,!include-java-sources,!include-maven-resources,!include-items,include-libs,!include-binaries,include-running-log4j,include-log4j,include-contexts,!include-test-sources,!include-test-reports,include-xmlMappings,include-running-xmlMappings,packaging-and-assembly,!ci-builder -Dmaven.test.skip=true -Dci.builder.skip=true
I have a Spring Boot project with gradle build tool. The JDBC url, username and password are kept in a property file which is not part of application it's a external property file, the path of the property file is taken from system properties as follows.
export _JAVA_OPTIONS=-DdatabaseConfiguration=db.properties
It is working if I run the application from terminal using gradle bootRun, but when I try to run from Intellij IDEA 13 gradle tasks its not working, the property value is null.
I tried the VM options in Run/Debug Configuration as in the below screen shoot its not working either
How can the JAVA_OPTIONS can be set in Intellij IDEA 13 gradle tasks.
This is because every time you use the Gradle tool window to kick off tasks in IntelliJ, it creates/overwrites the launch configuration for that task.
Basically, I've had to run from the Gradle tool window just once. Then I go into the failed Launch Config (shown in question) and enter the system property in the VM options. From there on out, I need to use that Launch Config to execute the task instead of the Gradle tool window.
Update: Even better solution:
Preferences->Build, Execution, Deployment->Build Tools->Gradle->Gradle VM options
Add your system properties there (i.e. -Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk)
Doing this will keep them from getting overwritten/lost in the Launch configs that the Gradle tool window generates.
Another thing to note is that using the Gradle tool window causes the commands to be run without access to Environment Variables. This can cause a lot of problems with builds that depend on these env vars.
I ran into this today with the appengine-gradle-plugin and had to put
-Dappengine.sdk.root=/opt/google/google-cloud-sdk/platform/appengine-java-sdk
in the VM options because it was not seeing the env vars. From the command line, it picks up the env vars and works fine. This worked for my appengineRun task.
But it does not work for appengineUpdate since that gives another error caused by lack of env vars: Toolkit not found: apple.awt.CToolkit
How can I make Jenkins do the following?
Checkout trunk/ from SVN, then build configurations Debug and Release using CMake, without having duplicate jobs for the configurations.
Took me a while to figure this out. Here's how I managed to do it.
Create a free-style job "Checkout". This job is going to do all the stuff that doesn't depend on the configuration type (Debug/Release).
Under "Source Code Management" select Subversion
Fill in the Repository URL. Probably a good idea to make it point to /trunk.
Set Local module dir to "." (no quotes)
As Check-out Strategy "Emulate clean" is nice
Build trigger Poll SCM, set Schedule to "5 * * * *" to check every 5 minutes.
Now under Advanced Project Options check 'Use custom workspace' and set the dir to e.g. "c:/src". We don't want Jenkins to use its internal workspace, because we want other jobs to be able to access the source.
Under Build add the following Windows batch command, which is used to clean the build dir. For some reason, CMake doesn't provide a way to do this.
cd c:\
rmdir /S /Q build
mkdir build
cd build
cmake --version
rem optionally: svn info c:\src
cmake -G "Visual Studio 10" c:\src
Create another job "Build", this time make it a "multi-configuration" job. This job is going to run for each configuration (Debug/Release).
First, set the Build Triggers to build after job "Checkout"
Now under Configuration Matrix add an axis "configuration" with values "Debug Release" (whitespace = separator). Unfortunately, the CMake builder plugin for Jenkins doesn't work with multi-configuration jobs. We can't even use cmake --build, because it always builds the Debug configuration. To build, we have to use another batch script:
cd c:\build
call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
msbuild ALL_BUILD.vcxproj /verbosity:minimal /maxcpucount:1 /property:Configuration=%configuration%
If you want to build the entire solution, specify the .sln file instead of ALL_BUILD.vcxproj. If you only want to build a specific project, use
msbuild <solution>.sln /target:<project>
Use Jenkins Matrix job. Define one of the axes as build_mode with values Debug and Release. You then run CMake that will create both configurations for the compilation tool you'll be using (XCode, gcc, VisualStudio, etc.). You can then use build_mode as if it were an environment variable and pass it to build steps that do actual compilation.
When using the Visual Studio generator you can pass the configuration to build to the cmake --build-command:
cmake --build . --config Release
cmake --build . --config Debug
See also the CMake docs.
After using Jenkins for a while now, I found that you should use as few jobs as possible if you want to reuse the source directory.
The default setup in Jenkins is that each build uses a different directory as its workspace. Which implies that you do a complete SVN checkout every build. Which takes forever.
If you want to use the same source directory for every build, you have to worry about synchronization: Only one build at a time. As far as I know, Jenkins has no built-in means of synchronization. The only way is to only use one executor. Even then you can't control the way the executor chooses its next job.
Let's say job "SVN update" triggers job "Build". Someone starts "SVN update #33", which is supposed to trigger "Build #33". If, however, Jenkins' "Poll SCM" feature schedules "SVN update" #34 in the meantime, I haven't found a way to tell it that "Build #33" must run before "SVN update #34". So you might end up with "SVN update #34" running before "Build #33", and everything fails. Unless you manually disable the polling job. And remind yourself to re-enable it afterwards, of course.
Anyways. After using Jenkins for two years, I change my answer to: Never use multiple jobs that share resources (like the source dir), and bake all the logic into shell scripts (for loop over configurations).