We have a variety of batch jobs that are currently set up with spring, quart, hibernate and talk to the webspere connection pooler. We deploy them to the EAR that is most closely related to them in subject matter.
But we are starting to think it might be a bad idea to link the batch jobs so closely with the GUI and web services. And it seems like a waste to have them in websphere merely to take advantage of the j2ee container.
Is there a way to run these jobs from outside the app server but still have all the comfort of the j2ee connection pooler? Or is there some other better way to organize? What is "best practice" for organizing your batch jobs in java?
Related
I have a java web application which uses some form of custom message queuing via a database table (EmailQueue) to queue delivery of emails. The application is deployed on Tomcat and uses Quartz jobs which polls for new entries in the EmailQueue table to send.
I now need to add queuing of a few other types of jobs and messages (notifications, sms, etc.) and am therefore looking into using a proper message queue (RabbitMQ, ActiveMQ, etc.) instead of the database. This is motivated by a few articles on the matter which argue a database should not be used as a queue.
I haven't completely gotten my mind wrapped around the whole ecosystem however and would appreciate some guidance. Specifically:
In the context of web applications, does the message queue broker usually run as its own process, like the database does? I need the messages to be persistent in case of server restarts.
Should the message queue consumers be deployed as servlets in Tomcat or as standalone java applications? I'm especially interested in the manageability of it all (i.e. start/stop instances, configuration, monitoring) Related question and email thread.
1. In the context of web applications, does the message queue broker usually run as its own process, like the database does? I need the messages to be persistent in case of server restarts.
The message queue broker typically runs as its own process. With RabbitMQ, your producers can define the messages to be persistent.
2. Should the message queue consumers be deployed as servlets in Tomcat or as standalone java applications? I'm especially interested in the manageability of it all (i.e. start/stop instances, configuration, monitoring) Related question and email thread.
Regarding my question on a similar topic here, I ultimately deployed my consumers as Tomcat applications, which did provide me with the manageability that I too was looking for. This allowed me to write servlets for monitoring and managing the queues.
This solution works for scalability, also, which is important with messaging & queuing. I was also able to easily scale the number of consumers on the fly by taking a snapshot of the server running Tomcat (I was using Amazon EC2 instances) and deploying that snapshot onto a new instance. I had configured Tomcat to start automatically as a service so that when the new instance started, the consumer .war files would deploy and automatically start consuming.
Be careful with the threading, however, as discussed in my question. I had initially run into problems with stopping Tomcat.
You can also achieve manageability with consumers as standalone Java applications using JMX, however. Using JConsole, you can remote into your Java applications and query/update parameters during runtime. Many monitoring programs, such as Zabbix, can connect to applications using JMX.
If you enjoy web development and building your own web applications, I would go the Tomcat route. Hope that helps.
A good choice! Message oriented middleware is already written and will save you some trouble - instead of reinventing the wheel.
In full profile Java EE servers, the messaging system is usually an integrated part.
For tomcat, look at TomEE+ or similar for an idea of how ActiveMQ and Tomcat is working together.
ActiveMQ can easily be deployed either as an embedded broker inside your servlet or as a standalone process. It's just a matter of manageability and what you prefer. I would consider a standalone ActiveMQ, since you might want to add more Tomcat servers in some scenario, and point both to the same ActiveMQ server. RabbitMQ is not running on Java, but an Erlang platform - so that is something different.
That is up to your architecture and what you feel is more comfortable to manage. Deployed as servlets seems like a reasonable approach as you might have monitoring and other things in place already.
You could as well run the mailing service inside ActiveMQ itself. You can easily embed spring beans in the ActiveMQ configuration - or, preferably, run Camel Routes with mail functionality that does these kind of things with simple XML configuration. If you have a lot of logic in the mailing consumer, it should probably be kept as a part of the servlet application.
Hey guys I am trying to display a maintenance message on my web page while I wanna deploy an updated war, so the original war must go offline first and at the same time, client will get 404 not found error page...My question is, what is the most common way for website maintenance? Thanks!
PS: I am not specifying which server is being used, so it could be tomcat, jboss, websphere and etc.
Ideally, you'll want some kind of hot-deployment support so that your users won't ever notice a service interruption. Common methods of achieving this are:
Having multiple instances of the web application behind some kind of load balancer which directs incoming requests to a running instance. If you'd perform a deployment, you wouldn't take all instances offline at once, but sequentially take one instance offline, redeploy, restart, and repeat this sequentially for all other instances.
Code-based hot-swapping while the software is running. The Oracle's JVM has limited support for this (HowSwap). A popular commercial tool which enables redeployments (using more sophisticated mechanisms than HotSwap) of Java web apps is LiveRebel.
We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)
First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.
we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.
I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.
I do understand that using the same tomcat instance for a number of web applications has some risks (e.g. if one web application crashes tomcat it will terminate the other web applications as well.). The benefit is of course cost effectiveness since one server is enough and having all the web applications in one place makes it very easy to administrate.
Are there any industry guidelines on how a good setup with multiple web applications on tomcat should look like?
Pros
One JVM to monitor
Common libraries can be shared (sometimes risky)
Cons
Common HTTP thread pool all applications are using (you can, however, configure several connectors with different thread pools)
One malfunctioning application can take down the whole server
Restarting one application requires restarting all of them (if not using hot-deployment)
You are right that hosting of multiple we applications on one application server / web container (either Tomcat or other) has benefits.
You mentioned the robustness issue when one application may cause failure of another. But let's simplify this: even if you have only one application you still want 24*7 availability. To achieve this goal people typically run more than one instance of application server with identical application on each one and load balancer in the enterence to the site. The same is relevant for several web applications. Just run N (2 as minimum) application servers with identical set of web applications deployed and load balancer. You will probably need a kind of watchdog that restarts server if it failed or if it stopped responding etc.
In some cases kind of clustering is required. But it is other story.
So we have a busy legacy web service that needs to be replaced by a new one. The legacy web service was deployed using a WAR file on an apache tomcat server. That is it was copied over into the web apps folder under tomcat and all went well. I have been delegated with the task to replace it and would like to do it ensuring
I have a back up of the old service
the service gets replaced by another WAR file with no down time
Again I know I am being overly cautious however it is production level and I would like everything to go smooth. Step by step instructions would help.
Make a test server
Read tutorials and play around with the test server until it goes smoothly
Replicate what you did on the test server on the prod server.
If this really is a "busy prod server" with "no down time", then you will have some kind of test server that you can get the configuration right on.
... with no down time
If you literally mean zero downtime, then you will need to replicate your webserver and implement some kind of front-end that can transparently switch request streams to different servers. You will also need to deal with session migration.
If you mean with minimal downtime, then most web containers support hot redeployment of webapps. However, this typically entails an automatic shutdown and restart of the webapp, which may take seconds or minutes, depending on the webapp. Furthermore there is a risk of significant memory leakage; e.g. of permgen space.
The fallback is a complete shutdown / restart of the web container.
And it goes without saying that you need:
A test server that replicates your production environment.
A rigorous procedure for checking that deployments to your test environment result in a fully functioning system.
A preplanned, tested and hopefully bomb-proof procedure for rolling back your production system in the event of a failed deployment.
All of this (especially rollback) gets a lot more complicated when you system includes other stuff apart from the webapp; e.g. databases.