a4j:push and timeout attribute

[digitalseraphim]

I'm not sure this is in the right place, but here'goes anyway...

According to the Richfaces devguide:

The example shows how date is updated on a page in compliance with data taken from a server. In the example "interval" attribute has value "2000". This attribute defines an interval in milliseconds between the previous response and the next request. Default value is set to "1000" milliseconds (1 second). It's possible to set value equal to "0". In this case connection is permanent.

The "timeout" attribute defines response waiting time in milliseconds. If a response isn't received during this period a connection is aborted and the next request is sent. Default value for "timeout" attribute isn't set. Usage of "interval" and "timeout" attributes gives an opportunity to set short polls of queue state or long connections, or permanent connection.

This leads me to believe that it is possible to do "long polling" with this component by setting the timeout high, and the interval low. when doing this, with no events occurring, i would expect the following (timeout=60000, interval=1000 for discussion's sake, times approximate):

time 0: connection opened
time 60000: empty response (no events), connection closed
time 61000: connection opened
time 121000: empty response (no events), connection closed
time 122000: connection opened
time 182000: empty response (no events), connection closed

and so on. what I actually end up seeing is:

time 0: connection opened
time 58: empty response (no events), connection closed
time 1058: connection opened
time 1107: empty response (no events), connection closed
time 2107: connection opened
time 2153: empty response (no events), connection closed

and so on, where the connection time is very short, but the interval is correct. Looking at the code (BaseFilter.java in 3.2.1GA) there is no support for the timeout value at all, and all push requests are responded to immediately. Am I misunderstanding something, is there a bug, or is the documentation wrong? I'm hoping its a bug, because the documented functionality is exactly what I'm looking for.

Thanks for your time,
DS

[ilya_shaikovsky]

timeout works only for normal ajax request which passed all JSF lifecycle.. (for the request after event actually appears and request sent to process this event)

[atsebro]

Hi, digitalseraphim!

This is not a bug and guide's description is correct. The reason is in the request type (ilya_shaikovsky was right).

Here is how the stuff works:

a) <a4j:push> sends HEAD-requests, that check for messages about an event;
b) if there is no message in the queue (no event), HEAD-responses come back with nothing to be processed ("empty" responds);
c) if there is a message (event exists), then HEAD-response comes back with Ajax-Push-Status "READY" (use FireBug plug-in for Firefox to explore that);
d) the response with "READY" status triggers POST-request, that works trough full JSF lifecycle, and POST-response bring back new information to be rendered;
e) this POST-request/response considered as "normal" in ilya's post; so, "timeout" time spreads exactly to this type of request, that's it!

P.S.: In your example all the requests/responses are "empty". So, "timeout" was not used. Time from 0 (connection opened) to 58 (empty response, connection closed) is in milliseconds; it is insignificantly time, that had been taken to proceed an "empty" request/response.

Regards,
docteam

[digitalseraphim]

Thank you for your responses, but I'm still confused. As quoted above, the documentation says:

Usage of "interval" and "timeout" attributes gives an opportunity to set short polls of queue state or long connections, or permanent connection.

If the timeout value does not work how I believed it should (and it doesn't) this does not give a way to change the duration of the connections (implied by "long connections" and "permanent connection"). So, while I agree that the description of "how the stuff works" by atsebro is correct with the current code, I still believe that it is inconsistent with the documentation.

Short summary: The documentation says I can do long polling, while in practice, I can't.

Thanks again for your time,
DS

[atsebro]

Sorry for not timely answer but here is a disclosing of the inconsistent.

As it was explored, there is actually a bug in the documentation, but not with long connection. The description touches permanent connection while it has been not implemented yet. Here it is!

The description in guide will be corrected in RichFaces 3.2.2. version that will be released soon.

Thank you for your post.

P.S.: what do you mean by saying "long polling"?

[digitalseraphim]

Long polling is a method of implementing server push over http, in which the browser makes a request of a resource on the server, and the server does not respond, nor close the connection until there is data to return or a specified time elapses. After the server responds or closes the connection, the client waits some amount of time (could be immediate, could wait a while) and then reconnects, and the process repeats.

My thoughts when reading the documentation were as such:

client would connect to server and server would either reply with data when it's available (event thrown on client side) or after {timeout} time has gone by. at that point, it would wait {interval} time to reconnect. if {timeout} is set to 0, it would do a permanent connection (unless there was a network problem or something else), and if you set {timeout} to a long value and {interval} to a short value, it would do your standard long polling. The short polling that is going on now is very server intensive, and very annoying when you are trying to debug some unrelated javascript in firebug :^)

Thanks for your time,
DS

[digitalseraphim]

Just another little followup on the push capabilities, Seam remoting appears to *claim* to do long polling (see section 22.11.4. Tuning the Polling Process). I have not tried it out yet, as long polling is not scalable to the degree that I am in need of. I'm currently looking at orbited for my push capabilities.

-DS