I use eclipse to develop a web based java application. My normal course of business is grab the next task tracking ticket. If there is a problem that needs to correcting, I run the application locally, which loads of a Jetty webserver, and binds to port 8080. After verifying the problem, I fix the problem, rebuild, and the re-run the application. The problem is, I far too often forget to close the jetty server before re-running. This generates the Java bind error:
WARNING: failed SocketConnector#0.0.0.0:8080: java.net.BindException: Address already in use: JVM_Bind
I work in Windows, and was looking to see if there is command I could run to un-bind the port, but couldn't find an answer there. Does anyone here have a good idea of how to fix my problem, other than remember to shut down the old jetty instance before starting a new one?
Thanks,
Jay
Use netstat -ap | grep 8080 to find which process is using that port. (What, you don't have a suitable grep installed on Windows? Everyone should!)
Use -Djetty.port=<port number> to change the default port number used by Jetty.
To unbind the port cleanly, you typically need to stop the process that is holding it open (otherwise, the process would probably die with strange communication errors anyway).
You could right a short batch file to detect if the port is in use and kill the Jetty process. Assuming you have Sysinternal's pskill.exe available in your path (e.g. under C:\Windows), here's an example that will kill the process which is holding port 8080 open:
FOR /F "skip=4 tokens=2,5" %%G IN ('netstat -ano') DO (
IF "%%G"=="127.0.0.1:8080" pskill %%H
)
You sortof answered your own question there... since you can't run two applications on the same port you'll need to remember to shut down the old one before starting a new one.
You mention the application starts a Jetty instance, could that launching application check if it's already running before doing so? I guess I'm not quite on the same page as you...
However, there are some nifty ways out there to "hot deploy" your changes -- once you have the appserver running you can make changes to JSP files or Java classes and it will automatically deploy those changes.
Are you using some integration like run-jetty-run? If not, you might want to give that a try.
MyEclipse also comes to mind, though I'm not a huge fan of it, some people really like it.
But for the most part, just remember to stop and restart.
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 am currently facing an issue with my java webapp running on Jetty 7.4.5.v20110725 on Linux. My Webapp serving static content is running out of file descriptors after a few days from its start timestamp. I am starting the jetty server with useFileMappedBuffer = true( in webDefaults.xml ) . I am using jdk1.6.0_30 . Please let me know if you'll have any suggestions on how to fix this issue.
Please note that this issue does not occur when useFileMappedBuffer = false (in webDefaults.xml).
If your application has run out of timestamps next time, please try to find out which files are open and if open connections are causing a problem.
Try to list open files by calling (I think it's lsof -p, but try or look at the lsof manpage as I'm writing this out of my mind):
lsof -p <jettypid>
This will show you what files are opened by the jetty process. Look for files which probably should have been closed already, etc.
Then do a:
netstat -an
This will show you established network connections. Look if there's lots of connections in CLOSE_WAIT state or similar indicating that connections are not properly closed.
Also have a look at your system wide OS limits with:
ulimit -a
It'll show you how many file descriptors can be opened by a single process. If you've a site with high traffic and the pretty common default value of 1024 max fd, you might need to raise that. If you think that traffic is the problem have a look at this guide: http://wiki.eclipse.org/Jetty/Howto/High_Load
However you've stated that the problem does occur only after a couple of days. This usually indicates not properly closed connections, file resources, etc.
If unsure what to do with the output of the commands above, feel free to paste them.
Independent of the problem I'd recommend you to upgrade to the latest jetty 7.x.
I'm running a number of java processes on a windows XP professional machine. When i attempt to connect to these processes via a local JConsole the processes are grayed out.
However i can run the same processes on another machine and connect via a local JConsole on that machine.
Both machines are running java 1.6 version for the processes and jconsole.
Any ideas why these processes are grayed out?
I'm fighting with this issue right now and I found out a work around:
You can change the local user's temp dir to something that they can definitely access (e.g. D:\temp). Make sure to do this for the process you're trying to monitor and the jconsole process.
Another thing that can apparently cause issues are usernames with uppercase letters in them. The directory will always be created with all lowercase letters, but simply renaming it to exactly how it's being shown in the Task Manager made all the issues go away: http://planeofthought.com/wp/?p=75
if the processes are running as a different user (e.g. if you start them as services), then you won't be able to connect to them. also, if they are running under an older jvm, you most likely won't be able to talk to them either.
in some cases, the local jmx communication mechanism uses the local filesystem and may have issues if permissions are not defined correctly. are you possibly running any of these processes on networked filesystems (nfs, samba)?
Say your windows user name you use to start your java application seen in task manager is YOUR_USER_NAME.
Please check a folder whose name looks like hsperfdata_XXXXX (XXXXX should be your user name) in your temp folder and make sure YOUR_USER_NAME and XXXXX are exactly the same (be careful about the upper and lower case).
From http://download.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html:
Applications that are not attachable, with the management agent disabled. These include applications started on a J2SE 1.4.2 platform or started on a J2SE 5.0 platform without the -Dcom.sun.management.jmxremote or com.sun.management.jmxremote.port options. These applications appear grayed-out in the table and JConsole cannot connect to them. In the example connection dialog shown in Figure 3-1, the Anagrams application was started with a J2SE 5.0 platform VM without any of the management properties to enable the JMX agent, and consequently shows up in gray and cannot be selected.
(source: oracle.com)
Despite what's being written in the documentation, most likely your process is running under a different user. You can run jconsole as an administrator and try then.
Here is what worked for me. I changed my %TEMP% and %TMP% environment variables to point to a folder I created in my %HOME% location (like C:\Users\[YOUR_NAME]\Temp). Once I did this, all problems vanished.
I had the problem as described earlier, but was advised a simpler solution: just close all programs using Java ("IntelliJ IDEA", "SoapUI", etc. - to unlock the temporary folder) and then delete %TMP%\hsperfdata_<user.name> folder. Then, after opening any Java program, this folder will be recreated but this time with correct name (most likely %TMP%\hsperfdata_<User.Name>). And after that, local Java processes can be monitored through "JConsole" or "VisualVM" (now runs without starting error with a link to VisualVM: Troubleshooting Guide) again.
instead of this steps you can just goto the CMD and then type in jconsole.exe (PID)
Remember to go to the path where jconsole is present and then run the executable file.
Change the name of the hsperfdata folder which for me was found at C:\Users\pmimgg0\AppData\Local\Temp\hsperfdata_pmimgg0 to match the User name found on task manager. Once I changed hsperfdata_pmimgg0 to hsperfdata_PMIMGG0 my local process was no longer greyed out on jconsole.
Change your TEMP paths in Environment Variables to something like D:\temp as it could be a permission issue. Fixed this issue for me
The best way is to run local process like a remote process.
Add these conditions in runtime arguments -
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=6001
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=localhost
-Dcom.sun.management.jmxremote.rmi.port=6001
Then select Remote Process and point to localhost:6001 as shown
Click Connect and Jconsole is connected successfully.
For me this fixed as I had some admin constraints.
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.
this really silly question probably, as no one else seems to be having this problem. In the Jetty documentation it says jar -jar start.jar starts Jetty, and it does. But when I close my SSH console, obviously it dies.
How do I run it PROPERLY?
Is this for running on a production machine that will actually serve up an application running under Jetty? I assume this is the case, since you're asking about starting it properly.
If so, you need a proper process supervision system, such as runit, daemontools, monit, upstart, systemd, or good ol' SysV init.d (as mentioned w/ a gist). Which to use depends on your preferences, business needs, and often, your underlying operating system.
I use and prefer runit. It is built on solid principles (daemontools), and for my preferred distribution (Debian and Ubuntu) it is nicely packaged by the author himself.
Despite being recommended in other answers, and mentioned in comments, starting a long running process in screen/tmux, or via nohup is sub-optimal. You don't have any real control over the process. It won't be restarted if it dies. You have to manually find its PID and otherwise manually manage the service. You have to do more manual work to get the log output (redirection, sending to some random file, etc). You cannot reliably make it depend on other processes, or have other processes depend on it. Decent process supervision systems provide all this functionality for you by default.
If your goal is something else entirely, then please update the question to be more specific about your use case.
java -jar start.jar &
(to run in the background) should also work, though logging won't be transmuted as nice as w/nohup.
This is because killing the shell that started a process (e.g. by logging out) will kill process to unless they're background processes. Screen works since as well since it runs in the background, and screen effectively keeps your session running while you attach/detach.
One way is to use nohup
nohup java -jar start.jar
This has the advantage of writing stdout and stderr to a file
Another way would be to use screen
If you're on a *nix system, the best solution is may be using a script in /etc/init.d (or whatever your system's equivalent is). There's one at https://gist.github.com/404672.
Otherwise, using nohup or screen from the command-line will at least have the process not die when you log out. So will putting the process in the background with &.