I have a web-application built with GWT (2.0.3) and run on Apache Tomcat 6.
My application uses long polling to enable client-server conversations.
When a client is unable to connect to the server it displays a disconnected message on the page and grays out the controls until it is able to resume conversation with the server.
This happens through the use of the onFailure method of the rpc services; I keep track on how many consequtive exceptions I've received and if it passes a defined threshhold the above scenario happens.
This allows notifying the user of a problem while in the background continuing to resume the server conversation.
This has been the configuration for about 6 months, and without a problem.
I compiled the application after a change and wanted to see it in stand-alone mode so I started up tomcat (not via eclipse) and everything seemed to work fine.
When I ctrl+c'd the apache (while having clients up) I saw the clients displaying a 503 error instead of my app with the disconnected message.
I then tried to reproduce the issue but was unable as the next times the app behaved as expected.
I'm not sure if it's relevant but recently I added an UncaughtExceptionHandler to my module's onModuleLoad.
Has anyone encountered such an issue?
Do you know how I can make my client immune to such an issue?
Thanks a lot,
Ittai
Probably your app tried to connect to server while it was in process of shutting down. Some of the services might have already shut so the request failed with internal server error.
I've got similar issue having an apache httpd in front of the tomcat and stopping tomcat while one of the "background" async requests were being made, due to the security redirection policy the failing request ends redirecting the browser and voilà our 503 error page.
Related
I keep getting lots of these warnings in my logs:
WARN o.atmosphere.cpr.DefaultBroadcaster - Duplicate resource fda35646-a562-4366-933a-ba93a01297ea. Could be caused by a dead connection not detected by your server. Replacing the old one with the fresh one
and:
WARN c.v.server.ConnectorResourceHandler - Ignoring connector request for no-existent connector 7866 in root 1
WARN c.v.server.ConnectorResourceHandler - Ignoring connector request for no-existent connector 8582 in root 4
As well sometimes the whole website seems to just kind of lock up, where no actions are possible. I'm still trying to connect the log errors with these lockups but either way as soon as I do a refresh of the page everything is back to normal. It's intermittent but seems to happen several times a day in my testing.
I'm pretty sure it has to do with mod_jk or something related because it only happens in the environment setup with apache in front of tomcat connected with mod_jk. Just tomcat by itself has none of these log warnings.
Any assistance with this would be greatly appreciated.
This is my first time asking a question on Stack Overflow. I recently configured an Ubuntu 16.04 virtual private server to host a web application. I run ngnix on a Tomcat server that reads and writes to a MySQL database. The application runs fine except for the fact that Tomcat restarts itself once in a while which results in a 500 error that stems from a "broken-pipe" when anyone tries to login (i.e. make a connection to the database).
I will post an image of the 500 next time it happens. I went into my vps and looked at my Tomcat restart message. This is what I see: Tomcat status message.
I also did a little diving into the Tomcat logs and this is a log file that corresponds with that restart time: Tomcat log file
I did some research to try and solve this myself, but with no success. I believe that the exit=143 is the process being terminated by another program or the system itself. I also have done some moving of the mysql-connector-java.jar. I read that it should be located in the Tomcat/lib directory and not in the WEB-INF of the web application. Perhaps I need to configure other settings.
Any help or any direction would be much appreciated. I've fought this issue for a week with having learned much, but accomplished little.
Thanks
Look at the timeline. It starts at 19:49:23.766 in the Tomcat log with this message:
A valid shutdown command was received via the shutdown port. Stopping the Server instance.
Exit code 143 is a result of that shutdown and doesn't indicate anything.
The question you need answered is: Who send that shutdown command, and why?
On a side note: The earlier messages indicates that Tomcat lost connection to the database, and that you didn't configure a validation query. You should always configure that, since database connections in the connection pool will go stale, and that needs to be detected.
Theory: Do you have some monitoring service running that tests your application being up? Does that monitoring detect a timed-out database connection, classify that as a hung webapp and auto-restart Tomcat?
While I don't think I am able to see to the core of the problem you have with your overall setup given the small excerpt of your log files, one thing strikes the eye. In the Tomcat log, there is the line
A valid shutdown command was received via the shutdown port. Stopping the server instance.
This explains why the server was restarted. Someone (some external process, a malicious attacker, script, or whatever. Could be anything depending on the setup of your server) sent a shutdown command to Tomcat's shutdown port (8005 by default) which made the Tomcat shut down.
Refer to OWASP's recommendations for securing a Tomcat server instance for fixing this possible security whole.
Regarding the ostensible Hibernate problems you have, I don't get enough information from your logs to make a useful statement. But you can leave the MySQL jar in Tomcat/lib, since this is not the root cause of your problem.
I have restarted a project that i closed after it became too comfusing, the original project was a webserver run entirely from java code. I have started this back up in the hopes of making the code 100% my own using java. I have gotten to the testing stage of hosting website however whenever i try to connect from the outside world i am shutdown with an error page. I have note coded this error page and after extensive research it is viewable that the error page is originating from apache. The only problem with this is that there is no apache in the code or in the virtualbox server. I have also tested this on two different virtual servers: opensuse 13.1 and fedora 20.
The URL of the server is blends.hopto.org/beta. There should be a black background there with some arrows and a blue dot, but instead there is an error that states:
"Not Found
The requested URL /beta was not found on this server.
Additionally, a 404 Not Found error was encounted while trying to use an ErrorDocument to handle the request."
I do not get this error if i request the page from inside my local network. But i do from outside, it is not a port forwarding problem because my minecraft server works and the server is assigned to the public ip of my home router!
Thanks, any help is appreciated!
Extra info:
After positing this question i stumbled across some other problems and it seems that the error is originating from SELinux, however i have disabled SELinux and the error is still coming through!
This is not an answer. I cannot comment on StackOverflow yet but would like to help.
You said that you get an Apache error page, which means that Apache must be running on your system. You can check this by typing this in the terminal:
apachectl status
You don’t mention what port you want to serve on. Apache usually uses port 80. You could configure your homemade Java server to work on a different port, say 8080. Also, if you are using Fedora 20, then you will have to configure FirewallD to allow this.
Okay well i finally found out what the problem was after just looking over the assigned ips to devices and found it strange that our networked hard drive was assigned the very first ip always. So i logged into the hard drive and found out it had been capturing all the port 80 requests from the router in an attempt to do remote login!!! I am very excited that this problem is resolved! I will be hoping to release my WebServer API for everyone to use as it is incredibly small and gives the programmer full controll
I have a setup in which some applications communicate with each other via Tibco rendezvous. The applications communicate using certified messaging. My problem is that two of my receivers have recently started exhibiting the behavior that they will get an Error 27, Not Permitted when they want to confirm a message (the first message in a certified message exchange isn't certified, we've accounted for that).
I've been looking around the internet to find people with the same error, and I have found many, but they all get the error when trying to create the tibco transport. I can create the transport just fine, but I can't confirm any messages received over it.
Our environment uses both tibco 7.X and 8.X, some times intermingled. This problem appears both when the peers use the same tibco version and when they use different versions. It doesn't show up for all applications, but when it does show up for an application, it remains "broken". Discarding the ledger files for both sender and receiver does nothing. We still get the error. Both sender and receiver have proper permissions to write to (and create the) ledger files. We are connecting to permanently running rvds. The sender and receiver are on different machines. Communication has worked flawlessly in the past, but at some point, it stopped doing so. The application is in java, and we're using the tibrvj.jar auto-native libraries.
The error is
...
Caused by: TibrvException[error=27,message=Not permitted]
at com.tibco.tibrv.TibrvImplCmTPortC.natConfirmMsg(Native Method)
at com.tibco.tibrv.TibrvImplCmTPortC.confirmMsg(TibrvImplCmTPortC.java:304)
at com.tibco.tibrv.TibrvCmListener.confirmMsg(TibrvCmListener.java:88)
....
I know you're going to ask me "what did you do to make it start happening", and my response is "I don't know".
Any input would be appreciated.
Thanks.
It may be possible that TCP connections between the two RVD servers is not possible. Can you check if you can connect from one to the other (connect from the subscriber host back to the publisher)? In my experience, CM acknowledgments are handled over TCP (please take this with a grain of salt as I'm more an end user than a Middleware support guy).
As it turns out, it was a screw-up on the application level.
Due to some old code lying around, after having updated a dependency (our messaging layer), we had moved from an application level confirmation to a container level confirmation, but we had forgotten to remove an explicit message confirmation in the application code.
To summarize: We tried to confirm the message twice, and the second time it threw this exception.
I recently encountered the same exception - application had been working for months, suddenly was throwing exception. In my case some maintenance had been done on the Windows server the application ran on and directories had been marked read-only. Once that was cleared the exception went away.
Discovered this after trouble-shooting hours worth of other potential causes.
Just my two cents: This exception also occurs when you try to explicitly confirm message on non-CM transport.
I have a problem with my Apache Axis 1.4 service, using the SOAPMonitor which comes with the binaries.
While the applet starts up with no problems (e.g. http://localhost:8080/axis/SOAPMonitor), the status bar in the embedded application gives the following error message:
"The SOAP Monitor is unable to communicate with the server"
Some further reading that I have already tried:
http://ws.apache.org/axis/java/install.html (See appendix)
http://ws.apache.org/axis/java/user-guide.html#AppendixUsingTheSOAPMonitor
http://www.javabeat.net/articles/25-programming-web-services-using-apache-axis-2.html
http://www-scf.usc.edu/~csci571/2005Spring/axisinstall.html (see "Enabling SOAPMonitor in Axis")
After ensuring that the SOAPMonitor is actually enabled in the web.xml configuration file, I noticed that it used a port of 5001. I used 'netstat.exe' and noted that nothing was already listening on this port but... Changed it anyway to another unused port, 8081.
After restarting my app server once more this seemed to work.
Note that the TCPMonitor application which also comes with Axis has similar functionality and was easier to set up!