Tuesday, April 12, 2011

Socket Accept Failed

Encountered funny error thrown by JBoss today when deploying JBoss 4.2.3GA

[JIoEndpoint] Socket accept failed
java.net.SocketException: Too many open files

Apparently JBoss somehow opened too many socket for some reason and start complaining itself.

So I've learned another new handy command to see what file handle are open using the following command.

lsof -p [PID]

Note: PID = process id, use ps command to see the process id.

If you want to count how many were open, can add wc command to it.

lsof -p [PID] | wc

Example output:

[root@localhost]# lsof -p 30328 | wc
1239 11141 153600

Translation: 1239 lines, 11141 words, 153600 chars.

So to solve this issue, go to jboss/server/default/deploy/jboss-web.deployer/ folder (might not be the exact path, depends on your JBoss version) and open server.xml file, replace the following

<Connector port="8080" address="${jboss.bind.address}"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />

with

<Executor name="appThreadpool" namePrefix="activeThread-"
maxThreads="150" minSpareThreads="3" maxIdleTime="30000" />

<Connector executor="appThreadpool" port="8080"
address="${jboss.bind.address}" maxThreads="150"
maxHttpHeaderSize="8192" minSpareThreads="3"
maxSpareThreads="20" emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />

And then replace the following

<Connector port="8009" address="${jboss.bind.address}" protocol="AJP/1.3"
emptySessionPath="true" enableLookups="false" redirectPort="8443" />

with

<Connector executor="appThreadpool" port="8009"
address="${jboss.bind.address}" protocol="AJP/1.3"
emptySessionPath="true" enableLookups="false" redirectPort="8443" />


Then save the server.xml and restart your JBoss.

Thursday, December 30, 2010

Recursively Remove .svn Directory and Files

Has it ever occurs to you that when you asked source code from your fellow developer, they will give you their whole workspace package including .svn files and you just want to delete these folders since you don't need it.

In that case, just quickly type in the following command so you have time to catch up for your coffee break with the above mentioned fellow developer.

rm -rf `find . -type d -name .svn`

Tuesday, June 22, 2010

Touch Files Modified Date Recursively in Unix

Sometimes you need to touch all your JSP files to current date so that your servlet container willing to re-compile your JSP again. It wouldn't be a problem if it's only one or two JSP files that you need to issue touch command.

When you need to touch a folder of JSPs recursively, the following command comes to your rescue

find jsp -exec touch {} \;

Saturday, April 10, 2010

View All Tables Record Counts in MySQL

To view all tables record counts in MySQL simply use this command

SELECT table_name, TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'database_name';

edit: it seems like the result returned is a cached result and it is not accurate, if you are looking for accurate result, I don't recommend the above mentioned approach.

Friday, January 2, 2009

Google Apps 2-Legged OAuth in Java

The java library of gdata v1.24 doesn’t support the use of 2-legged OAuth yet. If you try to implement the 2-legged OAuth with this library, it will throw you the exception below even you’ve done everything correctly:
com.google.gdata.client.authn.oauth.OAuthException: oauth_token does not exist.
The temporary solution to this problem is to change the source code inside the gdata library. Only two files need to be modified to makes the 2-legged OAuth working.

OAuthHelper.java

Inside this class, find getAuthorizationHeader method and comment out the following line:
oauthParameters.assertOAuthTokenExists();

GoogleAuthTokenFactory.java

Inside this class, find setOAuthCredentials method and comment out the following line:
parameters.assertOAuthTokenExists();

Recompile your gdata source code and you should be able to get the 2-legged OAuth works.

Below is the snippet code of 2-legged OAuth example.

import java.io.IOException;
import java.net.URL;

import com.google.gdata.client.authn.oauth.GoogleOAuthParameters;
import com.google.gdata.client.authn.oauth.OAuthException;
import com.google.gdata.client.authn.oauth.OAuthHmacSha1Signer;
import com.google.gdata.client.contacts.ContactsService;
import com.google.gdata.data.contacts.ContactEntry;
import com.google.gdata.data.contacts.ContactFeed;
import com.google.gdata.util.ServiceException;

public class OAuthManager {

public static void main(String [] args) throws IOException, ServiceException
{
try {
//Setting 2-legged OAuth credentials
GoogleOAuthParameters oauthParam = new GoogleOAuthParameters();
oauthParam.setOAuthConsumerKey("domain.com");
oauthParam.setOAuthConsumerSecret("yourdomainconsumersecret");
oauthParam.setScope("http://www.google.com/m8/feeds/");
URL feedUrl = new URL("http://www.google.com/m8/feeds/contacts/default/full/?xoauth_requestor_id=email@domain.com");

ContactsService contactsService = new ContactsService("apps-name");
contactsService.setOAuthCredentials(oauthParam, new OAuthHmacSha1Signer());

//Making request to Google
ContactFeed resultFeed = contactsService.getFeed(feedUrl, ContactFeed.class);

System.out.println("Response Data:");
System.out.println("Title: " + resultFeed.getTitle().getPlainText());

System.out.println("Showing " + resultFeed.getEntries().size() + " contact(s).");
for(int i = 0; i < resultFeed.getEntries().size(); i++)
{
ContactEntry entry = resultFeed.getEntries().get(i);
System.out.println((i + 1) + ". " + entry.getTitle().getPlainText());
}
} catch (OAuthException e) {
e.printStackTrace();
}
}
}

Wednesday, December 10, 2008

Java SSL No Subject Alternative Matched

When you trying to connect to a server with untrusted SSL certificate, you might encounter below mentioned exceptions:
java.security.cert.CertificateException: No subject alternative names matching IP address xxx.xxx.xxx found
or
java.security.cert.CertificateException: No subject alternative DNS name matching hostname.com found.
The reason is because the certificate did not set the correct subject alternative value correctly. Two possible solution for above scenario:
  • Change certificate’s subject alternative value
  • Create customize HostnameVerifier
Change Certificate’s Subject Alternative Value

If you’re connecting to your host by using IP address, then you must change the subject alternative value to your IP address value. Likewise if you’re connecting using DNS name, the subject alternative value must match with the DNS name.

Create Customize HostnameVerifier

Basically you just need to create your customized HostnameVerifier class like example below:

private static class CustomizedHostnameVerifier implements HostnameVerifier {
public boolean verify(String hostname, SSLSession session) {
return true;
}
}


and then apply this class to your single SSL connection

HttpsURLConnection connection = (HttpsURLConnection) new URL("https://url").openConnection();
connection.setHostnameVerifier(new CustomizedHostNameVerifier());


or apply to all SLL connection

HttpsURLConnection.setDefaultHostnameVerifier(new CustomizedHostnameVerifier());


However this method might pose a security risk because basically we don’t verify the hostname anymore. The server may use other website’s certificate and the program will still accept it.

Java SSL Untrusted Certificate

When you trying to connect to a server with untrusted SSL certificate, you might encounter below mentioned exceptions:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
It was thrown because Java was unable to verify the validity of the certificate. In your web browser it might warn you that the certificate is untrusted and you’re still be able to add the certificate to a trusted list. But in Java, you’ll have to use a keytool to do the same thing.

You can find the keytool in your Java jdk bin directory. After you located your keytool, follow the steps:
  • Download your server certificate to your local machine
  • Insert to your Java cacerts by executing the keytool with some parameters:
    keytool -keystore ..\jre\lib\security\cacerts -import -alias anyaliasyoulike -file c:\path\to\your.crt -trustcacerts
  • Keystore password: changeit
If you did it correctly, it should notify you with: Certificate was added to keystore.

Quick tip:
  • To list all the certificate in keystore
    keytool -list -keystore ..\jre\lib\security\cacerts
  • To remove certificate from keystore
    keytool -delete -alias certalias -keystore ..\jre\lib\security\cacerts