I have a case where a java application that is to be managed can be running within tcserver or Apache Tomcat or as a standalone java process. I know tcserver and tomcat expose mbeans/url endpoints to start/stop but they are different and I am trying to find a generic common way covering all 3 cases to stop an application. A stand alone process can exit itself easily but for a container managed application, what would be the best way?
Same way as a standalone app - just System.exit(0).
Or, if this is on Unix, kill <pid>
Related
I´m trying to get more familiar with Docker because everyone talks about it and everyone loves it. I know how Docker works in general, but I don´t understand how to used it in practice.
In my case, I have several web applications running on Tomcat. As far as I understand, it´s common to have one Docker container per application. But what does that mean in my case?
Should I have several containers each running Tomcat which in turn runs one web application? Or would I have only one container with Tomcat where all web applications are deployed on?
Understand why you will dockerise all your applications which are running in single tomcat instances ?
Lets say if your tomcat goes down then all your application will go down. So
Docker with microservices is the trend which tells a docker container should not have mutiple applications running i.e single resposibilty model.Avoid one container being responsible for multiple aspects of your overall application.
What will happen if you put all your applications in single docker ?
Availability : if container goes down all application will go down. Example : If you have ecommerce application and if offers service goes down then you should be able to do other stuff other that checking offers.
Deployment : If you need to deploy an application then all application will go down. for example : if you want to deploy offers update would it be correct to stop all running users which may be doing payments or other stuff?
Application Load and scaling :Lets say you have the modules, Payment, offers and shipping. I would expect the offer module will have more load than all others. So we can horizotal scale the offers service. But if we would have all application in single container then all application will be scaled which waste of resources.
Refer a nicely written nginx tech blog : https://www.nginx.com/blog/introduction-to-microservices/
Let me know if you have any questions more to ask. feel free to add comment.
Generally, it is better to run a Tomcat Docker Container for each .war app with filebeat or any other log shipping program in conjunction with single or fewer frontend containers. So 2 Frontend Web Containers for High Availability with 4 Tomcat Containers each serving a Tomcat app.
I'm complete able to configure spring boot in both cases, the question here is which of them are more robust and is the more recommended, because I didn't find in the spring boot documentation the recommended way to deploy it in a production environment, my concerns about use the embedded container are:
If I want to set it as a Windows or Linux service, is the jar file the best option?
If I use the jar file I'm not going to have access to restart the server.
Maybe in the future I need more applications in the same container.
If I restart the machine I have to execute again the java -jar.
The question in general is which is better use the jar file and execute it as java -jar jarname.jar in production or change the packaging to war set the tomcat as provided and set the generated war in an empty tomcat.
I hope you can help me.
---EDIT---
Many times the answer is depends, this is for a normal web application or REST web service.
jar packaging is perfectly suitable for production and you should rather fallback to war only if you really have to - which is often the case when you cannot control your deployment environment (which is often the case in large enterprises).
There is a chapter in Spring Boot Reference about setting up Spring Boot based application as a Unix/Linux/Windows service: Installing Spring Boot applications.
Regarding your concern:
Maybe in the future I need more applications in the same container.
With embedded containers if you need more applications running on the same machine, you should start two applications separately, each running on different port and effectively you will end up with two containers running - which is good, applications are better isolated from each other.
About a month ago I had the question like yours.
Let me share my conclusion:
1) JAR:
You can run independently every appliction with different ports (in linux, java -jar ... > app_logs.log &) and you can route it (e.g. nginx). Note that, restarting is not problem. You can write custom bash script (like this: ps aux | grep appname and kill by PID)
But there are some problems with configuring production app. Property files will archived into jar.
2) WAR
You can deploy into container and just run it. Easy managing at the server. If you want to re-configure app, open properties file from unarchived folder inside container, change it as need and restart container. So, managing and configuring will be easy.
But, if you want to run another app in this server with another port, then you must install another copy of container and config it.
So, in my practice, using war app easier than jar to manage and re-configure.
I don't know that much about Windows services but on Linux you can add the execution of a jar to a RC-Scripts (and thus make the application start at a certain run-level). For a spring boot app you just have to symlink to the jar and you can start/stop/etc like any other service, see: Spring Boot application as a Service
restart the machine or the JVM? A shutdown mechanism is built into spring boot, you just have to activate it (and you should enable security machanism so that not anybody can do that), see: How to shutdown a Spring Boot Application in a correct way?
Spring-Boot enables microservices - so the idea is to have one embedded webapp-container for each webapp/microservice. This reduces the risk of losing all services when only one is going down.
Yes. and you have to execute catalina.sh|bat start after every restart. Or you add an appropriate startup script (see 1.)
I sense that you'd rather do it the old-fashioned way. Despite the 'matter of taste' answer, there is one argument pro-jar: the only dependency is the JVM! The rest (the web-app-container, db-drivers, other libraries) is all part of the package you deliver. And if you decide to change the container for the next release, so will it be.
One more reason to use "war" file in production.
Springboot masked an error Jetty threw whereas WAR deployed in Jetty correctly caught it ( though issue below is still under review )
https://github.com/spring-projects/spring-boot/issues/8917#issuecomment-294673487
I don't know much about server kind of things, But my recommendation is
If you are using Monolithic application, better to use war with
external tomcat.
If you are using for Micro Service applications, use embedded
tomcat with different port. And each micro service applications are
independent from each other.
I'm new to Java and Java web applications. I'm trying to understand why I should use a Java application server like Tomcat instead of running it from command line.
Should I running Jenkins without a servlet container in production i.e using java -jar jenkins.war?
Is Tomcat more suitable for production environments?
Are there other advantages?
Please give me some idea why running the application in a servlet container is important.
Actually when you run Jenkins as "java -jar jenkins.war" it starts embedded servlet container anyway (Winstone or Jetty). Since main load on build server comes not from web users, but (surprise-surprise) from build jobs, I don't think servlet container type can affect performance. Moreover build jobs are started in separate JVM or even on slave machines.
Also all server/job/plugins configuration is stored in Jenkins home / config folder, so the way you started Jenkins does not affect server maintenance / backup tasks. Native installers also create user and start Jenkins as a service.
"Jenkins: The Definitive Guide" - "Running Jenkins as a stand-alone application may not be to everyone’s taste. For a production server, you might want to take advantage of the more sophisticated monitoring and administration features of a full blown Java application server such as JBoss, GlassFish, or WebSphere Application Server. And system administrators may be wary of the relatively little-known Winstone server, or may simply prefer Jenkins to fit into a known pattern of Java web application development. If this is the case, you may prefer to, or be obliged to, deploy Jenkins as a standard Java web application."
i have a core java application and a struts2 (jsp) application which use tomcat server running on local host. i need to call or restart my struts application from my core java application if it meets certain conditions. Seeks your good suggestion or snippets to do so.
I have a standalone java application which uses java based TCP NIO to collect some information from various clients (not on web/HTTP but through some indigenously developed middleware). Now I have to develop a front-end for the users to perform a lot of querying through HTTP. So is there a way to put this application inside tomcat, so that servlets can invoke required functions on this application ???
The thing is it has to listen on that middleware outside tomcat too and at the same time service servlets inside tomcat. How to do this ??
Putting this application outside tomcat and using RMI is an option but I don’t want to do that.
Can embedding tomcat inside my application is an option ???
The brand-new Tomcat 7 has Embedded version for download.
Tomcat is big. You should try to embed Jetty, which is meant in order to make it possible.
http://jetty.codehaus.org/jetty/
I don't know about embedding Tomcat, but you can embed a servlet container inside your application using embedded Jetty. If what you want is to add an HTTP interface to an existing server, I think that's the way to go.
It also should be perfectly workable to launch your server's TCP listening components from a standard servlet in Tomcat. Then the servlet can call methods in your existing application directly, while it continues to listen to its usual TCP ports.
A third option is to write a servlet that just talks to your existing server in the same way other clients do.
The way you want to go, is to have an embedded web server to your existing application since you just need a little bit of web functionality.
Going the other way is possible. You can use servlet listeners to get started and stopped, and you need to take great care of any thread you start since Tomcat have no idea they exist.
As Traroth said, embedding Jetty is a much better option than doing the same with Tomcat. You have an example and a small tutorial in the Jetty website:
http://docs.codehaus.org/display/JETTY/Embedding+Jetty
You can always open the ports and listen manually if the requests aren't complicated.
Have you considered going the other way? That is embedding your application inside a web application?
Using spring you can instantiate your web application and then inject in into the appropriate web classes (e.g. struts2 actions).
This way you can deploy your web application into any web server that is preconfigured separate from your application.
If you do have to use Tomcat, you're best just making your application as a .war file which when Tomcat is ran will deploy your code. This can then talk to any RMI/middleware you like.
I'm not sure I understand your comment regarding memory spaces.
At a very basic level you have two choices:
Run your appication and the web
application in the same virtual
machine.
Run your application and
the web application in a different
virtual machine
If you take approach 1, you will be able to get instances of your applications classes from the servlets and call methods on them.
Embed tomcat / jetty inside your application. You will start your application normally through its main method. After starting your app you will need to create instances of the tomcat / jetty classes which will start up their own threads.
Embed your application inside a war file to be deployed on tomcat / jetty. Similar to the previous option instead you will need to start your application from a context listener.
If you prefer approach 2; start tomcat / jetty and deploy your web app and separately deploy your application. You'll now have two jvms running. To communicate between these two processes you'll have to use some form of socket communication: OutputStream/InputStream over sockets; RMI; JMX; JMS etc.