jump to navigation

Java HTTP proxy settings February 18, 2011

Posted by Anoop Somasundaran in Java, Linux, Tomcat, Unix.
Tags: , , , ,
add a comment

Some of you might have come across http connectivity issues especially when you setup your java application on staging or production servers. Due to security reasons, access to internet/external URLs within an organization is often through proxy servers. When I was trying to setup one of the java web applications on staging and production servers, the application was throwing an exception – ‘java.net.ConnectException: Connection refused’ when it tries to make an HTTP connection to get the content. However we were not getting this error in our development environment. I was almost sure that the problem could be because of the proxy servers used in the production and staging setup. The proxy server was blocking outbound traffic from the application servers.

After some trial and error attempts, I found the following solution to fix this issue.

I was using tomcat as the application server and I had to add the following lines in catalina.sh

JAVA_OPTS="$JAVA_OPTS -Dhttp.proxyHost=ProxyURL"
JAVA_OPTS="$JAVA_OPTS -Dhttp.proxyPort=ProxyPort"
JAVA_OPTS="$JAVA_OPTS -Dhttp.proxyUser=UserName" (Optional)
JAVA_OPTS="$JAVA_OPTS -Dhttp.proxyPassword=Password" (Optional)

Note: Please don’t copy and paste the above lines into Linux environment. The double quotes might give you issues on Linux if you copy double quotes from windows. I have faced this issue several times 😦

This problem can also be resolved by adding the following lines in your code.
System.getProperties().put("http.proxyHost", "ProxyURL");
System.getProperties().put("http.proxyPort", "ProxyPort");
System.getProperties().put("http.proxyUser", "UserName"); (Optional)
System.getProperties().put("http.proxyPassword", "Password"); (Optional)

Adding the settings at the server level seems to be a much better option though.

How to setup virtualhost in Tomcat June 28, 2009

Posted by Anoop Somasundaran in Java, Tomcat.
Tags: ,
1 comment so far

I recently had to configure a couple of different tomcat web applications as virtual hosts each one with its own domain. I was accessing these applications using the URL http://localhost:8080/app1 and http://localhost:8080/app2. The basic intention behind the virtual host setup was to avoid the web application name from the url (app1/app2) and the applications to be accessed using http://www.domain1.com and http://www.domain2.com/ . If there was only one web application I could have achieved it by keeping the web application inside webapps/ROOT folder.

Though I am using Apache as front server which was used to forward the dynamic content request to tomcat, I am not describing the Apache-Tomcat configuration in this article. I have described the Apache-Virtualhost-Tomcat-configuration in another article.

Step 1: Configuring Tomcat server.xml

Add the following entry in server.xml (TOMCAT_HOME/conf/server.xml). This should be added below to <Host name=”localhost” ..>…….</Host>

<Host name="www.domain1.com" appBase="/opt/tomcat/www.domain1.com" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"/>

<Host name="www.domain2.com" appBase="/opt/tomcat/www.domain2.com" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"/>

Step 2: Deploying the applications

Create folders http://www.domain1.com and http://www.domain2.com inside TOMCAT_HOME. Copy the webapp1 to http://www.domain1.com and webapp2 to http://www.domain2.com. Rename both webapp1 and webapp2 to ROOT (ensure ROOT should be in uppercase).

The following should exist after the completion of step2.

TOMCAT_HOME/www.domain1.com/ROOT/webapp1_contents
TOMCAT_HOME/www.domain2.com/ROOT/webapp2_contents

Step 3: Enabling Tomcat Manager Console for the new hosts

The default tomcat manager console (http://localhost:8080/manager/html) will not be available for the new hosts. Manager Console needs to be enabled for the application deployed under each virtual host. This can be done by following the below steps.

Create folders http://www.domain1.com and http://www.domain2.com under TOMCAT_HOME/conf/Catalina/. Copy manager.xml from TOMCAT_HOME/conf/Catalina/localhost/ to TOMCAT_HOME/conf/Catalina/www.domain1.com/ and TOMCAT_HOME/conf/Catalina/www.domain1.com/.

The tomcat manager console for the hosts http://www.domain1.com and http://www.domain2.com can be accessed using the URLs http://www.domain1.com:8080/manager/html and http://www.domain2.com:8080/manager/html respectively.

Step 4: Adding host entry for each virtualhost

In production/staging environments normally the domain would be mapped to the IP of the machine. However in development environments we need to map the IP with the virtualhost. This can be done by adding a host entry in the host file. The ‘hosts’ file is typically located at C:\WINDOWS\system32\drivers\etc\hosts on windows and /etc/hosts on UNIX

Machine-IP http://www.domain1.com
Machine-IP http://www.domain2.com

Step 5: verifying the virtualhosts

Restart the Tomcat Server and check whether the webapp1 and webapp2 are accessible using the URLs http://www.domain1.com:8080 and http://www.domain2.com:8080 respectively.

If you are using Apache web server and Tomcat, you can leave Tomcat running on port 8080. Otherwise simply change the port of tomcat from 8080 to 80.

How to take Java Thread Dump? May 30, 2009

Posted by Anoop Somasundaran in Java, Performance Tuning, Servers, Tomcat.
Tags: , , ,
5 comments

Full Thread Dump is a complete list of active threads. A java thread dump is a way of finding out what each thread in the JVM is doing at a particular point of time. This is especially useful when your java application seems to hang when running under load. Thread dump will help you to find out where the threads are stuck.

A sample thread dump is given below

2009-04-28 05:21:57
Full thread dump Java HotSpot(TM) 64-Bit Server VM (11.2-b01 mixed mode):

"Keep-Alive-Timer" daemon prio=10 tid=0x000000005459ec00 nid=0x78d8 waiting on condition [0x000000004aa2c000..0x000000004aa2cc10]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at sun.net.www.http.KeepAliveCache.run(KeepAliveCache.java:149)
at java.lang.Thread.run(Thread.java:619)

"Thread-349" daemon prio=10 tid=0x0000000054ea4c00 nid=0x700b runnable [0x000000004ab2d000..0x000000004ab2db90]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
- locked (a java.io.BufferedInputStream)
at com.sun.jndi.ldap.Connection.run(Connection.java:805)
at java.lang.Thread.run(Thread.java:619)

Each section in thread dump indicates what the thread was doing.

How to take thread dump on UNIX:

First, find the process id by looking in the process table. You can generally get the process numbers of all running Java processes with the command:

ps axf | grep java

Run the following command to take the thread dump.

Kill –QUIT process_id

The thread dump will be sent to where ever the standard output is redirected to. (In tomcat, normally the thread dump will be sent to TOMCAT_HOME/logs/Catalina.out)

QUIT signal does not actually kill the java process. The thread dump will be sent to the standard output and the process will continue.

How to take thread dump on Windows:

press CTRL+Break

The thread dump is printed in the command window, and you must cut / paste to a separate file in order to continue working on it.

What happens when you take thread dump?

1. The Java process is paused — all threads simply stop dead in their tracks
2. The Main java process asks each thread in turn to give a complete account of what they’re doing
3. The thread dump is sent to standard error, or somewhere else, depending on your Java vendor
4. The Java process is unpaused — all threads simply continue where they left off.
The Java process usually keeps on running, and the whole process only takes a few seconds. Any activity, even input/output is suspended. After the thread dump has completed, everything returns back to normal, just as if nothing had happened.