Sometimes on the start STS hangs.
Does it possible found the reason? May be exists log or possible start in debug mode?
Also how I can distinguish between hangs completely and working very slowly?
Thanks.
P.S. How to fix ?
That is usually for the same resons descibed here tricks-to-speed-up-eclipse.
Garbage collection or validation.
If you have enough RAM I would suggest that you set -Xmx768m or higher (in eclipse.ini).
Under Windows->Preferences->Validation you can switch off a lot of stuff.
My STS hanged when I tried to start it. Couldn't tell why.
Doing this fixed things for me:
Shut down eclipse and then navigate to /.metadata/.plugins/org.eclipse.core.resources and remove the .snap file.
Courtesy: https://doctorjw.wordpress.com/2011/12/05/eclipse-locking-upnot-responding-try-this/
There's a log file I think it's in .metadata/.log in the workspace used. To see if memory causes the issue, and it usually does, try to run jconsole (part of the JDK) and connect to the running eclipse process, and see the memory stats.
Ensure that STS is running with admin privileges to avoid permission problems.
In ubuntu edit the following line in STS.desktop launch file:
Exec=gksu /etc/springsource/sts-3.4.0.RELEASE/STS
Complete file:
[Desktop Entry]
Name=STS
Comment=SpringSource Tool Suite
Exec=gksu /etc/springsource/sts-3.4.0.RELEASE/STS
Icon=/etc/springsource/sts-3.4.0.RELEASE/icon.xpm
StartupNotify=true
Terminal=false
Type=Application
Categories=Development;IDE;Java;
Related
I am facing issue here JConsole is not running.
Even though in my system hsperfdata_USERNAME directory and pid file also created. After that I try to run jconsole from the command line neither it shows any error nor i am seeing jconsole is running .
Today I have install JdK9 and I am facing this issue.
Please refer below image, thanks in advance for any kind of information or help.
I have refer this link and tried but still i could not start Jconsole.
When I launch start-dfs.sh in Hadoop 2.2.0 on Mac OS X, buried in the error messages, I have this:
2014-02-24 14:48:23,448 FATAL org.apache.hadoop.hdfs.server.datanode.DataNode: Exception in secureMain
java.lang.InternalError: Can't connect to window server - not enough permissions.
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1833)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1730)
...
I've dealt with this error before - it happens when Java is trying to access the window server (even though it's a command line program). For security reasons, this isn't allowed without a graphical login. This of course means that if you're running a headless server, you have to physically log in before your daemons run.
Now, without going into a rant about how STUPID Java and/or the developers are for doing this (it seems to be a trend; the only other Java server component I use does the same thing), I found the option:
-Djava.awt.headless=true
which looks like a possible solution. But not only do I have no idea where to pass the option to Hadoop, but I tried it on the other software, and it still gives the error.
I'd appreciate any help.
So I tried it, and it turns out there's two things going on. The option DOES in fact work... for Hadoop. But here's where it gets weird:
Hadoop won't append to a log file... if one exists, it leaves it and silently fails to write any logs. So I was looking at old log files.
The other software still doesn't work, but they said they're aware of the bug and they're fixing it.
I fixed it using:
export HADOOP_OPTS="-Djava.security.krb5.realm=OX.AC.UK -Djava.security.krb5.kdc=kdc0.ox.ac.uk:kdc1.ox.ac.uk -Djava.awt.headless=true"
in my bashrc
I have a single application which will cause eclipse itself to hang when run via eclipse. If I export this application as a jar and run it it works fine. But if I run (or debug) it the application will appear to start (according to ps) and run; but eclipse itself will hang, and is reported as a 'stopped' program with no CPU or memory usage. I've placed a breakpoints on the first line of this application and it doesn't even get there before eclipse ends up stopped. If I forcefully wake eclipse out of stopped state it will work; but it will also lose it's connection with the program I started. My program I want to debug will continue running but eclipse can't control or kill it after I resume the stopped eclipse.
I can run plenty of other applications without issue from eclipse. Oddly I had this issue before, then I could run my application for a day, and now I'm back to the original issue. I don't know what changed between those that would matter.
Can anyone suggest what may cause this or how to repair it?
UPDATE:
I did some more linux magic. It seems that eclipse is stopped while waiting for the command:
sh -c stty -lcanon min 1
It also seems that before that there was a sh (defunct) command which also hung without being reaped for a few minutes which I think was keeping eclipse from running properly; the sh (defunct) finally goes away if I wait long enough; but then the sh command I just linked comes up. I don't know what the original defunct SH command was; I can't do ps fast enough to catch it before it goes defunct. Both issues occur only with eclipse; as a jar file this program runs perfectly fine.
My running assumption is that eclipse isn't getting or handling the sigchild correctly? that would explain the sh (defunct) application at least. It doesn't explain the current SH command which doesn't show as defunct; despite it being something that should execute in seconds?
UPDATE 2.0:
I found this link: http://linux.about.com/od/srl_howto/a/hwtsrl13t04_3.htm basically stty is known to hang when it uses the < /dev/tty syntax; which is why the syntax is deprecated and replaced with a newer syntax. I'm pretty sure this is the problem. Sadly I have no way of figuring out what library is using the deprecated command. I think this all started with the ConsoleReader being constructed; but who knows what code actually ran the command that freezes? also, it seems if this was that broken anyone running consoleReader from eclipse on a linux environment would have the same problem; which I think is safe to assume isn't the case or it would be documented all over the net; so maybe my understanding is still off?
It is related to the configuration of the stty process that is created to attach the console and hence will occur only on UNIX like systems. Seems fixed on current 2.11 jline version.
To bypass the problem you can disable the special unix-terminal capabilities using:
-Djline.terminal=none
as VM argument on the eclipse launch configuration.
Try increasing -Xms<abc>m/-Xmx<efg>m (depending on the system memory) on eclipse.ini in the root directory of eclipse installation.
The problem was that we were using an older version of 'jline' which used deprecated functionality. The new jline jar fixed the problem, as it no longer used the deprecated stty calls. I'm not quite certain why eclipse caused this to happen every time; it seems as if it should be an intermittent error, but jline was definitely the cause.
I followed the instructions on the Datomic site: http://docs.datomic.com/getting-started.html, but I'm getting this error when trying to start up the datomic shell prompt. I'm using a windows machine. Any suggestions? I tried the same thing on my linux box and did not get this error.
Edit: moved to a different windows machine and it's working. If I have time to troubleshoot this problem and I find a solution I'll report back
I noticed that you cannot run the shell.cmd from within the bin directory, you need to call it with bin\shell.cmd from the parent directory... hope that helps.
In case you are using cygwin/bash and call bin/shell :
The java runtime on windows does not understand classpath with a ":"
but this is what you get from bin/classpath.
Either correct this or use DOS-CMD shell and call bin/shell.cmd inside.
Regards
Some tips for running datomic on Windows (7 at least):
Do not download datomic into Program Files. On startup, it creates logging directories and temp files into its own directories, so unless you run the command prompt as Administrator, you're gonna have screens full of Unable to write to file... errors.
You need to run datomic as such (assuming you extracted the download to C:)
c:\datomic-free-0.x.xxxx>bin\shell.cmd
Note the backslash. Tripped me up forever coming from *nix world.
After that, return to your regularly scheduled datomic tutorials.
I'm using ASANT to run a xml file which points to a NARS.jar file.
I'm getting "java.lang.OutOfMemoryError: Java heap space" and i'm researching around this.
So i have found that i need to set "-XX:+HeapDumpOnOutOfMemoryError", to create a dump file to analyze.
I edited ASANT.bat and added the "-XX:+HeapDumpOnOutOfMemoryError" to ANT_OPTS:
set ANT_OPTS= "-XX:+HeapDumpOnOutOfMemoryError" "-Dos.name=Windows_NT" "-Djava.library.path=%AS_INSTALL%\lib;%AS_ICU_LIB%;%AS_NSS%" "-Dcom.sun.aas.installRoot=%AS_INSTALL%" "-Dcom.sun.aas.instanceRoot=%AS_INSTALL%" "-Dcom.sun.aas.instanceName=server" "-Dcom.sun.aas.configRoot=%AS_CONFIG%" "-Dcom.sun.aas.processLauncher=SE" "-Dderby.root=%AS_DERBY_INSTALL%"
But i can't seem to find any dump file.
I will use the Eclipse Memory Analyzer to analyze when i find the dump.
I also tried to set the option "-XX:HeapDumpPath=c:\memdump\bds.hprof", but no dump was created there.
Anyone got an idea of what i'm doing wrong?
Thanks in advance
It looks like your application is running on Windows. A Windows file path needs to be escaped with \. As per your example, -XX:HeapDumpPath should look like:
-XX:HeapDumpPath=c:\\memdump\\bds.hprof
Besides ‘-XX:+HeapDumpOnOutOfMemoryError’ there are several other options to capture heap dumps as well.
I found that i could use VisualVM from SUN to get a heapdump, and see it live.
Easy solution
It's in the working directory of the application (i.e. where you've started it). I'm not sure what happens if the process does not have the necessary privileges to do so. Probably, writing the dump would fail silently.
are you sure that ANT is the process with the OOME ? It may be a process started by ANT.
Add "-debug" to the ANT_OPTS for debugging information.
Are you seeing the targets being printed out during the execution?
You can also fork the various processes started by ant ( will slow things down but may help isolate the culprit )
Lastly, maybe you just need more memory than the default. Add:
-Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=256m
to the ANT_OPTS
Umm... how about wherever java.io.tmpdir is pointing?