Not too long ago, I installed a java web application on a Red Hat server running JBOSS.
After a recent reboot, I realized that the site did not start up automatically when the machine was booted.
Is there an easy way to ensure that this happens? There are shell scripts to start and stop the application, something like :
/opt/myApp/StartMyApp.sh
/opt/MyApp/StopMyApp.sh
I have been reading about Redhat Run Levels, (etc/rc.d), but it seems too complicated for what I need to do - just run the shell script after booting.
Making it a Windows service is quite easy, but I'm unfamiliar with how to do the equivalent with Redhat.
Thanks
It's been covered at
http://www.jboss.org/community/wiki/startjbossonbootwithlinux
edit: redhat page on that: http://www.redhat.com/docs/en-US/Red_Hat_Application_Stack/2.2/html/Release_Notes/sn-usingjbossas.html
Related
As the title says - when launching Spring app (STS) with embedded Tomcat, both java.exe and javaw.exe processes are created on the same port.
That means I have troubles with busy port, even when using the Relaunch option (which typically shuts Tomcat down and then restarts it). Indeed, relaunching does stop one of the two processes but then I get an error stating that the port must be busy. Killing the remaining one does solve the issue but I life is too short to both develop in Java AND kill the process manually.
Is there a convenient way to overcome this? I see that is STS (and Eclipse too, of course) there's a way to specify project specific JRE but I'm unsure on how to proceed.
Note: I have both 32- and 64-bit java8 instances installed.
Try running it as a java application (ie, just run main).
It sounds like you are deploying it on Tomcat, while at the same time there is an embedded Tomcat being started... :)
I have a Java application which should run on a server machine in the background (the application can be started by a command without GUI). The problem is: When I log off from the server, the application gets killed. I'm looking for something similar like nohup under Linux. I found some solutions, but I'm unsure, what is the best for my situation (Windows Server 2003, Java Application run from BAT-Skript, restart after booting the machine)? What are the pros and cons of the solutions?
psexec: Do the process really need to run under the SYSTEM account?
Combination of instsrv and srvany: But srvany should should never be used in a production environment
I have started the application with the scheduled tasks with the option run as NT AUTHORITY\SYSTEM. But after log off, the application was still killed. Can I get this working?
The DOS Task Scheduler AT command
Write a windows service (on Java, C# - I don't think it does matter)
Start the app from your service
or
Run your app as a window service using 3d party utility
The only way in which you can get a process to run without a user being logged in is to have the process run as a windows service or at the very least called by a windows service.
Just to add to above answers.
Consider using http://wrapper.tanukisoftware.com.
It's rather mature and popular (in contrast to ServiceEx and RunAsService).
Yes, a Windows Service is definitely the way to go but there are a few things to watch out for when you run a Java application as a Windows Service. Most of them are covered in this tutorial showing how to setup a java application with our commercial run-anything-as-a-service application, AlwaysUp:
http://www.coretechnologies.com/products/AlwaysUp/Apps/RunJavaApplicationAsAService.html
Beware: You will almost surely need the "-Xrs" flag on Windows 2003 to prevent the closing-on-logoff behavior but things can get tricky if you are catching shutdown events. Let me know if that is an issue for your situation.
I'm looking for a tool (in linux) that can montior a tomcat/jboss process and if the process fails, I can respawn either or both without having to manually ssh into the box, do any house keeping and then start them up again. I'm not too sure if there is a good tool out there that can monitor the health of jboss/tomcat and report on it's performance. I know jvisualvm gives you various tools, but I'm looking for a disaster recovery solution that is a bit higher level than jvisualvm.
Java Service Wrapper is an application that wraps your Java process and installs it in the system using service (Windows) or daemon (Linux). It pings the VM periodically and restarts it when it does not respond. Worked for us in production with several application, including Tomcat, JBoss, Mule, etc. Actually Mule ESB is even bundled with this application in the distribution.
Also you don't have to run the application manually when the system starts.
I'm currently working on a daemon to do this and more, since JOPR nor naggios didn't do what we needed, but those are good tools you could use. I'm not sure but JOPR (or whatever is called today) can restart your servers in case something goes wrong.
A custom made solution as we're working on shouldn't take you more than a week. The main problem, is that to start either JBoss or Tomcat you have to call the startup scripts. But the startup script will restart the service if the exit code is 10, something like this:
while $? -ne 10; do
start_jboss
done
So, this daemon which is made in Java uses JMX to connect to the JBoss server and tells JBoss to go down and exit with status code 10 using a method in a MBean. I'm at home, so I'm not sure the exact name of the MBean you have to call for this but I'll provide more info tomorrow.
I am using monit to control the launch of Tomcat/JBoss.
I have a java GAE web app with datanucleus as the JPA provider. When deploying locally on my machine - the deployment hangs (takes minutes). Looking at the task manager I have a javac process running. Any idea what is going wrong?
Agreed. Its the problem with GAE as it takes a 6permutation Compilation only after which the application would be deployed and shown on the browser. I feel its the problem only with GAE and not JPA. I have developed a similar app and if you feel its because of JPA, you can check the corresponding database admin to see how many threads are being opened for the user. If you seem to find some aren't Garbage collected, check your code. Else you can use ConnectionPooling mechanism (to speedup db retrieval using ORM).....
The answer depends on several parameters
How you deploy, are you using eclipse or command line?
GAE version (and GAE/GWT eclipse plugin version)
Windows or Linux?
In any case, a Thread Dump can help seeing which non daemon threads are stuck.
For command line deployment in Windows - press CtrlBreak after it hangs to get the thread dump
In Eclipse, if there is a way to deploy in debug mode, look at the debug view stack for the same info
See this answer as well: How to Force Thread Dump in Eclipse?
This thing depend on which platform u r using
Windows
linux
mac os x
you can check what is going on by checksignal
sending a signal
Usage:
SendSignal <pid>
<pid> - send ctrl-break to process <pid> (hex ok)
You can get the source via anonymous CVS at
cvs -d :pserver:anon#www.latenighthacking.com:/code-cvsroot co 2003/SendSignal
I have recently deployed my simple application in google app engine via eclipse. It failed to deploy couple of times. after sometime, It deploy successfully. I was able to access the application. if it hangs, stop the deployment process and redeply
I'm trying to run jstack command on my java application. Application is rather big, running inside jboss AS occupying about 4gb of memory. OS is Windows Server 2003 Standard edition. Every time i get an error "Not enough storage is available to process this command". There is enough ram, 16gb, and disk space. So, any ideas?
I ran into this recently on Win2008r2 and thought I'd share my solution since it took a while to figure out. Rob's comment about psexec -s is what did it for me.
It appears that on Vista and later jstack doesn't work against services because of the user context. It has nothing to do with memory. I suspect this is the same reason people have seen this problem on 2003 via remote desktop, unless you use the /admin or /console switch on mstsc. As of Vista the tightened security is probably what broke it.
Starting my app from a cmd window worked fine, but that doesn't help me debug our standard install. Enabling the java debug port (for VisualVM, Eclipse or most any Java debugger) requires an app restart, so you lose the state you're probably trying to capture if you don't already have debugging enabled. Starting the service under my user credentials did not work - I was a little surprised at that. But psexec -s runs jstack from the system context, which worked like a charm. Oh, and you'll need to run psexec from an elevated cmd prompt, if UAC is on.
In the past I have seen this when the JVM is running as a Windows Service on Windows 2003.
First, check to see if this is an issue with the TMP directory.
Second, jstack (or the other utilities like jconsole) will not connect to the local process unless it is running in the same session. If the service is running as a specific user, you may be able to connect by logging into the same session. If you are using Remote Desktop, you can connect using "mstsc /admin" (used to be /console) and try to run jstack again. Definitely check to make sure the TMP directory is set properly if this doesn't fix the problem.
If the service is running as LocalSystem, the above procedure probably will not help much. I don't know if there is a way to log into the same session as LocalSystem.
Some other alternatives may be to set the process up for remote monitoring and use jvisualvm (from the server itself or another machine) to connect over a port and do a thread dump.
We had problems running JStack on a Windows machine with even a modest application (1GB). We ended up doing our stack and heap analysis using Netbeans. This seemed to cope with the parsing of dump files a lot better. YMMV.
Give Netbeans a try for profiling - its very good. Note that VisualVM is a cutdown NB profiler and comes with 6u7.
psexec -s jstack PID >> c:\jstack.log perfectly works on the same machine. For the first time it took some time but again I executed with the redirect to file option, it completed with in few seconds.
This is an error message from the underlying O/S. There's not much you can do in your code to deal with this other than catch the exception which is thrown. Boo to Windows for being so limited.
http://technet.microsoft.com/en-us/library/cc978735.aspx