db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Fredriksson <andreas.fredriks...@digitalroute.com>
Subject Re: Class loading deadlock
Date Tue, 13 Sep 2005 14:15:07 GMT
On Tue, 2005-09-13 at 06:52 -0700, Daniel John Debrunner wrote:

> I working in Derby's classloader area at the moment, so I'll look into
> this, do you have a simple reproducible case?

Hi Daniel,
I don't think it's easily reproducible without breaking some rules.

Here's an idea for a testcase (untested, but probably not too far off):

Write a ClassLoader that performs some random query against a database
before calling the parent's findClass() method. Making this query take a
long time is a good idea. Maybe a CREATE FUNCTION that maps to
Thread.sleep() would help. A slow query increases the window for
deadlock, but it might need to vary because of caching schemes inside
Derby I'm not aware of--just include the class name as a query parameter
or so.

public class TestClassLoader {
   public Class findClass(String name, boolean resolve) {
	issueTestQuery(name);
	return super.findClass();
   }
}

Set your TestClassLoader as the context class loader for both threads:

TestClassLoader myClassLoader = new TestClassLoader();
thread_a.setContextClassLoader(myClassLoader);
thread_b.setContextClassLoader(myClassLoader);

Have one thread continually try to load bogus classes from this class
loader so that the findClass() map will always fail and your loadClass()
will be called. This first thread represents the ClassLoader->DB lock
chain.

for (;;) {
   String pkg = "nonexistent.package.foo_" + System.currentTime();
   try {
      Class.forName(pkg);
   } catch (ClassNotFoundException ignored) {}
}

Have one other thread continually run a large query against Derby (with
its context class loader also set to myClassLoader). With luck this
query will trigger the DB->ClassLoader lock chain and you will see the
deadlock eventually.

for (;;) {
   issueLargeQuery();
}

This should produce the deadlock fairly quickly, if you have box with
more than one CPU; with one CPU you will have to wait for the scheduler
to timeslice the threads so that the deadlock can occur (that's why the
sleep inside the query helps).

Please let me know if there's anything else I can assist you with.

Best regards,
Andreas


Mime
View raw message