Archive for the ‘Java’ Category

Java 9 adds Yet Another Logging framework (YAL)

Java 9 and JEP 264 addresses a gaping whole in the Java ecosystem: the lack of logging frameworks and abstractions. Finally there is a logging API built into the platform for those who don’t like the other logging API already built into the platform!

The java.util.logging option is commonly referred to as JUL. Why not call the new one YAL?

Most Java EE applications these days ship with third-party components that use JUL, SLF4J, commons.logging, Log4j and quite probably several additional frameworks for good measure. Unified logging is by no means trivial. It is a mess and with YAL we have one more framework and probably several additional adapters.

I can see the need to isolate the core classes from JUL, but I’m still not convinced that this is what Java needs. Why not spend more time on my pet feature, value types, instead?

Categories: Java

Enable JCA resource adapter statistics in JBoss EAP 6

Performance tuning is guesswork without good instrumentation. Knowing the bottleneck is at least half the battle. Thus it is always nice to graph connection pool statistics for databases and resource adapters. With EAP 6, statistics can be enabled in the connection-definition element, for example:

      jndi-name="java:/QCF" enabled="true" pool-name="QCF"

Unfortunately it doesn’t work, most metrics (such as InUseCount) are reported as 0. Why? Apparently this is a bug that has been fixed in EAP 7. However, for 6.4.8+ statistics can be enabled by setting the system property Do it now…

Categories: Java, Performance

Negative queue depths in ActiveMQ

For quite some time we battled with negative and sometimes false positive queue depths in ActiveMQ and the commercial AMQ equivalent. Apparently there is a race condition somewhere in the broker. It is usually easy to see when it has happened in the graphs, as the number of messages on a queue suddenly jumps up or down dramatically in an instant. It does play havoc with monitoring, though. How can you set alarms if you can’t trust the reported queue depth? Restarting the broker fixes the counter, but that is not a viable solution.

Fortunately there is a configuration option that solves this. Define a policyEntry for the affected queues/topics and set useCache="false". That is a fairly large change, but it works.

Categories: Java

Native memory leaks in Java

By request, here is the presentation I held at JavaForum on native memory leaks in Java.

Categories: Java

JBoss EAP 6 and CACHE_CONSUMER with Spring DMLC

The documentation for Spring’s DefaultMessageListenerContainer states:

Some Java EE servers only register their JMS resources with an ongoing XA transaction in case of a freshly obtained JMS Connection and Session.

Rumour has it that JBoss EAP is one of the guilty servers, but is it true? We couldn’t find any definitive answers for the recent versions. But yes, caching consumers with JBoss EAP 6 using XA transactions will fail. The application server only enlists with the active transaction when a connection is checked out from the pool. If the consumer is reused for other transactions that will seem to work (no error messages), but in fact the messages are consumed without transactions. If a rollback occurs messages are lost.

In short, be sure to use CACHE_NONE with JBoss EAP 6.

Categories: Java, Performance

Beware of interned strings with G1

Interned strings can always be problematic, as the size of the hash table is fixed. Perhaps the -XX:+UseStringDeduplication option can make things worse, as (according to native memory tracing) it seems to use the same pool. However, at present there is a more pressing problem with Java 8 and 9 using the G1 garbage collector: interned strings may not be garbage collected at all, resulting in a native memory leak. See JDK-8180048. What to do? Stay calm or switch to another garbage collector. But be sure to keep an eye on the native memory usage of your Java applications!

Categories: Java

Effective low-tech alternative to @formatter:off for Java

I love automatic formatting for source code. Back in 2004 I scrapped the detailed formatting guide for the project I was running and replaced it with a single sentence: all code must be formatted by the automatic formatter using the project’s conventions. Done. Sure, manual formatting can look better, but at what cost (and tedium)?

There are some places where the automatic formatter always fails, though, for example string concatenation for SQL commands. No problem, use @formatter:off and @formatter:on and there you are – until someone comes along who hasn’t enabled the tags. And disabling formatting completely can introduce tabs where there should be spaces, for example.

Fortunately there is an effective low-tech alternative that works everywhere (cross-IDE): comments! Use line comments after each line and the formatter can’t join them:

   "select something from some_table " //
   + " where some_column = ?"

It will still handle indentation.

Categories: Java