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;