I do not think any sort of synchronization will help in this particular case
although I agree the implementation could use some more comments so it could
be improved upon.
However the spec is also extremely vague when it comes to the connection
manager.
The RIDs (317, 319) are within in the "window" as per the spec, 318 never
makes it to the server (again this is to be expected as per the spec).
(A disturbing point here is that all these requests are "empty" keep alives)
IF the continuation expires BEFORE Jetty has determined the socket has been
dropped the server will run out of memory every time because the loop is
tight and the state will never change.
I am still quite puzzled as to why this was done in the first place, there
does not seem to been a reason to write more than a single "keep-alive"
response from this Jetty upstream notification.
synchronized private void requestExpired(Continuation continuation) {
... ...
while (!requestsWindow.isEmpty() && requestsWindow.firstKey() <=
req.getRid()) {
write0(boshHandler.getEmptyResponse());
}
For now I just changed the WHILE loop to an IF statement and we have not run
out of memory since.
The delayed response queue will rise and fall normally and there do not
appear to be any dropped stanzas.
-paul
-----Original Message-----
From: Bernd Fondermann
Sent: Wednesday, April 04, 2012 4:50 PM
To: [email protected]
Subject: Re: BoshBackendSessionContext.requestExpired - InfiniteLoop
On 04.04.12 19:53, Mike Mahoney wrote:
I have been struggling with an issue where more than occasionally
the delayedResponseQueue will be filled with empty responses until
the server eventually runs out of memory. The client is JSJac but I
am not really focused on that implementation, I just want to try
and protect the server from being over run by any client.
We're running into the same issue now using Strophe, so it probably
isn't due to the client.
<snip>
If an rid is skipped, as in the scenario you outlined, then the
highestReadRid won't be incremented to 319 and will remain as 317
forever. Which causes the firstKey to be greater than the
highestReadRid. That loop doesn't seem right to me.
Thoughts?
Yes. I think BoshBackedSessionContext needs a major refactoring. The
whole logic around queuing is flawed and hard to understand
(code-readability). Missing synchronized statements can cause even more
trouble.
Bernd
