|
Replies:
7
-
Last Post:
Sep 10, 2007 7:31 AM
by: Jeanfrancois Ar...
|
|
|
|
|
|
|
Push via messaging vs pull via polling..
Posted:
Sep 6, 2007 4:04 PM
|
|
|
Hi,
I'm starting to consider how I'm going to design a portion of my application. I
guess the best way to describe it would be:
A queue shared between multiple application clients / users.
I can think of two ways to do this...
1. Use the messaging system to publish changes relevant to the queue to
subscribed application clients.
2. Have each application client poll the server (refresh) at regular intervals.
I'd like to know if anyone has any thoughts / comments relating to either
strategy. I have a preference, but would like to see what other people think
before I start.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
Re: Push via messaging vs pull via polling..
Posted:
Sep 6, 2007 4:31 PM
in response to: Ryan J
|
|
|
Hi,
Ryan J wrote:
> Hi,
>
> I'm starting to consider how I'm going to design a portion of my application. I
> guess the best way to describe it would be:
>
> A queue shared between multiple application clients / users.
>
> I can think of two ways to do this...
>
> 1. Use the messaging system to publish changes relevant to the queue to
> subscribed application clients.
>
> 2. Have each application client poll the server (refresh) at regular intervals.
>
> I'd like to know if anyone has any thoughts / comments relating to either
> strategy. I have a preference, but would like to see what other people think
> before I start.
Is your client web application (or does is support the http protocol)?
If yes, you might want to consider Comet programming. See [1] and [2] if
you are interested.
Thanks
-- Jeanfrancois
[1]http://weblogs.java.net/blog/jfarcand/archive/2007/05/new_adventures.html
[2]
http://weblogs.java.net/blog/jfarcand/archive/2006/07/the_grizzly_com.html
>
> Ryan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Push via messaging vs pull via polling..
Posted:
Sep 7, 2007 4:19 PM
in response to: Jeanfrancois Ar...
|
|
|
Hey Jeanfrancois,
Does this "long polling" technique work with stock, out of the box Glassfish and stock, out of the box Servlets, or is there some configuration and/or special classes that need to be done?
Basically, can you just write every day servlets, do you need to code them special, or tell the container something special about them, or can you use servlets at all?
|
|
|
|
|
|
|
|
|
Re: Push via messaging vs pull via polling..
Posted:
Sep 10, 2007 7:13 AM
in response to: whartung
|
|
|
Salut,
glassfish@javadesktop.org wrote:
> Hey Jeanfrancois,
>
> Does this "long polling" technique work with stock, out of the box Glassfish and stock, out of the box Servlets, or is there some configuration and/or special classes that need to be done?
Yes, it works 'out-of-the-box' with Servlet, JSP or event POJO if you
uses Grizzly standalone.
By default the http-listeners aren't 'comet-enabled'. To enable it, you
just need to add the following property under the http-service element:
<property name="cometSupport" value="true"/>
The main reason I didn't enable it by default is their is a very small
performance penalty when doing asynchronous request processing, as you
need to parse the request line to determine if its a comet request or
not. It is probably a very very low impact, but since an extra for
people who aren't using long polling.
>
> Basically, can you just write every day servlets, do you need to code them special, or tell the container something special about them, or can you use servlets at all?
You just need to write a Servlet and then implement the long polling
support by using the Grizzly's Comet API [1]. This is quite simple to
write the server side...for the client side, you will need to know a
little bit of JavaScript/iframe.
Hope that help.
-- Jeanfrancois
[1]
http://weblogs.java.net/blog/jfarcand/archive/2006/10/writting_a_come.html
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=234503
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Push via messaging vs pull via polling..
Posted:
Sep 7, 2007 4:26 PM
in response to: Ryan J
|
|
|
It really depends on your clients, your data volume, you overall "activity" and timliness.
On the one hand, you've got things like RSS feeds which typically refresh every 5, 10, or even 30 minutes. They just don't need to hammer the server, or necessarily be that up to date. So that's a perfect scenario for polling.
On the other, you having something simple like a "status bar" monitoring a the progress of a process as it goes from "0%" to "100%".
That's something that would better be served by a push mechanism, because it's important to be as "up to date as possible" and you don't want to hammer the server every second creating and destroying sockets like potato chips.
Then there are the clients. Lots of clients and their internal implementations are MUCH happier with a pull model rather than having random events pound them from the server. Many developers find pure asynchronous programming difficult, and the "fetch the data, process it all, and fetch some more" idiom suits them very well.
So it's hard to recommend one over another.
In a perfect world, it would all be an asynchronous "push" model with instantaneous updates everywhere. But that's easier said than done and can be more expensive than necessary.
|
|
|
|
|
|
|
|
|
Re: Push via messaging vs pull via polling..
Posted:
Sep 9, 2007 1:34 AM
in response to: Ryan J
|
|
|
Within an imbedded space pull architectures are considered superior simply because a call for example to query a service layer takes a certain ammount of time and therefore an answer can be arrived at a predictable momemt in time. Also with this load on the service can be calculated in advance, all of it makes a poll architecture better in environments which operates on strict time/load constraints.
For interactive applications this can be bad from a user's perspective. Simply because an user may judge system to be slow and un unresponsive while waiting for an answer.
The moral of the story is simply, if you have an back end process which gathers data for consumption, a poll process may be more network friendly. Users can be press an F5 button very fast, and all of that translates to an hit on the network infrastructure.
Sometimes an hybrid solution can also work: If no data arrives in x, start polling the queue. Once data arrives, stop polling, allowing the client process data from the queue in an interactive manner.
|
|
|
|
|
|
|
|
|
Re: Push via messaging vs pull via polling..
Posted:
Sep 9, 2007 7:38 AM
in response to: wildfirexy
|
|
|
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.
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.
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.
- Tim
|
|
|
|
|
|
|
|
|
Re: Push via messaging vs pull via polling..
Posted:
Sep 10, 2007 7:31 AM
in response to: tjquinn
|
|
|
glassfish@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@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
java.net RSS
