Category Archives: Java

Presentation – Java Web Start : How Zhara POS Works

This is a presentation that I did recently for my team, on Zhara POS (which is the Point of Sale module of Zhara Hospitality Suite, the product that I’m working on at JKCS). We developed the application using Swing, and deployed it over the web via Java Web Start.

The presentation discusses the rationale for using Java Web Start, and how we applied it to meet with the requirements.

The audience of the presentation was the entire Zhara Team, which consists of designers, developers, QA, business analysts working on many modules.

This presentation was part of the Zhara Tech Talks Series (session 03), which is held bi-weekly, where the team meets up and discuss about various topics of interest, both technical and non-technical.

JBoss – Changing RMI Remote Client Callback Address

Recently during a JBoss production deployment (4.2.3.GA) that I had to carry on, I came across a problem with RMI Remoting (EJB3), which gave an exception when remote EJBs are invoked. The exception I got was ‘java.lang.IllegalArgumentException: port out of range:-1’, whenever a Remote EJB call was made.

12:57:58,354 WARN  [ServiceExceptionTranslatorAspect] Unable to Translate Exception : org.jboss.remoting.CannotConnectException
12:57:58,402 ERROR [[default]] Servlet.service() for servlet default threw exception
java.lang.IllegalArgumentException: port out of range:-1
at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118)
at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:183)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:827)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:569)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)

The application was working fine in our local environments, and this problem happened only in production. This deployment consisted of two JBoss AS instances running two applications, which communicates with each other via EJB Remoting.

Googling did not give me any positive lead, and I was stuck on this problem for a while. So I tried out the only option I was left with, trying to go to detailed log output to see what’s happening under the hood. After changing the log level for CONSOLE and org.jboss category to DEBUG level (if you are new to JBoss, you can change the logging mechanism by modifying jboss-log4j.xml in conf directory of server profile).

This gave me the following output.

12:21:41,049 DEBUG [AuthenticationContextInterceptor] AuthenticationContextInterceptor Intercepting EJB Invocation...
12:21:41,049 DEBUG [AuthenticationContextInterceptor] Setting the authenticated user details in Authentication Context: XXXX
12:21:41,061 DEBUG [AuthenticationContextInterceptor] AuthenticationContextInterceptor Intercepting EJB Invocation...
12:21:41,061 DEBUG [AuthenticationContextInterceptor] Setting the authenticated user details in Authentication Context: XXXX
12:21:43,994 DEBUG [MicroSocketClientInvoker] SocketClientInvoker[b874d2, socket://192.168.12.4:-1] constructed
12:21:43,994 DEBUG [MicroRemoteClientInvoker] SocketClientInvoker[b874d2, socket://192.168.12.4:-1] connecting
12:21:43,994 DEBUG [MicroSocketClientInvoker] Creating semaphore with size 50
12:21:43,994 DEBUG [MicroRemoteClientInvoker] SocketClientInvoker[b874d2, socket://192.168.12.4:-1] connected
12:21:43,995 DEBUG [InvokerRegistry] removed SocketClientInvoker[b874d2, socket://192.168.12.4:-1] from registry
12:21:43,995 DEBUG [MicroSocketClientInvoker] SocketClientInvoker[b874d2, socket://192.168.12.4:-1] disconnecting ...
12:21:44,946 ERROR [[default]] Servlet.service() for servlet default threw exception
java.lang.IllegalArgumentException: port out of range:-1

As the highlighted line shows, JBoss was trying to communicate to the remote EJB via port -1, which is of course invalid. Also, an interesting observation was that the IP address which JBoss tries to use is not the one I expected it to use. This, was actually due to the network setup of the production environment. The production server in question had two network cards, each having local IPs  192.168.12.4 and 192.168.12.5. The 192.168.12.4 NIC was used to expose the server to Internet via NAT. 192.168.12.5 was used to internally connect to the machine via VPN for maintenance, etc. Since 192.168.12.4 was used for NAT, it was restricted to HTTP traffic on port 8080 only.

So the problem that I was facing was that JBoss was using the 192.168.12.4 to refer to the remote EJB, where as I expected it to use 192.168.12.5 (note that we have to start JBoss bound to all addresses using -b 0.0.0.0 because we access it via multiple NICs). Since JBoss could not get a free port on 192.168.12.4, it was falling back to port -1.

So I wanted to find out a way to force JBoss to use the IP address I wanted for remote EJB calls (without binding it specifically to one IP using -b). I was already referring to the remote server’s JNDI Registry via the IP I expected (192.168.12.5). After trying out various options, finally I found the following in the deploy folder of JBoss.

File: <JBOSS_HOME>/server/xxxx/deploy/ejb3.deployer/META-INF/jboss-service.xml

<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
<depends>jboss.aop:service=AspectDeployer</depends>
<attribute name="InvokerLocator">socket://${jboss.bind.address}:13873</attribute>
<attribute name="Configuration">
<handlers>
<handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
</handlers>
</attribute>
</mbean>

I changed it to the following, so that instead of dynamically resolving the IP address, JBoss will use the IP I wanted when remote client callbacks are created.

<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
<depends>jboss.aop:service=AspectDeployer</depends>
<attribute name="InvokerLocator">socket://192.168.12.5:13873</attribute>
<attribute name="Configuration">
<handlers>
<handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
</handlers>
</attribute>
</mbean>

With this in place, the client was able to invoke the remote EJBs without any issues. This is a rare situation, but if anyone else face the same issue, I guess this post would help to get it sorted out.

The Dark Art of Logging

Logging is a mechanism of keeping track of the runtime behavior of an application, mainly for debugging / tracing purposes. In almost all of significantly complex / vital applications, maintaining a proper application log is a must; hence, almost all developers are quite familiar with the paradigm of logging. And it isn’t rocket science. You just have to call a simple method with whatever you want to log, and mess around with a simple configuration file, and that’s all. So what’s the big deal?

The problem is that though logging is a simple thing to do, doing it correctly needs a lot of practice, experience and understanding. That makes it more of an art than a science. In my personal experience, mastering the art of logging requires lots of patience, experience and forward thinking. It’s quite difficult to teach someone how to do it (sort of tacit knowledge), and most freshers tend to see the effort put into writing to log files as something additional. But all that effort pays up when you go through long nights trying to figure out what went wrong in a production system. But for that, it is important that proper logging is done through-out the system, which requires all of the team to master this dark art. Just one guy doing it right in a team is simply not enough.
Continue reading

Know the JVM Series – 4 – Thread Locals

Thread Local Storage (TLS) is a special construct in multi-threaded programming, which allows to associate a variable with a particular thread. This is different from normal variables, which are associated with a process. In other words, a normal variable will be shared by threads of a same process (in procedural programming terms). However, a Thread Local variable has a copy of it per thread, and modifications by a particular thread is applicable for code running inside that thread only.

With the inherent multi-threaded nature of most enterprise Java applications, having some understanding about Thread Local variables are useful to solve some problems which would otherwise be difficult. We’ll start our discussion by looking into a practical problem that is faced by JEE applications, so that we have a good understanding about the power Thread Locals.

Consider a web based JEE application, which consists of JSP/Servlet based presentation tier, EJB based service facade tier, and business logic implemented in POJOs, and finally Hibernate in the persistence tier. In this application, users are required to authenticate before using secured parts of the application, and we will be using the standard JAAS to facilitate this. Assume that in our POJO based Business Logic classes and Hibernate DAOs, we need to obtain the currently logged in users ID for auditing purposes. How can we solve this problem? Continue reading

Nothing Personal; It’s Just Business

Recently, Apple informed that they will be deprecating the JDK in Mac OS X 10.7, code named Lion. With the history of Apple being indifferent towards Java as a platform (for example, not supporting Java on their i Platforms – iPhone, iPad), this is not a suprise move. To quote from the Apple release notes,

As of version 10.6 Update 3 of the version of Java that is ported to Apple (and consequently ships with Mac OS X) is deprecated. Apple’s port will not be maintained, and may be removed from future versions of Mac OS X. The Java runtime that ships with Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained.

A significant portion of Java development commmunity have been using Apple based products, and the JDK maintained by Apple supported the growth of this community. However, with Apple backing off their support in future Mac OS versions, this community will need to have another alternative coming up, hopefully, from the (now Oracle + IBM backed) OpenJDK movement.

As I see this, from Apple’s perspective, this is a “nothing personal, it’s just business” situation. With the success of Apple’s i Platform, what I see in this move is that they are attempting to bring in the i Platform based development into the arena of desktops and notebooks, so that they could expand their business on development platforms as well. May be someday in the near future, we might be able to witness the dawn of another development toolkit from Apple (probably based on the i Platform), competing with Java and .NET platforms.

Personally, I believe that the Java community will work out a solution to keep the Java platform running on Mac based products, but certainly, this will not have the same momentum as it had so far.


Note : Just to avoid confusion, the ‘i Platform’ that I refer to in this blog entry merely stands to represent the platform which is the basis for iPhone and iPad products.