Tuesday, June 24, 2014

java.sql.SQLException: ORA-01008: not all variables bound

One of the causes of this error can be found in the following snippet of code:

query = "select * from AAA where condn = ?";
pstmt = con.prepareStatement(query);
pstmt.setString(1, firstValue);
// ResultSet rs = pstmt.executeQuery(query); // Wrong Usage - Do not provide query again
ResultSet rs = pstmt.executeQuery(); // Correct Usage

Another reason is that you have not mapped all '?' with corresponding values

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal


package foo;

import java.math.BigDecimal;

public class BigDecimalTest {

   public static void main(String[] args) {

       BigDecimal foo = new BigDecimal("1");
       BigDecimal bar = new BigDecimal("125.4");

       BigDecimal result = foo.divide(bar);
       System.out.println(foo + " / " + bar + " = " + result);


The above example will result in a  

java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.. BigDecimal's divide() method uses a really effed up way to calculate the scale of the result: dividend.scale() - divisor.scale(). In order for this to work, you have to use one of the other divide() methods, where you can add another parameter specifying the scale or a predefined MathContext. Mh, I just noticed that the divide() method in question was added in 1.5, in 1.4 all divide() methods required a scale or RoundingMode.
As I see it, the new version of the method is pretty much useless,
since there's always the chance of breaking at runtime when you don't
have control over the values, e. g. if read from a database. Seems like
they tried to fix a class that's broken beyond all repair.

So a working version of the above example would look like this:

package foo;

import java.math.BigDecimal;
import java.math.RoundingMode;

public class BigDecimalTestScale {

   public static void main(String[] args) {

       BigDecimal foo = new BigDecimal("1");
       BigDecimal bar = new BigDecimal("125.4");

       BigDecimal result = foo.divide(bar, 3, BigDecimal.ROUND_HALF_UP);

       System.out.println(foo + " / " + bar + " = " + result);



java.net.SocketException: Connection reset by peer

The server is reporting "connection reset by peer" in the middle of a request. That means one of the following things:

  • The browser started a request and the user pressed STOP.

  • The browser started an request in one frame and JavaScript on another frame told it to go somewhere else (which has the same effect as a user pressing STOP).

  • You have a meta refresh reload someplace that is firing so fast that the previous request hasn't had a chance to complete yet. The five second periodicity makes me pretty suspicious of this.

  • You have some network component in between (a router or proxy) that is misbehaving.

  • You have some completely separate connection attempts going on that are disobeying the HTTP protocol (such as doing a telnet connection to port 8080 and then disconnecting).

Error message in the HTTP Server error.log: File does not exist:

Problem Description:
I have deployed an webapplication on Websphere Application server This runs on port 9080.
I have also deployed HTTP server and the plugin and are planning to use the HTTP Server as a proxy for the WAS server.
HTTP server is running on port 8080.

When trying to open following url: http://localhost:8080/myapp/signin.do I am supposed to be forwarded to the Application server where the myapp resources resides. This is not happening. Seems like the HTTP server is looking on its own document root instead of doing the actual forward.
Error message in the HTTP Server error.log:
File does not exist: D:/IBM HTTP Server/htdocs

Solution in my case was to manually set the port 8080 in the WAS admin console:
Environment -> Virtual Hosts -> Default host -> Host Aliases

Servlet Custom error page not shown

The Servlet 2.2 specification allows you to specify an error page (a servlet or a JSP) for different kinds of HTTP errors or ServletExceptions. You can specify this in deployment descriptor of the web application as:


where FooException is a subclass of ServletException.
The web container invokes this servlet in case of errors, and you can access the following information from the request object of error servlet/JSP: error code, exception type, and a message. Refer to section 9.8 of Servlet 2.2 spec.

Here is the document:

<?xml version="1.0"?>

<!DOCTYPE web-app

   PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"









The problem I am experiencing is that Internet Explorer refuses to show my error page and shows his.
I tried with different browsers (Mozilla, Opera) and the output of the 404.jsp page is nicely shown.

Solution 1: (Client Side)

Explorer catches the HTTP message code 404 and replaces all the content with its own error page.

To switch this feature off go to:
Tools -> Internet Options... -> Advanced.

Then look for "Show friendly HTTP error messages" and uncheck it. Click OK.

Solution 2: (Working Solution)

The custom error pages are catched and replaced if they are "too small".

Looks like that Explorer thinks your "small" page is too ugly and so decides to show his.

If the page weights a few Kb then it is shown: so you can either create
a nice looking page or you can add some extra spaces to you page to
meet the Explorer's expectations.

Solution 3:

try setting the status to 200 in your error jsp.
<% response.setStatus(200); %>
This should tell the browser that the request was valid and it will show your page instead of the 'Friendly Error Page'.