db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Noll <dan...@nuix.com>
Subject Re: NPE getting length of Blob
Date Tue, 04 Mar 2008 21:58:15 GMT
On Tuesday 04 March 2008 21:14:43 Narayanan wrote:
> Can you give more information about the code that uses this?

It looks like this.  I've omitted some of the code which was present as it was 
calling framework methods anyway.

private long id;

public int read(byte[] b, int off, int len) {
  Connection conn = (get from pool)
  try {
    PreparedStatement ps = conn.prepareStatement("SELECT data FROM binaries 
WHERE id = ?");
    ResultSet rs = null;
    try {
      ps.setLong(1, id);
      rs = ps.executeQuery();
      if (rs.next()) {
        Blob blob = rs.getBlob("data");
        int pos = pointer + 1;
        int length = (int) Math.min(blob.length() - pointer, len);//throws NPE
        if (length == 0) {
          return -1;
        } else {
          byte[] tmp = blob.getBytes(pos, length);
          System.arraycopy(tmp, 0, b, off, length);
          pointer += length;
          return length;
        }
      }
    } finally {
      if (rs != null) rs.close();
      ps.close();
    }
  } finally {
    conn.commit();
    conn.close();
  }
}

This is part of an InputStream implementation so it's being called multiple 
times in a row with different offset and length.

If I try this on a fresh connection by itself, it doesn't occur.  The only 
thing that really seems unique about running it in the application itself is 
that we're accessing it through a connection pool.  I'm still attempting to 
get it to happen standalone so I can open a proper bug record for it.

> Can you check what version is the derby network server? What version is
> the network client?

They are the versions I specified in the previous mail.  In both situations I 
used the same version for the server and the client; I haven't tried one 
version of the server against the other version of the client (nor vice 
versa.)

> This information will be very useful if we try to single step the code
> to find out
> the problem source.

I was able to finally reproduce the problem on my own machine so it isn't 
dependent on the network, and I have confirmed that it isn't dependent on the 
type of data in the database either although since I have only managed to 
reproduce it in our own application, all databases tested have more or less 
the same schema.

The same code on the embedded version does work.  Additionally the same code 
on 10.2.2.0 client/server works fine too.

Daniel

Mime
View raw message