[ 
https://issues.apache.org/jira/browse/VYSPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262766#comment-13262766
 ] 

Paul Clare commented on VYSPER-309:
-----------------------------------

This one was really nasty to track down, like you I thought is was related to 
the synchonization on the request window however as it turns out this is not 
the case.

The problem lies in the way the BoshHander and BoshBackendSessionContext 
interact and shows up during the merging of the delay buffer.

Let's say we have two rids in the delayedQueue {001, 002} they will wait there 
untill the next request comes in from the client.

Client request 003 comes in and is inserted into the session 
(BoshBackendSessionContext.insertRequest)

The session determines it needs to flush the delay buffer {001, 002) to rid 003.

003 is now in the request window and and when the delayed response is flushed 
003 will be removed from the request window.

The problem is that 003's stanza was never processed by the BoshHandler so it 
is basically "dropped".

It is not a race condition as far as I can tell, just the way the code is 
written. 

In BoshHandler.process()...

synchronized (session) {
  session.insertRequest(br);
       ...  ...
  processSession(session, br);
}

Before processSession can be called, the session will hadle the delayed 
response merging and in doing so with remove 003 from the request window. 

When processSession is invoked it will find an empty requestWindow for 003 and 
go on it's merry way.

For POC I added the followling line to BoshBackendSessionContext.insertRequest 
and although it is ugly there are no longer any dropped stanzas.

if (mergedResponse != null) {
            *** boshHandler.processSession(this, br); ***
            writeBoshResponse(mergedResponse);
            return;
        }





                
> BOSH plugin does not always send or recieve messages from client
> ----------------------------------------------------------------
>
>                 Key: VYSPER-309
>                 URL: https://issues.apache.org/jira/browse/VYSPER-309
>             Project: VYSPER
>          Issue Type: Bug
>          Components: BOSH
>    Affects Versions: 0.7
>         Environment: Tomcat 7.0.25 / Tomcat 7.0.27 / Jetty 8.1.2
>            Reporter: Stig Runar Vangen
>
> The BOSH extension does not always return a result from a request. I saw the 
> same behavior using both the Jetty Continuation API's and the Servlet 3.0 
> API's. The result of this is that Emite (http://code.google.com/p/emite/) 
> never finished logging in. I also tried using Pidgin (http://www.pidgin.im/), 
> which has BOSH support if you enable it. Using Pidgin I was able to log in 
> successfully, but chatting was a bit problematic. Sending a message to the 
> server wasn't noticed by the server using an already open async request. I 
> know the server never received the message as I had enabled both console 
> logging of all BOSH messages as well as database logging of all chat 
> messages. When Piding lost the connection and created a new one however, the 
> message was resent, and the message got through. I then also received pending 
> messages from others.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to