Wednesday, May 14, 2014

Monitor Java on Unix/Linux/Solaris

Just a short memo of useful commands that can help to troubleshoot Java on *nix:
(Btw, most of them will also work on Windows, but who runs Java on Windows? Just kidding...)

jps -m - show running Java processes and their pids.
jstack <pid> - print thread dump
jmap -dump:format=b,file=<path to file> <pid> - save heap dump to file

Thursday, August 1, 2013

UnresolvedAddressException Tip

Getting java.nio.channels.UnresolvedAddressException?
Having no idea why does this happen?

Check the code that creates the address. Did you use java.net.InetSocketAddress.createUnresolved(String, int) to create it?
Do NOT! Just new java.net.InetSocketAddress and it should be fixed.

P.S. This is kind of a post I write here after spending hours on a stupid bug.
So people can google it out and spend less time on it.

Tuesday, May 21, 2013

DevOps: Making Fast Deployments of Java Servers using Maven and Nexus

A Warning: this post is theoretical. I have never tried something like this yet. Maybe I will try it in the future. But currently it's just a nice idea.
In addition, if you know about somebody who works in a similar way, I would really like to know. So please comment!

If you provide a SAAS service you probably have multiple Java servers running in some sort of a cluster. If your SAAS solution is complicated, and if your solution is multi-tier, you should have multiple servers types. And now comes a question: How to make quick deployments to the production?

The common solution suggests that you build a package and release it. It might be a war, or a zip, or a rpm if you are running on Linux.
Once released, you upload the package to the server, unzip/copy it to the relevant folder and restart the server.

The problem with this solution might be if your packages are large. (And if you are using OSGi, your packages are usually very large!) So the upload itself takes time. It also uses traffic which might become expensive if you perform a lot of deployments. And the really funny thing is that most of the upload is redundant: most of the jars in your package are third parties that do not change between the deployments at all!

The common solution suggests pre-uploading the third party jars to the server and exclude them from the package. I've seen such a solutions and in my opinion they are the exact opposite of a good solution: in this way you split the package, the third parties become manages in two (sometimes more) places and each deployment involves at least additional (probably manual!) step of checking if the third parties were changed and if additional deployment if third parties is required.

But if you use Maven. And if you upload your released packages to Nexus (or actually any other Maven repository). This Nexus repository contains all the third parties, all the released packages and the most important: The pom file that was used to build your project!
If you download this pom file, you will be able to build the package on the production server! Pay attention that you don't need to do the full build that includes the compilation, testing and so on. You just need your package, so considering that you deploy a war, you only need to run the "mvn war:war" (Once again: I never tried it myself and the actual execution might be more complex, but I think that the idea is clear).
Sometimes, if you a running a java application with a main class (pure old java and not some kind of JEE inside the application server or a servlet container), you don't even need a package, you just need a correct classpath and Maven will be happy to assist you: mvn dependency:build-classpath.

So I guess that the idea is clear now. Each time Maven will download only the relevant jars and save them to the local repository. The dependencies are managed in the same pom file that is used to release the application, so when making a package, or creating a classpath on a production machine, the exact same dependencies will be used.
And the deployment process will become much faster!

I know that this idea is somewhat different from the usual process. Instead of doing some like "build, deploy, run", we do something that might look even more complicated: "build, deploy descriptor only, package, run". But this should be much faster. So I definitely think that this idea is worth trying.


P.S. The idea described in this post relates only to the package itself: building, packaging and running. The deployment may contains additional steps like changing the local configuration files and so on. These steps are not covered here as they are usually not covered in a build process, but part of release notes. The possible solution can be deploying the relevant scripts to Nexus repository and somehow describe them in a pom file. When downloading the pom, the relevant scripts will be also downloaded and executed.

P.P.S. The idea also doesn't cover the tool that makes the whole process. Although it describes that the tool is using Maven, it says nothing about the actual implementation. It might be a java process. Or a shell script. Or even Ant.

P.P.P.S. Notice that downloading files from Nexus using Maven makes important checks for you, for example it makes an integrity check, which is very important in case of a bad network between the Nexus with releases and a production site.
In addition, you can make some optimizations on Nexus. For example, if you have several production sites all over the world, each site may have a Nexus pointing to the main release repository and caching it. This will make the deployments even faster.


Recommended Reading



Wednesday, February 13, 2013

Deadlock in Jetty or Be Careful while Synchronizing

About nine months ago I reported a bug to the Jetty community that session timeout doesn't work properly. The bug was fixed quite quickly, but nine months later I have discovered that the fix leads to a deadlock in some scenarios.

Deadlock in Jetty illustrates an interesting coding guideline that you must follow while writing your code.

So what happened in Jetty?

Consider a class A that carries state and lives in a multi-threaded environment. Obviously this class must be synchronized.
Consider that you can subscribe to events of class A. So let's say class you must implement an interface I that will be notified when something important in class A happens.
Let's assume that the method in which class A invokes instances of I is synchronized (A carries state, remember?)
Let's also assume that your implementation of I also carries state and must be synchronized as well.

And now let's see what happens:

Thread-1: Some event on A occurs. It's wants to notify I, but first acquires LOCK_A and then invokes method of I. Method of I tries to change state of I, so it tries to acquire LOCK_I, but it was already acquired by Thread-2.

Thread-2: Runs on I. It changes the state of I, so it acquires the LOCK_I. During the change it needs some information of A. It tries to get it, but LOCK_A was already acquired by class A.

And here we have a deadlock.

So what is wrong here?
The most wrong part is of class A: it invokes method of some other class while it is locked. BAD! Finish the lock before calling someone else! And when I say "someone else" I include the other methods of the class! (What really happened in Jetty is that in class A method f1() was synchronized. Method f1() called to f2(), which called to f3(), which called to f4(), which called to I. It was clear in f4() that no synchronization is needed. But the mistake is actually in f1()!)
So you have some member to change? acquire the lock, change them and release the lock.

In addition, the situation could be a little improved if Read-Write lock was used instead of synchronized: most of the access to class are to read data. May be if LOCK_A was split to READ_LOCK_A and WRITE_LOCK_A; and LOCK_I was split to READ_LOCK_I and WRITE_LOCK_I, it was not causing the deadlock. But this is not about preventing the situation, but about improving.

Summary

The main point of my post is that when synchronizing, find the critical section and synchronize it only! Do not call other methods (even if they are of the same class) from the critical section: gather all information before and notify everyone else after.

Monday, January 14, 2013

Initiate Infinispan with a Custom JChannel

In all Infinispan sample the JGroups part is almost omitted. You are told that you should provide a configuration xml and the infinispan-core.jar contains three samples: udp, tcp and ec2.

But what happens if you don't want to use samples? What happens if you want to have a dynamic configuration that changes based on the environment/database/external configuration tool? What happens if you want to configure it from code?

It appears to be not an easy task, but not very complicated. A special interface org.infinispan.remoting.transport.jgroups.JGroupsChannelLookup exists that allows an injection of org.jgroups.Channel.

So you can write something like:
public classJGroupsChannelLookupImpl implements JGroupsChannelLookup {
   
    public Channel getJGroupsChannel(Properties p) {
        return new JChannel();  // of course the code here might be quite complex, initializing the channel with a custom configuration
    }

   
    public boolean shouldStartAndConnect() {
        return true; // change to false if you start and connect the channel yourself
    }

    
    public boolean shouldStopAndDisconnect() {
        return true; // change to false if you stop and disconnect the channel yourself
    }
}

Make sure to have a default public noargs constructor or a static getInstance() method that returns an instance of JGroupsChannelLookup.
(Personally I prefer a static method, so I have control how the instance is created and managed)

Now you need to tell the Infinispan to use your JGroupsChannelLookup:
Configuration conf = new ConfigurationBuilder().clustering().cacheMode(CacheMode.REPL_SYNC).sync().build();
GlobalConfiguration globalConf = new GlobalConfigurationBuilder().clusteredDefault().transport()
                    .addProperty(JGroupsTransport.CHANNEL_LOOKUP, JGroupsChannelLookupImpl.class.getName()).asyncTransportExecutor()
                    .build();

            
DefaultCacheManager manager = new DefaultCacheManager(globalConf, conf);

Tuesday, October 2, 2012

Send Mail Via Gmail

I already spent some time few years ago to figure that out and now I spent this time again.
So here's the short code snippet with an example how to send mail using Java Mail and GMail.

First, pom.xml. Include the following dependencies:

<dependency>
    <groupid>javax.mail</groupId>
    <artifactid>javax.mail-api</artifactId>
    <version>1.4.5</version>
</dependency>
<dependency>
    <groupid>javax.mail</groupId>
    <artifactid>mail</artifactId>
    <version>1.4.5</version>
</dependency>

And now the code:

import java.util.Date;
import java.util.Properties;

import javax.mail.Message;
import javax.mail.Session;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

import com.sun.mail.smtp.SMTPTransport;

public class SendMail {

 public static void main(String[] args) throws Exception {
  Properties props = System.getProperties();
  props.put("mail.smtps.host", "smtp.gmail.com");
  props.put("mail.smtps.auth", "true");
  Session session = Session.getInstance(props, null);
  Message msg = new MimeMessage(session);
  msg.setFrom(new InternetAddress("somebody@gmail.com"));
  msg.setRecipients(Message.RecipientType.TO,
    InternetAddress.parse("somebody_else@gmail.com", false));
  msg.setSubject("I'm the subject!");
  msg.setText("And I'm text of your message");
  msg.setHeader("X-Mailer", "Java Program");
  msg.setSentDate(new Date());
  SMTPTransport t = (SMTPTransport) session.getTransport("smtps");
  t.connect("smtp.gmail.com", "somebody@gmail.com",
    "here comes the password");
  t.sendMessage(msg, msg.getAllRecipients());
  System.out.println("Response: " + t.getLastServerResponse());
  t.close();
 }
}

And the thanks goes here.

Sunday, July 1, 2012

Apache HTTP Client - Ignore SSL Problems

Sometimes, especially when testing, it can be useful to make Apache HTTP Client ignore the SSL problems.
SSL problems may include ignoring of certificate trust (issuers) and host verification. The following snippet creates an Apache HttpClient with SingleClientConnManager that will ignore the SSL problems:
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import org.apache.http.conn.params.ConnRoutePNames;
import org.apache.http.conn.scheme.PlainSocketFactory;
import org.apache.http.conn.scheme.Scheme;
import org.apache.http.conn.scheme.SchemeRegistry;
import org.apache.http.conn.ssl.SSLSocketFactory;

public HttpClient createHttpClient() {
  TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {

    @Override
    public java.security.cert.X509Certificate[] getAcceptedIssuers() {
     return null;
    }

    @Override
    public void checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType) {
    }

    @Override
    public void checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType) {
    }
  } };
  SSLContext context = SSLContext.getInstance("TLS");
  context.init(null, trustAllCerts, null);

  SSLSocketFactory sf = new SSLSocketFactory(context, SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

  SchemeRegistry schemeRegistry = new SchemeRegistry();
  schemeRegistry.register(new Scheme("http", 80, PlainSocketFactory.getSocketFactory()));
  schemeRegistry.register(new Scheme("https", 443, sf));

  SingleClientConnManager cm = new SingleClientConnManager(schemeRegistry);

  return new DefaultHttpClient(cm);
}

Pay Attention! In production you must use a valid SSL! Use this code for testing purposes only!

Monday, June 18, 2012

Jetty - Basic Hardening

Jetty by default is shipped with two annoying features that should be turned off in production.

The first one is contexts listing. If you access the root folder, and if there is no special context configured to be a root context, Jetty will display a list of all contexts installed. While it may be nice to see it during the development, it's unnecessary information during production.

The class responsible for displaying this list is org.eclipse.jetty.server.handler.DefaultHandler and it's configured in jetty.xml. setShowContexts to false to turn off the contexts listing.

Actually you may consider to provide your own Hanlder class instead of the DefaultHanlder. The org.eclipse.jetty.server.handler.DefaultHandler is also responsible to display the Jetty's default favicon. It may be configured not to server the favicon at all by setServeIcon(false), but it does not allow to customize the favicon. So if you want to do it, you'll need a custom class.


The second annoying feature is a directory content listing - when you access a directory, the Jetty will generate a page with a list of files located inside. This configuration can be turned off per context: under <Configure class="org.eclipse.jetty.webapp.WebAppContext"> put the following init parameter:

<Call name="setInitParameter">
  <Arg>org.eclipse.jetty.servlet.Default.dirAllowed</Arg>
  <Arg>false</Arg>
</Call>

Monday, May 7, 2012

REST Best Practices: Use HTTP Status Codes

When implementing RESTful service, keep in mind that HTTP already provides you with an ability to send the status code as part of the protocol. Do NOT put the error code inside the message itself!

HTTP defines five types of status codes:
* 1xx - Informational
* 2xx - Successful
* 3xx - Redirection
* 4xx - Client Errors
* 5xx - Server Errors

See Full reference of HTTP/1.1 Status Code Definitions

I'm not going to describe all HTTP Status codes here, but to give some basic tips.

1. In case of a successful request, always return the status code from the 2xx group. It's highly recommended to use not only the basic 200 code, but also additional codes. For example 201 means a new resource was created and the LOCATION header contains its path. 204 means that the response contains no content, so the client can optimize its code and not even try to read the content of the response (saves some redundant objects creation).

2. In case of an error request, clearly distinguish between the client and server errors. Client errors mean that the client has sent a bad request: it may be incorrectly formatted, unauthorized, method not allowed (e.g. Server accepts GET requests, while POST has been sent), and more.
In case of a client error, the best is to detect it as soon as possible in the server's code, to reduce amount of logic that will run, until the request is rejected. For example it's redundant to parse request body, if it misses the security header.
2.1 Send clear response to client. It can be a good practice to supply text or html content inside the message telling what was wrong in the request.
2.2 Don't log requests with a client's error above the info level. After all, it's a client's error, not server's. The only reason to log client' errors at all, is to help clients by taking look at the server logs. Make sure not to create a misleading picture of a log full with exceptions, while there is no problem at server side at all.
2.3 By receiving the 4xx code, the client must understand that it did something wrong and should correct its request.

3. In case of a server error, return 5xx error code. Usually the best choice will be to return simply 500. Do NOT put the full stacktrace into the response body. Actually put nothing in the response body. Why should a client care about the reason of server's failure. Is the database down? Is it a code problem? Whatever it is, it's not the client's business.
3.1 Sometimes, it can be nice to return 501 Not Implemented code. Usually it will happen, if you agreed on some functionality, created a prototype for it but didn't implemented it yet.
3.2 By receiving the 5xx code, the client must understand that something went wrong and that it should retry the same request. Does it make sense to retry immediately, in 5 minutes or in 5 days depends on the client. The server can return the *Retry-After* header and client should respect it.

There are more status code that can and should be used with RESTful APIs. For example 304 Not Modified allows you to save traffic and skip the response if the resource was not modified. Many status codes are implemented by the frameworks and intermediaries, for example JAX-RS frameworks will automatically return some client errors, like 405 and 415.

Summary

1. In case of successful request, always return a request from 2xx group.
2. In case of unsuccessful request, never return 2xx with embedded status code in the message. Return appropriate 4xx or 5xx status code.
3. For client errors, return 4xx. Don't log these requests above the info level. These are client's problems, not server's.
4. For server errors, return 5xx. Log the error, but don't send it to client.

Thursday, May 3, 2012

Promoting tarlog-plugins

In the last four years, since I have first published the tarlog-plugins Eclipse plugin, it has 4600+ downloads.
I know that many readers of this blog are actually using it.
I won't ask you why none of you has never clicked the Donate button. After all I have never did it myself...
But why you won't you share it?
You can star and/or +1 it on the project's page.
You can favorite it on the marketplace.
You can... well, the previous two are enough. But if you really want to Donate, there is a Donate button on the project's page.

P.S. And there is also an Encoder Tool. It didn't become as popular as tarlog-plugins, but it still nice for small encoding/decoding tasks.