Author: Apurba Nath

Ok, the post topic is a bit grandiose, it should have been “Development time swap of spring beans using a custom classloader”, so a few disclaimers, I am only talking about development, I am not aiming for the most optimal solution and yes I am still working on it. The blog is about an approach that comes with some code snippets. Is more of an idea implemented for a very particular problem which can be applied in a more generic way rather than an actual generic solution.

So if u r still reading…,
My project essentially uses spring for all the services, meaning there are a lot of stateless services which are only dependent on each other and are essentially looked up from a single big map (yes, am oversimplifying am not doing anything that stupid, actually use the appcontext there).  I am tired of making a change like adding another private method or changing some lines and introducing new local variables and then seeing my debug hotswap crying hoarse about this new method and saying that add method is not supported by my VM or something else like that (yes, I know at least some of the complexity of how hot swap does it, what are the risks involved and why binary compatibility is such a key thing for it).

So I wrote a little classloader which loads the classes from my compile folder, creates an instance out of it. In another method refreshMyBean which I can access from any of my jsp pages, I use this classloader to create a new instance of the spring bean and then wire and inject it in the context from where I lookup all beans.

The class loader implementation is as rudimentary as

public class RefreshingClassLoader extends ClassLoader {
	private URL url;
	public RefreshingClassLoader() throws Exception {
		super(RefreshingClassLoader.class.getClassLoader());
		url = new URL("file:///");
	}
	protected synchronized Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
		System.out.println(name +"  "+resolve);
		// First, check if the class has already been loaded
		Class c = findLoadedClass(name);
		if (c == null) {
			if (name.indexOf() != -1) {
				c = findClass(name);
			} else {
				c = super.loadClass(name, resolve);
			}
		}
		if (resolve) {
			resolveClass(c);
		}
		return c;
	}
	protected Class findClass(String name) throws ClassNotFoundException {
		System.out.println(name);
		byte[] buffer = null;
		String path = name.replace('.', '/').concat(".class");
		String filePath = url.getPath() + File.separatorChar + path;
		buffer = readFile(filePath);
		return defineClass(name, buffer, 0, buffer.length);
	}
	private byte[] readFile(String filePath) throws ClassNotFoundException {
		try{
			FileInputStream inStream = new FileInputStream(filePath);
			int length = inStream.available();
			byte[] buffer = new byte[length];
			inStream.read(buffer, 0, length);
			return buffer;
		}catch(Exception exc) {
			throw new ClassNotFoundException("Could not do IO for "+filePath, exc);
		}
	}
}

The code for refreshing the spring bean is something like

public void refreshMyBean() {
	RefreshingClassLoader classLoader = new RefreshingClassLoader();
	Class changeClass = classLoader.loadClass(changeClassName);
	ChangedClassInterface changedInstance = (ChangedClassInterface) changeClass.newInstance();
	//now wire the spring services this guy uses into this instance
	//then put the new guy into the bean context wrapper
}

Fortunately for me, the actual code that uses this service does not keep any local copies and always looks up from the context. Obviously I can not handle changes in the interface yet, but theoretically if this invoker were to be created afresh it could get a handle on to the new interface too. One of the main advantages of most of the enterprise applications I have worked on is the coupling between the web request and the flow life. So if it is a new request, we can swap in all new versions of classes used in the flow.

Though, I call refreshBean from one of my UI pages when I make a change, this could be jmx or any other cooler thing (the coolest being direct IDE integration, just a plain ResourceDeltaVisitor in eclipse which would know the java file which was changed, would know if it was a spring bean and the mapping for it). There are other more evolved strategies like proxying which we can use for the same purpose, but that seems to lose on the debug information of the changed class.

This simple solution seems to help me save a lot of time in my development, so was just wondering if something this rudimentary would not be helpful for most people, if u think so, leave a comment. I know in this entry have not really covered the wiring and the reinjection part in more details as I have done it in a very non generic way, can make it much more generic (have done that before for something else), but need some proof that it is worth that effort (I was born with this congenital defect which makes u think every idea of yours is the next great thing, so now I wait for others to reject them before giving them my all).

Author: Fazal Gupta

Introduction

Java XML APIs have been one of the most used APIs in Java world. Still I think most of you would agree with me that there are so many mysteries in it, that even for developers who have been working on them for ages, it is a bit scary. The cumbersome implementations have only multiplied the horrors. But fact of the matter is whether you love or hate them, you need to live with them and use them in the most effective manner to solve the problem at hand while spending minimum of your effort in figuring out ways to parse the XML. In this article I would like to mention few small idiosyncrasies which I had to face while working with XML APIs. I have worked with Xerces and Xalan implementations and therefore my experience is based on these implementations.

Take the case of javax.xml.transform.Transformer class. Typically Transformer class is used to convert a source XML tree into a result XML tree by applying some rules. Typically the rules are written in XSL. Also one might need to convert a given DOM Node to its string representation for which Transformer class is used.

There are many important properties which one sets on the transformer before applying the transformation. The properties are set on the transformer object using setOutputProperty method. As such the method only takes two String arguments, but the possible set of properties can be figured out by looking at javax.xml.transform.OutputKeys class.

One of the interesting properties of this class is the METHOD property. This property identifies the overall method that should be used for outputting the result tree. The three possible options are xml, html or text. I had been using this API for more than 2 years but it was only recently that I realized the importance of this property. Take the below XHTML as an example.

<html>

<head>

<p>This is head</p>

</head

</body>

<p>&#160</p>

<p>HelloWorld</p>

</body>

</html>

If one tries to parse this DOM node into a String with METHOD property set to anything other than html, you will see that the numeric code for “ “ (&#160), would be ignored or may get converted into some junk character (the behavior is not consistent) and the final output of the string will be something like this

<html>

<head>

<p>This is head</p>

</head

</body>

<p> </p>

<p>HelloWorld</p>

</body>

</html>

All looks fine as of now but if one would open this html string in a html editor like tinymce, one would notice weird question mark symbols on the editor and most HTML editor expect &nbsp; for space.

One could overcome this issue by going in a smart way and replacing the “ “ symbol with &nbsp;, but there is a easier way than this. Just set the METHOD property of the transformer and &#160 would automatically get converted into &nbsp; in the result. The result would be as following

<html>

<head>

<p>This is head</p>

</head

</body>

<p>&nbsp;</p>

<p>HelloWorld</p>

</body>

</html>

As an example following is the code piece to set the METHOD property

Transformer transformer = TransformerFactor.newTransformer();

transformer.setOutputProperty(OutputKeys.METHOD, “html”);

The way to set output properties of the parser looks bit cumbersome as the only way is to use setOutputProperty method. I am not sure if the API developers could have given an easier way (like providing setters for such properties), so that figuring them out becomes easier. But this is something worth investigating.

This point is the complementary scenario for the above point. Sometimes one may want to read a given HTML string and convert it into a Document object. HTML contains &nbsp; to represent space and if one tries to convert this string directly into DOM, you would encounter the following error

The entity “nbsp” was referenced, but not declared.

I am not sure what is the best way to handle this issue, but we guys converted &nbsp; to  . This did solve the issue, but at the cost of expensive string replacement operation.

Again this may be a common issue every developer would have faced while working with DOM API. Let’s say one is traversing over a DOM and a given node needs to be replaced with a node which was created from a different document. Doing this would result in the following error

WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.

There are two possible method exposed in the Node class to achieve this. One is adoptNode and the other one is importNode. The difference between the two is that the former tries to adopt the same node object whereas the latter method creates a copy of the node and tries to adopt the copy. Following code can be used as a sample to achieve the copying of node using adoptNode method and replacing a given node of the given document.

Node doc1Node;

Node doc2Node;

Node adoptedNode = doc1Node.getOwnerDocument().adoptNode(doc1Node);

doc1Node.getParentNode().replaceChild(adoptedNode, doc1Node);

This is not an API issue but a peculiar problem which happened due to bug in Xalan 2.7 because of which it could not be used with OC4J. Since this article was on XML APIs I just felt it would be better to mention this point briefly. The problem has already been solved in Xalan 2.7.1 and therefore now it remains more of academic interest. The issue was that Xalan 2.7 included BCEL classes which were not required for Xalan at all. This was actually a bug. More details on this issue can be found on the following link: http://issues.apache.org/jira/browse/XALANJ-2196

Again this is a universally known fact but is worth mentioning in any discussion on Java XML APIs. Thread safety is always an important issue when one is using any API. In case of Java XML APIs, it’s worth keeping in mind that DocumentBuilder and DocumentBuilderFactory are not Thread safe. And it’s the onus of the developers who are using the objects of these classes to make sure they are not being used by multiple threads at the same time. While doing profiling of the application we observed that creation of documentbuilder objects was quite expensive. At that point we overlooked the thread safety aspect of the DocumentBuilder class and ended up paying a heavy price in the later phase of the release. As its known that concurrency errors come in such disguises that its hard to even understand them. In our case we were getting a Null Pointer Exception. That’s when I leant the hard way about the importance of thread safety. Hopefully most of you are already aware of this.

Author: Apurba Nath

Anyone who has done some serious development knows about debugging. There is a lot of stuff that goes under the hood for debugging, this blog takes a look at some of these. After reading this blog the reader may have a better understanding of the reason behind rare but weird errors about the “line number information not being present” when we try setting a break point. To keep things simple I am going to cover only the basics and will oversimplify and generalize without much discretion.

There are two parties in debugging, one the program which is running and the other which is issuing debugging commands to it. The first guy being the debugee and the second guy debugger, so kinda like debugger is running the show making the debugee jump through hoops (or should it be loops). To enable this cross talk, we need to launch the program in debug mode. The most common way of talking is via sockets, depending on who is running the server socket we can term it as a local or remote debug session. We use options like

-agentlib:jdwp=transport=dt_socket,suspend=y,
address=localhost:4321

for starting a process in debug mode. Essentially this command means use socket communication as transport for the java debug wire protocol( jdwp param) with the server socket running at localhost on port 4321( address param) waiting for commands from the debugger (suspend param). For remote debugging instead of running the server socket at the debugee end we would run it at debugger, so the options address=localhost:4321 changes to address=7777 and we add server=y. Of course now we do have to run the debugger program at the 7777 port. Remote debugging is very handy while working with appservers or any other program which you need to launch outside your ide environment and then connect to for debugging. (Ahem!! -Xdebug -Xrunjdwp are there too).

The cross talk between the debugger and debugee is done via requests and events. The event is dispatched as a response when the event actually happens, for example when we set a line breakpoint, when this line is actually to be invoked, the VM would issue a BreakPointEvent and the debugger can take appropriate action (step in, inspect variables etc). The requests from a technical perspective need not be only breakpoints, but can be method entry, exit, class loading, exceptions etc, most editors however abstract this out and represent everything as a breakpoints, so they mock features like MethodBreakPoints or ExceptionBreakPoints. (Ahem!! yes, jvmti does not necessarily use the dispatching, it can use callbacks)

Requests:
To stop the program at our points of interest, we tell what our points of interest are (requests) and then give the vm further instructions when it hits them (it sends us events to indicate it may have hit it, we then send more requests in response to these events). These points of interest could be lines, methods, variables or many other things. A few details about some of the obvious ones are give below.

1. Line

When the point of interest is a line, we set a line breakpoint. To facilitate line breakpoints, the vm has to make sure that the class file has line information. For example if we pick up one of the base java classes like java.lang.String in rt.jar from the standalone jre and the ones in the JDK, we will notice that the ones in JRE do not really have line number information (opening up the files in any byte code viewer will give that information). From a debugging perspective, line breakpoints can only be set if the class has line number info. In the actual byte code Line number information is conveyed using many of the attributes that are a part of the class file spec, for additional details refer to the sections about attributes like LineNumberInformation, SourceVariable etc at Class File Specification. An oversimplified view would be something like
Line 129 of the String.java (1.5.06 sun version) which is something like

this.offset = 0;


would have a byte code equivalent like

L1
LINENUMBER 129 L1
ALOAD 0
ICONST_0
PUTFIELD java/lang/String.offset : I
L2

This tell us that the VM instructions that follow Label L1 are actually generated because of line 129 in the source code. We can suppress generation and addition of such information in our class files by using -g:none switch at compilation time (try javac -g). There are other parts like source, sourcepath and some other details which are important for the actual functionality.

2. Method

At times we are interested in the execution of a certain method or we do not have the source file, in such a case we can request the vm to wait when it hits method entry and exit. Most IDEs provide Method Break Points to cater to this, the best part about method break points is that they do not rely on the line number information, just the method names and its signature. The only disadvantage of the method breakpoint is that they are slower than their line counterparts. (Ahem!! technically method breakpoints are not breakpoints. From the api perspective, debuggers raise requests to listen to method entry and exit events and then filter them out appropriately at their ends, so a lot of crosstalk and slower responses).

3. Field

We can also suspend the vm or thread when a field is accessed or modified. In eclipse parlance we will call it WatchPoint. This is really handy when the code base uses reflection to modify values. For example a field gets magically modified to null and then we see NullPointerExceptions, we can use a WatchPoint to understand which part of the code does this and if this is really a bug.

In addition to these, the actual JDI actually supports requests for a lot more stages like class loading, unloading, monitor entry etc (for a more comprehensive feel look at com.sun.jdi.request package JPDA api).

When the debugger gets the event from the debugee, it can step in or resume the thread or VM. This feature is leveraged widely for catering to finer needs of debugging via Conditional Breakpoints. Most debuggers evaluate a condition on receiving the event and could then ask for user interaction or silently resume the thread. For example in case of the field being set to null, we could set a conditional watchpoint which would be true only if the current value of field were null. In an IDE like eclipse the condition can be specified using the breakpoint properties dialog box.

Another nifty feature is to tie the request to a specific thread. This can come in very handy in debugging problems on a webserver, so that parallel flows do not impact the debugging. In Eclipse this can be done via the Filtering page of the breakpoint properties. This too is a condition which is evaluated at the debugger level, meaning it does have a performance penalty.

There are many other very interesting details like stratum or hotswap. But guess will leave them for another day …

Author: Abhishek Khurana

I have got a JSP page which after being rendered needs to call an onload event to look for all divs (believe me there are many of them) having some style class assigned to them and hide them from view. This is one of those kitchen sink problem that came back to haunt me making me realize that JS DOM API doesn’t give me anything to fetch elements containing a class as one of its style attributes.

I came across one of the implementation which goes like this:

<script type="text/javascript">
function findByTagAndClass(tagName,cn1){
    var list = document.getElementsByTagName(tagName);
    var list2 = new Array();
    for(var i in list){
        if(hasClass(list[i],cn1)){
            list2.push(list[i]);
        }
    }
    return list2;
}

function hasClass(element,c){
    if(element!=null && element.className!=null) {
        if(element.className==c)return true;
        var classes = element.className.split(" ");
        for(var i in classes){
            if(classes[i]==c)return true;
        }
    }
    return false;
}

var list = findByTagAndClass('DIV','xyzClass');
</script>

With due credit to this piece for its correctness, one must not overlook the hasClass() which does a costly action of splitting the className string into Array to traverse over it and find the match. Just imagine numerous of unrelated divs goings across this cycle makes it a lesser meaningful approach. For those statistically inclined, the action, that has inspired me to write this entry, takes around 48 sec (on average) to render the page on IE 6. This example may as well qualifies for an Anti Pattern in JavaScript.

Here goes the two approaches I followed to tackle this issue.

1. Minimize the scope of my search for the nodes with this class. Rather than searching over the whole document, its always better to find out if there exists an immediate parent node which contains all possible elements.
2. Get rid of that splitting of className to look for a matching type.

These will be taken care of as follows: (courtesy: AnyExample.com)

<script type="text/javascript">
function getElementsByClassName(searchClass, domNode, tagName) {
    if (domNode == null) domNode = document;
    if (tagName == null) tagName = '*';
    var el = new Array();
    var tags = domNode.getElementsByTagName(tagName);
    var tcl = " "+searchClass+" ";
    for(i=0,j=0; i<tags.length; i++) {
        var test = " " + tags[i].className + " ";
        if (test.indexOf(tcl) != -1)
        el[j++] = tags[i];
    }
    return el;
}

var list = getElementsByClass(document.getElementById('div_mainTable'), 'DIV', 'xyzClass');
</script>

Notice that String.indexOf() turns out to be better and usually lighter approach. As much as this snippet helped me reduce the cost down to 20 sec (on average), I couldn’t stop myself to better this milestone. Understandably, using a regex to find a match is the next level, but why not reuse something already in place.

If Joshua Bloch (Author: Effective Java) says Know and Use the Libraries (Item 47), the scope of his teachings were never limited to Java. jQuery has redefined the way we can now traverse html document elements faster and with lesser effort in semantics of the algorithm.

All that talk and a better handling of boundary conditions (which will be unknown to us most of the time), can now be replaced by just one liner (modified after one of the comments suggesting a better way).

$("#div_mainTable div.xyzClass").hide();

Luckily I could find myself a method to hide the concerned components. Had this been not the case, I already had a way out:

$("#div_mainTable div.xyzClass").css({display:"none"});

For those beginners like me, the above piece of line is a chained query which first fetches all the children of element (id: mainDiv), filter out those of “div” tag followed by those which do not match the expression xyzClass before working upon them. Using the library did redefine the standard and cost went further down to 12 sec (on average).

For the completeness of the article, here’s how getElementsByClass can be agnostically implemented:

<script type="text/javascript">
function getElementsByClassName(searchClass, tagName, domNodeId) {
    if(searchClass == null || searchClass == "")
        return new Array();
    else {
        var expr = "";
        if (domNodeId != null) expr = "#"+domNodeId+" ";
        if (tagName != null) expr += tagName;
        expr += "."+searchClass;

        return $(expr).map(function(){
            return $(this)[0];
        }).get();
    }
}
</script>

jQuery is en route a good web development framework featuring DOM elements selection, traversal and modification plus many more. Its unique chaining model we witnessed in the example to perform multiple operations on elements (in page document) deserve no less praise. I shall be coming up with more related & performance-oriented examples using this library to replace many day-to-day web development.

Author: Pavitar Singh

In theory everyone knows Hash Map is not Thread Safe and it shouldn’t be used in multi Threaded applications. But still people come out with their own theories that they can use HashMap in their context. Some say they are just reading the data and map is not written to a lot. Unfortunately none of these explanations holds good when one lands up in a synchronization issue. Normally most of the guys do not understand fundamentals around Java Memory Model and Concurrency .One cannot blame them for not knowing their fundamentals as its hard for people to visualize concurrent executions since from college days we are used to sequential executions of program.

Enuf of blame game, now lets look into some code.Have a look at the code mentioned below and come out with all your theories of what can go wrong with it or theories which say its all correct.

public class MapTestTask implements Runnable {

private Map hashMap;

private Object      value = new Object();

public MapTestTask(Map map) {
  this.hashMap = map;
}

public void run() {
  hashMap.put(Thread.currentThread(), value);
  Object retrieved = hashMap.get(Thread.currentThread());
   if (retrieved == null) {
  // Can it ever Happen
  }
}
}

Now question is when we run multiple such Threads can we ever see retrieved as null.

If we look from sequential point of view it can never happen.But when concurrency comes into picture this can happen. I will give you a code with which can reproduce this scenario.

This is my sincere advise : do not over engineer when Concurreny is involved. Because none of the theories will stand the test of time in a concurrent environment. As a rule of thumb use Thread safe collections wherever concurrency is involved.

Finally i will leave you with this interesting bug in Java which says HashMap can get into infinite loop when used in muti Threaded Environment which further reiterates my point that not all the possible scenarios can be visualized in a multi threaded environment and therefore one should rely on basics rather than trying a smart creativity which has high probability of landing into trouble at some point in future.
You can read details about the infinite loop problem here.

Source Code for Reproducing:
MapTestTask.java

package test;

import java.util.Map;

public class MapTestTask implements Runnable {

    private Map hashMap;

    private Object      value = new Object();

    public MapTestTask(Map map) {
        this.hashMap = map;
    }

    public void run() {
                hashMap.put(Thread.currentThread(), value);
                Object retrieved = hashMap.get(Thread.currentThread());
                if (retrieved == null) {
                    // Can it ever Happen
                    System.out.println("Oh My God it can happen.");
                }

            }
}

TestMap.java

package test;

import java.util.Map;
import java.util.HashMap;

public class TestMap {

    public static void main(String[] args) throws InterruptedException {

        Map map = new HashMap();

        int NUM_THREADS = 1000;
        Thread[] threads = new Thread[NUM_THREADS];
        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i] = new Thread(new MapTestTask(map));
        }

        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i].start();
        }

        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i].join();
        }
    }

}

Author: Fazal Gupta

Issues in porting existing Applications on Clustered Environments

The ideas mentioned below are based on the practical experience of porting an existing application over a clustered environment. The work around and the solutions mentioned below should not be taken as “best practice guidelines” but possible quick fixes which may be needed to make sure that the application can run in a stable fashion without causing serious issues though with some trade off on scalability.

Environmental Setup of Cluster

The typical cluster being discussed here is not application severs cluster where the App servers are started in a clustered mode. Here multiple instances of App servers were started on different machines connecting to the same DB and a load balancer was placed in front of them for receiving requests and forwarding it to one of the App Server instances.

Also session stickiness instead of session replication was preferred in this case based on the application’s requirements. Hence one user’s interaction with the system is always handled by one node only until he logs out. This can simplify lot of clustering issues and is easier to implement. The drawback of going with session stickiness is the load among nodes can be greatly skewed as one server may end up serving many more users and would cater to greater load than other nodes. Thus the real benefits of clustering may not appear in some cases with session stickiness. Still based on the domain where the application is in use, session stickiness may not be a bad way to implement the clustering solution.

Problem of Pocket Caches

The idea of maintaining some kind of cache in java code is to increase performance. Unfortunately such pocket caches in java classes become a pain in the clustered environment. The issue one faces is maintaining these caches in sync when a change is made on one of the nodes and all other nodes need to update itself for the latest value. Typically these caches are built on some information from DB itself so as to minimize the DB hits for better performance.

Possible Solutions

1. Terracotta is one of the obvious solutions to this problem. I would not waste time in copying information about terracotta in this article and interested readers can refer Terracota Site site to know more about this. Unfortunately in our case we could not use terracotta because Oracle App Server support is yet not integrated in terracotta and Oracle App Server users would need to weave in OC4J classloader hierarchy within terracotta to make it work. I think Terracotta provides hooks for achieving this but in our case we did not have so much time for researching the solution and testing the changes. But if one wants to try this look further at Teracotta Forum

2. There are 3rd party caches like EH Cache available in the market which one can use to convert there caches to be cluster aware. Only issue is the amount of code change required in existing applications is quite significant and would normally be followed by a proper release of the product after good amount of testing. Hence this would again not qualify as a quick fix solution.

3. Use the common Database: This is a quick fix solution but definitely has a major performance drawback. The idea is to make use of a date column of a table related to the cached entity, and use the data of the column to determine whether the cache is stale or not. The drawback of this approach is obvious. To make sure that user always sees the correct value, every time value is looked up in cache one would need to do a DB hit to check for the data value. One can be smarter and try some small optimizations in this approach. One idea can be to keep some heuristic time gap before one goes to the DB to check whether the cache is stale or not. Thus between these intervals cache lookup would not involve any DB hit. The time interval can be decided on various factors like the type of application, how long is the stale data state acceptable and what is the probable interval within with some change in the cache is expected. Another optimization one can bring into this solution if the latency factor cannot be tolerated is to make the DB hit for a given request only once. This idea applies only to those caches which get looked up multiple times within one request scope. Thus one can set some parameters to make sure that the DB hits happens only once for that request.

4. Use some kind of Messaging between the nodes: Since DB itself can become a contentious resource in a clustered environment, sometimes it might be a good idea to relieve DB of the responsibility of doing sync up of pocket caches. Thus one can apply some alternative tricks to achieve this. One crude way to achieve this would be to send a sample HTTP request between the nodes whenever the cache is updated on one of these nodes. Apart from relieving the DB from the sync up work, this approach can also benefit in applying diff over the cache i.e. One can directly send the delta change in the message which other nodes can directly consume to update there caches. Further JMS can also be explored as an alternative messaging mechanism between the nodes. The biggest drawback of taking this approach is managing the communication between nodes. If the number of nodes is large such cross talk itself may hog up lot of traffic within the cluster and lower the overall performance itself. Hence this solution should be implemented with proper design to make sure that cluster can bail out of such scenarios gracefully while still achieving the sync up.

Recheck Code for possible Concurrency Issues

Clustering is to solve issue of scalability and allowing more users to concurrently access the application. Hence one can expect concurrency issues to become much more visible in a clustered application. Also some code pieces work fine when all the users connect to the same Application Server but with multiple instances of App server in place such methods need to be checked again to make sure that the Business logic works well in this case.

Revisit Synchronized methods
Consider the following piece of code

Synchronized void a() {

//Some select query on DB
// Process the returned value
//Update the new value of the record to DB

}

Take the case of above method. Since the method is synchronized, one can be sure that no two threads on this server would execute this method at the same time. Hence the task of reading and writing to DB for a given record is being done only 1 thread. But as soon as this application is ported to a cluster the above method lands up in trouble. Issue is obvious; two threads on two different nodes can be in the method at the same time and can end up playing with data integrity if both are accessing the same row. The solution to this problem is to execute the above piece of code within a transaction block and setting the right isolation level of the transaction. By default the driver normally return TRANSACTION_READ_COMMITTED as the level of isolation which is good enough for most of the cases. But the case mentioned above may need a stricter level of isolation like TRANSACTION_REPEATABLE_READ.

The choice of isolation level depends upon the scenario in which this method is being used. Another alternative to resolve the problem can be to put the above code within a transaction scope and making a SELECT FOR UPDATE query to the DB. This would attain a row level lock until a commit or rollback happens on the connection and other connection would wait before accessing this row or throw back an SQL Exception ( depending on the lock timeout parameters either at the sql level WAIT or NOWAIT option or the db settings like locktimeout). I am not an expert in DB stuff but these are some of the options that have worked well for us. Interested people can look these concepts in detail on the net.

Integrate time sync

While running nodes in clustered mode, it is very important that the system times of both the nodes are in sync. Though everyone seems to know the advantages of doing so, it is surprising how many systems do not have an automated time sync facility. Absence of time sync could show weird issues ranging from the clustered cache behaving in unpredictable ways to some frameworks like Quartz trying false cluster recoveries.

When in doubt use a Thread safe Collection

Though not related to to clusters this is a typical concurrency issue which many people underestimate or ignore. The use of Thread safe collections is of utmost importance to ensure consistent behavior for a concurrent application. The reason for mentioning this point here is because we mostly go for a clustered solution only when the concurrent traffic increases, more concurrent traffic means more chances of exposing unsafe collection issues. Thus for any Collection which is expected to be modified by different threads at the same time (though seemingly they may not be playing with the same record or value), its better to choose a thread safe collection as debugging concurrency issues especially in Collections is really hard and can be highly inconsistent. In one of our future articles we will cover more about usage of Thread safe collections and the possible concurrency issues related to them.

I hope this article helps some developers in future to resolve few small but painful issues in running their application over a cluster.

Author : Pavitar Singh

Java supports two intrinsic concurrency mechanisms “synchronized” and “volatile”. We tend to use synchronized or its newer avatar “locks” from java.util.concurrent most of the times without even checking if volatile or some other option could have been a fit. A careful analysis from concurrency perspective could yield a much smarter and performant solution in many of these scenarios. This analysis would need a good understanding of the properties of each of this mechanism, some of the guarantees that they hold and how it impacts a typical program.

This article takes a look from a Java perspective at some of these semantics and guarantees and does a comparison between synchronized and volatile on some of these parameters. I am also going to go over usages of volatile to build highly performant concurrent programs.

Properties of Concurrent Programs :

A.) Visibility : It determines when actions of one Thread can be seen by the other.
It guarantees whether results of one action can be seen by another action, where both actions can be performed by different Threads.

For Example:

private boolean status;

public void setValue(boolean status){
this.status = status;
}

public boolean getValue(){
return this.status;
}
a.) Thread 1 does setValue
b.) Thread 2 does getValue

Will both Threads see the same value? In order to answer this question we need visibility guarantees which will ensure that value set by
Thread 1 will be visible when Thread 2 does getValue.

B.) Atomicity : It determines whether a set of actions occur indivisibly.
It is also possible that what seems like one action from the language perspective is actually multiple actions in the actual implementation (like incrementing a counter). Atomicity can be enforced on a sequence of actions. Unlike the transactional world it is not about success or failure of the steps, but more about their result being visible together.

C.) Ordering : It determines when actions of one Thread seem to happen out of order to other Threads.
Compilers and Processors do a lot of optimizations which end up reordering the way instructions are executed. But concurrent programs need some
guarantees which restrict some reorderings.

For Example :

void threadOne() {
a = true;
b = true;
}

boolean threadTwo() {
boolean r1 = b; // sees true
boolean r2 = a; // sees false
}

Thread One sets a and b both to true and Thread two can see true for b but false for a.

As compiler or processor may do some reordering like:

void threadOne() {
b = true;
a = true;
}

boolean threadTwo() {
boolean r1 = b; // sees true
boolean r2 = a; // sees false
}

Comparison of synchronized and volatile

We need to see what Java Memory Model has to say about these properties for synchronized and volatile. Guarantees provided by Java Memory Model are centred around Happens Before Relationship( Def: “Two actions can be ordered by a happens-before relationship.
If one action happens before another, then the first is visible to and ordered before the
second”). And according to Java Memory Model :

a.)An unlock on a monitor happens before every subsequent lock on that monitor.
b.)A write to a volatile field happens before every subsequent read of that volatile.

That means volatile and synchronized are going to have same visibility guarantees.

Now question comes about Orderings.For that again we need to look into JMM. If we look into JMM section 6.4 we find following statement :

“It is generally legal to reorder a normal memory access and a following acquire action, or a release action and a following normal memory access. This has been referred to as “roach motel” semantics: variable accesses can be moved into a synchronized block, but cannot, in general, move out.“

And the same section says : “Some operations (e.g., writing a volatile variable, unlocking a monitor, starting a thread) have release semantics.Other operations (e.g., reading a volatile variable,locking a monitor) have acquire semantics”

That means volatile and synchronized have same ordering semantics.

So Volatile doesn’t have Atomicity properties.That means we cannot enforce a sequence of actions to occur atomically with volatiles.

For Example :


volatile int i;

someMethod(){
i++;
}

Here i++ is not a single instructions its basically 3 instructions :
i.) Read i
ii.) Increment i
iii.) Set i

These 3 instructions may not happen atomically.

Thats what make volatile unfit for Counters.

But that still keeps open a lot of other use cases of volatile. Some of these patterns are nicely presented by Brian Goetz here.

I am not going to repeat these patterns, but what I have tried to stress on is the similarity of memory model semantics between volatile and synchronized, other then mutual exclusion (Atomicity is mutual exclusion) and show how these properties has been leveraged in some Java Library Classes to build performant solutions.

We find one of the smartest usages in ConcurrentHashMap which uses volatile properties (as described above) to achieve read (get method) without Locking.

If you will look into the source code you will find that the get method of ConcurrentHashMap is lock free and volatile is used to enforce memory flushes.Now here question comes why in first place we need get method to have any lock.What are guarantees from JMM perspective we are looking for while reading the data. So the answer which should come to our mind is Visiblity, whether changes made in put will be visible in get.As if they are not visible then lot of things can go wrong. So we need Visiblity guarantee in read method. Think more and you will realize other guarantee which we need is ordering. But Why ? When we see visibility its mainly provided by memory barrier being placed at (monitor release/volatile write).But then some variable write instructions can jump over the barrier and they may not be visible in read. So we need ordering guarantee also.

Now if we look into the ConcurrentHashMap source code, we see writes to volatile is happening at the end of put method and same volatile is being read first in get method. This is enforcing Visiblity and Ordering Guarantees which we needed in get method.

count is a volatile variable

V put(K key, int hash, V value, boolean onlyIfAbsent) {
lock();
try {
…
…
…
count = c; // write-volatile
}
return oldValue;
} finally {
unlock();
}
}

As you might have noticed in ConcurrentHashMap, method “put” sets count to a new value which is nothing but a volatile – write which will enforce a memory flush and also enforce ordering and no variable writes can move below it.


V get(Object key, int hash) {
if (count != 0) { // read-volatile
HashEntry e = getFirst(hash);


Now if you will see “get” method, we are reading value of count which is volatile-read.Which means whatever variables will be changed in put method will be visible in get method.

Once again reiterating According to Java Memory Model:
Writing to a volatile field has the same memory effect as a monitor release, and reading from a volatile field has the same memory effect as a monitor acquire.
Effectively, the semantics of volatile have been strengthened substantially, almost to the level of synchronization. Each read or write of a volatile field acts like “half” a synchronization, for purposes of visibility.

Performance Check:

Test Scenario:
1. 8 Threads writing/reading to a ConcurrentHashMap doing 100,000 operations

Ran the Test for ConcurrentHashMap and on a Modified ConcurrentHashMap where i removed count as a volatile and used locks in read method.

As you can see from the Chart that using volatile rather then a lock had significant performance improvements. So volatile if used smartly can be used to build highly performant concurrent application. Thanks to Doug Lea for showing us how volatile can be smartly used.

Another aspect of volatile which i wanted to explain:

A thumb rule which many of us believe is that volatiles make more sense when reads outnumber writes. However, I have always wondered if writes are more, does volatile still give us some benefits, so I thought I will try a test scenario where I vary write percentages and see how volatile performs when Writes outnumber Reads in comparison to synchronized, Locks and Atomic Variables.

Test Scenario:
1. 8 Threads doing 100,000 operations (read and write) on a Volatile,Synchronized,Atomic

As you can see from the Chart that it’s not true that Volatile should be only used when Reads outnumber Writes.

Source code of above tests can be downloaded from here.

Author: Apurba and Pavitar

A smarter brain than mine at work, pointed out this interesting article to me.
Java String Performance testing
It talks about string performance testing. I could make sense of most of the observations made in this test and thought of sharing it.

In short the test compares string operations like “+”, “new String” and then “+”, “+” with fields and then StringBuffer append. One of the conclusions of the test is

the ‘+’ operator is not evil when used with Strings

I agree with this statement and a look at the generate byte code pretty much convinces us of so. But, a word of caution here, it always makes sense to check this on our target compiler before committing to it.

Running through the examples, lets examine the first test “allPlusses”, the method uses constant strings, so the compiler is free to perform the operation before hand and work on the end result. For example if we look at the byte code generated for

String x = "0" + "1" + "2" + "3" + "4" + "5" + "6" + "7" + "8" + "9" ;

it is

LDC "0123456789"

So all the “+” operations are now replaced with a big string which is the end result of all those operations, this puts this test out of the same league for comparison. Had the code been something like

String x = counter + "1" + "2" + "3" + "4" + counter + "6" + "7" + "8" + "9" ;

where counter is a variable, the constant pool string would not have been this large and the plus operation would have been also forced to do some append operations. The byte would have been something like this

ILOAD 1
INVOKESTATIC java/lang/String.valueOf(I)Ljava/lang/String;
INVOKESPECIAL java/lang/StringBuilder.(Ljava/lang/String;)V
LDC "1"
INVOKEVIRTUAL java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lang/StringBuilder;

In this case the compiler was not smart enough to add all the other strings, since the variable x starts with another variable “counter”, but all the plus operations are being performed with StringBuilder.

Coming to “new String” usage, this gives the compiler the least amount of choice, the byte code looks something like

DUP
LDC "1"
INVOKESPECIAL java/lang/String.(Ljava/lang/String;)V
INVOKEVIRTUAL java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lang/StringBuilder;
NEW java/lang/String

In this case, we have to pay the overhead of creating the string and then doing the StringBuilder append, for brevity am not going in to what dup does.

Now between concatFields and stringBuffer methods, 1.5 introduced StringBuilder, so the compiler is smart enough to convert the

return f0 + f1 + f2 + f3+ f4 + f5 + f6 + f7 + f8 + f9;

into StringBuilder.append operations on 1.5. The byte code looks like

ALOAD 0
GETFIELD org/apurba/misc/TestStringPerformance.f1 : Ljava/lang/String;
INVOKEVIRTUAL java/lang/StringBuffer.append(Ljava/lang/String;)Ljava/lang/StringBuffer;


Since the 1.5 example was still using StringBuffer for stringBuffer method, it is not able to leverage this new class and lags behind so much on performance scales on 1.5. On 1.4 (checked only on jdk1.4.2_15) it was StringBuffer calls for “+” operations, so it was comparable with the stringBuffer() method on 1.4.

Another thing to notice is that we are using GETFIELD in contrast to LDC in other snippets, which could tilt the results in this direction at times. If the stringBuffer method were written with stringBuilder and field access, it would have been pretty much the same as the concatField method.

1. In short, “+” does do a decent job, assuming that the compiler optimizations are present which would convert the calls to StringBuilder append calls.
2. If it is “+” operations between constant strings, then it is even better than StringBuilder append calls.

We also have to understand that all these are dependent on the compiler optimizations and it is always best to test them before assuming it is true for our target vm. I checked on 1.4.2_15 and 1.5.0_06 and the ibm jdk 1.5 (IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3)) and these optimizations were present.

Author: Apurba

In this blog, I take a look at the query cache, well it is more than a cursory glance, would try to dive in some detail. The blog would explain some of the details of it (enough introduction, lets get to the meat).

As most of us already know, hibernate supports plugging in external cache providers for addressing certain aspects of performance. There are some very good articles on hibernate caching, some of which are
Understanding the second level and query cache
Chapter 19: Improving performance

Lets start with what we are trying to achieve by query cache. The intention is to cache the results against the query (the sql along with the parameters and their values). The effectiveness of the cache is determined to a large extent by its invalidation logic. The isolation level semantics that we want the cache to follow also impacts this logic. In this blog I will go over some of the these details and how it impacts some of the performance choices I need to make. Rather than detail the implementation logic, will run over some common scenarios explaining the implementation detail along the way.

Natural Key Lookups
A lot of heavily used data is cached at the second level. However, most of this data is looked up using its natural key, the second level cache however would store it using its primary key as the key, so we could go ahead and use the query cache to save this lookup. In an implementation like this, the query cache invalidation logic plays a huge role.

We have to understand that the query cache is leveraged by many other types of queries too, so the safest invalidation logic is to mantain update timestamps for each table. When any value is looked up from the query cache, we would also check if any of the tables involved in this query have been updated since the results were cached, if they were, the safest thing to do is query the db again. This is from a very simplistic point what hibernate does. It maintains the timestamps in the update timestamp cache. The query results are cached with the query as its key in the query cache.

The way the query cache maintains this values also impact our natural key lookup logic, since hibernate in its query cache disassembles the results and stores only the primary key for queries that return results of only one type, we also need to cache the entities with the natural key at the second level.

In simple words the way query cache would work in this scenario is something like

1. check query cache for the query
2. if results are found, check if they are uptodate (that is no entry in update timestamps table or one which predates the cache)
3. if they are assemble the object (assembling involves creating the object from its primary key or group of columns from their values or other strategies)

The thing to remember is that the invalidation logic is “timestamp per table” based, an update on any field of a particular table would invalidate the cache for all queries using this table. For this reason the query cache approach may not be a great fit for natural key queries. Hibernate does provide criteria queries which are much better suited to Natual Key, in case of Criteria keys, since we mention that the fields used are natural keys, hibernate query cache is smart enough to understand that we can bypass the uptodate check and depend on the assembling logic for handling it properly.

A smarter hql translation to support hints for the standard query cache for natural key logic or an inbuilt memoization approach that translates natural keys to primary keys and then queries would have been really handy for this type of work.

In the next set of blogs will try to get into the cache concurrency strategy and how it impacts us from a performance perspective.

Author: Fazal Gupta

This is a small article which explains the steps to register custom fonts with Apache FOP engine. Registering custom fonts with Apache FOP becomes important in the context of Internationalization, especially if one wants to display CJK languages in the PDF being generated. The context of this article is when fop is being used in other application for generating PDF for some XML data.

Step 1:
Install the required fonts to your OS. E.g. for Windows the fonts should be installed using the Control Panel or by copying the fonts to Windows Directory\Fonts.
If one is looking for Chinese/Korean Language, MS GOTHIC is a good font carrying a wide range of symbols.
The font can be in a standalone ttf (TrueType Font) file or a ttc (TrueType Collection)

Step 2:
Generate a font XML file that helps in registering the font with FOP engine. Fop.jar provides a TTFReader program to do this.
Example way to run the program
TTC Font: Java –classpath .\fop.jar org.apache.fop.fonts.apps.TTFReader –ttcname “DejaVu Sans” c:\windows\fonts\DejaVuSans.ttc dejavusans.xml
TTF Font: Java –classpath .\fop.jar org.apache.fop.fonts.apps.TTFReader c:\windows\fonts\DejaVuSans.ttf dejavusans.xml

Step 3:
Next we define a configuration file which JAVA program can read and update the FOP Configuration to use the new fonts along with the standard fonts available. The file is available in fop.jar named userConfig.xml.

Example structure of the configuration file

<font metrics-file=”file:///C:/ fonts/msgothic.xml” embed-file=”file:///C: /fonts/msgothic.ttc” kerning=”yes”>

<font-triplet name=”MSGothic” style=”italic” weight=”normal”/>

<font-triplet name=”MSGothic” style=”italic” weight=”bold”/>

<font-triplet name=”MSGothic” style=”normal” weight=”normal”/>

<font-triplet name=”MSGothic” style=”normal” weight=”bold”/>

</font>

The font name attribute in font-triplet tag should be taken from the font xml file.
If one uses fop program in a stand alone manner, one can use the userConfig.xml file to register the custom fonts there directly. The documentation of the XML file in fop.jar lists the usage of the custom file as follows
java org.apache.fop.apps.Fop -c userconfig.xml -fo fo-file -pdf pdf-file
If one directly modified the userConfig.xml one need not give the config file location.
But if one is using fop.jar in another application one may need to define an external xml file and make fop engine use the custom XML file as one may not invoke the fop program directly but use its API in turn. The custom XML file structure can be constructed by looking at userConfig.xml.

To achieve this, after generating the XML file, you can write the following piece of JAVA code to load the custom XML file and run the Apache engine to get the pdf byte stream
File userConfigFile = new File(configXmlLocation);
new org.apache.fop.apps.Options(userConfigFile);
ByteArrayInputStream xsl = new ByteArrayInputStream(inputByteArray);
ByteArrayOutputStream pdf = new ByteArrayOutputStream();
org.apache.fop.apps.Driver driver = new org.apache.fop.apps.Driver();
driver.setInputSource(new InputSource(xsl));
driver.setOutputStream(pdf);
driver.setRenderer(org.apache.fop.apps.Driver.RENDER_PDF);
driver.run();

That’s it. One can now write the xsl-fo file to use the new fonts mentioned and give to FOP to see the text in their desired fonts.