So I'm running an integration test/spec using configuration for an ActiveMQ in-memory broker.
SomeSpec.groovy:
#SpringApplicationConfiguration(SomeApplication.class)
#WebIntegrationTest(randomPort = true)
class SomeSpec extends Specification {
application.properties
spring.activemq.in-memory=true
spring.activemq.pooled=false
The in memory broker starts up and runs fine when I do gradle test and
also runs fine when used with gradle bootRun at the command line. However when I run inside IntelliJ without explicitly having it run gradle test the in memory broker does not start and the tests fail.
How can I take and advantage of the nice test/spec running features in IntelliJ but still have it initialize the in memory queue properly? I know with Grails you could run with JUnit or Grails. Is there something similar with Spring/SpringBoot so everything starts up properly.
It's probably because your config files are not refreshed under project/out/production/config/ location.
When you run it from cmd line, it takes the latest application.properties, so every thing is fine.
But Idea takes the already compiled config files, and if they are not rebuilt inside Idea then it still loads the load configuration.
I am getting "Could not reserve enough space for object heap" error when I am trying to start hybris server.
I have set
wrapper.java.additional.1=-Xmx1G
wrapper.java.additional.2=-XX:MaxPermSize=1024M
My machine is 64 bit 8GB RAM Windows
I faced the same problem once, The problem in my case was that too many other Applications were running on my system.
So go to the task manager and check the memory available use.
Close some applications and try running.
Also if you are using eclipse Then, In your eclipse.ini file (this is beside the eclipse executable), replace -Xmx256m with -Xmx1024m (or Xmx512m).
This is not compulsory but in certain cases it works.
If you are using some extension then,
Open YOURPATH/config/local.properties file.
Add the following entry:
config/local.properties
build.parallel=true
Save the file.
(In cases where we have multiple cores in the machine, we can tell hybris to utilize these by building in parallel and in certain cases this too works)
I too faced the same probelm. I followed below steps and set the max heap size to 1GB.
Add the following content to local.properties
tomcat.generaloptions=-Xmx4G -ea -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dorg.tanukisoftware.wrapper.WrapperManager.mbean=true -Djava.endorsed.dirs="%CATALINA_HOME%/lib/endorsed" -Dcatalina.base=%CATALINA_BASE% -Dcatalina.home=%CATALINA_HOME% -Dfile.encoding=UTF-8 -Dlog4j.configuration=log4j_init_tomcat.properties -Djava.util.logging.config.file=jdk_logging.properties -Djava.io.tmpdir="${HYBRIS_TEMP_DIR}"
ant clean all
start hybrisserver
Reference
https://launchpad.support.sap.com/#/notes/0002437669
While using IntelliJ 13 ultimate edition for a week, it just seems really slow.
First of all, the whole IDE stops for a second or so every once in a while. The Java editor's auto complete is really slow compared to 12 version.
I have not changed anything from the default settings other than using a Dracula theme.
It seems that this is not a problem of my own. Many people suggested setting the heap size higher than default, or clearing the cache, but I have not checked or tested on these suggestion. Do I need to change some setting to improve the new version's performance?
I had the same problem with slowness in IntelliJ 13 after upgrading from 12.
What worked for me was editing the idea64.vmoptions in the bin folder and setting the max heap to 8 GB (was 512 MB) and the Max PermGen to at least 1GB (was 300MB).Example below:
-Xms128m
-Xmx8192m
-XX:MaxPermSize=1024m
Upon restart it was much faster.
For IntelliJ 2020 going back to 2017 on Mac
/Applications/IntelliJ IDEA.app/Contents/bin/idea.vmoptions
On a Mac, this file is located in this path:
For IntelliJ 14 or 15 on Mac
/Applications/IntelliJ IDEA 14.app/Contents/bin/idea.vmoptions
For IntelliJ 13 on Mac
/Users/yourusername/Library/Preferences/IntelliJIdea13/idea.vmoptions
IntelliJ's updater (since 2017) seems to roll this change back, so you may need to re-apply it after updating.
On Ubuntu Linux, this file is located in this path relative to the install directory:
idea-IU-135.475/bin/idea64.vmoptions
and for 2016.2:
~/.IdeaIC2016.2/idea64.vmoptions
On Windows 10 (Community edition shown here) these files are located in:
C:\Program Files (x86)\JetBrains\IntelliJ IDEA Community Edition 2016.1.3\bin\idea64.exe.vmoptions
I noticed that disabling many of the plug ins really helps speed up IntelliJ. For example, I am not developing Android Applications. Turning the plugins related to Android development off speed up load time and makes the program run much smoother on my machine.
In my case, GIT integration appears to be causing the editor to be frustratingly slow with 13.
While typing, even comments, with GIT integration turned on, after about 30 characters, the UI freezes for a second or so. Its usually not long, but very annoying.
I am using GIT 1.7.8.0. Running on Windows 7 64 with a solid state drive and 12 gigs of ram and an intel I7 with 8 CPUs. I tried various things, like updating the idea64.exe.vmoptions to use more memory, like -Xmx2400m and -XX:MaxPermSize=2400m, -XX:ParallelGCThreads=6, but it didn't fix the problem.
The git repository is 1.3 gigs with 65,000 files.
I created a new "grails" project in a new git repository, and there is no issue. I created a new grails project in the existing large git repository, and intellij is slow. I turned off git integration by opening the project settings dialog and deleting the git root, and the problem goes away.
I tried disabling all of the GIT background operations through the 13 UI, but it didn't make a difference. I also tried both GIT built-in and native modes, and it made no difference.
In my case the workaround seems to be to disable GIT integration until I need it, and to then just re-add the git root. If anyone else can verify the same problem, then we might report it as an issue.
In my case massive performance degradation was caused by IntelliJ unintentionally using JDK/JRE 1.8. This seems to affect rendering performance quite badly and also leads to some unexpected crashes and deadlocks.
This would render the IDE unusable (latency of 1-2s on operations) for even a small ~3KLOC project.
Just ensure you are using JDK/JRE 1.7 when running intellij:
JAVA_HOME=/usr/lib/jvm/jdk1.7.0_67 intellij
(or whatever the equivalent is for your OS)
You can check the JRE that is being used to run intellij under Help -> About -> JRE.
Well I can't reply to Engineer Dollery's post above because I don't have 50 rep yet... but I've noticed the same thing. One problem has been reported already regarding hg4idea: http://youtrack.jetbrains.com/issue/IDEA-118529.
There't no fix yet except to disable the hg4idea plugin. But if that turns out to be your problem, vote for the bug!
Edit: JetBrains has fixed the bug in build IU-138-815!
I had a similar problem.
In that case it was the Subversion plug-in. (Mac Mavericks, SVN version 1.7.10)
Once I disabled this IntelliJ became useable again.
Got this from jstack:
"Change List Updater" daemon prio=2 tid=10df3f000 nid=0x12a421000 runnable [12a41f000]
java.lang.Thread.State: RUNNABLE
at java.util.Collections.unmodifiableList(Collections.java:1131)
at com.intellij.execution.configurations.ParametersList.getList(ParametersList.java:88)
at com.intellij.execution.configurations.GeneralCommandLine.getCommandLineString(GeneralCommandLine.java:210)
at com.intellij.execution.configurations.GeneralCommandLine.getCommandLineString(GeneralCommandLine.java:189)
at org.jetbrains.idea.svn.commandLine.CommandExecutor.createProcessHandler(CommandExecutor.java:186)
at org.jetbrains.idea.svn.commandLine.CommandExecutor.start(CommandExecutor.java:137)
- locked <76afcdfb8> (a java.lang.Object)
at org.jetbrains.idea.svn.commandLine.CommandExecutor.run(CommandExecutor.java:262)
at org.jetbrains.idea.svn.commandLine.CommandRuntime.runWithAuthenticationAttempt(CommandRuntime.java:62)
at org.jetbrains.idea.svn.commandLine.CommandUtil.execute(CommandUtil.java:206)
at org.jetbrains.idea.svn.commandLine.CommandUtil.execute(CommandUtil.java:189)
at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.execute(SvnCommandLineInfoClient.java:120)
at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.issueCommand(SvnCommandLineInfoClient.java:104)
at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.doInfo(SvnCommandLineInfoClient.java:90)
at org.jetbrains.idea.svn.commandLine.SvnCommandLineInfoClient.doInfo(SvnCommandLineInfoClient.java:232)
at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.doStatus(SvnCommandLineStatusClient.java:106)
at org.jetbrains.idea.svn.SvnRecursiveStatusWalker.go(SvnRecursiveStatusWalker.java:79)
at org.jetbrains.idea.svn.SvnChangeProvider.getChanges(SvnChangeProvider.java:89)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:686)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:596)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.d(ChangeListManagerImpl.java:480)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.access$1100(ChangeListManagerImpl.java:71)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl$ActualUpdater.run(ChangeListManagerImpl.java:387)
at com.intellij.openapi.vcs.changes.UpdateRequestsQueue$MyRunnable.run(UpdateRequestsQueue.java:260)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
other run:
"Change List Updater" daemon prio=2 tid=124556000 nid=0x129c7a000 runnable [129c78000]
java.lang.Thread.State: RUNNABLE
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228)
at java.io.File.exists(File.java:733)
at org.apache.xerces.parsers.SecuritySupport$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.xerces.parsers.SecuritySupport.getFileExists(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.parseResult(SvnCommandLineStatusClient.java:138)
at org.jetbrains.idea.svn.commandLine.SvnCommandLineStatusClient.doStatus(SvnCommandLineStatusClient.java:118)
at org.jetbrains.idea.svn.SvnRecursiveStatusWalker.go(SvnRecursiveStatusWalker.java:79)
at org.jetbrains.idea.svn.SvnChangeProvider.getChanges(SvnChangeProvider.java:89)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:686)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.a(ChangeListManagerImpl.java:596)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.d(ChangeListManagerImpl.java:480)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl.access$1100(ChangeListManagerImpl.java:71)
at com.intellij.openapi.vcs.changes.ChangeListManagerImpl$ActualUpdater.run(ChangeListManagerImpl.java:387)
at com.intellij.openapi.vcs.changes.UpdateRequestsQueue$MyRunnable.run(UpdateRequestsQueue.java:260)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
Best experience with following options (idea64.exe.vmoptions):
-server
-Xms1g
-Xmx3g
-Xss16m
-XX:NewRatio=3
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
-XX:SoftRefLRUPolicyMSPerMB=50
-XX:ParallelGCThreads=4
-XX:+UseConcMarkSweepGC
-XX:ConcGCThreads=4
-XX:+CMSClassUnloadingEnabled
-XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=65
-XX:+CMSScavengeBeforeRemark
-XX:+UseCMSInitiatingOccupancyOnly
-XX:MaxTenuringThreshold=1
-XX:SurvivorRatio=8
-XX:+UseCodeCacheFlushing
-XX:+AggressiveOpts
-XX:-TraceClassUnloading
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-Djava.net.preferIPv4Stack=true
-Dsun.io.useCanonCaches=false
-Djsse.enableSNIExtension=true
-ea
75s -> 10s intellij startup. All I did was switch from using the default 32bit exe to using the 64bit exe.
For me the problem was a nodes_modules folder with more than thousand files. I had to mark the directory as excluded.
Also see this list of possible problems.
I am on 13.1, and I have found the following setting works wonders for me: IDE Settings --> Editor --> Autoreparse delay (ms), which I have set to 1500 (default is 300).
On a large project, the compiler and inspections would be constantly kicking off between interactions. The delay perhaps help to reduce heap pressure and generally make the whole experience a lot quicker. My cpu is a lot cooler as well, which probably helps.
I have solved my performance issues by switching to the 32 bit mode. It seems to be related with the JRE that IntelliJ runs with. It ships with a 32 bit 1.7 JRE which is used when starting idea.exe. If you start idea64.exe, it uses a 64 bit JRE installed on the system. In my case this was a 1.6 JDK (the one I use for development). This caused IntelliJ to be nearly unusable.
After installing a proper 64 bit 1.7 JDK everything was fine with the 64 bit mode, too.
See the answer on the IntelliJ Support web site.
In my case I am developing within Moodle which creates huge JS and CSS minified files. Once I excluded theses "cached" minified files from the project, InitelliJ ran normally again.
I had similar issues with a very slow start and heap issues, increasing VM did not make a huge difference, just delayed the inevitable, the fix for me was to invalidate the cache via File > InvalidateCaches/Restart.
https://www.jetbrains.com/help/idea/2016.1/cleaning-system-cache.html
I've been using 13 since early beta and I have no problems at all. Perhaps it's your specific settings. Maybe your project has grown over time and the memory you gave Idea originally isn't sufficient for it now? Try giving Idea more memory to work with: http://www.jetbrains.com/idea/webhelp/increasing-memory-heap.html (instructions on how to do that).
IntelliJ version 13 is markedly slower than the 12 version from my experience. There are a few ways to speed it up, like increasing the VM options for intelliJ. For eg. I'm using a maven project, and for that I increased the runner and importer options to 4GB . It made things much faster than before.
My particular case (Mac) was I edited the info.plist to use java 1.7* (for whatever reason), and it ran like an absolute dog.
Changed back to 1.6* and installed java 1.6, and it was fast.
I was facing sluggish performance with Intellij 2016.1(64-bit) and JDK 1.8(64-bit).
I switched to
64 bit intellij
64 bit Java 8 as JAVA_HOME path (This is required to run 64-bit Intellij)
32 bit Java 8 as JDK to be used for Intellij projects (File -> Project Structure | Project Settings -> Project | Project SDK).
By this combination, now Intellij performance is quite OK.
Editing the idea.vmoptions file is only a temporary solution until the next product update. See the JetBrains help pages for a more permanent solution to setting these values via the vm settings - https://www.jetbrains.com/help/idea/tuning-the-ide.html
Increase heap size for the compiler. By default the value is 700m which is a way too small with increasing number of plugins.
At v2019.1 it located here:
Settings -> Build, Execution, Deployment -> Compiler -> Build process heap size (Mbytes)
After I put 4000 there it solved most my performance issues.
My particular case:
I had a number of method breakpoints while I was running my code in debug mode, which made my intelliJ slow.
I have a few EJBs compiled with Weblogic's EJBC complient with Weblogic 9.2.1.
Our customer uses Weblogic 9.2.3.
During server start Weblogic gives the following message:
<BEA-010087> <The EJB deployment named: YYY.jar is being recompiled within the WebLogic Server. Please consult the server logs if there are any errors. It is also possible to run weblogic.appc as a stand-alone tool to generate the required classes. The generated source files will be placed in .....>
Consequently, server start takes 1.5 hours instead of 20 min. The next server start takes exactly the same time, meaning Weblogic does not cache the products of the recompilation. Needless to say, we cannot recompile all our EJBs to 9.2.3 just for this specific customer, so we need an on-site solution.
My questions are:
1. Is there any way of telling Weblogic to leave those EJB jars as they are and avoid the re-compilation during server start?
2. Can I tell Weblogic to cache the recompiled EJBs to avoid prolonged restarts?
Our current workaround was to write a script that does this recompilation manually before the EAR's creation and deployment (by simply running java weblogic.appc <jar-name>), but we would rather avoid this solution being used in production.
I FIXED this problem by spending a great deal of time researching
and decompiling some classes.I encountered this when migrating from weblogic8 to 10
by this time you might have understood the pain in dealing with oracle weblogic tech support.
unfortunately they did not have a server configuration setting to disable this
You need to do 2 things
Step 1.You if you open the EJB jar files you can see
ejb-jar.xml=3435671213
com.mycompany.myejbs.ejb.DummyEJBService=2691629828
weblogic-ejb-jar.xml=3309609440
WLS_RELEASE_BUILD_VERSION_24=10.0.0.0
you see these hascodes for each of your ejb names.Make these hadcodes zero.
pack the jar file and deploy it on server.
com.mycompany.myejbs.ejb.DummyEJBService=0
weblogic-ejb-jar.xml=0
This is just a Marker file that weblogic.appc keeps in each ejb jar to trigger the recompilation
during server boot up.i automated this process of making these hadcodes to zero.
This hashcodes remain the same for each ejb even if you execute appc for more than once
if you add a new EJB class or delete a class those entries are added to this marker file
Note 1:
how to get this file?
if you open domains/yourdomain/servers/yourServerName/cache/EJBCompilerCache/XXXXXXXXX
you will see this file for each ejb.weblogic makes the hashcodes to zero after it recompiles
Note 2:
When you generate EJB using appc.generate them to a exploded directory using -output C:\myejb
instead of C:\myejb.jar.This way you can play around with the marker file
Step2.
Also you need a PATCH from weblogic.When you install the patch you see some message like this
"PATH CRXXXXXX installed successfully.Eliminate EJB recomilation for appc".
i dont remember the patch number but you can request weblogic for that.
You need to use both steps to fix the problem.The patch fixes only part of the problem
Goodluck!!
cheers
raj
the Marker file in EJBs is WL_GENERATED
Just to update the solution we went with - eventually we opted to recompile the EJBs once at the Customer's site instead of messing with the EJBs' internal markers (we don't want Oracle saying they cannot support problems derived from this scenario).
We created two KSH scripts - the first iterates over all the EJB jars, copies them to a temp dir and then re-compiles them in parallel by running several instances of the 2nd script which does only one thing: java -Drecompiler=yes -cp $CLASSPATH weblogic.appc $1 (With error handling of course :))
This solution reduced compilation time from 70min to 15min. After this we re-create the EAR file and redeploy it with the new EJBs. We do this once per several UAT environment creations, so we save quite a lot of time here (55min X num of envs per drop X num of drops)
I'm using the Maven plugin for embedded Glassfish - here's my plugin declaration:
<plugin>
<artifactId>maven-glassfish-plugin</artifactId>
<packaging>maven-plugin</packaging>
<version>1.0-alpha-4</version>
<configuration>
<httpPort>8080</httpPort>
</configuration>
</plugin>
After several clicks through my data-intensive web app, I run out of PermGen space.
java.lang.OutOfMemoryError: PermGen space
I've already configured MAVEN_OPTS to use more memory:
set MAVEN_OPTS=-Xmx1024m
But it looks like the Java process spawned by mvn glassfish:run is only getting about half a gigabyte of memory before it seizes up.
Does the Glassfish plugin have any configuration settings for upping its memory?
Thanks!
Just to clarify. The permanent generation space contains loaded class objects and interned strings. It is allocated outside of the Java heap as illustrated below:
On recent Sun VMs, the default maximum size is 64m (i.e. -XX:MaxPermSize=64m) and is adequate for most applications (the problem is very likely related to frequent undeploy/redeploy here though). I would anyway try with -XX:MaxPermSize=128m or -XX:MaxPermSize=256m, 1024m seems really oversized!
After further consultation with some colleagues, it seems I was increasing the wrong memory value in Maven.
To increase PermGen space, I added this to my MAVEN_OPTS:
set MAVEN_OPTS=-Xmx1024m -XX:MaxPermSize=1024m