[jboss-dev-forums] [Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

[adrian@jboss.org]

I think I know what the problem is, but if I'm correct it will be very difficult to
reproduce the problem.

If you look at the old code in JBoss4, LoadMgr3 in nextTask()
when releaseInNextTask == true just removes the lock on the classloader
and unassigns the current thread as the owner of the classloader.

The important part is that it doesn't try to reschedule any outstanding tasks
back to their original threads. That only occurs in endLoadTask().


  |          if( threadTask.releaseInNextTask == true )
  |          {
  |             if( trace )
  |                log.trace("Releasing loadLock and ownership of UCL: "+threadTask.ucl);
  |             synchronized( registrationLock )
  |             {
  |                loadClassThreads.remove(threadTask.ucl);
  |             }
  |             synchronized( threadTask.ucl )
  |             {
  |                ucl3.release();
  |                ucl3.notifyAll();
  |             }
  |          }
  | 

While in JBoss5, it does:

  |          if (threadTask.isReleaseInNextTask())
  |             threadTask.getClassLoader().unlock();
  | 

The classloader unlock() will always try to reassign the outstanding tasks
when it invokes ClassLoaderManager.unregisterLoaderThread()
so it is reassigning tasks in both places.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206697#4206697

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206697