Problems with HTTP binding

Candy maintainer here. You might care that people are still reporting that HTTP binding is unreliable. We experienced the same problems years ago.

Related thread on our mailing list: https://groups.google.com/forum/#!topic/candy-chat/6afPFX8SHeE

Cheers,

Patrick

I’ve had this issue too, while implementing BOSH:

(returned by Openfire.)

After checking Openfire logs I saw something like:

rid 123456 > 123455.

It turned out, that I’ve sent a with a an unexpected rid, e.g. Openfire expected 123455, but I’ve sent 123456 instead (before sending 123455).

In your logs in the mailing list, you sent:

2962056780

2962056781

2962056780 (I suspect this to be the problem).

Although I believe according to the spec, an XMPP Connection Manager should just return a cached element for cases, when an ack was not received and the client tries to resend an old message (with old rid).

I still remember that this was a problem related to Openfire. Back in 2011 when we used Openfire in production we ran into the exact same issues. I won’t go any further here, just wanted to let you know that such problems exist.

So you want to say, that Openfire does not cache old requests, and instead of resending them to the client it terminates the connection?

Definitely a more serious bug.

According to this post, Punjub would solve this problem. Can you confirm?

(I’m not sure if other BOSH servers support this, but Punjab will cache and resend request responses.)

I don’t know what Openfire does or does not, I just said that the HTTP binding part seems to be unreliable.

Yes, punjab improves the situation.

Thanks for reporting.

The problem is that we need folks to take the extra step of solving the problem by looking at the Openfire source code and posting a fix that we can apply. There is no one free to look at issues as they are reported. The few people who are available just look at issues that affect them.

I have stoped using BOSH in favour of websockets

I can understand that. Openfire is a great product, that’s why I felt obligated to report this here.

Best wishes,

Patrick

Yes punjab improved the starvation by extending the timeout delays to around 12 hours where the default http-bind from open fire was causing the timeout in matter of minutes in some cases, this was primarily happening on slow connections,

I will try to enable debug and catch the problem and report later, thanks for everyone’s support on this matter

Did anyone found a solution, as after few mins i too get logout when i get following stanza

i tried specifying connectionTimeout in PassProxy but that didnt work

i have read somewhere that i need to use punjab for that , is that really required ?

implementing ping functionality resolved the issue to some extent http://xmpp.org/extensions/xep-0199.html