db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Lock table messages are truncated in Client/Server mode
Date Tue, 06 Dec 2005 20:31:12 GMT
I'm moving this message from the derby-user list to the derby-dev
list because I've investigated further, and now I wish to discuss
code.

I've stepped through my test case in the debugger and discovered
the following:

1) The truncation occurs in DRDAConnThread.buildSqlerrmc(), at
    about line 5220:

    // Truncate the sqlerrmc to a length that the client can support.
    int maxlen = (sqlerrmc == null) ? -1 : Math.min(sqlerrmc.length(),
		appRequester.supportedMessageParamLength());

2) appRequest.supportedMessageParamLength is very simple:

    protected int supportedMessageParamLength() {

       switch (clientType) {

           case JCC_CLIENT:
           case DNC_CLIENT:
              return Limits.DB2_JCC_MAX_EXCEPTION_PARAM_LENGTH;
           default:
              // Default is the max for C clients, since that is more
              // restricted than for JCC clients.  Note, though, that
              // JCC clients are the only ones supported right now.
              return Limits.DB2_CCC_MAX_EXCEPTION_PARAM_LENGTH;

       }

   }

3) Limits defines DB2_JCC_MAX_EXCEPTION_PARAM_LENGTH as 2400:

    // Warning. Changing this value will affect upgrade and the creation of the
    // SQLCAMESSAGE procedure. See org.apache.derby.impl.sql.catalog.
    public static final int DB2_JCC_MAX_EXCEPTION_PARAM_LENGTH = 2400;

So now I understand why the lock table is truncated to 2400 bytes
when running in Network Server mode.

Unfortunately, this is a pretty severe constraint for me, since a
truncated lock table is not of very much value, so I would like to
explore this a bit further and understand whether the limit can be
raised.

Can somebody help me understand the comment in Limits.java, and what
would be the implication of allowing longer error messages to be
returned from the Network Server to the client?

thanks,

bryan


-------- Original Message --------
Subject: Lock table messages are truncated in Client/Server mode
Date: Sat, 03 Dec 2005 08:42:01 -0800
From: Bryan Pendleton <bpendleton@amberpoint.com>
Reply-To: Derby Discussion <derby-user@db.apache.org>
To: Derby Discussion <derby-user@db.apache.org>

Hi all,

I think this is a bug, but I wanted to ask the list before
reporting it as such.

I am running Derby 10.1.1.0 in Network Server mode.
My application intermittently encounters lock timeouts. To diagnose
them, I have derby.locks.deadlockTrace=true in order to print the
lock table when the timeout is encountered.

When the lock times out, I get message 40XL2 as I expect. However,
the symptom that concerns me is that the message is truncated, to
some length around 2,500 characters.

Is there some sort of max limit to the size of a message which can
be returned to the client in Network/Server mode? It does appear
that the entire message is printed to derby.log, so perhaps the
truncation occurs when transmitting the exception from server to
client?

I created a small test program, below, and ran it in two
configurations:
- when I run derby embedded, the entire lock table is displayed
- when I run derby client/server, the lock table is truncated, after
   about half-a-dozen lines are printed.

Is this a bug? If so, I will file the bug and ask the developers
list for some help in diagnosing it. I searched JIRA but didn't
find anything obvious (though I'm still learning how to use the
JIRA search tools).

thanks,

bryan

----------------------- Test program is below -------------------

-- How to use:
-- 1) set derby.properties to contain
--    derby.locks.deadlockTrace=true
-- 2) Start the network server
-- 3) create a database called 'testLockTimeout'
-- 4) Adjust this script to give the proper 'connect' statements
-- 5) run this script from ij
--
-- the point of the script is that it creates a whole lot of tables
-- then arranges for a lock timeout, to see if all the tables are reported
-- properly when derby.locks.monitor is set.
--
-- Use these to run embedded, where the full lock table is printed correctly:
-- connect 'jdbc:derby:testLockTimeout' as me;
-- connect 'jdbc:derby:testLockTimeout' as you;
-- 
-- Use these to run in Network Server mode, where the table is truncated:
connect 'jdbc:derby://localhost:1527/testLockTimeout' as me;
connect 'jdbc:derby://localhost:1527/testLockTimeout' as you;

set connection me;
drop table a;
drop table b;
drop table c;
drop table d;
drop table e;
drop table f;
drop table g;
drop table h;
drop table i;
drop table j;
drop table k;
create table a(a integer);
create table b(b integer);
create table c(c integer);
create table d(d integer);
create table e(e integer);
create table f(f integer);
create table g(g integer);
create table h(h integer);
create table i(i integer);
create table j(j integer);
create table k(k integer);
commit;

set connection you;
autocommit off;

set connection me;
autocommit off;

lock table a in exclusive mode;
lock table b in exclusive mode;
lock table c in exclusive mode;
lock table d in exclusive mode;
lock table e in exclusive mode;
lock table f in exclusive mode;
lock table g in exclusive mode;
lock table h in exclusive mode;
lock table i in exclusive mode;
lock table j in exclusive mode;
lock table k in exclusive mode;

-- This, of course, will block, and will (after the configured number of
-- seconds have passed) return a lock timeout.

set connection you;
lock table a in exclusive mode;



Mime
View raw message