maven jetty does not shutdown properly in eclipse - java

I am currently running jetty from eclipse as an external java program. The problem is when I terminate jetty and I try to relaunch it again, it cannot due to the port still being in use.
What I have to do is open up Windows Task Manager and kill the java process manually. How do you get jetty to shutdown/terminate/end nicely?
The following are my maven jetty application settings
Arguments: jetty:run-war
MAVEN_OPTS: -Xdebug -Xnoagent
-Djava.compiler=NONE -Xrunjdwp:transport=dt_socket, address=8080,server=y, suspend=y
Setting suspend=n doesn't seem to solve the problem either.

If a java application does not shutdown it is because of an alive non-daemon thread. Try getting a thread dump of the running maven process, e.g. using VisualVM and see what keeps the application alive.

You could run the application via the 'Run Jetty Run' Eclipse plugin, rather than the Maven jetty plugin. Eclipse has more direct control over the new JVM then.

I'm not familiar with the maven plug-in, but when starting jetty with start.jar, you can use stop.jar to have it shutdown gracefully (since version 4.something).
Stopping Jetty
Programs started with the start.jar mechanism may be stopped with the
stop.jar:
java -jar stop.jar
This connects via a local port to stop the server. The default port can be set
with the STOP.PORT system property
Source
Alternatively, and maybe more to your liking, you can do it within eclipse by writing a class like this, and running the main method:
package mypackage;
import java.io.OutputStream;
import java.net.InetAddress;
import java.net.Socket;
public class Stop {
public static final int PORT = 8079; //Change to whatever your port is, 8079 is default
public static void main(String[] args) throws Exception {
Socket s = new Socket(InetAddress.getByName("127.0.0.1"), PORT);
OutputStream out = s.getOutputStream();
System.out.println("*** sending jetty stop request");
out.write(("\r\n").getBytes());
out.flush();
s.close();
}
}
Source

It seems that I forgot to tick "Allow termination of remote VM". Strange that it didn't seem to work before.

Related

JxBrowser with Java Swing (IntelliJ plugin) - "Received signal 10 BUS_ADRERR"

I'm writing an IntelliJ plugin, and attempting to integrate JxBrowser into the plugin's tool window via Java Swing.
I'm using the toolWindow extension to keep the tool window integration simple.
plugin.xml
<extensions defaultExtensionNs="com.intellij">
<toolWindow id="pluginid" anchor="right" factoryClass="com.solutionloft.codeclippy.MainWindowFactory" />
</extensions>
And so my main factory class looks like this:
public class MainWindowFactory implements ToolWindowFactory {
#Override
public void createToolWindowContent(#NotNull Project project, #NotNull ToolWindow toolWindow) {
Browser browser = new Browser();
BrowserView view = new BrowserView(browser);
Content content = toolWindow.getContentManager().getFactory().createContent(view, "", false);
toolWindow.getContentManager().addContent(content);
browser.loadHTML("<html><body><h1>Hello World!</h1></body></html>");
}
}
This appears to work when I run the plugin locally initially (the tool window comes up, and I can see Hello World), but if I terminate the process and then try to run it again, I run into this error:
Received signal 10 BUS_ADRERR 000103bc3000
[0x00017cd9540c]
[0x00017cd95301]
[0x7fff572eef5a]
[0x7fbe7e9f5000]
[end of stack trace]
Process finished with exit code 138 (interrupted by signal 10: SIGBUS)
Am I missing some kind of cleanup step? I'm not sure what could still be running - the only workaround I've found at this point is to do a full computer restart, so I guess some process must be still running that's causing it to conflict. What's the proper way to clean up? Does it have anything to do with browser.dispose()? I haven't had much luck finding documentation on when .dispose() would be appropriate / if it's needed.
I'm using:
* macOS High Sierra
* Java 1.8.0_151 as my JDK
* PyCharm Ultimate as my JRE
Thanks!
Update: Noticed if I kill this process /System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd, the problem goes away for the next few runs. But sometimes this process doesn't exist and killing a still-running java process is the fix... odd.
According to TeamDev support, the solution is to set the system property jxbrowser.ipc.external=true. Calling System.setProperty("jxbrowser.ipc.external", "true") before you create your browser instance should do the trick. The catch is that the JxBrowser will run in lightweight mode.
You may also ensure that you're properly disposing all browser instances via browser.dispose() and the Chromium engine via BrowserCore.shutdown().
According to the article, all browser instances should disposed when you don't need them. Please try disposing all browser instances before closing your application.

Selenium Tests hang when attempting to be run with Bamboo

I'm attempting to use Bamboo's build and deployment capabilities to run Selenium Automated tests with my project.
We're currently using a Maven task to build and run regular JUNIT tests, and the plan is to use another Maven task to run the Selenium tests after the code has been successfully deployed to the server. At the moment, everything seems to run just fine locally, but when bamboo attempts to run the Selenium tests it seems to hang indefinitely. Unfortunately I don't have remote access to the server to watch it first hand, but I do know that it's a Microsoft server running with OS version: Windows 2012 R2 64-bit. I also know that the server is using java version "1.8.0_101", which is the same as my local setup. I've included a sample of the code I'm running below.
import java.util.concurrent.TimeUnit;
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.ie.InternetExplorerDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
public class SeleniumTestExample {
WebDriver driver;
#Before
public void setup(){
System.setProperty("webdriver.ie.driver", "src/test/resources/IEDriverServer32bit.exe");
DesiredCapabilities ieCapabilities = DesiredCapabilities.internetExplorer();
ieCapabilities.setCapability(InternetExplorerDriver.INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS, true);
driver = new InternetExplorerDriver(null, ieCapabilities);
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
driver.get("https://google.com");
}
#Test
public void printPageTitle(){
System.out.println("Title of Page is: " + driver.getTitle());
driver.quit();
}
}
When run through Bamboo, the only output in the logs are the lines...
Started InternetExplorerDriver server (32-bit)
2.53.1.0
Listening on port 8080
Only local connections are allowed
CI or Bamboo server should be used for controlling your tests. You should not try to run your tests on a CI server. The issue you are having is probably because of that. Your are trying to use CI server as you local machine, which it will not respond the same way as your local. Instead you should use selenium grid in your setup to remotely connect to a machine by making use of hub and node. You may also have to use remote webdriver. Also have a look at this post
I've seen this using TeamCity, in this case the IE tells you that its executable will only accept connections from the local machine. According to Selenium org
The HTTP server started by the IEDriverServer.exe sets an access control list to only accept connections from the local machine, and disallows incoming connections from remote machines. At present, this cannot be changed without modifying the source code to the IEDriverServer.exe. To run the Internet Explorer driver on a remote machine, use the Java standalone remote server in connection with your language binding's equivalent of RemoteWebDriver.
So first run a chromedriver via passing through a param like so :
chromedriver --whitelisted-ips=""
This will basically whitelist all IP's, not always an ideal solution of course. But will show you that your tests can run on this CI configuration. Next thing to look for is your users privileges. Ask your admin to grant you more permissions in order to do your job. Keep in mind that IE's Protected mode may require some additional changes from your user. If none of this helps, consider Selenium grid with IE nodes.
Try to get rid of the line in the code:
System.setProperty("webdriver.ie.driver", "src/test/resources/IEDriverServer32bit.exe");
First of all, it tells where selenium should look for the webdriver for IE. Since the Bamboo server is a windows machine, you have to set it up with the absolute path of the file, like "C:\test\webdriver\IEDriverServer32bit.exe".
Secondly, the property could be set using environment variables of the Bamboo task.
Thirdly, if you want to define it on the fly, you can define the property in pom.xml as:
<webdriver.ie.driver.path>
C:\test\webdriver\IEDriverServer32bit.exe
</webdriver.ie.driver.path>
and use it in a system property with help of maven-surefire-plugin.
then you can run test with the command
mvn test -Dwebdriver.ie.driver.path=C:\test\webdriver\IEDriverServer32bit.exe
with whatever path you want.

Shutting down remotely debugged tomcat started from eclipse

When I start my Tomcat 7 from Eclipse, I usually add something like
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8101
to its launch configuration, since I sometimes want to attach the Eclipse debugger remotely later. But when I do this and try to shut down the Tomcat from Cclipses "servers" view, I receive the error
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized
I assume this is because Eclipse starts a new process that normally tells the running Tomcat to shut down, and also uses the debugging arguments I introduced in to the launch configuration. This process fails, since the named port 8101 is already used. Does anybody have an idea to allow a clean Tomcat shutdown in that setting?
(I do not want to start the Tomcat in Debug mode in the first place since that slows down both eclipse and the Tomcat. Neither do I want to restart it in debug mode when I want to debug, since that takes quite some time.)
In Tomcat's server.xml
<Server port="8005" shutdown="SHUTDOWN">
The setting can be used to shutdown Tomcat. You can write a simple program and run it.
import java.net.*;
public class t {
public static void main(String[] args) throws Exception {
Socket s = new Socket("127.0.0.1",8005);
s.getOutputStream().write("SHUTDOWN".getBytes());
s.close();
}
}

Browser can't connect to Jetty server

I saw another question like this on StackOverflow, but the answers he got were pretty, rediculous. "Connect to the localhost." -- Like, okay.
Anyway, the problem is I finally got my embedded Jetty server to compile and run, the problem was since I'm using it in an API i needed the sources, instead of just the dependency.
I'm running the most basic hello-world code right now, and the server is starting, but none of my browsers can form a connection.
Here's the code:
try {
httpServer = new Server(8080);
httpServer.setHandler(new JettyPage());
httpServer.start();
} catch(Exception e) {
e.printStackTrace();
}
Naturally, here's JettyPage.java:
public class JettyPage extends AbstractHandler {
#Override
public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException {
response.setContentType("text/html;charset=utf-8");
response.setStatus(HttpServletResponse.SC_OK);
baseRequest.setHandled(true);
response.getWriter().println("<h1>Hello world.</h1>");
}
}
The output in the console:
2014-11-07 07:01:05.155:INFO::main: Logging initialized #599ms
2014-11-07 07:01:05.190:INFO:oejs.Server:main: jetty-9.3.0.M1
2014-11-07 07:01:05.215:INFO:oejs.ServerConnector:main: Started ServerConnector#6e5e91e4{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2014-11-07 07:01:05.215:INFO:oejs.Server:main: Started #660ms
Firefox:
The connection was reset
Opera:
No data received
Chrome:
No data received
--- Yes, I am connecting to localhost:8080
I've also tried: 0.0.0.0:8080 and 127.0.0.1:8080
Note: If I disable my apache server that's running on port 80, and bind Jetty to port 80, I still can't connect.
I had exactly the same problem...very simple code, couldn't get browser to connect to Jetty even though it compiled and ran from both command-line and IDE. Finally traced it down to mismatched servlet and Jetty jars (at least I think that caused the problem). The ones that worked for me were javax-servlet-api-3.1.0.jar and jetty-all-9.2.8.v20150217.jar. Once I started using those I could connect if the code was compiled at command-line or from NetBeans IDE.
For raw noobs like me, most of the online examples for command-line compile use Linux/Unix path separators (":"). It took me several minutes to figure out on a Windows machine I needed a different one (";"):
javac -cp .;javax.servlet-api-3.1.0.jar;jetty-all-9.2.8.v20150217.jar HelloWorld.java
Hope that helps.
If you followed the HelloWorld example exactly, you would have a response.
There is still something wrong with your runtime environment.
Is this windows you are running on? If so, try setting the port to something other than 8080 (try 38080), as you might have something already on that port, and Windows will not throw an error or warning in this situation. (on other OS's this would result in a bind exception)
Do you have any logging output that indicates an error or warning?
There should be plenty of logging output to the console, even when there is an error in starting up the server, or serving some content.
If you want to enable VERY verbose logging, you can add -Dorg.eclipse.jetty.LEVEL=DEBUG to your java execution.
Windows Version
> java -Dorg.eclipse.jetty.LEVEL=DEBUG -cp .;servlet-api.jar;jetty-all.jar HelloWorld
Linux / OSX / Unix Version
$ java -Dorg.eclipse.jetty.LEVEL=DEBUG -cp .:servlet-api.jar:jetty-all.jar HelloWorld

Debugging JNLP started application

I created a Java desktop-application (using Swing) and am now trying to make it work by starting it from the net using JNLP. The application works fine when I start it from the terminal, but as soon as I launch it from JNLP, it does not close. I have to manually kill the process every time.
I read that there might be a problem if my JFrame uses DISPOSE_ON_CLOSE as the default close-operation, but it doesn't. It uses DO_NOTHING_ON_CLOSE (implicitly). Also, I'm explicitly calling System.exit(0) after releasing all my objects:
f = new JFrame("Pacman");
f.addWindowListener(new WindowAdapter() {
#Override
public void windowClosing(WindowEvent e) {
// Terminate the Game-loop:
GameLoop.INSTANCE.stopLoop();
// Close the application:
System.exit(0);
}
});
I guess that there might be an exception thrown when I close the application, but I can't find a way to get the console-output (e.g. the Stack-Trace) of a running application started with JNLP. Here's what I tried:
Start javaws with the debugging parameters and connect with jconsole (works but I can't find any exception- or console-ouput).
Start javaws with the debugging parameters and attach IntelliJ debugger to it (also works but does not give me any output)
So, how can I start the application with JNLP and get the output (written to the default out- and error-streams), as if I would do with a normal desktop application?
Solution #1 - Enable Java Console, and look for exceptions.
You can do it via Java Control Panel. Switch to Advanced tab, and in the Java Console make sure Show console is selected.
Then, run your application and monitor the console for exceptions. Fix the exception.
Solution #2 - Debug your running application (properly).
Start the Web Start app like this (for Java 1.6 and newer):
javaws -verbose -J-Xdebug -J-Xnoagent -J-Xrunjdwp:transport=dt_socket,server=n,suspend=y,address=8123 http://myserver.com/path/to/myapp.jnlp
If using earlier java versions (1.4.2, 1.5) set the environment variable, like this:
set JAVAWS_VM_ARGS="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=n,suspend=y,address=8123"
and run the app via:
javaws http://myserver.com/path/to/myapp.jnlp
When the app runs:
Attach a debugger (Eclipse will do - use Run => Debug Configurations => Remote Java Application, and in Connection Properties panel enter the port passed in the parameters to javaws (in this case: 8123).
Set a breakpoint inside your windowClosing method.
Try to close your application - Eclipse should break the execution on your breakpoint
Step into the GameLoop.INSTANCE.stopLoop() method to see where/when it hangs.
Don't expect to see a solutions in the console, just step through the code with a debugger - if the application hangs, it will show you where.
There are times when even the console doesn't show anything, for example when there is a problem with the TLS/SSL handshake (i.e. a close_notify or handshake_failure). In these cases you need to do the following:
Enable the Java logs and tracing in the Java Control Panel > Advanced.
Enable parameters for debugging Java & launching the JNLP, there are two ways you can do it:
2.a. Download the JNLP file and execute it from command line (the SET command is not required in this particular case).
set JAVA_TOOL_OPTIONS=-Djavax.net.debug=all
javaws -wait jnlp.jnlp
2.b. Add arguments (i.e. -Djavax.net.debug=all) for the JVM in the Java Control Panel > Java > View (this is not required in this particular), and launch the JNLP file from browser:
The logs and traces are located in the log directory from the Java Deployment Home from where I paste these locations:
a. Windows XP: %HOME%\Application Data\Sun\Java\Deployment
b. Windows 7/Vista: %APPDATA%\..\LocalLow\Sun\Java\Deployment
c. Linux/Solaris: %HOME%/.java/deployment
This answer is an alternative to npe answer to enable the remote debug (Windows).
Go to Control Panel;
Click on Java, to open Java Control Panel;
Inside of Java Control Panel, go to Java tab, and click "View";
This will open a window with installed java versions. On runtime parameters put "-Xdebug -Xrunjdwp:transport=dt_socket,address=8123,server=y,suspend=n" (if you want to debug when application is starting, change to "suspend" to "y", that will make the application stop until an editor connect remotely);
Afer that, configure you editor to debug remotely to the configured port (localhost:8123 in this case).

Categories