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
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Ken Fyten
made changes -
Fix Version/s | 1.8.2-RC1 [ 10210 ] |
Jack Van Ooststroom
made changes -
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. |
Mircea Toma
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Mircea Toma
made changes -
Field | Original Value | New Value |
---|---|---|
Salesforce Case | [] | |
Fix Version/s | 1.8.2 [ 10190 ] | |
Assignee | Mircea Toma [ mircea.toma ] |
Mircea Toma
created issue -