I am planing to develop a profiler by using the JVMTI API provided by Oracle. For a visualization I would like to implement a GUI (Qt framework) on top of the agent code. My first jvmti agent is aready compiling and running and I started to integrate the agent into my Qt project.
Now I am facing the problem how to couple agent with GUI. Should the GUI be launched inside the agent? For instance in the Agent_OnLoad function?
A long-term would be to start the profiling out of the GUI, though I cannot imagine how to realize that.
Well.. you have a number of choices the most obvious would be socket based comms. You'll have to assume that the majority of profiling use cases will involve a remote headless JVM on a server. In my profiler you can operate headless with a small start/stop/control utility on the same machine as the agent, data is collected on the server and transfered to the client for visualisation. You can also start the remote (or local) jvm with the agent and connect to the listening agent over a socket from the full GUI.. collecting over that socket to the client.
There is also the new "JVM Attach API" which allows you to "insert" an agent into an already running JVM, therefore if the target machine is UNI* then you could use ssh/scp from your GUI and script an sCP transfer of the agent to the server and SSH to initiate the attach.
So... sockets (IP and/or domain) and reuse that code from the GUI for a headless control/collection client
Related
I have a Java Application(works as server for a client application) with a GUI. This application has to run always even after restarts of the server.
I have created a windows service using Apache daemon for this purpose.
When the server starts I can see my services running as system service. But when I open the GUI of the application another instance starts.
I need the GUI to be attached to the same instance which started after restart, is this possible.
A Windows Service (as well as daemons on Unix-systems) can't run with a GUI because it starts without a Window Management System like Windows Desktop or KDE, Gnome, etc. I'm actually surprised that your application starts as a service because attempts to start GUI-elements should lead to an error.
You have to separate the GUI from the server components. The GUI then needs to communicate with the server by some protocol. Because you already have finished your application I suggest RMI as protocol of choice, that should be the easiest to implement because you essentially just have to add some interfaces to your classes to get RMI on its way instead of adding a complete layer of complexity by your own (an additional server to receive commands from the client, etc.).
RMI can be set up to only listen for connections from localhost, so in terms of security you should be good as well.
How does DRMAA work? Can a local Java program using DRMAA start jobs on a remote cluster over SSH (so that nothing will need to be installed on the server-side)?
Background:
I'm developing a general (or as general as possible) HPC client in Java/Eclipse RCP, and
wanted to use DRMAA in order to support any resource manager as backend.
I have the SSH connection functionality through the Remote System Explorer (RSE) Eclipse plugin already.
Most of the DRMAA implementations use the native API calls (the same which are used inside the qsub/bsub/sbatch... commands). One can see DRMAA as the "ODBC for the batch systems".
Most of the DRMAA implementations require you to run it from submit host of your local cluster, there is no SSH inside. What you can try to do is to build a portable, DRMAA based "drmaa-run" command (example: http://apps.man.poznan.pl/trac/drmaa-misc/browser/drmaa_utils/trunk/drmaa_utils/drmaa_run.c) and run it via SSH.
I'm using Eclipse remote debugger connected to the JVM running my application at the Unix box. I can easily suspend/resume remote application from the Eclipse. My question is how can I achieve the same from the back-end side?
Let's say that there is a certain trigger or condition only back-end is aware of. Once trigger has been detected I want to instruct JVM to suspend in order to enable myself to examine current program state using debugger in Eclipse at my workstation.
I've got this new project at work. We are using Eclipse for the project. There are two run configurations, server and client. I have to launch the server and the client independently, and connect to the server using the client. Now, it so happens that this has to be done on both Windows and Linux. (four possible combinations: WS-LC, WC-LS, WS-WC, LS-LC, where W-windows, L-linux, C-client and S-server)
I have Linux on my machine (in which Eclipse is running) and run Windows on a VM. Is there a way I can make Eclipse launch the application in the VM?
I understand I have to build the application locally to a shared folder and send a launch command to windows (using openssh?, not sure). What are the best practices used in this scenario.
EDIT: I need to use this during development, to test my changes to the code. The same application provides both client & server. (yes, horrible, i know :X )
You can publish the server functions as JMX Beans using the MBean interface standard. Then use JMX Console to remotely connect to the server JVM and launch the application.
Eclipse has integration points for remote servers, look to "tomcat configuration" for an example of how it integrates with one remote server.
Whether your application can use an existing server integration solution or not depends heavily on details which aren't present. If you want to actually launch a stand-alone Java process from your remote machine, you generally need a program to capture the request and launch the process.
In Java development on Windows there are two different transports that can be used while debugging.
What are the advantages of using Socket transport on the same computer where the app is running?
I know Socket can work on a remote computer. But I am trying to figure out if it makes a difference on my local dev box vs Shared memory?
Thank you.
UPDATE: I am using Intellij IDEA.
Shared memory will be faster :-)
The only advantage of sockets on same machine I can think of is that you have the same, universal debugging protocol, so when you deploy your app to a remote server the only visible change will be the ip.
What are the advantages of using Socket transport (...)?
The advantage of using Socket transport on the same machine is to ignore incompatibilities between the IDE JDK and the application's (or web-application) JDK.
Example:
Connect to a application that run on JDK32-bit will fail if the IDE is running a JDK64-bit using shared memory. In this case:
You MUST use Socket on the same machine.