We've had a similar problem for a long running bean. We're running JBoss 3.2.1
against an Interbase database. The exception (javax.resource.ResourceException:
"Interrupted while requesting permit!") is thrown in the following piece of JBoss code:
| class org.jboss.resource.connectionmanager.InternalManagedConnectionPool
| ...
| private final FIFOSemaphore permits;
| ...
| public ManagedConnection getConnection(Subject subject, ConnectionRequestInfo
cri)
| throws ResourceException
| {
| subject = (subject == null)? defaultSubject: subject;
| cri = (cri == null)? defaultCri: cri;
| try
| {
| log.trace("jadigby: attempting get of permit with blockingTimout=" +
poolParams.blockingTimeout + ",permits available=" + permits.permits() + ",
Thread.isInterrupted()=" + Thread.currentThread().isInterrupted() );
| if (permits.attempt(poolParams.blockingTimeout)) // <==== THROWS
InterruptedException (jadigby)
| {
| ...
| } catch (InterruptedException ie)
| {
| ResourceException re = new ResourceException("Interrupted while
requesting permit!");
| re.initCause(ie);
| throw re;
| } // end of try-catch
|
(We've added the log.trace line ourselves). The problem is that permits.attempt(...)
fails immediately, where we really expected it to timeout after blockingTimeout
milliseconds. It fails because of the following code:
| class EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore extends QueuedSemaphore
| class EDU.oswego.cs.dl.util.concurrent.QueuedSemaphore:attempt
| public boolean attempt(long msecs) throws InterruptedException {
| if (Thread.interrupted()) throw new InterruptedException(); // <====
FAILS IMMEDIATELY HERE (jadigby)
| if (precheck()) return true;
| if (msecs <= 0) return false;
|
| WaitQueue.WaitNode w = new WaitQueue.WaitNode();
| return w.doTimedWait(this, msecs);
| }
|
SO, somewhere, sometime, previously in this Thread's execution, this thread has been
doing something (maybe Object.wait()?), that has been interrupted, but hasn't cleared
the thread's interrupted status. We've seen this explicitly as our inserted log.trace
method shows that Thread.currentThread().isInterrupted() is TRUE. Hence
permits.attempt(...) fails immediately.
Our quickfix hack has been to call Thread.currentThread().interrupted() immediately
before requesting any database connections. (See Thread Javadoc extracts below for
why this works) Problem disappeared (or at least is papered over for now). When we
get time, we'll try to find out where previously this Thread.interrupted has been set
(unless any other brave souls wish to volunteer?)
JavaDoc for java.lang.Thread:
public static boolean interrupted()
....Tests whether the current thread has been interrupted. The interrupted status of
the thread is cleared by this method...
public boolean isInterrupted()
....Tests whether this thread has been interrupted. The interrupted status of the
thread is unaffected by this method.
Our hack in our application code:
| if (Thread.currentThread().isInterrupted())
| {
| l4jLogger.debug("clearing thread interrupted flag");
| Thread.interrupted();
| }
| javax.sql.DataSource ds =
ServiceLocator.getInstance().getDataSource("java:comp/env/jdbc/AppDataSource");
|
Whew!
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3844753#3844753
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3844753
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
