We Keep Coding

Tomcat process suddenly crushes

Trying to diagnose some bizarre Tomcat 6 and/or JVM errors on a 64-bit linux machine:
OS VERSION : RED HAT ENTERPRISE LINUX SERVER RELEASE 6.3 (SANTIAGO)
SERVER MODEL : VMWARE VIRTUAL PLATFORM ()
I am running some application tests on virtual machines and facing a weird issue.
The problem occures on certain VMs where exactly 2 process are running: Tomcat Application server process (java process) and a monitor process, at one randomal point, after some random hours of execution the following message can be found on catalina.out (server log) of the VM that fails (the problem doesnt occurs always on same machine):
org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-50100
INFO: Stopping service Catalina
org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
After this moment the Tomcat process is shutted down and execution fails.
No picks can be seen on memory or CPU use.
No system messages can be seen under /var/logs.
At first stage we suspected that an external signal is killing our Tomcat process and we tried to use the -Xrs flag for JVM arguments of the process but issue still occurred.
The java flag (-xrs ) should prevent the Java runtime environment handling exception signals such SIGSEGV and SIGABRT not help
Before adding xrs flag we saw INFO: Pausing Coyote HTTP/1.1 on http-50100 error that happened because outcome signal
After adding `xrs flag the kettle/tomcat behaves the same way and crushes without any errors in log files.
Running starce command on relevant process gives us the following output:
Process 12917 attached - interrupt to quit
futex(0x7f6b9e8ab9d0, FUTEX_WAIT, 12918, NULLPANIC: attached pid 12917 exited with 143
We cannot run starce -f to include all threads because it causes our application to be stuck.
However, killing son process with kill command behaves similary - we see that parent JVM
exit with error code 143 and we see also the signal sent to the son process.
We are running also with java -XX:+HeapDumpOnOutOfMemoryError optind to create a heap dump for jvm crash due to out of memory error but no core dump or heap dumps are creted due to the crush.
Any ideas?

is it possible, that before the crash, there is some sort of memory depletion, so that the java process could be killed by the OOM.
Also, I found a link http://bugs.centos.org/view.php?id=4059 that describes a similar problem.

Tomcat does not start

When I try to startup my embedded tomcat my application will run until tomcat reaches following lines:
"Dez 11, 2012 3:28:06 PM org.apache.coyote.AbstractProtocol start
Information: Starting ProtocolHandler ["http-bio-8080"]"
Can anyone help me with embeddedTomcat?
Best regards

Try this. Run this from the command line:
netstat -a -n
Look through there and see what ports are in the LISTEN state. Do you see your port open? From the logs it looks like it's running on port 8080 (ie ["http-bio-8080"]). If you see it running on port 8080 then hit this URL:
http://localhost:8080
Did you get some sort of response from apache? Even a 404 shows it's running.
Read this: http://www.copperykeenclaws.com/embedding-tomcat-7/

google app engine service unavailable

I'm was following http://googcloudlabs.appspot.com/ tutorial to create new Google App Engine project. It throws me an error as per below when I try to run the from my local host, but when I deployed it working fine. (http://mynewcloudcom.appspot.com/). Please help.
HTTP ERROR: 503
Problem accessing /. Reason:
SERVICE_UNAVAILABLE
Powered by Jetty://
Eclipse Console
Mar 05, 2012 10:42:46 AM com.google.apphosting.utils.jetty.JettyLogger info
INFO: Logging to JettyLogger(null) via com.google.apphosting.utils.jetty.JettyLogger
Mar 05, 2012 10:42:46 AM com.google.apphosting.utils.config.AppEngineWebXmlReader readAppEngineWebXml
INFO: Successfully processed C:\Smartag_Eclipse_Project\DontEditProject\war\WEB-INF/appengine-web.xml
Mar 05, 2012 10:42:46 AM com.google.apphosting.utils.config.AbstractConfigXmlReader readConfigXml
INFO: Successfully processed C:\Smartag_Eclipse_Project\DontEditProject\war\WEB-INF/web.xml
Mar 05, 2012 6:42:48 PM com.google.appengine.tools.development.DevAppServerImpl start
INFO: The server is running at http://localhost:8888/
Mar 05, 2012 6:42:48 PM com.google.appengine.tools.development.DevAppServerImpl start
INFO: The admin console is running at http://localhost:8888/_ah/admin

Found the answer. I need to run in JDK1.6. Once i changed the Java Compiler(right click project -> properties -> Java Compiler -> (Check) Enable project specific settings -> change the Compiler compliance level), its works fine now. Thanks.

I had the same problem. I justed changed the port from 8888 to 80 in the Debug Configuration and it worked for me.

I had the same issue.
for me the problem was one of my filters had an exception. specifically objectify - it was not loaded properly. you can delete the filter and see if that's it

When using Java 1.7, also check for the Execution Environment and set it to JavaSE-1.7.
You can look into the Execution Environment in:
Right Click -> Properties -> Java Compiler
And you have the option above Restore Defaults and Apply.

I faced the same issue and resolved it by selecting "Automatically select an unused port" in run configuration.

Sometimes it happens there is a "hanging" process that blocks the port. Therefore changing port in Run configuration helps, as well as checking "Automatically select an unused port" in run configuration.

It happened with me too. In my case, I had Run the project and due to some error in my code, the Project ran with errors. So, I debugged it and Run it again but without cancelling the earlier one in the console and it gave me that error. After cancelling or stopping the Project, it ran fine.

i had the same issue. Seems that Plugin is stocked on creating and opening the socket for the server. i don't really know why happens, I've resolved in this way.
Open Run Configurations.
Open Server tab. Change the Embedded server Port.
Open Arguments tab.
3.1 - VM arguments box. i've deleted all that stuff there and just let this
line and save changes and run it.
-Xmx512m -javaagent:/Applications/eclipse/plugins/com.google.appengine.eclipse.sdkbundle_1.7.5/appengine-java-sdk-1.7.5/lib/agent/appengine-agent.jar
It has worked pretty good 4me.
If someone know which events or configuration change are the reason for . please let us know it
NOTE: "I'm not responsible for unexpected behave. I'm don't know if there is side effects ahead"

The solution working for me is to run appEngineServer from command line using Gradle, as comments in generated build.xml for endpoints module proposes. And gradle config includes option for Java 1.7 compatibility, so it's no reason to use Java 1.6 if You want 1.7:
gradlew modulename:appengineRun
Currently, the appengine gradle plugin's appengine devappserver
launch doesn't interact well with Intellij/AndroidStudio's
Gradle integration. As a temporary solution, please launch from the command
line. ./gradlew modulename:appengineRun

I had a condition where a servlet defined in the web.xml with non existent class name. I specified proper class name, worked!

Remote debugging on Tomcat with Eclipse

I'm trying to initiate a remote debugging session on my PC with Eclipse & Tomcat.
I managed to run tomcat (not through eclipse) with the following params:
set JPDA_TRANSPORT=dt_socket
set JPDA_ADDRESS=5050
cataline jpda start
The server starts ok, this is the outcome:
Using CATALINA_BASE: "C:\Java\Tomcat"
Using CATALINA_HOME: "C:\Java\Tomcat"
Using CATALINA_TMPDIR: "C:\Java\Tomcat\temp"
Using JRE_HOME: "C:\Java\jdk1.6.0_27"
Using CLASSPATH: ...
Listening for transport dt_socket at address: 5050
...
...
INFO: Server startup in 12502 ms
Now, I opened eclipse, and loaded the relevant project.
I set a new debugging configuration using Remote Java Application with localhost and the right port. however when I run it, I get this error message:
Failed to connect to remote VM. Connection refused.
Connection refused: connect
Can't really understand where is the problem. this is all local inside the PC, so there shouldn't be any firewalls involved, can someone think of something ?

Found the solution. apparently the connection was made, but Eclipse & Tomcat don'tt show any notification or status regarding it.
Then, when you initiate the connection again, you get the error because you're already connected.
I think that a small notice, either from Eclipse, or from Tomcat would be nice.

Try adding the following debug options directly to the JVM startup by directly modifying the catalina startup script
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5050

There could be problems when there are code mismatches between eclipse and tomcat. So when it matches the error will disappear

You can configure it in remote java application section in debug configuration.
For more details you can refer this link

Launching Jade In Ubuntu10.04 Linux

When I run the below command in terminal of ubuntu linux and also I set the ClassPath properly but I wasn't successful.
java jade.Boot -gui
I got following errors in terminal window:
15 Jun, 2011 6:33:10 PM jade.core.Runtime beginContainer
INFO: ----------------------------------
This is JADE snapshot - revision 6357 of 2010/07/06 16:27:34
downloaded in Open Source, under LGPL restrictions,
at http://jade.tilab.com/
----------------------------------------
Retrieving CommandDispatcher for platform null
15 Jun, 2011 6:33:11 PM jade.imtp.leap.CommandDispatcher addICP
WARNING: Error adding ICP jade.imtp.leap.JICP.JICPPeer#ae506e[Error: Not possible to launch JADE on a remote host (127.0.1.1). Check the -host and -local-host options.].
15 Jun, 2011 6:33:11 PM jade.core.AgentContainerImpl joinPlatform
SEVERE: Communication failure while joining agent platform: No ICP active
jade.core.IMTPException: No ICP active
at jade.imtp.leap.LEAPIMTPManager.initialize(LEAPIMTPManager.java:138)
at jade.core.AgentContainerImpl.init(AgentContainerImpl.java:316)
at jade.core.AgentContainerImpl.joinPlatform(AgentContainerImpl.java:482)
at jade.core.Runtime.createMainContainer(Runtime.java:165)
at jade.Boot.main(Boot.java:89)
15 Jun, 2011 6:33:11 PM jade.core.Runtime$1 run
INFO: JADE is closing down now.
help me to recover from this error.

I am so tired of this problem. It is one of many quirks and problems with JADE.
The problem you are facing is that you need to supply correct host information in the command line. Example
java jade.Boot -gui -local-host
This is all described here: http://jade.tilab.com/doc/tutorials/JADEAdmin/startJade.html
In many cases you don't have this problem and then it is sufficient to use the -gui option only. However I have discovered that Jade does not work very well when your resolves to 127.0.1.1. You can fix this by setting your IP address in or if you are on Linux edit your /etc/hosts file for a more permanent solution.

just type in JADE path..
java -cp lib/jade.jar jade.Boot -gui -local-host 127.0.0.1
(JADE has some problems to set local host adress)

The problem might be is previous java process might be still running on the local port , Make sure to check if port is in use or not if in use kill the java process before you rerun.

It's simple.
Modify /etc/hosts
Modify the line for the address 127.0.0.1, as follows:
127.0.0.1 localhost.localdomain localhost <machine_name>
Remove or comment the line with 127.0.1.1:
# 127.0.1.1 <machine_name>
and you're done.

The error isn't in the jade. It's a bug used by jade to start the default parameters with a bugged java method that should be fixed.
When jade runs the java method, it will retrieve 127.0.1.1 instead the loop-back 127.0.0.1.
I'm saying it because I tested. I read the JADE src that do this and I executed the java method that I didn't remember now.
Unfortunately it's happening in a few linux machines. In windows I didn't see it happens.
What I did to solve this problem was to edit the /etc/hosts file, like this:
Original file:
127.0.0.1 localhost
127.0.1.1 machine-name
Modified file:
127.0.0.1 localhost machine-name
127.0.1.1 machine-name
What I did was to put an alias of the machine-name on the loop-back ip address. This will bypass the bug.