Details
Description
Through studying the semaphore logic of the Thread Blocking environment a race condition was discovered causing another thread leak. Due to time-slicing it could happen that the Servlet Container supplied thread decides to use the semaphore logic to block and another thread trying to send a response decides the semaphore logic is not in effect yet and will not release the semaphore eventually. This causes the Servlet Container supplied thread to block and never gets unblocked.
public void respondWith(final ResponseHandler handler) throws Exception {
try {
super.respondWith(handler);
} finally {
if (semaphore == null) {
--> timeslicing
blockResponse = false;
} else {
semaphore.release();
}
}
}
public void blockUntilRespond() throws InterruptedException {
if (blockResponse) {
--> timeslicing
semaphore = new Semaphore(1);
semaphore.acquire();
boolean acquired = semaphore.tryAcquire(TIMEOUT, TimeUnit.MINUTES);
if (acquired) {
semaphore.release();
} else {
// log some warning
semaphore.release();
}
}
}
The thread blocking code (ThreadBlockingAdaptingServlet) should use immutable objects to avoid any synchronization issues.
public void respondWith(final ResponseHandler handler) throws Exception {
try {
super.respondWith(handler);
} finally {
if (semaphore == null) {
--> timeslicing
blockResponse = false;
} else {
semaphore.release();
}
}
}
public void blockUntilRespond() throws InterruptedException {
if (blockResponse) {
--> timeslicing
semaphore = new Semaphore(1);
semaphore.acquire();
boolean acquired = semaphore.tryAcquire(TIMEOUT, TimeUnit.MINUTES);
if (acquired) {
semaphore.release();
} else {
// log some warning
semaphore.release();
}
}
}
The thread blocking code (ThreadBlockingAdaptingServlet) should use immutable objects to avoid any synchronization issues.
Activity
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #19071 | Wed Jul 15 16:43:57 MDT 2009 | mircea.toma | |
Files Changed | ||||
![]() |
Field | Original Value | New Value |
---|---|---|
Salesforce Case | [] | |
Fix Version/s | 1.8.2 [ 10190 ] | |
Assignee | Mircea Toma [ mircea.toma ] |
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #19082 | Fri Jul 17 09:09:14 MDT 2009 | mircea.toma | |
Files Changed | ||||
![]() |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #19087 | Mon Jul 20 10:45:42 MDT 2009 | ted.goddard | TimeUnit.MINUTES from JDK 1.6 and backport-concurrent not available on JDK 1.5 ( |
Files Changed | ||||
![]() |
Salesforce Case | [] | |
Description | The thread blocking code (ThreadBlockingAdaptingServlet) should use immutable objects to avoid any synchronization issues. |
Through studying the semaphore logic of the Thread Blocking environment a race condition was discovered causing another thread leak. Due to time-slicing it could happen that the Servlet Container supplied thread decides to use the semaphore logic to block and another thread trying to send a response decides the semaphore logic is not in effect yet and will not release the semaphore eventually. This causes the Servlet Container supplied thread to block and never gets unblocked. public void respondWith(final ResponseHandler handler) throws Exception { try { super.respondWith(handler); } finally { if (semaphore == null) { --> timeslicing blockResponse = false; } else { semaphore.release(); } } } public void blockUntilRespond() throws InterruptedException { if (blockResponse) { --> timeslicing semaphore = new Semaphore(1); semaphore.acquire(); boolean acquired = semaphore.tryAcquire(TIMEOUT, TimeUnit.MINUTES); if (acquired) { semaphore.release(); } else { // log some warning semaphore.release(); } } } The thread blocking code (ThreadBlockingAdaptingServlet) should use immutable objects to avoid any synchronization issues. |
Fix Version/s | 1.8.2-RC1 [ 10210 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Simplify interaction with semaphore. Make ThreadBlockingRequestResponse immutable.