I have been working hard on getting the binding working but keep running into a frustrating problem.
I am using the JSJAC libraries. (Have same issues when testing with JWCHAT which use the same libraries).
The problem is that chatting works fine, but when I send IQ messages for roster updates and others,
I don’‘t receive a response when there should be one. For example if I change an item group then I don’‘t receive the roster update back again, and can’'t update the local client roster.
However if I update the holds to 2 or 3 etc (so there is more than one bound connection) (after increasing the max in Wildfire) then I do receive the responses correctly and immediately to IQ requests. For example I can change a roster item group and I get the roster update back immediately with the new group.
BUT if I do this, then the issue is that the chatting breaks. The messages seem to queue up, and are not received by the recipient until after they type in a message! So it gets muddled.
I am in a catch 22. By increasing the holds I can fix the IQ responses but chatting breaks.
Thanks for the detailed bug report! Which version of Wildfire are you using? If it is anything less than the latest nightlies of Wildfire could I ask you to try it out and see if you are still experiencing the same issues? When you say the messages queue up until the user is typing, what do you mean?
From that description it seems like there is not a mechanism in place to poll the server for new messages after a period of time. Perhaps try lowering the polling interval on your server:
xmpp.httpbind.client.requests.polling
The default is 5 seconds, but if you are seeing a delay of greater than 5 seconds than it may be a client problem I am not sure though.
Actually it isn’‘t a polling problem, because I just don’'t receive the message at all until after the recipient types a message. Unless, of course, the wait expires. If I make the wait really small then the site kind of works…
but that is effectively just polling and still causes other problems.
I haven’‘t used JSJAC so I can’'t be sure if it is related to it or something along those lines. If you can email me some of the code you are using along with JSJAC i maybe able to investigate and determine what is going on.
Using http binding - packets are not received until either the wait period expires or in response to sending a packet. This defeats the purpose of binding and there must be something causing this incorrect behavour.
I can see the open http connection to Wildfire using Fiddler.
When wildfire has a packet for the web client it should close the open http connection with the packet content being sent back. This just isn’'t working for some reason. It is only when the wait period expires, or as a response to the web client sending a new packet to Wildfire that the packet content is sent to the web client.
PS. The issue raised in this thread could be related to the same problem?
When you say in response to sending a packet what do you mean? This is how the http-binding is supposed to behave, you make a request and Wildfire responds with any waiting packets. If there are no waiting packets, Wildifre will wait until the wait value is reached and then return.
I think we both agree with what HTTP-binding is supposed to do. I am going to look into this using JWChat and see if I can’'t get to the bottom of what is going on.
I’'m testing on two builds, 31-01-07 and 12-02-07.
The build on the 31st behaves as expected. The http poll returns as it receives a message. Unfortunately the new build waits until the “wait” time regardless of whether it is receiving messages or not. It then either returns all the messages it has received in that time or none.