Rids getting out of order frequently

[Vineet Naik]

Hello,

I am working on a one-to-one chat app using Strophe 1.0.2,

ejabberd 2.1.10 over BOSH (proxied by apache2) and facing the

problem that when messages are sent quickly, the rids sent with

the http bind requests get out of order and the session is

terminated. This happens rather frequently and thus can be

reproduced easily (tried on Chrome and FF). The problem is

similar to the one described in this older post -

https://groups.google.com/forum/?fromgroups#!topic/strophe/cUG6cQnSiLM

I managed to find a pattern from the exported HAR content and the

ejabberd and apache2 log files.

Here are some of the http-bind requests with their status codes

and the corresponding info logged by ejabberd and apache2.

Rid           resp status   ejabberd logs  apache logs

              (chrome)

 

4197991538    200 ok         sends          200

        39    200 ok         sends          200

        40    0 cancelled    sends          200

        41    200 ok         ..             ..

        ..    ..             ..             ..

        ..    ..             ..             ..

        49    200 ok         ..             ..

        40    200 ok         bad_key        200

        50    404                           404

        51    404                           404

Notice that the request with rid=4197991540 is cancelled for some

reason but strangely it reaches ejabberd and gets logged

there. It seems when strophe retries to send the request some

requests have already been sent and the rid has jumped to

4197991549 so ejabberd returns 404 and closes the

session. The "timings" info from HAR file shows a blocked time of

246ms for the retried 4197991540 request.

Having a difficulty figuring out which component (strophe, ejabberd, or apache) 

might be causing the problem. What's exactly happening here? 

Thanks,

Vineet

[Matthew Wild]

On 14 June 2013 09:16, Vineet Naik <nai...@gmail.com> wrote:
> Hello,
>
> I am working on a one-to-one chat app using Strophe 1.0.2,
> ejabberd 2.1.10 over BOSH (proxied by apache2) and facing the
> problem that when messages are sent quickly, the rids sent with
> the http bind requests get out of order and the session is
> terminated. This happens rather frequently and thus can be
> reproduced easily (tried on Chrome and FF). The problem is
> similar to the one described in this older post -
> https://groups.google.com/forum/?fromgroups#!topic/strophe/cUG6cQnSiLM

Hmm. As far as I know, ejabberd handles out-of-order requests (this is
described in the BOSH XEP). However the server is only required to
allow requests within a certain fixed window. Generally he client is
not supposed to have more than 2 outstanding requests at any time.
From your data, can you see if Strophe is violating this?

If it is, it's a problem with Strophe - it should hold onto outgoing
messages until it receives a response from the server, then it can
make a new request. If it isn't, it's a problem with ejabberd - it
shouldn't process the second request until it has received the first.

Regards,
Matthew

[Vineet Naik]

Thanks for the reply

On Fri, Jun 14, 2013 at 2:16 PM, Matthew Wild <mwi...@gmail.com> wrote:

On 14 June 2013 09:16, Vineet Naik <nai...@gmail.com> wrote:
> Hello,
>
> I am working on a one-to-one chat app using Strophe 1.0.2,
> ejabberd 2.1.10 over BOSH (proxied by apache2) and facing the
> problem that when messages are sent quickly, the rids sent with
> the http bind requests get out of order and the session is
> terminated. This happens rather frequently and thus can be
> reproduced easily (tried on Chrome and FF). The problem is
> similar to the one described in this older post -
> https://groups.google.com/forum/?fromgroups#!topic/strophe/cUG6cQnSiLM

Hmm. As far as I know, ejabberd handles out-of-order requests (this is
described in the BOSH XEP). However the server is only required to
allow requests within a certain fixed window. Generally he client is
not supposed to have more than 2 outstanding requests at any time.
From your data, can you see if Strophe is violating this?

If it is, it's a problem with Strophe - it should hold onto outgoing
messages until it receives a response from the server, then it can
make a new request.

The problem is, periodically a request is marked as cancelled but Strophe goes 

ahead and sends further messages and after a while tries to resend the cancelled one.

Also, I tested a bit more on FF and found that it doesn't always resend the cancelled 

request but Chrome always does. Can this be a browser issue? 

Regards,

Vineet

 

If it isn't, it's a problem with ejabberd - it
shouldn't process the second request until it has received the first.

Regards,
Matthew

--
You received this message because you are subscribed to the Google Groups "Strophe" group.
To unsubscribe from this group and stop receiving emails from it, send an email to strophe+u...@googlegroups.com.
To post to this group, send email to str...@googlegroups.com.
Visit this group at http://groups.google.com/group/strophe.
For more options, visit https://groups.google.com/groups/opt_out.

[Daniel Dormont]

I'm not sure if this matters or not, but what "hold" value are you using in your BOSH session? 

dan

[Jack Moffitt]

> The problem is, periodically a request is marked as cancelled but Strophe
> goes
> ahead and sends further messages and after a while tries to resend the
> cancelled one.
> Also, I tested a bit more on FF and found that it doesn't always resend the
> cancelled
> request but Chrome always does. Can this be a browser issue?

Is this someone hitting escape? That can cancel XHR requests I think.

Canceled or failed requests are fine. Strophe will try to the resend
them, and this is ok. The BOSH spec allows for this, because there are
network conditions under which the client cannot know if the server
has or has not processed the message. The server is supposed to
respond with the exact same content it did before if it sees a
duplicate request. Note that there is a bounded window of RIDs where
this behavior is valid.

Are you using current master? If not, you should be. The released
version is probably quite old. Someone should do a new release of
master.

jack.

[Vineet Naik]

On Fri, Jun 14, 2013 at 7:16 PM, Daniel Dormont <d...@greywallsoftware.com> wrote:

I'm not sure if this matters or not, but what "hold" value are you using in your BOSH session? 

It is the default value of 'hold' (1)

Thanks,

Vineet

[Vineet Naik]

On Fri, Jun 14, 2013 at 8:09 PM, Jack Moffitt <ja...@metajack.im> wrote:

> The problem is, periodically a request is marked as cancelled but Strophe
> goes
> ahead and sends further messages and after a while tries to resend the
> cancelled one.
> Also, I tested a bit more on FF and found that it doesn't always resend the
> cancelled
> request but Chrome always does. Can this be a browser issue?

Is this someone hitting escape? That can cancel XHR requests I think.

I just tried it, hitting escape is not cancelling requests for me. Also, I guess 

this case is highly unlikely.

 

Canceled or failed requests are fine. Strophe will try to the resend
them, and this is ok. The BOSH spec allows for this, because there are
network conditions under which the client cannot know if the server
has or has not processed the message. The server is supposed to
respond with the exact same content it did before if it sees a
duplicate request. Note that there is a bounded window of RIDs where
this behavior is valid.

Are you using current master? If not, you should be. The released
version is probably quite old. Someone should do a new release of
master.

Ok, I am using a pretty older version in that case (downloaded almost an

year ago), didn't update since I found the version to be unchanged.

I will try upgrading to current master and post an update by tomorrow. 

Thanks, 

Vineet

 

jack.