Wildfire HTTP Binding problems


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.

Any help is really appreciated at this stage,



Hey Daniel,

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?



Thanks for the quick response.

I am using the 3.2.0 release version but will download last nights build and try that now.

Well what happens is the chat message is sent into Jabber ok…

But the message isn ''t not relayed to the recipient through the recipients active bound connection.

It is only sent to the recipient client after they type a message.

For examples.

John -> Jane: Hello how are you?

(Jane doesn’'t get the message)

Jane ->John: Why aren’'t you talking to me?

(Now Jane gets the original message after she sends a message)

Hope that makes sense.

I will try the most recent build now.


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:


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.



I have tried with build Wildfire 3.2.1 Beta 1 .

Still having the same problem.

I have tried lowering the polling.

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.

To simply the problem I am having:

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?


I will keep trying to figure it out. I assume it is a configuration issue in Wildfire.



I managed to fix the problem by going back to your RC version which works properly!

In the final release and subsequent builds the binding just won’'t work as intended.

Not sure what you updated for the final release?

However the RC version does seem to have some other problems so it would be great

if you could get this fixed in your recent builds asap.



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.


Also, are you using HTTP or HTTPS?



With binding, Wildfire should hold the http connection open until there is a packet to respond with or the

wait time is reached. If it doesn’'t hold the http connection open then it would be a polling connection - not a binding connection.

Anyhow, in your final release version it holds the connection open until the wait time expires, even if there are packets waiting, which is incorrect.

In the RC version it closes the binded http connection correctly and responds with the packet.

Just as it should be, and it all works great.

I am not using any special settings. Can actually leave everything as default to test this behaviour.

Just HTTP. Plain Text. Can test with a standard install of JWCHAT.

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.



Thanks Alex Let me know if I can help with anything.



I’'ve just encountered the same problem.

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.

Was this change planned?




I have found the issue.


The fix will be in the next nightly build.



Great to see you found the issue and that it has been updated so quickly!

Thanks AWenckus and TomForum for looking into this.


Brilliant, thank you very much for the quick update.