Java 3D

My Story on Java Memory Leak

Weeks ago I got an email saying that someone investigated our application (well, the application is neither initially designed nor implemented by me to be precise). Apparently he was hired by our client to find problems and give advice on how to increase application's performances. One of his findings that was sent to me to analyse was a memory leak report. I didn't have an idea on how Java can create memory leak. I understand that we have to destroy an object and release its memory, only if we, our self, allocate memory as in C. Turned out, there are many ways to create memory leak in Java through inappropriate use of design and code. These are the reports that were sent to me.

Having little knowledge of this application's design now I need to find the root cause of this? Great. The report shows that the top three memory consumers are Hibernate SessionFactoryImpl so it must be something to do with Hibernate. My first step was I need to be able to reproduce the report, see if it happens on my local machine (hoping that it only happens on production machine so I can blame the production environment :p). The report was generated using Eclipse Memory Analyser Tool (MAT), so I run it and boom the MAT produced completely same report. Interestingly, the memory leak happens even after the application was deployed on Weblogic App Server.

First, I thought the session was not properly closed. But looking at the code, it uses getCurrentSession() method provided by Hibernate and then by reading at Hibernate document I knew that it is maintained by Hibernate, developers are not allowed to close it manually.

So then how about Hibernate configuration? I changed the configuration a bit here and there.

<prop key="hibernate.connection.release_mode">after_statement</prop>
The connection must be released immediately after a statement is run.

<prop key="hibernate.cache.use_query_cache">false</prop>
I disabled the query cache.

<prop key="hibernate.transaction.flush_before_completion">true</prop>
Each transaction is flushed immediately.

<prop key="hibernate.transaction.auto_close_session">true</prop>
Each session is closed automatically.

But none of them cure the problem. Until then I realized that the SessionFactoryImpl was loaded because Hibernate check named query at startup. So I set this startup_check to false.

<prop key="hibernate.query.startup_check">false</prop>

Then the report shows the actual culprit. The root cause is our ApplicationContextLoader.

The configuration is loaded statically when the class is loaded by using static block. Moreover, it is set to a static variable which means it stays forever until the ApplicationContextLoader class is unloaded from memory.

Java Web Start

Creating simple Java Web Start application is quite simple. There are three things we need to do.

1. Create the main class and wrap it in a JAR file. For simplicity sake, the main class extends JFrame that contains a JButton inside a JPanel as shown below:

2. Create a JNLP (Java Network Launch Protocol) file that links to the JAR file.

This file is an xml file and the structure is quite self explanatory. The main things here are the codebase attribute in <jnlp> element and the <jar> tag inside <resources> element. The codebase describes base path for all href in the file, in this case it is the base path to find jnlp.jnlp and jnlp.jar since I put those two files in the same folder. The jnlp.jar contains a main class which is stated in main="true" and main-class="edu.mat.jnlp.Main".

3. Create a HTML file that contains a link to the JNLP file.

Opening the HTML in a browser displays the following screen

Clicking the launch button launches the application as shown below:

Simple Drools Example

Implementing an expert system using Drools is quiet easy. First of all create ordinary java project in Eclipse. The following image shows the project structure in Eclipse:

There are two source folders, first one is src/main/java to save java classes and second one is src/main/rules to save Drools rule files. Don't forget to include all required libraries in Drools distribution archive to this project. Two important files that need attention are Main.java and validation.drl. Let's see each of them.

The Main.java contains one method main(). In the main method we load the validation.drl file, create a Customer object, and then fire the validation rule. We also add a Map object that is used to save error messages during validation process. Next we will see the validation.drl.

The .drl file has its own format structure. First we state package name, this is used for grouping only. No same Drools file name exists in the same package. Then we import all classes just like we do in java file. Next we create a series of rules.

In the validation.drl above we have two rules, addressMandatory to validate address, and emailMandatory to validate email. In the when clause we get objects that are inserted through session in KnowledgeBase before; the HashMap object which we put inside a variable named errors for later use and also Customer object that we put inside a variable named cust. While addressMandatory rule checks whether the customer's address is null or not, emailMandatory rule checks whether the customer's email is either null or empty.

If the address or email is null we put an error message to the errors variable so that we can write it to console in the main() method. We can safely write any Java code inside the then clause as we do in ordinary java file.

When we run the main() method, the following output is displayed on console:

Java Compiler API

Java Compiler API has been around for a while since Java 6. We can use it to compile java files at runtime. Let's now have fun with it:

Inside main method above we have two java files to compile. Next we obtain the JavaCompiler object from ToolProvider. The JavaCompiler object then does its job to compile those files using verbose parameter supplied. Verbose parameter is useful to display compilation log. When we run the code, two .class files are created at the same location of the original files. Here is the output on console:

Let's now see another approach to compile java files.

First we state the files to compile. Then we obtain the JavaCompiler object from ToolProvider as we did before. After that we create an object of type DiagnosticCollector. This object is used to collect information during compilation process. Next, we get a StandardJavaFileManager by passing the DiagnosticCollector to the JavaCompiler's method getStandardFileManager. From the StandardJavaFileManager we create an Iterable object that contains the files being compiled. Then the actual compilation process is done by CompilationTask object by calling call() method. If an error occurs during compilation, we print the error information that has been collected by our DiagnosticCollector.

Instead of using DiagnosticCollector, we can use DiagnosticListener to collect error information. To do that we have to implement DiagnosticListener interface as shown below:

Then we can use it to compile java files as shown below:

We should be familiar with the code above since in fact we have seen it before. The only difference is that we replace the DiagnosticCollector with our own MyDiagnosticListener. Both DiagnosticCollector and MyDiagnosticListener implements DiagnosticListener interface.

So far we have seen how to compile java files reside on disk. Next we'll see how to compile java file from a string.

 

Again, the code above looks familiar but instead of getting the java content from files we get the java content from a string. The string itself is wrapped inside an object of type JavaObjectFromString which extends SimpleJavaFileObject which implements JavaFileObject as expected by our Iterable object.

To load the compiled class, we can use URLClassLoader by supplying it with a path where the compiled classes are put. Those classes are most likely compiled in the working directory.

Java RMI

The Java Remote Method Invocation (RMI) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides for remote communication between programs written in the Java programming language.

That is the definition of RMI provided by Oracle on this page. So, now let's have fun with RMI.

We will create two classes that act as a client and a server. The client consumes object provided by server. First we create the object which is a POJO that implements Remote and Serializable. All the methods that are accessible from client (which are public methods) should declare RemoteException.



Next we create the client. It does the following things in order: Locate remote server host which in my case is localhost, lookup User object, and then update user's address. A note here is that the update is not persisted to the object on server, it is kept locally.



Now we will take a look at the server class. The server first will create a registry at port 1099. It then creates a User object and bind it to the "user" registry. After that, it will execute infinite loop while waiting for user's interaction.

If user types 'a', the User's address is updated and the update is available for the next clients looking up for it when they call lookup() method.

If user types 'b', the User object is unbound so that an error is thrown if next clients looking up for it.

If user types 'c', the "user" registry is replaced with new object user2; this is known as rebind.

If user press 'p', it will simply write user's properties to console.

ThreadLocal

ThreadLocal is a class that lets you wrap an object inside it so that each thread accessing ThreadLocal will get its own copy of the object. Consider the following example.

Suppose I have a multithreaded application. The main purpose of each thread in the application is to modify an object through long running processes by calling so many methods (OK this is quite unrealistic example :p). Each thread has its own object to modify. We can declare the object variable in the Thread class or Runnable implementation class or pass it around the methods but obviously it is not a good practice and not always can be done. To overcome this, we can use ThreadLocal.

Images below show us how to implement this: First we have the object to be manipulated, in this case it is a POJO.



Next, we will create a main class which has three threads. Each thread is intended to manipulate a User.



Now we will see the Runnable class to manipulate the object. In the run() method we can see that we modify the user's address in another method and try to see if the changes are persisted correctly. In real life, this is the long-running process that calls many methods to modify the User object.



It's the time to see the ThreadLocal variable in UserFactory class. In the UserFactory class we create a ThreadLocal variable and implement it anonymously. The initialValue() is called only once so it is the best place to initiate everything. All other method's names are quite self-explanatory.



The results are shown below. We can see that each thread has exactly one copy of the User object and the User in each thread is modified correctly. ThreadLocal is very convenient to store an object to be accessible throughout the thread.

Yet Another SQL Best Practice

Just happened to know a best practice to replace NOT IN in SQL using LEFT OUTER JOIN. Consider the following query:

SELECT * FROM a WHERE a.pk NOT IN (SELECT fk_a FROM b)

Nothing's wrong with query above; however, we can make it better by replacing it with:

SELECT * FROM a LEFT OUTER JOIN b ON a.pk = b.fk_a WHERE b.fk_a IS NULL

This can be explained like this: Left outer join uses table "a" as the master. Each row in table "a" will be matched with each row in table "b". If there is no row matched in table "b" for table "a", null will be returned. See an example below:

a b
1 1
2 null
3 3
4 null
5 5

Now in the WHERE clause we state that we are only interested in rows where b.fk_a is null which means we get all rows in table "a" that has not matched any row in table "b".

Simple Ship Movement using OpenLayers

Cross Site Scripting (XSS)

So far when developing a web app, Firefox has been my default browser. However some clients only have Internet Explorer installed on their machine, IE 6 to be precise, no update/patch from the first time Windows XP was installed. No, I was joking, but it's true that for some reason some people don't want to update their browser. Anyway, since IE 6 is quite old, it is vulnerable to Cross Site Scripting (XSS) attack.

Suppose I have a URL address shown above. When user change any of parameters with <script>a, some scenarios occur. As we can see, there are two parameters passed in URL, method and tab. Some scenarios that may occur are:

1. Changing method parameter with any string including <script>a. This will throw Servlet NoSuchMethodException since method parameter is used by Struts to choose what action method to fire, so this is not XSS case.

2. Changing tab parameter with any value including <script>a. This one will make the script be executed and an alert with message a is displayed so it is an XSS case.
3. Adding any parameter. This will not cause any harm since the parameter will not be processed.
   

So basically the problem is with tab parameter. What does tab do? It is used to choose which element to be decorated.

The value of tab parameter is assigned to activeTab and then the activeTab is used to get element by id. Since value of tab is changed to <script>a, it will be executed first and make the alert popped up.

We can overcome this by replacing any character "that is not supposed to be passed" as shown above. Here is the complete code: