Programming | edwin's journey

Weird Exception, “Unsupported startup parameter: extra_float_digits” When Connecting to PostgreSQL

2 Comments / Database, Programming / By edwin

Today I’m planning on deploying my application (which runs well on my local laptop), to a production server. But there is a very weird error occur, it says

Caused by: org.postgresql.util.PSQLException: ERROR: Unsupported startup parameter: extra_float_digits
	at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:291)
	at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:108)
	at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
	at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125)
	at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)

Somehow it seems that the error happen because of some wrong PostgreSql JDBC version. But the error stays even if I changed my Postgresql JDBC version several times. So my temporary conclusion is, improper Postgresql configuration.

After debating with several sysadmins and DBA, i found out that my sql connection actually goes to a Connection Pooling called PGBouncer, instead of connecting directly to Postgresql. Weird, because i also using Connection Pooling (Apache DBCP) for my application. So it means that my app is using a double connection pooling 😀

After spending sometime googling, i found out that all i need to do is adding this simple configuration on pgbouncer.ini

ignore_startup_parameters = extra_float_digits

hint :
If your are unable to found the location for pgbouncer.ini, just using a simple ps -ef command on console.

bash-4.1$ ps -ef | grep pgbouncer
500      18927     1  0 May30 ?        00:00:00 /opt/PostgresPlus/pgbouncer-1.6/bin/pgbouncer -d /opt/PostgresPlus/pgbouncer-1.6/share/pgbouncer.ini
500      19045 18913  0 00:11 pts/4    00:00:00 grep pgbouncer

As you can see, the pgbouncer.ini location is in /opt/PostgresPlus/pgbouncer-1.6/share/.

Well, one thing solve, and suddenly i found another error :sigh. So many errors today. Here is my complete stacktrace

 org.postgresql.util.PSQLException: ERROR: No such database: mydatabase
 	at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:291)
	at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:108)
	at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
	at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125)
	at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)
	at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:22)
	at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:30)

Somehow i cannot find mydatabase, despite i already created it.

Actually, the answer is simple. Again pgbouncer is the culprit. I cannot connect to a database if the database havent registered yet at pgbouncer.ini. Registering my database solve this issue.

;; database name = connect string
;;
;; connect string params:
;;   dbname= host= port= user= password=
;;   client_encoding= datestyle= timezone=
;;   pool_size= connect_query=
[databases]

; foodb over unix socket
edb = host=127.0.0.1 port=5444
mydatabase = host=127.0.0.1 port=5444

You can see my PostgreSQL’s port is 5444.

Hopefully, my tutorial helps other. Because i spent a ridiculously amount of time solving it 😀

ServletContext.getRealPath Always Return Null on Apache Tomcat 8

Leave a Comment / Java, Programming / By edwin

I met a very strange error, that somehow works on Tomcat 7, but not working on Tomcat 8. I’m using ServletContext’s class getRealPath method, for getting my application’s absolute file path. Here is my code,

@PostConstruct
    private void init() {
        try {
            // get report location
            String reportLocation = servletContext.getRealPath("WEB-INF");           
        } catch (Exception e) {
            logger.error(e.getMessage(), e);
        }
    }

On this code, i’m trying to get my report’s location and then processing it, by using servletContext.getRealPath. Which works well on my Apache Tomcat 7, but not well enough on Apache Tomcat 8. Somehow it always show null instead of the absolute path of my “WEB-INF” folder.

The workaround is actually quite simple, adding slash in front of “WEB-INF” make the problem disappear.

@PostConstruct
    private void init() {
        try {
            // get report location
            String reportLocation = servletContext.getRealPath("/WEB-INF");           
        } catch (Exception e) {
            logger.error(e.getMessage(), e);
        }
    }

How to Deploy War File Manually On JBOSS EAP 6.2.0

Leave a Comment / Java, Programming / By edwin

I usually deploy my war file into JBOSS EAP, using JBOSS’ web console. But i found a very weird condition where i cannot access my web console, so i need to deploy my war file manually from the server’s local disk.

This is how my EAP web console looks like, where i used to deploy my War file.

So basically what i do is i use FTP to transfer my war file from my local disk to the server’s disk, and after that i copy my war file to EAP’s deployment folder. Well in my case, this is my folder location

/usr/share/eap/standalone/deployments

After a while, there will be a file, with the same name as my war file, but with an added extension (.deployed). It means that my war file, has successfully deployed.

Those new file with extension are called marker files, and they have a different function depends on their extension. Different marker file suffixes have different meanings. And the relevant marker file types are, based on README.txt file,

.dodeploy — Placed by the user to indicate that the given content should be deployed into the runtime (or redeployed if already deployed in the runtime.)

.skipdeploy — Disables auto-deploy of the content for as long as the file is present. Most useful for allowing updates to exploded content without having the scanner initiate redeploy in the middle of the update. Can be used with zipped content as well, although the scanner will detect in-progress changes to zipped content and wait until changes are complete.

.isdeploying — Placed by the deployment scanner service to indicate that it has noticed a .dodeploy file or new or updated auto-deploy mode content and is in the process of deploying the content. This marker file will be deleted when the deployment process completes.

.deployed — Placed by the deployment scanner service to indicate that the given content has been deployed into the runtime. If an end user deletes this file, the content will be undeployed.

.failed — Placed by the deployment scanner service to indicate that the given content failed to deploy into the runtime. The content of the file will include some information about the cause of the failure. Note that with auto-deploy mode, removing this file will make the deployment eligible for deployment again.

.isundeploying — Placed by the deployment scanner service to indicate that it has noticed a .deployed file has been deleted and the content is being undeployed. This marker file will be deleted when the undeployment process completes.

.undeployed — Placed by the deployment scanner service to indicate that the given content has been undeployed from the runtime. If an end user deletes this file, it has no impact.

.pending — Placed by the deployment scanner service to indicate that it has noticed the need to deploy content but has not yet instructed the server to deploy it. This file is created if the scanner detects that some auto-deploy content is still in the process of being copied or if there is some problem that prevents auto-deployment. The scanner will not instruct the server to deploy or undeploy any content (not just the directly affected content) as long as this condition holds.

How to Create A HTTP Request with Proxy Using Apache HTTP Client

Leave a Comment / Java, Programming / By edwin

In this tutorial, im trying to simuate a http GET request using apache http client, the version im using is 4.5.1

<!-- http client -->
<dependency>
	<groupId>org.apache.httpcomponents</groupId>
	<artifactId>httpclient</artifactId>
	<version>4.5.1</version>
</dependency>
<dependency>
	<groupId>org.apache.httpcomponents</groupId>
	<artifactId>httpmime</artifactId>
	<version>4.5.1</version>
</dependency>

Usually, my application connects well without proxy. But on production environment, I need to put a proxy configuration. So this is my method for making a proxy request connection.

public String process(String lat, String lon) {
	try {
		HttpClient httpclient = HttpClientBuilder.create().build();
		HttpGet httpGet = new HttpGet("<INPUT YOUR URL HERE>");
		
		HttpHost proxy = new HttpHost("127.0.0.1", 3128, "http");
		RequestConfig config = RequestConfig.custom()
				.setProxy(proxy)
				.build();
		httpGet.setConfig(config);
		
		HttpResponse response = httpclient.execute(httpGet);
		HttpEntity resEntity = response.getEntity();

		String responseText = EntityUtils.toString(resEntity);		
		return responseText;
	} catch (IOException e) {
		logger.error(e, e);
	} catch (Exception e) {
		logger.error(e, e);
	}
	return null;
}

[Mule] Error 400 Bad Request, Request Header Or Cookie Too Large

Leave a Comment / ESB, Programming / By edwin

I had an error yersterday, when connecting Mule ESB to NGinx. Very weird, because somehow it never shown any errors when fired directly without a reverse proxy. Here is the complete stacktrace

<head><title>400 Request Header Or Cookie Too Large</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.4.4</center>
</body>
</html>
 (javax.xml.ws.soap.SOAPFaultException)
  org.apache.cxf.jaxws.JaxWsClientProxy:156 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/xml/ws/soap/SOAPFaultException.html)
3. Response was of unexpected text/html ContentType.  Incoming portion of HTML stream: <html>
<head><title>400 Request Header Or Cookie Too Large</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>Request Header Or Cookie Too Large</center>
<hr><center>nginx/1.4.4</center>
</body>
</html>

It happens because Mule, by default, send a very large cookies called “X-MULE_SESSION”. After removing it, my ESB runs well again. This is how i remove it,

<http:connector name="NoSessionConnector">
	    <service-overrides sessionHandler="org.mule.session.NullSessionHandler"/>
</http:connector>