According to XEP-0124 BOSH spec section 12 ([http://www.xmpp.org/extensions/xep-0124.html#poll]) , http-bind should check client polling interval only for “polling sessions”.A polling session is defined at the beginning of section 12. There are 2 bugs involved:
Openfire checks polling interval even for non-polling sessions.
Even for polling sessions , Openfire ignores the clause in section 12 which says “and if the connection manager’s response to the first request contained no stanzas."
The consequence of these bugs is unnecessary delay and breaks the essential technique of the BOSH spec which says "As soon as the client receives a response from the connection manager it sends another request, thereby ensuring that the connection manager is (almost) always holding a request that it can use to 'push' data to the client. ". A compliant client will be disconnected by Openfire http-bind incorrectly due to this incorrect check of polling interval.
To fix it, in HttpSession.java, method addConnection(), checkPollingInterval should be called only if this session is a polling session AND http-bind’s response to the last poll
Combined with these problems of 100% CPU usage in the HTTP Bind component, deadlocks, and incomplete spec implementation has us possibly looking elsewhere. Can anyone recommend an alternate HTTP binding (proxy, hopefully, so it can at least be used with Openfire) component?
The conditions you mention are not in this version, Openfire will behave accordingly when it is upgraded to utilized the latest version of the XEP.
That spec version also states that the client “SHOULD make a new request as soon as possible.” That draft and the accepted spec work in the same way. It’s how binding was designed from the start. The client submits an empty stanza, and waits for data. Upon receiving data it immediately connects again in the same way. The problem is when 2 messages are received a couple seconds apart (for example) - the client HAS to disconnect and reconnect to see the second message. The “checkPollingInterval()” in HttpSession.java is not smart enough to handle this case.
We ran into the same problem while investigating some work for a potential client. As a potential work around instead of sending an empty stanza you can send a stanza with an empty presence packet. Such as the following:
It’s not an ideal solution, and we didn’t investigate what (if any) side effects this may cause but it will keep Openfire from sending a 403 when it mistakenly thinks it is being polled too frequently.
We ran into the same problem while investigating some work for a potential client. As a potential work around instead of sending an empty stanza you can send a stanza with an empty presence packet. Such as the following:
It’s not an ideal solution, and we didn’t investigate what (if any) side effects this may cause but it will keep Openfire from sending a 403 when it mistakenly thinks it is being polled too frequently.
Hope that helps,
Ryan
Ryan,
Although a potential, temporary solution, the problem with this is that anyone with subscription to this user will receive a presence packet. This will cause these users to have to constantly poll the BOSH server, sending more presence packets and perpetuating the problem.
Although a potential, temporary solution, the problem with this is that anyone with subscription to this user will receive a presence packet. This will cause these users to have to constantly poll the BOSH server, sending more presence packets and perpetuating the problem.
Like we’ve both said, it is just a potential, short-term solution and sending empty presence packets was the quickest way to implement it. If we had gone forward with an Openfire/BOSH solution we might have had the client send a custom iq packet to an Openfire plugin that would basically discard the packet upon receiving it.
Ideally, of course, it would nice if the spec was fully implemented within Openfire. Have you studied the Openfire code to see how close it is to being 1.5 or 1.6 compliant? Are you aware of any BOSH testing tools that could be used to speed along development of making it standards compliant?
No, unfortunately (fortunately? =D) I am not a Java developer. Right now I’m actually dealing with a polling issue that is basically causing our client to appear slow because we can’t ask for data fast enough (upon login). I’m considering reverting to an older version of Openfire where I might be able to look at the way Sparkweb went about grabbing the roster so quickly.
The code you showed indicates that it checks only for “polling packets”, which is used by both “polling connection” and non-polling connection. My first posting has details on what exactly the spec says. If you have questions, please continue the discussion here. This is definitely a problem.
I’m using a javascript client with openfire http-bind and xmpp.httpbind.client.requests.polling property set to 0!file:///C:/DOCUME%7E1/Ofir/LOCALS%7E1/Temp/moz-screenshot.jpg!
I have issues with and I’m not sure if it is a client bug or related to this discussion.
Can you please explain in what circumstances the current implementation of BOSH should end a client connection and what will be written in the error log?
Is there a temporary workaround?
In my case clients are being disconnected once per few hours with no evident reason.