> 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).

I agree, it is very vague.  I don't understand what the proper behavior should 
be for a missing RID.  The connection manager is suppose to keep the request in 
order before sending to the server, but how long should it wait to send a 
request if the previous RID was missing?  Any thoughts/opinions on this anyone? 
 Maybe I'm missing something in the spec.

> 
> <snip>
> 
> For now I just changed the WHILE loop to an IF statement and we have not run 
> out of memory since.

We did the same thing and it seems to be working for us as well.  Thanks for 
the advice.

> 
> 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 
> 

----------------------------------------
Mike Mahoney
OEM Application Specialist
ThingWorx
Office:   (610) 594-6200 x817
Mobile: (585) 314-8592

Reply via email to