glassfish_at_javadesktop.org wrote:
> As wildfirexy suggests, without saying so in these words, "it depends."
>
> Not only do you need to factor in the type of application and response requirements (such as embedded vs. interactive) but it's also important to assess how often the expected data will become available vs. how often to poll (if you consider a polling approach) and how expensive the network round-trip is in the runtime environment.
>
> How many clients will be polling? A polling solution that works well with a handful of clients may not scale well to hundreds or thousands or more clients.
About doing push/poll with Comet (noy talking about JMS here): I think
the performance depends on the way the 'long polling'/'push' frequency
are implemented. With a push approach, you need to decide if you
throttle the update from browser locally (meaning avoid sending all the
client side events to the server) to avoid flooding the server. A good
example can be found in [1]. Mainly, if you move a word, all browsers
that subscribe to receive push events will be updated, which is clearly
not something you want to do in a real application. One way to reduce
the load is to throttle/filter the events on the client side. The
drawback of throttling on the client side is you may end up having to
write complex javascript/client side code, and might be quite difficult
to debug if you cannot log what the client is throttling.
Another alternative is to throttle the push on the server side [2]
(which IMO perform much better). In that case, the server can decide,
based on some algorithms/policies, when it is time to execute push. The
server side approach allow you to implement all kind of policies (like
avoiding updating the client who send updates, delay the updates, filter
the updates, etc.) Performance wise, I would think it 'can' perform
better that the client side throttle if the policy is properly
implemented (and an application per policy is probably the best
approach). So I agree with you...'it depends' :-)
>
> The polling approach can be very network-unfriendly if the polling interval is significantly faster than the actual arrival rate of the data. In that case polling generates many network messages that return no new information. Of course, no one would purposefully set up this sort of overly-aggressive polling frequency but in many situations you cannot predict how often new data will be available and therefore how often to poll.
>
> I have also seen applications with dynamically adaptive polling rates. The algorithm polls less and less frequently if several successive requests return no new data and polls more and more frequently if successive requests do return new data. Well-designed approaches that use this technique will need to limit how fast or slow the polling occurs to avoid flooding the network and the server with too many requests or, in the other extreme, being too slow to discover when new data is available.
Indeed.
>
> As with many application design decisions, the "best" choice is going to depend on the specific requirements in a particular case. Most apps I've come across would be best handled with a "push" approach, due to high network costs associated with unneeded messages. Having said that, the predictability aspects of a "pull" approach as wildfirexy mentioned is a very interesting twist on this discussion.
>
Thanks
-- Jeanfrancois
[1]
http://weblogs.java.net/blog/jfarcand/archive/2007/03/jmaki_comet_orb_1.html
[2]
http://weblogs.java.net/blog/jfarcand/archive/2007/03/new_adventures_1.html
> - Tim
> [Message sent by forum member 'tjquinn' (tjquinn)]
>
> http://forums.java.net/jive/thread.jspa?messageID=234586
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>