After I deploy the web app to websphere the application run normally, one day later the application get stuck when in loading phase and take infinite time to load.
should be mentioned that the same application work just fine on testing environment and the problem occur just on production environment.
I try to change dependencies, clear cache, reinstall several time but nothing seems to work
Related
I am coding my basic servlet programs in notepad but every time I make changes in my java file and after compiling it, I need to restart my tomcat apache to see that changes on browser. Is there any solution for this as I have to work on project and will need changes frequently.
I have tried making service automatic from services manager.
The changes made in Servlet/Java code will not reflect itself, we have to re-compile the Java code and again deploy the application to the Tomcat server. Only after these work server will be able to get the modified values.
If you don't want to do it manually then you can set reloadable="true" in the context.xml file. Now Catalina (tomcat server) will monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications. That's why the default setting for this attribute is false. You can use the Manager web application, however, to trigger reloads of deployed applications on demand.
I am not sure what I am asking is correct approach or not. So, let me first clarify my requirement.
Till date I was using each app as a root app and was deploying them in separate tomcat instance, but my app number are now growing and I can not keep on deploying a separate instance of tomcat for each app.
There are two things which make me deploy every app as root:
For updating an app you have to shutdown tomcat instance which will also stops other app running in same instance. And I do not want this to happen (as some users are live on one web app or some job is running on some app, so I can not stop all apps at any given time).
For writing urls, if I deploy a web app as root, then in web-app I can simply write "/students/list" , but if I deploy them in same instance with some different context name, then I have to write context name before the urls, like "ctxt1/students/list"
And for developers sake I don't want them to write context name before every url in web-app and also I don't want context names to appear to a user.
Is there any approach with which I can solve these 2 problems. I am thinking of migrating to Glassfish for some apps. If glassfish offer solution to these problems then I can migrate all apps to glassfish as well
Secondly I am running tomcat behind IIS, using ISAPI. If IIS can be of any help here?
You should not use one tomcat per App. The amount of tomcats should increase only when needed (really needed).
It is not true that you have to kill the whole tomcat, for one App update, you should only restart the specific context (going to http://your.tomcat:8080/manager/html).
About the URLs you can use an apache in front with mod_proxy_ajp configured to talk with tomcat (see this: http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html)
I have a Java 1.6 application deployed on several machines (~ 30), and started as a Windows service.
My main problem concerns the maintenance of these deployed artifacts: if I develop a new version of this application, I don't want to manually redeploy it on every machine.
Ideally, when the Windows service is starting, it checks on a remote server if an update exists, and if it is found, then it upgrades the application.
Note that it is acceptable that after this upgrade the service requires to be restarted again.
This mechanism can be compared to the Maven snapshot verification: if there is a newer version of a SNAPSHOT version on a remote repository, then Maven download it before running it.
Note that the application itself will be deployed on a Maven repository (in our case Nexus), so the check for an update will be done against this Nexus instance.
What are my technical solutions to implement such an automatically application update?
Do not hesitate to ask me more details about technical information or about the context...
Thanks.
Edit: As stated by Peter Lawrey, I can use Java Web Start. However, how can I integrate JWS within a Java application that is run as a Windows service?
I would look at Java Web Start
A common technique for this is to use a launcher. The steps are something like this:
Start the launcher.
The launcher checks to see if the application should be updated. If yes, the launcher updates the application (I think of this as "the update step").
After the update step, the launcher runs the application.
I'm using (trying) GlassFish v2.1.1 + MySQL connector 5.0.8 to teach myself J2EE. I try to develop some simple Web application with JPA persistence. Just when the server starts, deploys go smooth and everything, but after several deploys it starts acting weird, throwing all kind of exceptions and failing predeploy.
For example, on deploy it could throw ClassNotFoundException about class which is even not there anymore (but was there several deploys ago)!
I would have gathered it was my fault (some misconfiguration maybe) if it didn't deploy smoothly again after server restart. I just get the exception, restart the server, and bam - "Command deploy executed successfully". :-\
But maybe there's some intricate dependencies left in runtime, I don't know. Simply undeploying module and deploying it again does not help.
This is subjective but to my experience, redeploys always become unstable at some point. Sometimes things don't get cleaned as they should, sometimes some parts don't release memory as they should, sometime you get an explicit PermGen error, etc and at some point, you have to restart the server (which is also why some people never use redeploy in production). I live with that.
That said, to strictly answer the title of your question, I consider GlassFish 2 and the MySQL Connector as very stable and totally production ready. But as hinted, development and production do not stress a platform the same way.
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.