From Java to Java EE

Wildfly and Resteasy are missing support for FastInfoset collection and map...

2014-06-04T11:43:00.001+02:00

so, if you have a REST resource returning a java.util.List or a java.util.Map, like:


@Path("people")
@Produces({"application/fastinfoset"})
@Consumes({"*/*"})
public class SomeResource {
  
  @GET
  public List<SomeType> getAll() {
  ...
    
  // and / or

  @GET
  @Path("/map")
  public Map<String, SomeType> getMap() {
  ...

and you try to access it (e.g. curl -H "Accept: application/fastinfoset" http://localhost:8080/.../resources/map) you will see

Could not find MessageBodyWriter for response object of type: java.util.ArrayList of media type: application/fastinfoset

Could not find MessageBodyWriter for response object of type: java.util.LinkedHashMap of media type: application/fastinfoset Unfortunately Resteasy "forgot" to implement two following classes:


@Provider
@Consumes("application/*+fastinfoset")
@Produces("application/*+fastinfoset")
public class FastInfosetCollectionProvider extends org.jboss.resteasy.plugins.providers.jaxb.CollectionProvider {
  @Override
  protected boolean suppressExpandEntityExpansion() {
    return false;
  }
}


@Provider
@Consumes("application/*+fastinfoset")
@Produces("application/*+fastinfoset")
public class FastInfosetMapProvider extends org.jboss.resteasy.plugins.providers.jaxb.MapProvider {
  @Override
  protected boolean suppressExpandEntityExpansion() {
    return false;
  }
}

I already sent my pull request, but in case it is never merged, you just have to provide two classes I showed above to make it work.

How to convert broken FastInfoset stream into XML?

2014-05-27T10:29:00.001+02:00

Have you ever received a broken FastInfoset (FI) stream? Or maybe, your logging infrastructure is truncating the logs so FI messages are incomplete? If you try this piece of code:


import java.io.IOException;

import org.xml.sax.InputSource;
import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;

import com.sun.org.apache.xml.internal.serialize.OutputFormat;
import com.sun.org.apache.xml.internal.serialize.XMLSerializer;
import com.sun.org.apache.xml.internal.serializer.Method;
import com.sun.xml.internal.fastinfoset.sax.SAXDocumentParser;

public class FiDecoder {

  public static void main(String[] args) throws IOException, SAXException {
    XMLReader saxReader = new SAXDocumentParser();
    OutputFormat format = new OutputFormat(Method.XML, null, false);
    format.setOmitXMLDeclaration(true);
    XMLSerializer handler = new XMLSerializer(System.out, format);
    saxReader.setContentHandler(handler);
    saxReader.parse(new InputSource(System.in));
  }
}

on a broken FI stream (e.g. PersonMap-broken.fi) you will see just an exception, no XML in the standard output. The problem is that the internal buffer hold by XMLSerializer has not been flushed yet and in case of error it is just dropped. It's a problem for small FI documents where buffer has no chance to be filled up before EOF or invalid FI character. Fortunately there is a simple solution. You just need to extend XMLSerializer and handle error case correctly:


import java.io.IOException;
import java.io.PrintStream;

import org.xml.sax.ErrorHandler;
import org.xml.sax.SAXException;
import org.xml.sax.SAXParseException;

import com.sun.org.apache.xml.internal.serialize.OutputFormat;
import com.sun.org.apache.xml.internal.serialize.XMLSerializer;

public class XmlAutoFlushHandler extends XMLSerializer implements ErrorHandler {

  public XmlAutoFlushHandler(PrintStream out, OutputFormat format) {
    super(out, format);
  }
  
  @Override
  public void fatalError(SAXParseException exception) throws SAXException {
    try {
      _printer.flush();
    } catch (IOException e) {
      throw new IllegalStateException("unable to flush the stream", e);
    }
  }

  //remainder omitted
}

Finally you have to slightly modify FiDecoder class:


    XmlAutoFlushHandler handler = new XmlAutoFlushHandler(System.out, format);
    saxReader.setContentHandler(handler);
    saxReader.setErrorHandler(handler);
    try {
      saxReader.parse(new InputSource(System.in));
    } catch (IOException | SAXException e) {
      // I don't care
    }

Done! Now when you try PersonMap-broken.fi, you will see incomplete XML (which is correct) and no exception.

CXF / Spring integration using @Configuration annotation

2013-12-09T17:00:00.000+01:00

If you develop JAX-WS services and run outside of Java EE container (that supports e.g. @WebService annotation) you probably use Apache CXF. If you want to integrate your services with CDI (again, outside of Java EE container), you probably use CXF / Spring integration - http://cxf.apache.org/docs/writing-a-service-with-spring.html

This works fine, but the problem is if you want to use exclusively annotations and you don't use XML-base Spring configuration.

There is a solution - so far my own: https://issues.apache.org/jira/browse/CXF-5448 but I opened a discussion on CXF dev mailing list to check if it could be integrated in CXF source code: mail thread

If you have another solution, comments or feedback please use CXF dev list.

Lombok - cool stuff, worth trying!

2012-08-01T11:48:00.000+02:00

A friend of mine just shared with me Project Lombok (weird name but I guessed correctly that it's something Thai ;) As I understand the goal of this project is to minimize boilerplate Java code (like getters, setters, constructors, etc.) Very good idea!

The only question that bothers me is if it's easily possible to override any behavior (e.g. setters) without the need of resigning from Lombok auto-generatin for the rest of class' elements...

Anyway - it's really worth trying!

Byteman - use it when Mockito can't help

2012-03-07T10:06:00.000+01:00

Byteman is a really cool stuff with which you could simulate JVM or OS behavior hardly possible to mock using mocking library (like Mockito). Read the full exaple (really short with no fluff) here: http://theholyjava.wordpress.com/2012/02/25/cool-tools-fault-injection-into-unit-tests-with-jboss-byteman-easier-testing-of-error-handling/

Errata to Maven2 → Maven3 migration

2012-01-05T14:11:00.005+01:00

In the section Cobertura plugin and Maven3 of "Maven2 → Maven3 migration - real life example" article I made a mistake that resulted in reporting a bug that does not exist.


  
    package
    
      clean
      check

should be changed to:


  
    clean
    clean
    
      clean
    
  
  
    package
    package
    
      check

Both goals instrument and check must never be in the same execution because check depends on instrument and calls it itself. So, in my example goal instrument was executed twice every time and it cause a lot of problems - many of them are still magic for me e.g. compilation error saying that ...HasBeenInstrumented class cannot be identified blah, blah, blah, even though "buggy" source code was untouched and did not use this Cobertura class. Anyway MCOBERTURA-155 is a non-issue.

Maven2 → Maven3 migration - real life example

2011-12-15T10:43:00.005+01:00

Couple of months after JDK 7 release I decided to update my projects to build on both new JDK and Maven3 (Maven2 previously). From JDK 7 I was expecting nothing new as the codebase of our projects should be migrated step by step as soon as the Ops start supporting new application servers that could run on Java 7. More important things were expected from Maven3, namely we wanted to shorten build time, that we already optimized by 20% using Maven2 by smart initialization of our unit tests (but that's another story). In this post I will explain what I had to change to make this happen.

Status quo ante

Our projects have pretty standard build options, no homemade plugins or execution paths, etc. Just couple of standard plugins with standard configuration.

During each build of multi-project Maven setup, Jenkins (currently 1.422) runs additionally CheckStyle, Cobertura and FindBugs plugins. CheckStyle and Cobertura are actually run twice, once during package to see if nobody wrote any crap, and second time during reports generation.

After the reports are generated everything travels to our projects website (run on Tomcat) via WebDAV protocol (oh, yeah! good old WebDAV).

Every time someone commits a change Jenkins runs mvn -e --batch-mode clean package site-deploy and we're all happy.

First run

Ok, let's change to Maven3 now. It should be easy. This is what I thought - "just change MAVEN_HOME and run the same stuff i.e. mvn ...". Well, ... it worked but besides couple of warnings it did not finish successfully.

Warnings, first (they are easy): Maven3 does not like if you don't provide version with plugin group and artifact ID, so this was my first change. I found all newest stable versions of plugins we use and added <version> tag everywhere.

Warnings disappeared but I still had errors. CheckStyle and Cobertura plugins were reporting style and coverage errors. It means that plugins were not configured correctly because they were executed but they did not load our settings.

Main problem was that in our pom.xml we defined that we want to use plugins within:

...

section but the configuration was set in <reporting> section.
This caused Maven3 not to read plugin setup during the build - and as I mentioned before we do check the style and code coverage during the build, not only during the report generation.

Fixing the build for Maven3

In Maven3 if you want to have some specific configuration to be take in to account during the build you have to put it in the <build> section. If you want the same config to be take into account during report generation you have to copy-paste it into <reporting> section, simple.

Cobertura plugin and Maven3
The biggest change had to be applied to Cobertura. In my Maven2 pom.xml we had:


  
    package
    
      clean
      check

and it had to be changed to: (not valid, see errata)


  
    clean
    clean
    
      clean
    
  
  
    package
    package
    
      instrument
      check

but... it did not solve all of the issues...

Cobertura plugin v2.5.1 bug in Maven3
(not valid, see errata
Cobertura plugin has some problems with Maven3 that were not present in Maven2 - check my bug report in Cobertura Maven Plugin JIRA site: MCOBERTURA-155
I provided a patch with workaround that works for me.

After all of these changes I was able to run mvn clean package Yeah!

Maven3 = site-deploy 3.0

Another warning I saw during the build was Maven3 asking to use maven-site-plugin version 3.x. Let's start with the fact that I had to add the following in the <build><plugins> section:


  org.apache.maven.plugins
  maven-site-plugin
  3.0

I had some problems generating the site but they seem to disappeared automagically so I will ignore them.

Maven3 = No WebDAV support

In each of our pom.xml we have the following:


  
    artifactory.internal
    Internal Release Repository
    dav:http://${artifactory}/libs-releases/
  
  
    website
    dav:${project.url}

Everything is ok but note the protocol i.e. dav:. It is not supported out-of-the-box in Maven3, so you have to add and extension in the <build> section:


    
      org.apache.maven.wagon
      wagon-webdav-jackrabbit
      2.1

Side-effect changes

As a side effect I updated Jenkins CI to the newest version 1.422, and also Artifactory to version 2.4.2.

Was it worth?

I spent one whole day on this migration but it was worth IMHO. For all the migrated projects we saw build time saving from 25% up to 45% (!!!) depending on the size of the project (of course, you may notice different figures).

Before the change our projects were built using JDK 1.6.0_23 and Maven 2.2.1, after the change we use JDK 1.7.0_1 and Maven 3.0.3.

I'm pretty happy with the change, and you?

FW: Garbage collection in HotSpot JVM

2011-12-05T08:04:00.004+01:00

There is an excellent new post from Alexey Ragozin on JVM Garbage Collector:
http://www.dzone.com/links/r/garbage_collection_in_hotspot_jvm.html.
He posted almost all basics you should know about different types of GCs, how to enable them in HotSpot JVM and most importantly when to enable them.

Just go there and read it!

HotSpot (64bit server) hangs on socket read (JVM 1.7 bug?) - updated

2011-11-25T09:43:00.006+01:00

Picture (c) Clker.com

Few days ago I started working on some maven-based project (Java 1.7.0) on my new laptop (with Windows 7 64bit installed) and I noticed that very often Maven 3 was stuck downloading JARs from the internet even though my internet connection was fine. I started investigating this issue and after checking thread dump and binary dump (DMP) I think I found a bug in HotSpot for 64bit Windows.

It's quite strange but any Java application using java.net.DualStackPlainSocketImpl (from rt.jar) class - JVM hangs on native socket0(boolean stream, boolean v6Only) method.

Here is an excerpt from the thread dump from my problematic Java app:

"main" prio=6 tid=0x0000000001d3b000 nid=0x6ec runnable [0x00000000020df000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
- locked <0x00000000eb31e490> (a java.io.BufferedInputStream)
at sun.net.www.MeteredStream.read(MeteredStream.java:134)
- locked <0x00000000eb321280> (a sun.net.www.http.KeepAliveStream)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2968)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
- locked <0x00000000eb2fcc08> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at io.DownloadJar.main(DownloadJar.java:20)

Locked ownable synchronizers:
- None

This is what I got from Win Debug Diagnostic Tool when I analyzed full memory / process image:

The following threads in java.dmp are waiting on data to be returned from another server via WinSock.

The call to WinSock originated from net!Java_java_net_SocketInputStream_socketRead0+160 ( 1 ) 5,56% of threads blocked

Ensure that any remote server this application may be calling is functioning properly and there are no network issues between the two servers. If the problem continues, please contact the application vendor for further assistance

Below you can find a source code of this simple app causing the problem (imports omitted):

// netty-3.2.6.Final.jar from maven repository
URL url = new URL("http://tinyurl.com/cg43cju");
try (BufferedInputStream in = new BufferedInputStream(url.openStream());
    BufferedOutputStream out = new BufferedOutputStream(new FileOutputStream("netty.jar"))) {
   
 byte[] buf = new byte[2048];
 int len = 0;
 int total = 0;
 while ((len = in.read(buf)) > -1) {
  total += len;
  System.out.println(total / 1024 + "KB");
  out.write(buf, 0, len);
 }
} catch (IOException e) {
 e.printStackTrace();
}

This problem occurs very often (almost every time) and it's quite easy to reproduce (at least on my machine).

You would suggest to check my internet connection but it's fine. I'm able to download this JAR (or anything else) with no problems at all.

What is EXTREMELY weird is that if I run the very same byte code on HotSpot installed on Ubuntu that runs on VirtualBox on my Windows, it WORKS FINE 100% of time. WTF? I think it proves there is no problem with my network interface or connection but with HotSpot implementation for 64bit Windows?

If you encountered problems like this and know how to fix it, please let me know.

BTW. I already posted a bug report to Oracle but it's pending - I will provide a link here when it becomes public.

UPDATE
Bug link: 7115226

GC and preformance tuning for Tomcat (from VMware)

2011-11-23T08:09:00.002+01:00

Coming back to my previous post "Beware of your GC": just yesterday Daniel Mikusa from VMware published his post "Performance Tuning the JVM for Running Apache Tomcat" which adds some more interesting information complementing my post. You could find "Selecting a Collector" section specifically interesting e.g.:

When you specify the option to run the concurrent collector, it is important to realize that garbage collection will happen concurrently with the application. This means that garbage collection will consume some of the processor resources that would have otherwise been available to the application. On systems with a large number of processors, this is typically not a problem. However, if your system has only one or two processors then you will likely want to enable the -XX:+CMSIncrementalMode option. This option enables incremental mode for the collector, which instructs the collector to periodically yield the processor back to the application and essentially prevents the collector from running for too long.

Enjoy!

Be aware of your GC

2011-11-18T17:00:00.006+01:00

When you're learning Java and later developing your applications you usually tend to not to worry about the memory management - we have garbage collector after all, so what's to worry about. Surprisingly you should worry about memory in your Java applications as it's not that difficult to introduce memory leak after all. You should worry about memory also in order to minimize pause time GC infers, and to use CPU to process your client's requests instead of cleaning your memory. It all depends on your non-functional requirements of latency, throughput, etc. (which can be tuned with some VM settings, not changing any applicative code)

There are two (at least) perspectives of memory management and GC in Java:

1.	You should be careful while developing you application and make sure not to cache any objects. In other words do not be afraid of using `new` in Java - creating objects in Java is extremely fast and cheap (e.g. comparing to C++) as physical memory is already allocated - more in http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html short article
2.	You should be aware of GC tuning options that can match your concrete application - and this is what I will address in this post.

Usually you have two options while tuning GC: either you limit number of global collections (young + tenured generations), or limit max pause of garbage collection (thus increasing number of collections). You have plenty of options and quite exhaustive list can be found at Alexey Ragozin Blog

You should start analyzing your application under heavy load by enabling GC logging first:

-Xloggc:/opt/java/logs/gc.log
-verbose:gc

After running your application (Server HotSpot 1.6.0_23-b05) you should see at least one line like this:

8.847: [GC 138240K->4866K(501248K), 0.0148485 secs]

which says that 8.8 sec after VM startup there was a young generation collection that freed memory from 138240K used to 4866K with total mem available of 501248K and that garbage collection took ~15ms.

I recommend you adding also two following VM options:

-XX:+PrintGCDetails
-XX:+PrintGCDateStamps

that will result in such GC log line:
2011-11-18T16:36:04.513+0100: -0.813: [GC [PSYoungGen: 13824K->1376K(16128K)] 13824K->1376K(48896K), 0.0030416 secs] [Times: user=0.05 sys=0.01, real=0.02 secs]
Here you basically have more details about what happened i.e. that young generation was collected indeed and more importantly you have timestamps that are critical if you're running GC logs in production environment and simply time elapsed from VM startup says absolutely nothing.

When you start some heavy load of your application GC log might start looking more like this:
2011-11-18T16:37:51.472+0100: 99.088: [GC [PSYoungGen: 17338K->573K(17600K)] 49913K->33167K(50368K), 0.0011993 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 2011-11-18T16:37:51.800+0100: 100.780: [GC [PSYoungGen: 17341K->547K(17600K)] 49935K->33165K(50368K), -1.3929204 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 2011-11-18T16:37:52.097+0100: 99.670: [GC [PSYoungGen: 17315K->512K(17664K)] 49933K->33193K(50432K), 0.0011831 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 2011-11-18T16:37:52.097+0100: 99.671: [Full GC [PSYoungGen: 512K->0K(17664K)] [PSOldGen: 32680K->13582K(32768K)] 33193K->13582K(50432K) [PSPermGen: 29382K->29382K(58880K)], 1.5108144 secs] [Times: user=0.11 sys=0.00, real=0.13 secs] 2011-11-18T16:37:52.503+0100: 100.066: [GC [PSYoungGen: 16896K->557K(17664K)] 30478K->14140K(50432K), 0.0015381 secs] [Times: user=0.05 sys=0.00, real=0.02 secs] 2011-11-18T16:37:52.800+0100: 100.337: [GC [PSYoungGen: 17453K->501K(17664K)] 31036K->14188K(50432K), 0.0011944 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 2011-11-18T16:37:53.206+0100: 100.656: [GC [PSYoungGen: 17397K->402K(17344K)] 31084K->14117K(50112K), 0.0009709 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
You can notice that on 99.671 sec from the VM startup there was a Full GC executed. It means that the old generation was full.

Now it's time for you to play with some settings like -XX:NewSize, -XX:MaxNewSize, -XX:SurvivorRatio and others to see what's the best compromise between the max pause time and the number of GC pauses.

It's also time to play with different types of GC. You still have to test -XX:+UseConcMarkSweepGC, -XX:+UseParNewGC and -XX:+UseG1GC. Be careful with the last option as if you use JVM version 6.x you have to combine it together with -XX:+UnlockExperimentalVMOptions as "Garbage-First Garbage Collector (or G1 GC for short) is a new GC that is being introduced in the Java HotSpot VM in JDK 7. An experimental version of G1 has also been released in Java SE 6 Update 14. G1 is the long-term replacement for HotSpot's low-latency Concurrent Mark-Sweep GC (widely referred to as CMS)".

IMPORTANT: there is no golden formula for correct and optimal settings / GC implementation. It really depends on your application (sometimes you would need to re-implement some parts to help GC), traffic, given memory (remember than on 32-bit machines max heap size is 4GB and it could be insufficient for some applications), number of cores, etc. But most of all it's your application that drives GC behavior. Be careful and optimize your GC setting with production settings, not to have unpleasant surprises on launch date :)

Note on HotSpot's GC on Windows: it sucks because many times I can get negative GC time in logs like '-1.3917690 secs' which is not very helpful for analysis. After some playing with GC logs I'm not sure times given there can be trusted at all - what a pity.

In the next post I will explain what monitoring / analyzing tools you can use to monitor you application in runtime as well analyze GC logs offline.

Java 7 - it's here

2011-07-29T14:50:00.005+02:00

JDK 7 is finally out...

2011-07-22T08:10:00.002+02:00

...well, not yet but it will be in few days (Oracle Announces Release Date for Java 7). After Wikipedia "Java 7 (codename Dolphin) is an upcoming major update to Java, it has been launched on July 7 of 2011 and will be made available on July 28, 2011."

Here's the list of new features Java 7 will bring (consult JDK 7 project page for more details):

Features are listed in order, more or less, from lowest to highest in the overall JDK software stack.

vm	JSR 292: Support for dynamically-typed languages (InvokeDynamic)
	Strict class-file checking
lang	JSR 334: Small language enhancements (Project Coin)
core	Upgrade class-loader architecture
	Method to close a URLClassLoader
	Concurrency and collections updates (jsr166y)
i18n	Unicode 6.0
	Locale enhancement
	Separate user locale and user-interface locale
ionet	JSR 203: More new I/O APIs for the Java platform (NIO.2)
	NIO.2 filesystem provider for zip/jar archives
	SCTP (Stream Control Transmission Protocol)
	SDP (Sockets Direct Protocol)
	Use the Windows Vista IPv6 stack
	TLS 1.2
sec	Elliptic-curve cryptography (ECC)
jdbc	JDBC 4.1
client	XRender pipeline for Java 2D
	Create new platform APIs for 6u10 graphics features
	Nimbus look-and-feel for Swing
	Swing JLayer component
	Gervill sound synthesizer [NEW]
web	Update the XML stack
mgmt	Enhanced MBeans

For me one of the most interesting changes are "Small language enhancements" that come from project Coin.
The goal of Project Coin is to determine what set of small
language changes should be added to JDK 7. That list is:

Strings in switch
Binary integral literals and underscores in numeric literals
Multi-catch and more precise rethrow
Improved type inference for generic instance creation
(diamond)
try-with-resources statement
Simplified varargs method invocation

All Java developers have waited for this moment since December 2006 when JDK 6 was released. It was the longest and the most painful release in Java history. It took almost five years to do it while for previous versions the period between releases was more or less two years. Of course, five years waiting for new Java was the effect of many factors like problems of Sun (eventually bought by Oracle), making JDK an open source project and thus opening a pandora's box of non-open source licenses, etc.

But it's finally here.

Now we'll wait for JDK 8 with lambda expressions that were supposed to be delivered in version 7 but actually it's good that JDK guys decided to postpone some features to finally release it.

Enjoy and celebrate the new JDK 7.

JBoss AS 5 Performance Tuning - book review

2011-03-13T15:44:00.005+01:00

Picture (c) Packt Publishing

Some time ago I received a new book from Packt Publishing i.e. "JBoss AS 5 Performance Tuning". This book couldn't reach me at a better time - few weeks ago my team was also releasing a new software, web application deployed in JBoss 5.x. Let me just write that this books was very useful in this critical time.

Before I start let me just mention that I’m experienced Java and Java EE developer and have worked with JBoss server before. This means that I know how to develop, deploy and monitor web applications in this application server. I also know how to monitor, profile and tune memory as well as performance using JMeter, VisualVM and VisualGC. Despite that, this book gave me even more detailed information and knowledge. With this book I was able to take another look at Java Virtual Machine settings, Garbage Collector settings as well as more advanced JBoss settings.

Let’s start the review here - first of all I’d like to say that the author Francesco Marchioni met my expectations about this book. You can really learn how to monitor and tune JVM, GC and JBoss but you will not learn how to write good and stable Java EE applications. This book is for people who want to know how to find memory leaks, performance bottlenecks, weak points in their applications, how to fix them programatically as well as with help of settings on different levels. You can easily check all topics covered by this book here Table of Contents.

"JBoss AS 5 Performance Tuning" is a very useful and pragmatic book. Francesco uses the same standard (open source/ free) tools as most of Java developers i.e. VisualVM, VisualGC, JMeter and Eclipse Test and Performance Tools Platform (TPTP). He explains why and how to use them and gives concrete examples.

You can read this book from cover to cover or just use it as an encyclopedia and read only the chapters you think could be useful for you. I have to mention a very important information here. Even though this book is named "JBoss AS 5 ..." it is very useful even if you use any other application/web server. Some of the chapters will be useless (especially those dedicated for JBoss ;) but many information in this book is very generic to the Java EE platform.

This book is for experienced Java developers and architects but also for developers who would like to think out of their programming box and to see what problems their code might cause in production and how to solve them and avoid similar issues in the future. You can spend a lot of money for professional training on this subject but maybe you should buy this book before to learn techniques and ideas presented by Francesco.

What I like and don't like at the same time in this book is that the language is quite "hard-core". It means that you really need to spend couple of years developing and deploying production code before you can take this book in your hands. This limits the potential audience significantly but on the other hand limits the size of the book as the author does not have to (or want to) explain every little detail that you as a Java developer should know.

To summarize I think "JBoss AS 5 Performance Tuning" is a really good book one and meets the goals set but the author in 100%. This book is definitely worth it's price as by reading it and applying knowledge from it you could save a lot of money spent for unnecessary hardware resources that could become redundant after correctly tuning JVM/JBoss or you application.

Good job guys - I like this book!

Java Best Practices – Vector vs ArrayList vs HashSet

2010-08-18T08:24:00.001+02:00

Interesting article on Java ArrayList, Vector and HashSet performance comparison:

Java Code Geeks: Java Best Practices – Vector vs ArrayList vs HashSet

Do NOT write books this way! "Wicket in Action" case.

2010-05-07T12:53:00.000+02:00

I've been just reading quite a good book on Apache Wicket from Martijn Dashorst and Eelco Hillenius and I got really pissed off at some point. I've always loved "... in Action" series because of its language, attitude to teaching the subject and quality of the material. I've had the same feelings with current book i.e. "Wicket in Action" until page 219 where authors were presenting advanced custom component creation and under one of the listings they wrote: "an elaborate explanation of it (the listing) is outside the scope of this book". WTF?

How can a writer put something like this in his book? If you think the example is too difficult for the scope of current book don't show it at all! You could also redirect readers to the other resources like: "detailed explanation of this concept can be found at ...". But writing "an elaborate explanation of it is outside the scope of this book" is just stupid and frivolous! I pay for the book to have explanations of difficult and complicated subjects - not to read that it's out of the scope (show external resources!).

Anyway, the book is quite good, but more and more examples in the second half of it are getting blur and need more explanations (maybe better metaphor than a bit artificial "lasagne"?)

I hope the authors will make an effort and upgrade the content of this book to the newest Wicket release 1.4.x that introduced Java generics and refactored many classes (e.g. validators).

When multithreading / multitasking your application doesn't help...

2010-04-26T13:57:00.011+02:00

Last week we spotted some behaviors of our system that could be improved significantly. In some specific cases our system is sending multiple independent requests to the underlying subsystems and it is sending them sequentially i.e. is waiting for the first response before sending second request etc. This would not be any problem if this specific processing didn't take more than 30 seconds (which is our system's hard timeout).

First thought was to send all the independent requests simultaneously and to collect responses. This way if each request / response action takes 5 seconds and we have 10 such actions we could get all responses in ~5 seconds, not in over 50. Assumption here is that such processing will take utmost only the time necessary for the longest task to complete. Of course ~5 seconds also depends on thread creation / allocation from the pool overhead but usually could be neglected (we assume that this time is at least order of magnitude lower than time necessary for task to complete).

The best overview of the problem and the solution I'm writing here can be found in my older post Combining Callable or Runnable with Future and FutureTask:

List<String> urls = new ArrayList<String>() {{
  add("http://www.java2jee.blogspot.com");
  add("http://www.yahoo.com");
  add("http://www.msdn.com");
  add("http://c2.com/xp/ExtremeProgrammingRoadmap.html");
  add("http://apache.org/");
  add("http://sourceforge.net/");
}};
List<Future<Integer>> futures = 
  new ArrayList<Future<Integer>>(urls.size());

final ExecutorService service = 
  Executors.newFixedThreadPool(1);

long start = System.nanoTime();
for (String url : urls) {
  // compile error - create this task first
  futures.add(service.submit(new ProcessUrlTask(url)));
}

long result = 0;
for (Future<Integer> future : futures) {
  result += future.get();
}

If you manipulate number of threads Executors.newFixedThreadPool(1) you will see performance boost - default value 1 means that all URLs are processed sequentially.

Coming back to our system - I basically did the same, I created shared thread pool, processing task that was sending request and was waiting for the response, updated unit tests (actually nothing changed here). What was my surprise when I discovered that this "improvement" actually didn't have any effect! Processing time was the same even though thread creation took ~0ms:

16:34:04,738 DEBUG[pool-19-thread-5] ...
16:34:04,741 DEBUG[pool-19-thread-2] ...
16:34:04,741 DEBUG[pool-19-thread-8] ...
16:34:04,741 DEBUG[pool-19-thread-7] ...
16:34:04,741 DEBUG[pool-19-thread-3] ...
16:34:04,741 DEBUG[pool-19-thread-6] ...
16:34:04,741 DEBUG[pool-19-thread-1] ...
16:34:04,741 DEBUG[pool-19-thread-4] ...

The detail I haven't mentioned yet is that messages that were supposed to be sent in multiple threads were sent using fancy middleware Java library our team doesn't develop. But more about it later...

My improvement sucks because it didn't shorten time necessary for request processing - still didn't know why. So, I started my local Tomcat, sent original SOAP request and watched the logs. What I spotted was in fact sequential message send / receive behavior. How is it possible if messages were being sent from different threads? There must be some lock in the middleware library!
This was not so sure and I needed proof before communicating anything to the management. I used my secret weapon i.e. Visual VM. In fact I connected to the JVM on which Tomcat server was running and started the test again. During the test I dumped threads and here's what I got:

Full thread dump Java HotSpot(TM) Server VM (14.2-b01 mixed mode):

"pool-2-thread-8" prio=6 tid=0x289ab000 nid=0x1690 in Object.wait() [0x2a92f000]
   java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on <0x25c34b78> (a java.lang.Object)
 at java.lang.Object.wait(Object.java:485)
 at company.utils.Mutex.lock(Mutex.java:41)
 - locked <0x25c34b78> (a java.lang.Object)
 ...
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619)

   Locked ownable synchronizers:
 - <0x24ecfea0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

"pool-2-thread-7" prio=6 tid=0x29913400 nid=0x1670 in Object.wait() [0x2a8df000]
   java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on <0x24fa2558> (a company.lib.Transaction)
 at java.lang.Object.wait(Object.java:485)
 at company.lib.Transaction.waitForCompletion(Transaction.java:530)
 - locked <0x24fa2558> (a company.lib.Transaction)
 ...
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
 at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:619)

   Locked ownable synchronizers:
 - <0x24ecfb50> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

"pool-2-thread-6" prio=6 tid=0x293ffc00 nid=0x1674 in Object.wait() [0x2a88f000]
   java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on <0x25c34b78> (a java.lang.Object)
 at java.lang.Object.wait(Object.java:485)
 at company.utils.Mutex.lock(Mutex.java:41)
 - locked <0x25c34b78> (a java.lang.Object)

... remainder omitted

Conclusions: middleware library used to send messages is "queuing" all the messages - if I can write "queue" about basic Java monitor lock (inside company.utils.Mutex.lock() method):

synchronized(lock) {
 while(locked) {
   lock.wait();
 } 
 locked = true;
}

And the lock was the current session object - it means that if I want to use 5 different threads to send messages simultaneously I have to create 5 different sessions (which in turn means that I have to log in to the system five times with the same credentials). This is additional memory and performance overhead we can't accept at this time. Not to mention our questions why session in this middleware does not allow us to send messages from many threads at the same time?

At this moment we abandoned improving this part of the system - it's hardly possible with current middleware implementation.

How to create Mylyn Connector Plugin - part 1

2010-03-08T13:00:00.004+01:00

Quite recently I struggled with my company's internal bug tracker, especially lack of Mylyn integration in Eclipse. The easiest way to make it work was just to develop it :) I started with Mylyn/Integrator Reference but as usual Eclipse documentation sucks (I used to develop a lot of SWT/JFace applications and the best documentation I found was outside of Eclipse). It's too short, too shallow and most of all written by/to people who knows Mylyn APIs and architecture quite well. As far as I understand someone who wants just to integrate Mylyn with some bug tracker doesn't have to have this kind of knowledge, but I also understand that Mylyn guys don't really have time for stuff like this.

Anyway, I also found very short tutorial (http://jvliet.blogspot.com/2007/02/creating-mylar-connector-plugin-for.html) explaining in a bit more details how to create Eclipse PDT project etc. But this tutorial doesn't explain all the tiny details that made me spend many hours wondering HTF it should all work together.

In this short series of posts I'll try to give you much simpler tutorial (for morons like me) how to start new Mylyn Connector Plugin even if you're new to Eclipse Plug-in Development. I'll save your time!

OK - let's start. First video shows how to checkout Eclipse Mylyn and Trac packages (only packages required for connector development reference). In all tutorials authors say that you should take Trac Connector as example but they never point to concrete CVS repository and CVSROOT directory. I do:

Second video shows how to create new Mylyn connector project and make it visible in the new Mylyn Connection wizard (I took icons from Trac for simplicity - you can/should use your own). All steps in this tutorial are MANDATORY - if you miss something I'm 99.9% sure it will not work:

Enjoy and stay tuned for more videos in the upcoming weeks...

PS. I used Eclipse 3.5 (Galileo):

JavaOne is dead?

2010-02-03T08:06:00.002+01:00

I was just looking for the information regarding JavaOne 2010 and found some worrisome blog posts:

Was JavaOne 2009 the last?
JavaOne 2010?
JavaONE 2010? Seems Like It Will Take Place

According to the Moscone Center website JavaOne 2010 is already scheduled between 22nd - 25th of June 2010.

I hope to go there this year! Keep your fingers crossed for my dept's budget :)

Memory Leak Protection in Tomcat 7 - fwd

2010-02-02T10:33:00.002+01:00

Picture (c) DZone

I'm just forwarding you to a good article on memory leaks protection implementation in the upcoming Apache Tomcat 7.

This article is a in a form of short (but quite comprehensive) interview with:

Mark Thomas, a Senior Software Engineer with SpringSource and committer for Apache Tomcat

Mark points directly to SVN repository where you can actually see how the mechanism he's describing works under the hood.

Mark also mentions about other new features that will be available in new Tomcat 7 (which should be released in alpha in Feb 2010).

How to ensure your IE toolbar buttons are always visible?

2010-02-01T16:59:00.004+01:00

Some time ago I encountered a wall while developing add-on for Internet Explorer. I wanted my add-on's button to be always visible after installation process, similarly to delicious stuff.

Problem seems to be quite simple - just check Browser Helper Object's (BHO) options and set some flag (aside of this subject I will tell you that developing pure BHO is a nightmare). In fact there is no such option. Internet Explorer seemed not extensible to this extent. Also finding something in the Internet appeared to be impossible. What the hell? Delicious guys made it!

After quite long searching I was very close to give up and resign from this "feature". But my sixth sense (yes, you should use it a lot while working with Microsoft) was telling me - "check the registry". So I did, and it was a bull's eye shot.

The thing you have to do is to increase the width of Tool Band Width of Internet Explorer (my NSIS script contains this):

WriteRegDWORD HKCU "Software\Microsoft\Internet Explorer\CommandBar" "ToolBandWidth" 800

It's very very primitive but it's the only solution I found to work. You just have to provide the desired width in pixels (decimal value) you'd like IE toolbar to be. Don't worry - you can put there even a value of 3000 - IE is smart enough not to extend the toolbar more than needed i.e. if you put a value of 1000 and your buttons need only 500 pixels IE will automatically adjust toolbar width to 500px.

This solution works but has also a big disadvantage. As you can see I write information to the registry for HKCU (HKEY_CURRENT_USER), so if you are installing the add-on with user Administrator, only this user will have Tool Band enlarged. If you open IE with another user she will probably not see your add-on button(s) (applies to IE7 and IE8).

Until now I couldn't find a better way - did you?

Tomcat 6 Developer's Guide - book review

2010-01-18T08:00:00.004+01:00

Picture (c) Packt Publishing

Few days ago I received brand new "Tomcat 6 Developer's Guide" book which I’ll try to review shortly here. The book is best described in few sentences by the author himself:

"While Tomcat is one of the most popular servlet containers, its inner workings still remain a mystery to many developers. If you only have a superficial familiarity of how this container actually functions, much of its power remains untapped and underutilized. [...]"

Before I start let me just mention that I’m experienced Java and Java EE developer and have worked with Tomcat server (with breaks) since version 4.x (year 2003). This means that I know how to develop, deploy, monitor and tune web applications in this web server. I also worked a little bit with Tomcat internals like custom class loaders. Despite that, this book gave me even more information and knowledge. With this book I was able not only to understand how Tomcat works internally but also where and how I could improve it or basically modify internal components for my needs.

Let’s start the review here - first of all I’d like to say that the author Damodar Chetty meets his goals in this book. He states in the preface that this book is not for web developers who want to learn how to write Java Servlet / JSP applications and how to deploy them in Tomcat container. I totally agree with the author – this book will not teach you that. This book is for people who want to know how Tomcat works internally in order to tune it or modify it for specific needs.

The author promises to go deep inside Tomcat’s architecture and implementation in order to better understand what’s under the hood, how it works and how you can improve or monitor it. I can assure you that this goal is met. This book describes in detail also other aspects of Java EE environment that are not directly connected to the Tomcat container but on which its implementation is based.

In this book Damodar Chetty firstly describes Tomcat’s high-level architecture and then breaks them down up to basic Java classes. This way he makes the whole complex architecture easy to understand. The author describes all Tomcat’s components one by one which is reflected in the Table of Contents. I think the author’s intention here was to make the reader read the book from cover to cover. I think so, because if you just want to learn about one particular component it will be a bit difficult to understand all the references to the previous sections. In my opinion this book should be read entirely to make every aspect clear, otherwise you will need to go back in the book and search for previously explained subjects, which is not easy.
This book is definitely component-oriented rather than how-to- or problem-oriented, so if you have a concrete problem or question regarding Tomcat you may have problems finding answer in this book.

All topics are difficult and in my opinion this book is for experienced Java and Java EE developers and administrators. In this field the book fully satisfied me. More so, many topics like "URLs and protocol handlers", "Java class loading" or "Implementing a custom class loader" may be very useful out of the scope of Tomcat server.

What I like in this book’s style is that all, even most complex subjects are explained in a clear way. Every complex component is broken down into pieces that are more easy to explain and understand. This book is also very concise in the source code examples. This makes it more time-consuming to read but on the other hand it forces the reader to understand the subject rather to copy-paste included source code. This aspect again makes this book accessible for experienced developers who know Java and Java EE environments pretty well and are able to start developing their own examples from the textual description.

This book does not promise to cover all the subjects around Tomcat but few of them are really missing in my opinion. Despite full description of how Tomcat is built and how it works I really miss chapters describing how to configure load-balancer for Tomcat or a cluster of Tomcat web servers. I know there are many books or Internet resources that cover these subjects but it would be just nice to have it here. I also realize that load-balancers and clustering components are not core Tomcat components and maybe this is the reason why they are not covered in this book.

To summarize, I think "Tomcat 6 Developer's Guide" book is a really good one and describes Tomcat web server in a pretty detailed fashion. Please note again that you will not learn from this book how to develop web applications using Java Servlet and JSP technologies. You will learn how to effectively use and also modify tomcat internals for you specific needs. You need to be experienced Java / Java EE developer to fully understand all the topics and successfully apply knowledge from this book. I would basically recommend you reading full description of this book available here before buying it.

Tomcat 6 Developer's Guide is here

2009-12-21T11:32:00.005+01:00

Picture (c) Packt Publishing

Few days ago I was contacted by Amit Sharma (Marketing Research Executive at Packt Publishing) who asked me if I can review their new book Tomcat 6 Developer's Guide. It was published just few days ago and sound interesting, so I agreed.

I expect the book to be rather for advanced users who want to dig in into Tomcat's architecture and more tricky configurations (e.g. SSL and load balancing with Apache front-end, clustering, security realms for Single Sign-In like Kerberos or Windows NTLM).

My short review of the book will follow shortly (in mid Jan 2010). Stay tuned!

Spring 3.0 goes public

2009-12-16T18:51:00.001+01:00

Here it is http://www.springsource.com/download

Spring 3.0 is here and I hope it will serve Java developers as good as the previous releases. Spring Framework used to be de facto Java EE standard and I believe it will remain so for the next couple of years:

For some very recent news, Spring 3.0 GA is compatible with Java EE 6 final in terms of runtime environments now (e.g. on GlassFish v3 as released last week) and supports JPA 2.0 final already (e.g. using EclipseLink 2.0). We also support the newly introduced @ManagedBean (JSR-250 v1.1) annotation for component scanning now, which nicely complements our @Inject (JSR-330) support for annotation-driven dependency injection.

Server timeout for maven release:perform or site:deploy

2009-09-29T13:56:00.003+02:00

I just wanted to release a piece of software I'm working on when I encountered a wall. Big, high and not very talkative wall - read timeout. I thought maybe the configuration of the server (and Web DAV) I described in this post has changed? No way - everything is like it was. The only thing that has changed is Maven version from 2.0.9 to 2.2.1 (where you don't have to define DAV extension in the build part).

Fortunately I also had my old environment where it worked (I meanMmaven 2.0.9). I noticed that the full build takes over 2 minutes while on the new Maven I get the timeout after 1 minute and few seconds. This way I realized that maybe increasing the timeout value will help. IT DID!!!

So how to do this? It's simple - just add:

<servers>
  <server>
    <id>someId</id>
    <username>blahblah</username>
    <password>blahblah</password>
    <configuration>
      <timeout>120000</timeout> <!-- your timeout in milliseconds -->
    </configuration>
  </server>
  ...

in the MAVEN_HOME/conf/settings.xml file and restart your Maven task.

Enjoy!