I'm running scripts inside GroovyConsole 2.4.5 on Windows 7 64-bit and they are crashing due to out of memory error. Runtime.getRuntime().maxMemory() shows 247MB and my PC has 32GB RAM. What is the way to increase memory available for GroovyConsole and underlying JVM?
I tried editing startGroovy.bat file with:
set GROOVY_OPTS="-Xmx2g -Xms1g"
and other values, but it had no effect.
I'm not on Windows, so can't test, but you should be able to use JAVA_OPTS instead of GROOVY_OPTS, ie:
set JAVA_OPTS="-Xmx1G"
Before you run groovyConsole
You're already doing correctly, edit startGroovy.bat and simply try with g lowercase, to set GROOVY_OPTS:
set GROOVY_OPTS="-Xmx1g"
After some tries I see the follow effect, If I use " to set GROOVY_OPTS only work with one parameter, if I want to use two parameters -Xmx1g -Xms512m I've to remove " if not it doesn't works. So you can try with:
set GROOVY_OPTS=-Xmx1g -Xms512m
Instead of
set GROOVY_OPTS="-Xmx1g -Xms512m"
Hope it helps,
Related
I have a bunch of unit tests which contain code like:
File file = new File("src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
This test is suddenly failing when running it with Maven Surefire and -DforkCount=0. With -DforkCount=1, it works.
Things I tried so far:
The file does exist. Windows Explorer, command line (copy & paste), text editors, Cygwin can all find it and show the contents. That's why I think it's not a permission problem.
It's not modified by the unit tests or anything else. Git shows no modifications for the last two months.
I've checked the file system, it's clean.
I've tried other versions of Java 8, namely 8u171 and 8u181. Same problem.
I've run Maven from within Cygwin and the command prompt. Same result.
Reboot :-) No effect :-(
More details:
When I see this problem, I start to see the "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" in other projects. That's why I tried forkCount=0 which often helps in this case to find out why the forked VM crashed.
This has started recently, maybe around the October 2018 update of Windows 10. Before that, the builds were rock solid for about three years. My machine was switched to Windows 10 late 2017, I think.
I'm using Maven 3.6 and can't easily try an older version because of an important bug that was fixed with it. I did see the VM crash above with Maven 3.5.2 as well.
It's always the same files which fail (so it's stable).
ulimit (from Cygwin) says:
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 2032
cpu time (seconds, -t) unlimited
max user processes (-u) 256
virtual memory (kbytes, -v) unlimited
I'm wondering if the "open files" limit of 256 only applied to Cygwin processes or whether that's something which Cygwin reads from Windows.
Let me know if you need anything else. I'm running out of ideas what I could try.
Update 1
Bernhard asked me to print absolute names. My answer was that I was already using absolute names but I was wrong. The actual code was:
File file = new File("src/main/java/com/pany/Foo.java");
if (!file.exists()) {
log.debug("Missing file {}", file.getAbsolutePath());
... fail ...
}
... do something with file...
I have now changed this to:
File file = new File("src/main/java/com/pany/Foo.java").getAbsoluteFile();
if (!file.exists()) {
log.debug("Missing file {}", file);
}
and that fixed the problem. I just can't understand why.
When Maven creates a forked VM to run the tests with Surefire, then it can change the current directory. So in this case, it would make sense that the tests work when forked but fail when running in the same VM (since the VM was created in the root folder of the multi-module build). But why is making the path absolute before the call to exists() fixing the issue?
Some background. Each process has a notion of "current directory". When started from the command line, then it's the directory in which the command was executed. When started from the UI, it's usually the folder in which the program (the .exe file) is.
In the command prompt or BASH, you can change this folder with cd for the process which runs the command prompt.
When Maven builds a multi-module project, it has to change this for each module (so that the relative path src/main/java/ always points to the right place). Unfortunately, Java doesn't have a "set current directory" method anywhere. You can only specify one when creating a new process and you can modify the system property user.dir.
That's why new File("a").exists() and new File("a").getAbsoluteFile().exists() work differently.
The latter will use new File(System.getProperty("user.dir"), "a") to determine the path and the former will use the Windows API function _wgetdcwd (docs) which in turn uses a field of the Windows process to get the current directory - in our case, that's always the folder in which Maven was originally started because Java doesn't update the field in the process when someone changes user.dir and Maven can only change this property to "simulate" changing folders.
WinNTFileSystem_md.c calls fileToNTPath(). That's defined in io_util_md.c and calls pathToNTPath(). For relative paths, it will call currentDirLength() which calls currentDir() which calls _wgetdcwd().
See also:
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/WinNTFileSystem_md.c
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/io_util_md.c
and here is the place where the Surefire plugin modifies the Property user.dir: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1060
When not forking, it's copied into the current VM's System properties: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1133
So I have checked via printing out the system properties with some simple tests.
During the tests via maven-surefire-plugin the user.dir will be changed to the root of the appropriate module in a multi module build.
But as I mentioned already there is a system property available basedir which can be used to correctly handle the location for tests which needs to access them via File...The basedir is pointed to the location of the pom.xml of the appropriate module.
But unfortunately the basedir property is not set by IDEA IntelliJ during the test run.
But this can be solved by a setup like this:
private String basedir;
#Before
public void before() {
this.basedir = System.getProperty("basedir", System.getProperty("user.dir", "Need to think about the default value"));
}
#Test
public void testX() {
File file = new File(this.basedir, "src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
}
This will work in Maven Surefire with -DforkCount=0 as well as -DforkCount=1 and in IDE's (checked only IDEA IntelliJ).
And yes that is an issue in Maven Surefire plugin changing the user.dir.
We might convince IDE's to support the basedir property as well ?
Aaron, we develop the Surefire. We can help you if you provide the path for this:
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
Pls post the actual path, expected path and basedir where your POM resides.
The theory would not help here. We are testing all the spectrum of JDKs 7-12 but we do not have the combination Cygwin+Windows which must be considered.
The code setting user.dir in Surefire you mentioned exists a decade.
I need to run side by side two ElasticSearch instances (version 1.7 and version 5.2.2) on the same server (Widows 2012 R2). When I try to run the newer version, I receive an error:
PS C:\Program Files\Elasticsearch\elasticsearch-5.2.2\bin> .\elasticsearch.bat
Error: encountered environment variables that are no longer supported
Use jvm.options or ES_JAVA_OPTS to configure the JVM
ES_HEAP_SIZE=8g: set -Xms8g and -Xmx8g in jvm.options or add "-Xms8g -Xmx8g" to ES_JAVA_OPTS
This is caused by the fact that that there was a breaking change (described here) in the way the heap size is set. In the previous version of ElasticSearch (1.7) it was set by an environment variable:
ES_HEAP_SIZE = 8g
I tried setting up another env variable:
ES_JAVA_OPTS = -Xms8g -Xmx8g
and I also edited jvm.options file by adding
-Xms8g
-Xmx8g
but I'm still getting the same error.
Is there a way to configure heap size in ElasticSearch 5.2.2 without deleting ES_HEAP_SIZE environment variable (which I need to keep version 1.7 up and running)? If not, is it possible to set heap size in the old version in a way that would also allow the new version to run?
Edit: Given that jvm.options is not an option, the only thing I see is modifying your elasticsearch/bin/elasticsearch script, mostly the line:
ES_JAVA_OPTS="$(parse_jvm_options "$ES_JVM_OPTIONS") $ES_JAVA_OPTS" #default
to:
ES_JAVA_OPTS="-Xms myXmsValue -Xmx myXmxValue -someOtherOptions someValue"
With the other options and value according to what you want.
Here is what I found out:
it turns out that the error I was struggling with was raised not by ElasticSearch itself, but by the batch script running the ElasticSearch (bin\elasticsearch.bat). The problematic lines are:
if not "%ES_HEAP_SIZE%" == "" set bad_env_var=1
(...)
if %bad_env_var% == 1 (
echo Error: encountered environment variables that are no longer supported
echo Use jvm.options or ES_JAVA_OPTS to configure the JVM
(...)
if not "%ES_HEAP_SIZE%" == "" echo ES_HEAP_SIZE=%ES_HEAP_SIZE%: set -Xms%ES_HEAP_SIZE% and -Xmx%ES_HEAP_SIZE% in jvm.options or add "-Xms%ES_HEAP_SIZE% -Xmx%ES_HEAP_SIZE%" to ES_JAVA_OPTS
(...)
exit /b 1
)
As far as I can see, this check is there in order to help people migrating from older version to the newer, pointing them to a new way of setting up the heap size. Apart from that, the environment variable ES_HEAP_SIZE is not mentioned in the script, so its' existence should not affect the ElasticSearch 5.2.2 instance. Based on these observations, the easiest fix seems to be simply commenting out the check:
rem if not "%ES_HEAP_SIZE%" == "" set bad_env_var=1
I tried it and both instances of ElasticSearch now run side by side without issues.
One additional trap to avoid is not to set up the heap size in both the file and ES_JAVA_OPTS, which leads to duplicate min heap size settings found error when deploying. Just stick to the file config.
Huge thanks to #asettouf whose answer led me to the correct solution!
I'm using Intellij 13.1.5 on Ubuntu 14.0.4 (amd64), Maven 3.0.5, Java Oracle 1.7.0_72
I noticed some irregularities with maven whilst using Intellij namely dependencies added and removed where not reflected in the module or in the External Libaries listing.
Then when I ran Intellij from the shell I saw this exception:
[ 14649] WARN - #org.jetbrains.idea.maven - Cannot open index /home/sbotting/.IntelliJIdea13/system/Maven/Indices/Index0
org.jetbrains.idea.maven.indices.MavenIndexException: Cannot open index /home/sbotting/.IntelliJIdea13/system/Maven/Indices/Index0
at org.jetbrains.idea.maven.indices.MavenIndex.open(MavenIndex.java:164)
at org.jetbrains.idea.maven.indices.MavenIndex.<init>(MavenIndex.java:139)
at org.jetbrains.idea.maven.indices.MavenIndices.load(MavenIndices.java:59)
at org.jetbrains.idea.maven.indices.MavenIndices.<init>(MavenIndices.java:47)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.ensureInitialized(MavenIndicesManager.java:107)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.getIndicesObject(MavenIndicesManager.java:91)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.ensureIndicesExist(MavenIndicesManager.java:164)
at org.jetbrains.idea.maven.indices.MavenProjectIndicesManager$3.run(MavenProjectIndicesManager.java:120)
at com.intellij.util.ui.update.MergingUpdateQueue.execute(MergingUpdateQueue.java:320)
at com.intellij.util.ui.update.MergingUpdateQueue.execute(MergingUpdateQueue.java:310)
at com.intellij.util.ui.update.MergingUpdateQueue$2.run(MergingUpdateQueue.java:254)
at com.intellij.util.ui.update.MergingUpdateQueue.flush(MergingUpdateQueue.java:269)
at com.intellij.util.ui.update.MergingUpdateQueue.flush(MergingUpdateQueue.java:227)
at com.intellij.util.ui.update.MergingUpdateQueue.run(MergingUpdateQueue.java:217)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.Alarm$Request$1.run(Alarm.java:327)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:298)
at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:295)
at com.intellij.util.concurrency.QueueProcessor$2$1.run(QueueProcessor.java:110)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:107)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:104)
at com.intellij.util.concurrency.QueueProcessor$3$1.run(QueueProcessor.java:215)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$3.run(QueueProcessor.java:212)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:419)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
Caused by: java.lang.RuntimeException: Cannot reconnect.
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.perform(RemoteObjectWrapper.java:111)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.createIndex(MavenIndexerWrapper.java:61)
at org.jetbrains.idea.maven.indices.MavenIndex.createContext(MavenIndex.java:305)
at org.jetbrains.idea.maven.indices.MavenIndex.access$500(MavenIndex.java:40)
at org.jetbrains.idea.maven.indices.MavenIndex$IndexData.<init>(MavenIndex.java:611)
at org.jetbrains.idea.maven.indices.MavenIndex.doOpen(MavenIndex.java:185)
at org.jetbrains.idea.maven.indices.MavenIndex.open(MavenIndex.java:161)
... 33 more
Caused by: java.rmi.RemoteException: Cannot start maven service; nested exception is:
com.intellij.execution.ExecutionException: -Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xdiag show additional diagnostic messages
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
-XshowSettings show all settings and continue
-XshowSettings:all
show all settings and continue
-XshowSettings:vm show all vm related settings and continue
-XshowSettings:properties
show all property settings and continue
-XshowSettings:locale
show all locale related settings and continue
The -X options are non-standard and subject to change without notice
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:124)
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:65)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.getOrCreateWrappee(RemoteObjectWrapper.java:41)
at org.jetbrains.idea.maven.server.MavenServerManager$5.create(MavenServerManager.java:387)
at org.jetbrains.idea.maven.server.MavenServerManager$5.create(MavenServerManager.java:383)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.getOrCreateWrappee(RemoteObjectWrapper.java:41)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.getRemoteId(MavenIndexerWrapper.java:159)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.access$100(MavenIndexerWrapper.java:37)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper$1.execute(MavenIndexerWrapper.java:64)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.perform(RemoteObjectWrapper.java:105)
... 39 more
Caused by: com.intellij.execution.ExecutionException: -Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xdiag show additional diagnostic messages
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
-XshowSettings show all settings and continue
-XshowSettings:all
show all settings and continue
-XshowSettings:vm show all vm related settings and continue
-XshowSettings:properties
show all property settings and continue
-XshowSettings:locale
show all locale related settings and continue
The -X options are non-standard and subject to change without notice.
at com.intellij.execution.rmi.RemoteProcessSupport.acquire(RemoteProcessSupport.java:142)
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:121)
... 48 more
I've tried deleting the ~/.IntelliJIdea13/system/Maven/
with no result
My M2_HOME is properly set to /usr/share/maven
I assume that the solution lies in finding the underlying cause for the ExecutionException although the diagnostic doesn't really help with this.
I've tried reverting back to Intellij 12.0.4 and it works fine (in terms of Maven - although sadly it doesn't support svn 1.8)
also the output seems to come from the java -X command which gives you a printout of all the -X options
Any suggestions?
I had this problem all of a sudden (after an update + Windows Update). I tried a lot of things, and in the end, set Settings > Build, Execution, Deployment > Build Tools > Maven > Importing > JDK for Importer to Use JAVA_HOME (which I've set up as an env var pointing to a JDK install). That seems to work.
Go to file and select the project from the menu structure.
Then change the JDK version form the list of JDKs.
In the Settings > Maven > Importing in box for "VM options for importer:" box I had -Xmx512m -X
for some reason there was a loose -X I removed that and everything is now working fine.
My hosts file lack of the line:
127.0.0.1 localhost
lead to this problem.
I had this issue and it was due to me changing the JDK for importing in Intellij
I changed it from using internal JRE to java 1.8.0_74
I changed this back to use the Internal JRE of intellij and it worked.
Didn't need to change anything with my .m2 settings
I am deploying a large Java project on Sonar using "Findbugs" as profile and getting the error below:
Caused by: java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
Java heap space
What i have tried to resolve this:
Replaced %SONAR_RUNNER_OPTS% with -Xms256m -Xmx1024m to increase the heap size in sonar-runner bat file.
Put "sonar.findbugs.effort" parameter as "Min" in Sonar global parameters.
But both of above methods didn't work for me.
I had the same problem and found a very different solution, perhaps because I'm having a hard time swallowing the previous answers / comments. With 10 million lines of code (that's more code than is in an F16 fighter jet), if you have a 100 characters per line (a crazy size), you could load the whole code base into 1GB of memory. I set it 8GB of memory and it still failed. Why?
Answer: Because the community Sonar C++ scanner seems to have a bug where it picks up ANY file with the letter 'c' in its extension. That includes .doc, .docx, .ipch, etc. Hence, the reason it's running out of memory is because it's trying to read some file that it thinks is 300mb of pure code but really it should be ignored.
Solution: Find the extensions used by all of the files in your project (see more here):
dir /s /b | perl -ne 'print $1 if m/\.([^^.\\\\]+)$/' | sort -u | grep c
Then add these other extensions as exclusions in your sonar.properties file:
sonar.exclusions=**/*.doc,**/*.docx,**/*.ipch
Then set your memory limits back to regular amounts.
%JAVA_EXEC% -Xmx1024m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m %SONAR_RUNNER_OPTS% ...
this has worked for me:
SONAR_RUNNER_OPTS="-Xmx3062m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m"
I set it direct in the sonar-runner(.bat) file
I had the same problem when running sonar with maven. In my case it helped to call sonar separately:
mvn clean install && mvn sonar:sonar
instead of
mvn clean install sonar:sonar
http://docs.sonarqube.org/display/SONAR/Analyzing+with+Maven
Remark: Because my solution is connected to maven, this is not the direct answer for the question. But it might help other users who stumple upon it.
What you can do it to create your own quality profile with just some Findbugs rules at first, and then progressively add more and more until you reach his OutOfMemoryError. There's probably only a single rule that makes all this fail because your code violates it - and if you deactivate this rule, it will certainly work.
I know this thread is a bit old but this info might help someone.
For me the problem was not like suggested by the top-answer with the C++ plugin.
Instead my problem was the Xml-Plugin (https://docs.sonarqube.org/display/PLUG/SonarXML)
after I deactivated it the analysis worked again.
You can solve this issue by increase the maximum memory allocated to the appropriate process by increasing the -Xmx memory setting for the corresponding Java process in your sonar.properties file
under SonarQube/conf/sonar.properties
uncomment below lines and increase the memory as you want:
For Web: Xmx5123m -Xms1536m -XX:+HeapDumpOnOutOfMemoryError
For ElasticSearch: Xms512m -Xmx1536m -XX:+HeapDumpOnOutOfMemoryError
For Compute Engine: sonar.ce.javaOpts=-Xmx1536m -Xms128m -XX:+HeapDumpOnOutOfMemoryError
The problem is on FindBugs side. I suppose you're analyzing a large project that probably has many violations. Take a look at two threads in Sonar's mailing list having the same issue. There are some ideas you can try for yourself.
http://sonar.15.n6.nabble.com/java-lang-OutOfMemoryError-Java-heap-space-td4898141.html
http://sonar.15.n6.nabble.com/java-lang-OutOfMemoryError-Java-heap-space-td5001587.html
I know this is old, but I am just posting my answer anyway. I realized I was using the 32bit JDK (version 8) and after uninstalling it and then installing 64bit JDK (version 12) the problem disappeared.
I am using WebLogic 10.3 with a Java EE application. Can anyone please tell me how to debug this application?
I think the other answers are somewhat wrong. For windows, if you setup an environment variable called debugFlag to be true or in solaris/unix do the same
debugFlag=true
export debugFlag
DEBUG_PORT=8453
export DEBUG_PORT
, then setDomainEnv.sh or setDomainEnv.cmd are going to be called to start WLS by the other scripts. They look for the debugFlag and DEBUG_PORT, as long as the "production" flag is not set it will pick up the right parameters from the script for debugging (-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE).
YOU SHOULD NOT BE HACKING THESE SCRIPTS. It's going to make deployment and maintenance hard, the entire purpose of the setDomainEnv script is so that the right defaults are used and maintained across the cluster and throughout the entire environment. They are poorly documented I admit.
Note, if you are using the Oracle weblogic maven plugin, the target wls:deploy or wls:start-server will then pick up those environment settings when starting because they call the commands under the hood, and those in turn first call setDomainEnv.
As of right now, if you are using eclipse and have set up a Oracle WebLogicServer, the maven plugin will not attach to it into debug mode when you issue a mvn:deploy, you can either restart it in debug mode (silly), or create a 'Run ==> Debug ==> DebugConfigurations ==> RemoteJavaApplication' with a connection type of 'standard (socket attach)', a host of 'localhost' (or the remote server) and a port (default for me is '8453'). You can then do Run ==> Debug Configurations ==> Local Server Attach.
For me this worked:
In the folder WEBLOGIC_HOME\user_projects\domains\my_domain\bin
There is a file setDomainEnv.cmd
In it I found the code:
if "%debugFlag%"=="true" (
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
) else (
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -da
)
I just put the lines for debug outside the if clause:
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
if "%debugFlag%"=="true" (
set JAVA_DEBUG=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=%DEBUG_PORT%,server=y,suspend=n -Djava.compiler=NONE
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -ea -da:com.bea... -da:javelin... -da:weblogic... -ea:com.bea.wli... -ea:com.bea.broker... -ea:com.bea.sbconsole...
) else (
set JAVA_OPTIONS=%JAVA_OPTIONS% %enableHotswapFlag% -da
)
After these settings you can debug on port 8453
The port is also configured in this file, you can also change it:
if "%DEBUG_PORT%"=="" (
set DEBUG_PORT=8453
)
Stop the server, run the script, start the server.
Now your weblogic server is setup for debugging.
The best approach to enable debug on weblogic server is as follows:
create a script file
put these lines into your script (for windows):
set debugFlag=true
set DEBUG_PORT=9001
call the start script (e.g.): C:\Oracle\Middleware\user_projects\domains\domain1\bin\startWebLogic.cmd)
So, there will be 3 lines on the script, that's all you need...
There are also more variables you can use....
WLS_REDIRECT_LOG=log_path <- redirect output to a file instead of console window...
JAVA_OPTIONS <- more options for the JVM
EXTRA_JAVA_PROPERTIES <- define aditional properties you may need
What I did to get the Eclipse Debugger working with Weblogic 10 was to lookup the startWeblogic.cmd file in the folder weblogic.10.3.3.0\user_projects\domains\base_domain\bin\ and modify the following line (around line 95):
set JAVA_OPTIONS=%SAVE_JAVA_OPTIONS%
to
set JAVA_OPTIONS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n %SAVE_JAVA_OPTIONS%
Then I stopped any weblogic server that was running from within Eclipse and started Weblogic using the startWebLogic.cmd file.
Then I created a new debug configuration in Eclipse. Go to debug configurations, choose 'Remote Java Application', it should recognize your project, use Standard (Socket attach) for the connection type and specify port 8453 in the connection properties.
Now apply and run. Set some breakpoints in a piece of code that will regularly run and see if it is working.
Try remote debugging the application. You can try these links, thay may be helpful:
http://download.oracle.com/docs/cd/E15051_01/wlw/docs103/guide/ideuserguide/servers/conWebLogicServer.html#DebugRemote
http://eclipse.sys-con.com/node/169364
http://www.jacoozi.com/index.php?option=com_content&task=view&id=119&Itemid=134
Jonnathan Q answer helped me to launch Weblogic in debug mode also. For unix you can use the syntax like this in shell scripts:
debugFlag=true
export debugFlag
DEBUG_PORT=9001
export DEBUG_PORT
and then run startWeblogic.sh and startManagedWeblogic.sh if necessary.
UPDATE: to make our IDEs (Eclipse, IDEA) to stop on breakpoints we deployed our webapp on AdminServer, because in case of deploying to the node in clustered environment our IDEs didn't stop at breakpoints at all.