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;

Reply via email to