WebSocket met Java EE... - I

Introduction

Since last decade web has changed a lot. Now web applications are more responsive continuously talking to servers without reloading the whole page again. Technologies like Ajax is doing very good in this field. But there is always a question "What next?". WebSocket might be answer to that.
WebSocket is technology which provide full duplex communication channels over a single TCP connection. So in simple words, the client will open a TCP connection and start sending and receiving the data. All latest browsers support WebSocket. Now I want to jump to the part where Websocket met Java EE, if you want to read more about WebSocket here is Wiki Link.

WebSocket & Java EE

Java EE 7 is going to be first version which will officially add WebSocket as an option for developers. So here is the list of Ingredients required to write a simple WebSocket application:

1. Script file written in JavaScript
2. A POJO with WebSocket Annotations

Lets try to write a simple examples:

Example :

There are two annotations which will convert POJO to a webSocket.

1. WebSocketEndpoint - URL pattern along with some encoder and decoder information is defined using this annotation.
2. WebSocketMessage - method with this annotation is called to process the message and produce any response (if required)

On client side, WebSocket class has been introduced to JavaScript. To start communication with WebSocket, we need to create a new object of WebSocket and need to register few callback methods which will be called on different state of connection and messaging. 

Lets check how it looks like:

The code will produce following output:

So as soon as the page is loaded the browser will try to open WebSocket if WebSocket is opened successfully onOpen method will be called. Then user need to enter some Data in text box and click greet button. Then send method will be called to send the data to WebSocket. Then WebSocket will process the data (in our example sayHello method will process the message) and send back the message. As soon as the browser receives the message onMessage method will be invoked and desired operation will be performed.

In this screenshot I tried to capture the network communication using Google Chrome developers tools. You can clearly see there is single connection used again for all transmission.

Conclusion:

WebSocket are  very easy to implement using Java EE. As WebSocket is still under development  there might be few changes in official release. You can do more complex tasks using WebSocket by encoding and decoding the messages, I will try to cover that in my next blog. 

XPath and Java...

Introduction:

XPath is an XML technology which is used to retrieve element from XML documents. Since XML documents are structured, XPath expression can be used to locate and retrieve elements, attributes or value from XML files. XPath is similar to SQL in terms of retrieving data from XML but it has it’s own syntax and rules.
As XML is most widely used for data storage or data transfer. So we require XPath to quickly fetch data from bulky XMLs. So Java 5 introduced the javax.xml.xpath package to provide an engine and object-model independent XPath library. Among other products, Xalan 2.7 and Saxon 8 include an implementation of this library.

How it Works with Java:

Lets look at one example to understand it. Here is an XML with some books data.
We need to search all books of some specific author or specific publication. To achieve this we can write some parser and get the desired results but that seems to be a lot of work and there are chances when we have to rewrite code for small change in requirement. So here comes XPath in picture.

In Java, here are few simple steps to use XPath:
1. Get XPath object from XPathFactory:

            XPathFactory xPathfactory = XPathFactory.newInstance();
     XPath xpath = xPathfactory.newXPath();


2. Generate XPathExpression:
      XPathExpression expr = xpath.compile(xpathVal);

3. Evaluate XpathExpression:
      NodeList nl = (NodeList) expr.evaluate(doc, XPathConstants.NODESET);

       Evaluate method could return different datatype on basis of second Argument, Possible values are:

1. XPathConstants.NODESET
2. XPathConstants.NODE
3. XPathConstants.BOOLEAN
4. XPathConstants.NUMBER
5. XPathConstants.STRING

Here is example implementation for different cases:

Quick Tips:

• To filter the nodes on basis of  attribute value you can use [@attribute_name='attribute_value']
• To filter nodes on basis of child node use [node_name='node_value']
• To get only values in result use "text()" at the end
• To get the nodes in result use wildcard character "*", Wildcard can be used in between the expression as well.

References:

http://www.ibm.com/developerworks/library/x-javaxpathapi/index.html

Thread Pooling in Java - I

Introduction:

 "Every user wish for user fast and user friendly application"
To fulfill user's wish every programmer tries to write efficient programs. Then tries to optimize and re-optimize the code. But there comes the time when single thread processing can not provide faster results on same hardware configuration. There comes the necessity of multi-threading. So programmer decide to go for it but it comes with some challenges:

1. How many thread application should be able to create? If it will create too many thread, it might choke other process, if the thread count is too less, it might not provide user the desired experience. So what should be thread count in pool?
2. When to introduce thread? If we somehow come up with solution to first problem and decide the thread count for application/process then we need to decide when to create these threads. Shell we create all these thread in beginning or we do it on demand? But how to know when demand is high?
3. When thread should die? If we decide that thread should be created on demand basis, so what happens to the thread when demand decreases? How long should these thread wait in pool and consume system resources?
4. What happens to the tasks if application is not able to process them at certain point of time? Will these tasks be stored in memory, How many unprocessed task we want to keen in memory?

Solution:

 If you start to think about all these challenges, you will realize that you have to write good amount of code to overcome each one of them. Few years ago there was no choice but to write this type of code, but now Java concurrency package come up with generic solution (ThreadPoolExecutor) to these problems.
ThreadPoolExecutor receives following arguments :

• corePoolSize: the number of threads to keep in the pool, even if they are idle
• maximumPoolSize: the maximum number of threads to allow in the pool
• keepAliveTime: when the number of threads is greater than the core, this is the maximum time that excess idle threads will wait for new tasks before terminating.
• unit: the time unit for the keepAliveTime argument
• workQueue: the queue to use for holding tasks before they are executed. 

Here is one example implementation:

In this example, I informed application to start 2 threads and thread count could be increased to 4. If you submit 4 task at a time application is not going to start 4 threads at a time and finish all tasks at a time but will keep two tasks in queue and whenever any of these thread will be free it will pick up the process from queue. So when would be 4 threads running in parallel? In source code we have defined the size of task queue to 50. Lets consider the case when your queue already has 50 tasks and now you are trying to add another task in queue at this time new process will be created. So reducing the size of queue will result more number of threads in thread pool but it will create a risk of rejection of task if application hits it maximum capacity, so chose it wisely. You can use java profiling to check how many threads are created and when these threads are created.
Here is snapshot of thread profile for execution of the program when workQueue size reduced to 6.

 In this snapshot we can see that the thread-3&4 created when system hit by more requests then workQueue size. This snapshot also show that the thread-3&4 died after waiting 30 ms.


References:
http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html

Java Collections - Synchronization Myth

Introduction:

Java community tried to reduce developers pain by adding synchronization mechanism for various java collections. There are 6 flavors of API available which could help developers to synchronize different java collections. Here is the list of API:

• Collections.synchronizedList()
• Collections.synchronizedCollection()
• Collections.synchronizedMap()
• Collections.synchronizedSet()
• Collections.synchronizedSortedMap()
• Collections.synchronizedSortedSet()

The collections returned by these methods are capable to handle synchronization for basic operations on collections e.g. get(), set(), add(), remove() etc.

The Myth:

As soon as  developers synchronize their objects using synchronization APIs, they start to believe that they need to put more code to deal with synchronization for these objects, which is not true for all cases. Let me demonstrate this with simple example.

"An ArrayList Need to be accessed by two different threads, One thread need to iterate over list and other will try to add few new entries"

Here is threads detail:

• t1 : This thread uses Iterator to traverse through the list
• t2 : This thread uses for loop with index based approach
• t3 : This thread uses Iterator with sync block to traverse through the list
• t4 : This thread will try to add new entries in the list.

Source Code:

I tried to execute code in different combinations:

case1:

Use t1 and t4. Start both threads. 

"ConcurrentModificationException" will be thrown.

 

case2:

Use t2 and t4. Start both threads. 

Successful execution with concurrently updating the list.

 

case3:

User t3 and t4. Start both threads. 

Successful execution with no concurrent update.

Conclusion:  

Developers need to be careful about synchronization even if collections has been synchronized using Collections API.

Efficient Logging in Java

Logging is very important part of any programming language. It gives important information to developers to understand the program behavior. Its almost next to impossible to debug issues without logs. So logs are very important but logging itself is overhead for any program. It shares valuable CPU time, consume program memory, perform I/O operations. So Logs are necessary evils. 

Various logging framework provide various techniques to reduce these overhead. Common techniques to improve performance

• Configuration Techniques
• Set default logging level to Severe
• On demand enable Logging for specific module
• Programming Techniques
• Use discretion while putting log level for evey log
• Check log level before processing logging command

Recently I come across some other ways to improve logging efficiency. I tried to run few tests around them. Here is test case result:

Test Code using "java.util.logging.Logger"
Test Results "java.util.logging.Logger"
Test Results "java.util.logging.Logger"
Test Code using "org.apache.logging.log4j.Logger"
Test Results "org.apache.logging.log4j.Logger"

Conclusion: 

1. Apache Logger is more efficient in logging than java default logger.
2. String concatenation technique in less efficient than new placeholder technique. [But for log4j placeholder technique is available in  log4j 2.0 only.]
3. Its very efficient to check log level before logging command for dynamic logs [The logs which require string concatenation or placing values in placeholders ]
4. Its inefficient to check log level before logging command for simple/static logs.

Reference:
http://logging.apache.org/log4j/2.x/performance.html