Background
As this is the first question I have posted, I will try to break it down as well as possible, and I apologize for any incorrect formats. I should also point out that I am brand-new to Linux, Tomcat, and Java (all within the last few weeks), so if you do have an answer please dumb it down as much as you can. Thanks!
This question is actually several questions, but I feel the issues are somehow related so I will include them all. As for my environment, I am running an EC2 Amazon Linux instance. Details returned using
cat /proc/version are:
Linux version 2.6.35.14-97.44.amzn1.x86_64
(mockbuild#build-31006.build)
(gcc version 4.4.5 20110214 (Red Hat 4.4.5-6) (GCC)
java -version gives me:
java version "1.6.0_29" Java(TM) SE Runtime Environment (build
1.6.0_29-b11)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)
Issue(s)
What would allow me to stop/restart Tomcat sometimes, but not
others? After I change configuration parameters and need to restart
Tomcat, I use /etc/init.d/tomcat6 restart or service tomcat6
restart with varying degrees of success: sometimes the nice green
OK, others the red FAILED. There seems to be no rhyme or reason to
why it works sometimes and not others. When it doesn't work I check
the status with service tomcat6 status, which yields something
like tomcat6 (pid ####) is running. Also worth noting is that my
Putty SSH session slows down significantly at the same time whenever
I am unable to stop Tomcat. I literally have to wait for each keystroke to be processed!
I cannot use any of the JVM-specific -XX parameters. I get an error
every time of Could not create the Java virtual machine. Of the
threads I've read about this, most surround heap memory allocation
issues, but I don't think that's my problem because when I run java
-XX, which should give me a list of available commands just like java -X does, I simply get:
Unrecognized option: -XX Could not create the Java virtual machine.
I should note that I had at least two versions of Java on this OS- it came with Open JDK, but I needed Sun Java as that was recommended for performance in Geoserver (which is the whole point of me learning all this). I read that it is not an issue to have two versions, as long as my JAVA_HOME path points to the correct directory, but is it possible that it was still somehow looking at something from the original configuration? That's what I thought, so to rule it out I did a yum remove java, which erased the original version (along with Tomcat due to the dependency, but whatevs, I can get it back later), ran java -version to make sure I still had the version I wanted. I did, then ran java -XX, hoping that it magically fixed itself after cleaning house with the unwanted OpenJDK removal, but NOPE, same error as before.
Conclusions
I am now assuming that there was no issue with old paths. I've also tried changing my JAVA_HOME variable to the appropriate path (/usr/java/jre1.6.0_29) in every conceivable location:
in bash_profile
in bashrc
java.conf
tomcat6.conf (well, before I deleted Tomcat, that is)
probably some other files. It's all a blur really.
export JAVA_HOME in the shell
... all with zero impact, with the exception of using export JAVA_HOME=/usr/java/jre1.6.0_29. Every time I ran echo $JAVA_HOME I would still get the original JAVA_HOME path, which I'm pretty sure is not what I want. Even when resetting the variable was successful (via export in the shell), I still got my -XX error. I also tried setting some JAVA_OPTS parameters, specifically for memory settings, then ran an echo $JAVA_OPTS that returned nothing.
I have spent a solid two days on this and am about ready to give up. I would really like to avoid reinstalling and reconfiguring a whole bunch of stuff if possible, not to mention I don't even know if that would fix my problem, but I would really, really like to know WHY I having these issues and whether or not they're related, so if any of you have suggestions on this or anything in general that I'm doing incorrectly, please let me know. Thanks!
I can't help you with the first issue but in regard to your second issue: "I cannot use any of the JVM-specific -XX parameters.":
the environment variable CATALINA_OPTS is used by tomcat when starting the JVM. So if you want to use 512mb of heap and 128mb of perm gen space you can issue the follwing command on a bash shell to start tomcat with some custom java options.
#> CATALINA_OPTS="$CATALINA_OPTS -Xmx512m -XX:MaxPermSize=128m" $TOMCAT_HOME/bin/catalina.sh run
you can also change the default parameters by changing CATALINA_OPTS in tomcat's startup script or you can add the paramenter to your environment (e.g. $HOME/.bashrc).
hope that helps.
Related
I've got this version on jruby in Windows 10:
jruby 1.7.13 (1.9.3p392) 2014-06-24 43f133c on Java HotSpot(TM) Client VM 1.7.0_80-b15 [Windows 8-x86]
and when I try to uninstall it from Control Panel I keep on getting the error:
The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firewall tool could block the execution.
Any idea what I could try to delete this installation? I tried reinstalling the .exe file, to see if it had an option to remove/repair, but nothing, it just reinstalled it and I still have the problem.
check your environment variables ... you might have JRUBY_OPTS or JAVA_OPTS set.
unset those or adjust the -Xmx setting accordingly.
No commands seem to work for me, at the end I had to do it through a specific software design for this kind of issues: http://www.perfectuninstaller.com/
I've just found out that TeamCity runs on the 32-bit JVM on Windows, for some reason.
I'm seeing memory errors logged when checking out a large (not that large) Git repo and am already at the max heap size for the JVM. I know nothing about Java or the JVM, or TomCat.
How can I run TeamCity on a modern, 64-bit JVM? I sense its going to be a pain, else it would be the default.
We're a tiny team and if something doesn't have Apple levels of 'it just works' then we skip it.
We can live with this one project not be on the CI server, but it would be nice to know what's involved and weigh up the investment.
Any advice appreciated.
Edit
Okay so Markus pointed to this snippet (which I had read), but I can't see any information there explaining what to do.
Using 64 bit Java to Run TeamCity Server TeamCity can run under both
32 and 64 bit JVM. It is recommended to use 32 bit JVM unless you need
to dedicate more than 1.3Gb of memory to the TeamCity process.
If you choose to use x64 JVM please note that the memory usage is
almost doubled when switching from 32 to 64 bit JVM, so please make
sure you specify at least twice as much memory as for 32 bit JVM, see
Setting Up Memory settings for TeamCity Server.
If you run TeamCity as a service and switch to x64 bit, you will also
need to use x64 Tomcat executables, see more.
Did I miss something?
Edit 2
Ah, okay, buried in some paragraphs above that link is this:
"if you run as Windows service and want to upgrade JRE to 64 bit
version, you will need to replace \jre with appropriate
JRE"
So I guess I need to copy some files into the /jre folder?
The way I made it work (TeamCity 8, Windows server 2008 r2):
Install the 64-bit JRE on the target machine, now there are two ways to do this
A -> If you are using the Teamcity bundled JRE, replace the JRE folder ([TC Server folder]\JRE) with the JRE folder in the newly installed JRE x64 - You have to shut down the TC server service (along with all java.exe*32 services that might also use this JRE)
B -> Change the TeamCity Internal properties, to point to newly installed JRE x64 (see documentation for TC version 8, TC version 9 can be found here):
java.home=C\:\\<JRE x64 install folder>\\jre
java.ext.dirs=C\:\\<JRE x64 install folder>\\jre\\lib\\ext\;C\:\\Windows\\Sun\\Java\\lib\\ext
java.library.path=C\:\\<JRE x64 install folder>\\jre\\bin\;C\:\\Windows\\Sun\\Java\\bin\;C\:\\Windows\\system32\;C\:\\Windows\;C\:\\local\\Oracle\\clients\\112_64\\bin\;C\:\\local\\Oracle…
An alternative to point B would be to change Environment variable JAVA_HOME, it`s more simple, but it requires a Windows server restart after that
If you run the TC Server service now, it should run as a 64-bit Java process (chceck via PID in task manager) :
Don`t be alarmed if the server does not start up throwing an error :
Error: SQL error when doing: Connecting to MSSQL: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property
Download JTDS - 1.3.1 (http://sourceforge.net/projects/jtds/files/jtds/1.3.1/) and install it
Take the ntlmauth.dll file from [JTDS-1.3.1 install folder]/x64/SSO folder and replace the one in [TC Server folder]\bin
The TC server should now run fine as 64 bit Java process
You can increase the memory allocation (as that is the whole point of the upgrade) now on the server as described here : https://confluence.jetbrains.com/display/TCD8/Installing+and+Configuring+the+TeamCity+Server#InstallingandConfiguringtheTeamCityServer-SettingUpMemorysettingsforTeamCityServer
The snippet from the updated question had a link in the original, pointing to the instructions on Java update for TeamCity server in TeamCity online doc.
Basically, the instructions vary based on the TeamCity distribution used and way of launching the server.
If your intent is to increase the memory for the TeamCity server, please make sure to read through the corresponding section on the same doc page.
Yet one more note: recent TeamCity versions perform Git fetch in a separate process and Git-related memory issues during fetch might require fine-tuning of the corresponding options.
"So I guess I need to copy some files into the /jre folder?"
No. You install a 64 bit JRE, and update the relevant setting to point at the 64-bit install's JRE.
Don't copy stuff from one JRE installation into another. You will break things!
We use Java within our build process, as it is used to resolve/publish our dependencies via Ivy.
No problem, nor have we had with it for 2 years, until we've tried to upgrade Java 6 Update 26 to Version 7 Update 7, whereas a build on a local developer PC (WinXP) now takes 2 hours to complete, instead of 10 minutes!!
Nothing else has changed on the PC, making it the absolute target for our concerns.
Does anyone know of any reason as to why version 7 of Java would make such a speed difference like this?
UPDATE: The build process is NAnt-based, so Java.exe is called from a NAnt script, running in a Command (DOS) window.
I'm using JDK 7u7 and I noticed a better performance by tuning some VM Options.
You could try the G1GC and AgressiveOpts to help with compile time.
Follow the settings I use in my editor:
-Xss8m
-Xmn256m
-Xms512m
-Xmx1024m
-XX:PermSize=256m
-XX:MaxPermSize=512m
-XX:+UseG1GC
-XX:+OptimizeStringConcat
-XX:+UseStringCache
-XX:+AggressiveOpts
You will find each option's description in the VM Options link.
I hope it helps.
In my experience, Java 7 was a huge step backward in terms of speed and compatibility. I've found it slower not only to compile, but running the JRE as well.
I've also had major issues running eclipse with it (and yes, i've used update 7).
And from my standpoint there's nothing in Java 7 that i need. I like the ForkJoinPool, and can get that as an add on library for Java 6.
Maybe Java 8 will be better.
First, did you remove JDK6 or leave it in place? Check your JDK_HOME and any other place it is specified to ensure that you are actually using JDK7. In the XP console type java -version and ensure it is what is expected. (Close/reopen the command prompt to pick up changes in the Win GUI.)
It was never stated what version of XP you are running -- 64-bit or 32-bit. Ensure the appropriate JDK environment is on the machine. (Depending on exactly what is executing, this can make a tangible difference. Also, the best bet for debugging is to keep it the same as before -- reduce variables.)
Troubleshoot the issue and narrow it down. Does an Eclipse installation perform slower after the upgrade? (Eclipse itself runs in a JVM. It's a good baseline.) Is Eclipse pointing at the correct JDK when you test it? Try other Java tools to see if there is a performance difference. Breakpoints and logging at different control points in the build and any Java executables are your friends.
Since Nant is .NET based, have you looked at the Java process that is actually launched? Is your Ivy distribution really old?
All this said, it is hard for me to believe this is a Java issue and not a configuration challenge on the Windows box. Have you tried it on any other machines, anyway?
Am getting the following error message while trying to run java. I have typed in java -version but am getting error:
C:\>java -version
Picked up _JAVA_OPTIONS: -Xrunjvmhook -Xbootclasspath/a:C:\PROGRA~1\HP\QUICKT~1\
bin\JAVA_S~1\classes;C:\PROGRA~1\HP\QUICKT~1\bin\JAVA_S~1\classes\jasmine.jar
Error occurred during initialization of VM
Could not find agent library jvmhook on the library path, with error: Can't find
dependent libraries
Java is being invoked in a slightly abnormal way.
I have multiple answers depending on your Java version number and whether or not you wish to perform automated testing on your computer.
HP's Quick Test Professional (QTP, an automation tool) has been installed on your computer; this is the program which creates _JAVA_OPTIONS (and usually also IBM_JAVA_OPTIONS) to be what you observed in your post:
-Xrunjvmhook -Xbootclasspath/a:C:\PROGRA~1\HP\QUICKT~1\
bin\JAVA_S~1\classes;C:\PROGRA~1\HP\QUICKT~1\bin\JAVA_S~1\classes\jasmine.jar
QTP puts these in place so that it can recognize Java objects, allowing you test a Java application.
It also can create environment variable
JAVA_TOOL_OPTIONS with
-agentlib:jvmhook
which is required for working with Java 1.6
If you do not require QTP to perform tests against Java applications then you can experiment with removing these environment variables.
Pro-tip for easy reverting, just amend the Environment Variable names (e.g. rename _JAVA_OPTIONS to IGNOREME_JAVA_OPTIONS)
*Environment variables require local admin privileges and a system restart to take affect.
If you are using Java version 1.5 or older then you can probably get away with removing JAVA_TOOL_OPTIONS only.
The jasmine.jar seems to be troublesome to a number of java applications; I have had considerable difficulty with this stopping my applications from running in the past.
The _JAVA_OPTIONS environment variable is making some very serious modifications to your Java environment -- and obviously doing it wrong, since it's not launching. I don't know what is setting that environment variable, but if it's not something you're trying to do yourself, if I were you I'd make a note of the value just in case you need to restore it, then go to your Windows "System" Control Panel and remove _JAVA_OPTIONS altogether.
I'm using Intellij IDE. Removing .idea folder from project's local directory solved this issue.
I'm running ubuntu and djatoka (which runs in tomcat) won't work with OpenJDK. So I set JAVA_HOME and JRE_HOME to the Sun java that I downloaded and exported the variables. When I start tomcat, it reports JRE_HOME to what I set.
However, when I actually look at the variables, they're pointing to OpenJDK and djatoka isn't working. I can't find anyplace where it's being hardcoded, and even when I drop the variable assignments in catalina.sh and export from there, the same thing happens.
What the heck is going on? Thanks,
kyle
Did you start tomcat in the same session where you exported the value?
Did you manually install tomcat or did you apt-get it?
You can set the JAVA_HOME that tomcat must use in tomcat/bin/catalina.sh
You can also set it in /etc/environment. eg:
JAVA_HOME=/usr/lib/jvm/java-6-sun
https://help.ubuntu.com/community/EnvironmentVariables#System-wide environment variables
What operating system are you using? Try making sure you are setting those environment variables for the entire system and not the user.
Ubuntu uses a somewhat wired alternatives system. Program in /usr/bin point to /etc/alternatives and from there it goes to /usr/share/jdk-something.
There is an easy way: Uninstall the OpenJDK and GCJ. But you might run into dependency-issues.
Or read about the alternatives-system.
man update-alternatives
should help. It's not that hard. A little complicated - that's all.
I should add, that the benefit of the alternatives system is, that you can have multiple installations of java in parallel (1.5, 1.6, 1.7 alpha, OpenJDK) and switch with one command all the links - to java, javac, appletviewer, javap and so on. Not to forget the CLASSPATH, afaik. And Updates from 1.6.23 to 1.6.24 are handled by Ubuntu flawlessly. But it is annoying to trace the links down to their root.
There is even a Java-shortcut for the alternatives:
update-java-alternatives --help