Debugging a Multithreaded Webserver in JVM - java

I'm developing a multithreaded webserver applet and have been dealing with system.out.println's for the past week or so as my "debugging" tool. As far as I understand it, the .jar I build is split by a builder and put into .html files and then spit out when I access the web server.
I am wondering if there is some way that I would be able to attach a debugger (plugin?) to Java's virtual machine that would allow me to step through the code as I operate the webserver- there are some critical exceptions that are very frustrating to track down. I believe they're timing issues related to the multithreading which makes them even more unreliable when attempting to locate, and may mean that the debugger won't process appropriately. I don't think it matters, but the IDE I'm building in is Netbeans.
I've taken over a previous developer's hastily-not-quite-finished project and am in well over my head. =/ Thanks in advance for any possible solutions, I appreciate it.

Sure you can.
You need to start the web server JVM with suitable arguments allowing it to be debugged remotely. You can see at http://download.oracle.com/javase/1.3/docs/tooldocs/win32/jdb.html how to do it. jdb is available in the JDK along with javac. You then launch your IDE debugger to connect to your JVM and tell it where the source for your classes is located. Remember to compile with debug information.
As you have it inside Netbeans already then consider just launching it in debug mode as then all the extra work described above will be done automatically for you.

Related

Expedite the develop / deploy / run cycle with Spring, Maven and Wildfly

I've just recently entered the Java world for a client of mine. I have 18 years experience as a .Net developer, but the Java side is new.
Coming from .Net, I'm used to expecting to be able to make a code change, compile my code and run it with a debugger attached all usually within sub 30 seconds, maybe 1 minute on large projects needing a full recompile.
I'm finding my current process with this Java project is taking me upwards of 5-6 minutes. Because of the long time and multiple steps, I find myself starting on other tasks or losing track of what I was doing.
Here is my current process for making a change and testing it:
Make code change
(~200s) Recompile code with Maven on the main Maven module mvn clean install. If I do -DskipTests I can save about 60 seconds here.
(~5s) Stop Wildfly server
(~5s) Copy .war file from myproject\target\myproject.war to c:\wildfly\standalone\deploy\
(~90s) Start Wildfly server c:\wildfly\bin\standalone.bat
Re-login to application (my session expired)
Attach debugger
Again, it is not only the amount of time required for each of these steps but the fact that there are so many steps and the waiting time in-between each makes for distraction as well - after all, who is going to sit and stare at a screen for a 3 minute compile? Whatever I go off to do, I am surely not going to return to that screen at the exact moment the compile is complete. There is going to be wasted time in there.
Further more, I'm repeating this process every time I want to make a single code change.
Is there a way to streamline this process? I.e.:
Is there a way to join some of these steps
Can I speed up the Wildfly boot process?
What will speed Maven up?
Can I do something like "Edit & Continue" which exists in .Net (i.e. live code changes).
Is there a way to get around having to have Wildfly reinitialize anytime I deploy a new war?
Disclaimer: My answer includes processes I personally use, thus it may not be the optimum or most popular solution. Anyway, these things tend to be bound to developer's personal preference.
Find below some recommendations that could speed up the development process.
Use a proper IDE for Java development
Using a popular java IDE can make development faster as it supports integration with build tools(Maven), Version Control Systems, Application Servers(Wildfly) and much more.
Popular choices are Eclipse, IntelliJ, Netbeans and much more.
Fast redeployment
As I said above, a proper IDE would support integration with application servers, Wildfly for your case. By using a Wildfly IDE plugin, you can speed things up as you do not have to wait for app server to boot every time you make a code change. IDE starts once the server and then applies your changes to the running instance.
Personally, I also prefer to use a standalone Wildfly installation instead of integrating it with IDE. To achieve fast redeployment I use hotswap agent. Note that you have to install DCEVM, an alternate JVM which however is not interfering with your main JVM.
Finally, to conclude it is understandable that you make a big turn from .NET to Java and you may feel lost at some points. I would advise to spend some time setting up your environment, and once you have finalised it and you feel comfortable, development will become much easier.
Why stop, move the archive and re-start the server ?
Check out the following maven plugin which will allow you to automate at least that part of it..
https://docs.jboss.org/wildfly/plugins/maven/latest/examples/deployment-example.html

How to Profile Execution of RDF4J Server?

As I indicated in another post, I'm having trouble with some SPIN constructors taking an excessive amount of time to execute quite limited data. I thought I'd take a different approach and see if I can profile the execution of the constructors to gain insight into where specifically they are spending excessive time.
How do I go about profiling the execution of constructors under RDF4J Server? I'm instantiating via SPARQL update (INSERT DATA) queries. Here's the System Information on RDF4J workbench:
I've attempted to profile the Tomcat server under which the RDF4J Server runs using jvisualvm.exe, but I have not gained much insight. Ideally, I'd like to get down to the class/method level within RDF4J so that I can post a more detailed request for help on my slow execution problem or perhaps fix my queries to be more efficient themselves.
So here's the version of Java Visual VM:
RDF4J is running under Apache Tomcat 8.5.5:
I can see overview information on Tomcat:
I can also see the monitor tab and threads:
HOWEVER, what I really want to see is the profiler so that I can see where my slow queries are spending so much time. That hangs on Calibration since I don't have the profiler calibrated for Java 1.8.
This attempting to connect box will persist indefinitely. Canceling it leads to the Performing Calibration message which doesn't actually do anything and is a dead-end hang requiring the Java VisualVM to be killed.
After killing the Java Visual VM and restarting and looking at Options-->Profiling-->Calibration Data, I see that only Java 7 has calibration data.
I have tried switching Tomcat over to running on Java 7, and that did work:
The profiler did come up with Tomcat:
However, when I tried to access the RDF4J workbench while Tomcat ran on Java 7, I could not get the workbench running:
So, I'm still stuck. It would appear that RDF4J requires Tomcat running under Java 1.8, not 1.7. I can't profile under Java 1.8.
I have seen other posts on this problem with Java VisualVM, but the one applicable solution seems to be to bring everything up in a development environment (e.g. Eclipse) and dynamically invoke the profiler at a debugger breakpoint once the target code is running under Java 1.8. I'm not set up to do that with Tomcat and RDF4J and would need pointers. My intention was not to become a Tomcat or RDF4J contributer (because my tasking doesn't allow that... I wouldn't be paid for the time) but rather to get a specific handle on what's taking so long for my SPIN constructor(s) in terms of RDF4J server classes and then ask for help from the RDF4J developer community on gitub.
Can Java VisualVM calibration be bypassed? Could I load a calibration file or directory somewhere for Java VisualVM to use instead of trying to measure calibration data which fails? I'm only interested in the relative CPU loading of classes, not absolute metrics, and I don't need to compare to measurements on other machines.
Thanks.

How can I setup Tomcat running on a virtual machine to enable remote debugging as well as hot swapping synced file changes?

Apologies in advance for the lengthy explanation.
We have an large web application which uses a RabbitMQ server, a Tomcat webserver, a MySQL database, and a Hadoop environment. Most of the team uses Windows, and one uses Ubuntu, but we use CentOS for our deployment environment. We've recently started using vagrant and ansible to standardise environment configuration and deployment across multiple environments. This is part of a move to improve the quality of our application, and helps us to avoid failure between different environments.
We have most of it working now, and over the last few days I've been looking into replicating (or maybe even improving) our current development process with regards to building, running, debugging, and hot-swapping minor code changes without restarting the application. Our existing setup uses embedded Jetty (within eclipse), and we can run Jetty in either Run or Debug mode. With this setup we can place breakpoints, navigate to a relevant page, and when the breakpoint activates we can step through the code, drop frames off the stack to run through a method again, and even make minor changes to the code (within the rules of JVM hotswapping). This is, of course, fantastically helpful for us.
I want to replicate as much of this behaviour as possible except instead of an embedded jetty instance, I want to remote debug the tomcat instance on the virtual machine, but still be able to make changes to the code without needing to restart tomcat each time. I should probably point out at this point that I am aware of JRebel, but it has been deemed unfeasible for our team at this point in time.
At this point in time I have managed to automatically sync (using vagrant); 'src/main/webapp/WEB-INF', 'target/classes' (compiled by eclipse), and 'target/lib' (created by the maven copy-dependencies plugin'. These are all synced to the correct place on the vm, so that tomcat believes it is an exploded war. I have correctly setup Tomcat so that it runs in debug mode, and I have connected to it with eclipse, and successfully entered debug mode by placing a breakpoint. Making any changes to one of the synced files causes tomcat to restart the application and use the new file.
The only problems left are that I lose all my session data when I save a change to a file, and I have to wait for the re-deployment to complete and then repeat appropriate steps to get back to my breakpoint. This is obviously a big waste of time.
So after that lengthy explanation, my questions are:
Has anyone managed to achieve what I'm trying to do?
Is what I'm trying to do even possible?
If so does anyone have any tips to help me finish my configuration?
Can I do hot class replacement without triggering a context reload?
Any help would be greatly appreciated and sorry for the essay! :)

Real time code compiling?

I was watching the livestream at http://www.humblebundle.com, and I saw them running the application, AND making changes to the code in Eclipse. Is this just changes for the next time they compile and run, or was he actually changing the application as it was running somehow?
Sometimes.
In Debug mode, eclipse can compile and change class files in a running JVM, this is called Hot Code Replace.
The idea is that you can start a debugging session on a given runtime
workbench and change a Java file in your development workbench, and
the debugger will replace the code in the receiving VM while it is
running. No restart is required, hence the reference to "hot".
Source: Eclipse Wiki
There are certain circumstances where this won't work, in which case Eclipse will prompt you to restart.
This is called hot code replace:
The idea is that you can start a debugging session on a given runtime workbench and change a Java file in your development workbench, and the debugger will replace the code in the receiving VM while it is running. No restart is required, hence the reference to "hot".
It's not really possible to tell from the stream. Java's capable of both to some extent - you can, with some restrictions, replace classes loaded by a JVM using the debugger. There's also JRebel, which gets rid of a great deal of those restrictions.
Ability to change application code while running is the feature of debugger. In Eclipse and many other popular IDEs it works "out of the box". Feature has several restrictions: can't change method signatures, add/remove class members, etc.
If you are in debug mode you can make certain changes while the application is running. Whether or not it is valid varies based on if the change is to currently loaded code. For example, you could change a sort function while the program isn't sorting and it will use the new code the next time it sorts.

Is it likely appdomains will help in this scenario?

I have a dotnet process that through calls to an unmanaged dll is communicating with a Java process.
Under some circumstances, the Java process appears to be crashing and taking my dotnet process down with it. No exceptions are raised, the process just dies. Upon crashing, java is creating a log file with names like "hs_err_pid3228" etc.
Not having received any satisfaction from the vendor that is providing the unmanaged dll and the java process, I am reduced to trying to mitigate the problem which would necessitate ensuring the calls into the java process, if they crash, don't take down my process.
Having read various articles, appdomains seem a likely candidate to use - my theory being I can with a bit of work separate my functionality that calls the java process and run it in a separate appdomain, which will hopefully allow me to if not catch the appdomain going down, at least detect that it has happened and restart that functionality.
Has anyone had a similar sort of issue? Does this approach seem reasonable to those of you with more experience of appdomain?
To make it even more fun, the Java crash is not really reproducible - it seems very random and I'm still battling with how I'm going to TEST that separating into the appdomain
This is a reasonable use of AppDomains, and what you propose will work.
In a similar vein, I once used AppDomains to create a single application that watched for itself crashing for exception reporting purposes. The application started itself up, created a new AppDomain, then re-executed itself in the new AppDomain, which then detected it was running in an AppDomain and executed normally. When an exception happened in that AppDomain, the original process is notified, it tears down the child domain reports to the user that an error occured, asks whether they want to report it or not, then picked itself up and tried it all over again.
EDIT: To give you a headstart, if you want to look at the Program.cs for that project, I've uploaded a stripped down version here. (It's pretty long, so I didn't think I should post it here.)
Yep, leveraging AppDomains make a lot of sense here.
I've recently reworked my Windows service to load its various WCF services as plug-ins that operate within their own AppDomain. I've got a few cases in the bootstrapping process where I'm using MarshalByRefObject objects to get things up and running, but once the plug-ins are loaded, communication between the AppDomains is extremely easy using WCF.

Categories