Details
Bug
Major
Description
Upon closing a browser window/tab a dispose-views request is send by the Bridge to the Core in order to clean-up the View structure. As a Bridge instance can have multiple connections to the Core and uses the Heartbeat mechanism to check the connection health, it could happen that a ping and a dispose-views are received by the Core out of order: dispose-views and then ping. When the ping is handled the associated View structure has already been cleaned up. As a result no response was send to the ping request and due to the Thread Blocking environment the thread got blocked and never got unblocked as the ping request is a non-blocking request.
Basically, when a Ping request is received while it's ICEfaces ID is still valid but has no Views associated to it it should send back a Close response. Currently it does not send back anything causing it to be in a blockUntilRespond state, which it cannot get out of as it is a non-blocking Ping request.
Basically, when a Ping request is received while it's ICEfaces ID is still valid but has no Views associated to it it should send back a Close response. Currently it does not send back anything causing it to be in a blockUntilRespond state, which it cannot get out of as it is a non-blocking Ping request.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
There was one loophole for the Ping request where it wouldn't get a response:
String viewIdentifier = request.getParameter("ice.view");
CommandQueue queue = (CommandQueue) commandQueues.get(viewIdentifier);
if (queue != null)
else {
if (LOG.isWarnEnabled())
}
If the ice.session is valid but the ice.view has been cleaned up a warning would be logged but no response would be send back, causing the thread leak. Changing this to always send a NOOP response as follows solved the issues:
String viewIdentifier = request.getParameter("ice.view");
CommandQueue queue = (CommandQueue) commandQueues.get(viewIdentifier);
if (queue != null) { queue.put(PONG); } else {
if (LOG.isWarnEnabled()) { LOG.warn("could not get a valid queue for " + viewIdentifier); }
}
request.respondWith(NOOPResponse.Handler);
Marking this one as FIXED.
Show
Jack Van Ooststroom
added a comment - - edited There was one loophole for the Ping request where it wouldn't get a response:
String viewIdentifier = request.getParameter("ice.view");
CommandQueue queue = (CommandQueue) commandQueues.get(viewIdentifier);
if (queue != null)
{
queue.put(PONG);
request.respondWith(NOOPResponse.Handler);
}
else {
if (LOG.isWarnEnabled())
{
LOG.warn("could not get a valid queue for " + viewIdentifier);
}
}
If the ice.session is valid but the ice.view has been cleaned up a warning would be logged but no response would be send back, causing the thread leak. Changing this to always send a NOOP response as follows solved the issues:
String viewIdentifier = request.getParameter("ice.view");
CommandQueue queue = (CommandQueue) commandQueues.get(viewIdentifier);
if (queue != null) {
queue.put(PONG);
} else {
if (LOG.isWarnEnabled()) {
LOG.warn("could not get a valid queue for " + viewIdentifier);
}
}
request.respondWith(NOOPResponse.Handler);
Marking this one as FIXED.
Changed Fix Version(s) to 1.8.2