![]() ![]() Instead, we leveraged the port-forwarding feature already available in OpenShift. We didn’t need to deploy Jolokia proxy or create additional Service or Route objects to make our setup work. In this blog post, we were able to attach a debugger and VisualVM to the Java application running on OpenShift. Issue the following command on your local machine to start the proxy and forward the three ports 8000, 3000, and 3001 to the remote pod running on OpenShift: What you need though is to start a port forwarding proxy on your local machine. Port forwarding doesn’t require you to define any additional objects like Service or Route to enable it. OpenShift features port forwarding that allows you to connect to an arbitrary port of a pod running on OpenShift. How are we going to connect to these ports? Let’s set up port forwarding on the local machine next. This verifies that our JVM options are in effect and the debug port and JMX ports are open. Picked up JAVA_TOOL_OPTIONS: -agentlib:jdwp = transport =dt_socket,server =y,address =8000,suspend =n = true .port = 3000 .rmi.port = 3001 =127.0.0.1 .authenticate = false .ssl = false $ oc logs dc/hello-world | grep JAVA_TOOL_OPTIONS For example, you can open the DeloymentConfig for editing like this: Go ahead and modify the DeploymentConfig or Pod descriptor of your application in OpenShift to add the JAVA_TOOL_OPTIONS variable. I recommend using this variable as there is a great chance that this variable will work no matter how deep in your wrapper scripts you are launching the JVM. It turns out that there exists an environment variable JAVA_TOOL_OPTIONS that is interpreted directly by the JVM and where you can put your JVM configuration options. ![]() Next, we need to convey our configuration options to the JVM running inside the OpenShift pod. However, there’s no RMI server running on the local machine, so what’s the deal? As you will see in the next section, we are going to forward the local port 3001 back to the remote server. Based on our configuration, the client is going to connect to 127.0.0.1:3001. After the successful lookup, the client initiates a second connection to the RMI server. And as a matter of fact, there are two RMI ports needed for this communication: * RMI registry port * RMI server portĪt the beginning, the client connects to the RMI registry on port 3000 and looks up the connection to the RMI server. By default, JMX utilizes RMI as the underlying technology for the communication between the JMX client and the remote JVM. This set of options deserves a bit more explanation. You can follow the build logs by issuing the command: ![]() "hello-world" createdīuild scheduled, use 'oc logs -f bc/hello-world' to track its progress.Īccess your application via route 'hello-world-myproject.192.168.42.' Run 'oc status' to view your app. "hello-world" createdĭ "hello-world" created * APP_OPTIONS = * GITHUB_TRIGGER_SECRET =EM325a5K # generated * GENERIC_TRIGGER_SECRET =CBCcCIWr # generated -> Creating resources. Sample Vert.x application build with Maven > Deploying template "myproject/vertx-helloworld-maven" to project myproject ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |