I am running a small webservice application with Spring Boot, Maven, Spring Data, Hibernate which is usually working fine. It has just a single webservice request mapping. The application is a standalone JAR and started in a shell with "screen".
Nearly once per day it just quits itself. There is nobody that forces the app to stop or so. It just says "Killed" in the shell. There is no exception, error or any other message. I already tried to activate logging in application.properties with:
logging.level.org.springframework.web=ERROR
logging.level.org.hibernate=ERROR
but that does not help. Also added exception handling to the webservice mapping trying to catch any exception thrown. But also nothing.
Does anyone know why the app could have been stopped or how I can display the problem?
Thanks in advance!
I encountered with the same problem and I had resolved it by creating swap area. I think it is a typical memory problem. I recommend you to create swap area if you are deploying the application in a linux environment. Check memory usage before..
This happens often when system kills your Java process because it started to consume a lot of memory.
Try to inspect your deployment target limitations and adjust heap size below that limit.
Related
There is Spring Boot application that runs on the server without exposing to external world. I connected Sentry to monitor it but never got any errors, even I have tons of them in the logs.
By without exposing to external world I mean that there is no open url that everyone can use for API connection.
How should I configure Sentry in order to get errors? Should I fall down to other scenarios, not default Spring Boot app configuration?
Sentry doesn't need to connect to your application. When you add Sentry's SDK to your app and configure it with the correct DSN, your app will connect to Sentry to send errors as they occur.
For that you need to make sure the DSN you used goes to the project your expect to see the events in Sentry. That could be a reason why you don't see the events.
Perhaps your server has not access to the Internet? Or if it does, it requires use of an internal proxy server which was not configured in your server/application/sdk.
I fight with this problem for some time but it seems that either some of error messages were lost on the way or Sentry.io default configuration for Spring Boot sends messages with low threshold, so 1 error message for several actual errors.
In the end, it fixed itself.
I'm having some trouble receiving large subprotocol messages using Spring Boot, Spring WebSocket and Undertow. The messages are cut off after 16kB. After doing some digging I found the following configuration property which seems to do what I want:
server.undertow.buffer-size=32768
This configuration property seems to be properly picked up when checking the /configprops actuator endpoint. Unfortunately, this doesn't seem to help in receiving messages larger than 16kB.
I also stumbled upon this ominous line from the Undertow documentation (emphasis mine):
For servers the ideal size is generally 16k, as this is usually the maximum amount of data that can be written out via a write() operation (depending on the network setting of the operating system).
This confirms what I've been experiencing that setting the server.undertow.buffer-size has no effect as it's capped by an OS level setting. As I'm using Ubuntu Linux I have been fiddling around with net.core.rmem_* and net.core.wmem_* settings but these don't seem to have any effect either. It's not possible to reproduce this issue on macOS.
Does anyone know how to configure Undertow, Spring Boot, and/or Spring WebSocket to support these messages?
I directly answered the question above myself. The settings I proposed in Spring Boot do work! The problem we had was that the load balancer, in our case haproxy, in front of it was cutting of the messages after 16kB. Tuning haproxy to allow larger messages solved the issue. In the meanwhile, we tweaked the protocol we were using to be more efficient so we don't require these large messages anymore so our haproxy solution wasn't tested in production (YMMV).
Because the developers were all working on macOS and Windows and the issue only occurred on the acceptance and production environments which ran Ubuntu we incorrectly assumed this was the cause.
Lessons learned (these are all really dumb and basic but we made these mistakes anyway):
Be sure to validate all your assumptions! If we thought Ubuntu was the issue we should've singled out Ubuntu in tests earlier. For example, by using a VM with Ubuntu on which to validate our assumptions in quarantaine.
Make sure your development environment matches your production environment! In our development environments we weren't running haproxy. As "high level" developers we tend to put aside load balancers and web servers as commodity infrastructure but this example once again shows that these "commodities" can very directly impact the working of your application.
I have a web application deployed in Websphere. At server startup, I am trying to load some values from database through ServletContextListener. If any exception occurs at that time, I want the web application start up status as failed.
In order to achieve this, I am throwing a Runtime exception from ServletContextListener. This is working fine on Tomcat as it is not starting the webapp. But, on Websphere, the application start up status is showing as Success.
Please let me know the way to handle this for a normal webapp, which does not use EJBs.
The section Application Status list all avaiable status. You can notice there is no fail or something like that.
Websphere does not support the behavior that you expected in 8.x or older version.
There is a discussion : Stop application on servlet initialization failure.
It mention a possible solution but the customize implementation is not released yet.
After working for a good number of weeks, I cannot deploy my application with Glassfish 3 to my local machine. I get:
EJB Container initialization error
and it appears there is a null pointer:
com.sun.messaging.jms.ra.DirectConnectionFactory._createConnectionId(DirectConnectionFactory.java:424)
I occasionally change my application to point to a glassfish instance on another server and have to update the settings for the correct server, but I am sure that the current configuration is proper for my local machine.
What might be causing this sudden behaviour?
A very likely solution, though not one which is immediately obvious, is that a locking has taken place. This often happens on a machine where the IP address is prone to changing. It is one of the first checks that should be performed for an error involving DirectConnectionFactory and it is a behaviour which has carried over since Glassfish 2 (so this fix may work for that as well).
What you do to fix is:
Go to the folder where your application is deployed (for me it is
glassfish3\glassfish\domains{MY_APPLICATION})
Look for imq/instances/imqbroker/lock
Delete that file
Restart glassfish
Try to deploy your application again.
I'm in the arduous process of trying to upgrade a couple of our servers to use a current version of the application installed on it and I've gotten a bit stuck. I've gotten everything replaced and have narrowed my issue down to 1 .jar file. If I use the new version of this specific file, I can not get the service to start, and using the old version (and the new version of every other file), it runs fine.
When I try to start the service I get this message: Could not start <service> service on Local Computer. The service did not return an error. This could be an internal Windows error or an internal service error.
I've looked in the event viewer, and all it has are these entries every time I try to start it:
<Service> has started
Could not find the service start class
<service> has failed to start
Is there some place else that I can look that might be able to give a bit more information on why it's failing to start?
We are using the 'JavaService' utility to create the windows process. This server is also running jboss.
EDIT: I have also determined that it is not an issue with my SQL database as I just did all of the upgrades between the versions. I still can't get it to start with the new .jar, and the old .jar still works.
Thanks!
You can't execute a java application as a service. Windows services implement a specific interface that java.exe or javaw.com do not. You will need a wrapper to implement this functionality. One such wrapper is http://wrapper.tanukisoftware.org.
As Pierre mentioned, you can't run java directly as a Windows service. Apache commons daemon (a.k.a. Procrun) is another tool that will adapt a java application for use as a Windows service.
I found the issue!
After days and days of looking around at configuration files, I finally noticed something: We are now using log4j for logging but it wasn't included in the .jar's manifest! I added it to the manifest and it now starts up!
Thanks for your help everyone :]