Real-time data display
hi all,
i am working on a tapestry web app. i want to send data from my server (java servlets) to the front end (html page) without refreshing the page manually in real time.
my servlet is constantly receiving data and i want to just send it to the browser and it should just display it constantly. i have looked at javascript http streaming, and some other implementations. it cant be that complicated to just send data to the browser w/o refresh.
i am sure a lot of other people are doing this too. i understand this is ajax implementation, but i want a light weight solution. can i get some code assistance here.
thanks.
[654 byte] By [
ag201a] at [2007-10-2 22:19:42]
This question gets asked in different forms all the time...
> i have looked at javascript
> http streaming, and some other implementations. it
> cant be that complicated to just send data to the
> browser w/o refresh.
Yes it can. HTTP, the protocol used by web applications, is a request - response protocol. The user makes a request. The server sends a response. Connection is closed. That is how it works, there aren't provisions for the server initiating contact with the client.
So you have to work around it.
> i am sure a lot of other people are doing this too. i
> understand this is ajax implementation, but i want a
> light weight solution. can i get some code assistance
> here.
> thanks.
Look up AJAX, or for other solutions try Pushlets. You could try from the client side using the XMLHttpRequest object in javascript to reularly poll the server for updates. Not "real time" but if you manage the polling time it might be close enough...
i have thought of implementing frames within my web app. one hidden frame when refreshed will send info to the other visible frame. but the issue is how can i tell this hidden frame to refresh. is there a way for my servlet listener to tell this particular frame (javascript within it) that please refresh.
> i have thought of implementing frames within my web
> app. one hidden frame when refreshed will send info
> to the other visible frame. but the issue is how can
> i tell this hidden frame to refresh. is there a way
> for my servlet listener to tell this particular frame
> (javascript within it) that please refresh.
The server can't tell the client anything the client doesn't ask for. Just make the page have a <meta http-equiv="Refresh" ...> tag that asks the server for the information every x number of seconds (ie sends a request to a servlet that has access to the information). Other than the refresh tag, the output would be a series of javascript calls filling information in on the regular page.
i currently have implemented the regular refresh option. but constantly refreshing the page puts a lot of strain on my web server. i want the page to update, when the server tells it to (as it will know when information has arrived or has changed). any ideas.
Did you consider server push? I've used it in my very old chat application and it worked just fine.
Here is ref to MIME where you can look for server push:
http://www.ltsw.se/knbase/internet/multipart.htp
Here is download of chat servlet:
http://7bee.j2ee.us/download/ChatHouse.war
the implementation looks all right. i cant get the source code to look at how you have done it. can you share the source code.
> Did you consider server push?
As I said in first post - Look up pushlets. They do a Server side Push.
Problem is that you have an open output stream to every user who visits your website. So if getting a lot of short requests is bad, then having tons of never-closing requests may also be problematic.
i am leaning towards not implementing server push, the reason being i would have to open up an output stream to every user and maintain that connection. there is no 100% way of knowing if the connection breaks.
instead i want to send information only when it changes. and that to i dont need to send it, i will store it in the session variable, tell the page to refresh and the page will retreive that info from the session variable.
the only place where i am stuck is how to tell the browser, please refresh. i am trying to find a way to ping the browser so that it knows when to refresh. i guess within my javascript i could have something like,
if (ping)
refresh page
else
do nothing.
and this pinging would need to be "on" all the time for me to send messages to it and for it to receive messages.
any thoughts.
> the only place where i am stuck is how to tell the
> browser, please refresh. i am trying to find a way to
> ping the browser so that it knows when to refresh.
Problem here is it is imposible to ping the browser. The brower does not accept input from the web that it doesn't ask for. The only ways to get the page to refresh is to have a regular refresh rate (see older style web apps), have a javascript that uses the XMLHttpRequest object to make a request on regular basis (similar idea as a refresh in a hidden frame - see AJAX), or have a server side push (see pushlets).
If the only thing you are worried about with pushlets is not knowing if the connection is broken, you could have part of the response to any push be a javascript response back saying they got it. On the server, if there is no response then the push was lost (store it for later), close your connection. Your real trick would then be to have a javascript that also times out after a real long period of time and forces a client side refresh if no pushes came, so if the connection was broken but the browser was still sitting on the page the connection could be re-established. At which point any lost data could be transmitted to the client.
> i
> guess within my javascript i could have something
> like,
> if (ping)
> refresh page
> else
> do nothing.
>
> and this pinging would need to be "on" all the time
> for me to send messages to it and for it to receive
> messages.
That is fine if you control the ping all from the javascript/client side. The server side can't control the ping value once it gets to the client.
>
> any thoughts.
var time = 100000 ( time in millis )
please have a look at
window.setInterval('updateJob(url,....., time)'
as far as i know, window.setInterval method in jscript triggers refresh of the browser.
time - this would basically tell the browser to refresh itself after confiugurble time
hope that helps
Thanks
Nilesh
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/setinterval.asp
Thanks guys for your feedback.
stevejluke -> I need to digest your feedback. you seem to have a valid argument and I will give it a try and see if its actually practically possible. But it has made me rethink my strategy. more updates later.
AccessNilesh -> I am avoiding refresing the page every x number of seconds, the reason being I dont want Tomcat to constantly regenerate the page.
in the meantime i am going to keep on working and researching and try and find a fix to this problem.
>Problem is that you have an open output stream to every user who visits your >website. So if getting a lot of short requests is bad, then having tons of never->closing requests may also be problematic.
Are you sure? If a user visited the page and then closed it or selected other, then stream will be closed by a browser. If you are afraid of idiling, then you can send mouse and keyboard activites telling your code that stream is still used, otherwise you can enforce closing it. AFAK Google is also using the same technology for google mail chat.
> >Problem is that you have an open output stream to
> every user who visits your >website. So if getting a
> lot of short requests is bad, then having tons of
> never->closing requests may also be problematic.
>
> Are you sure? If a user visited the page and then
> closed it or selected other, then stream will be
> closed by a browser.
I was cavalier with the use of 'never-closing'. What I meant was ones that hang around for long periods of time - very long periods of time - compared to normal requests. It is a trade off to be had. You have a lot of short requests that occupy the server (really a Thread from the server's thread pool) for tiny amounts of time or you have a few long requests that occupy the server (again Thread from thread pool) for very long periods of time. Either way you get to starving your Thread pool and making responsive-ness poor if you don't do the correct balance between request length and Thread pool size.
So with a short response (the constant refresh in a hidden frame to see if more data is required) you can have fewer threads because the requests are short enough that if the user has to wait for a thread, he isn't waiting too long. On the other hand, each update has a longer delay between server-side readiness and client-side view, and each update on the server requires a full server roundtrip and some lag time between...
On the other hand, the server side push ensures prompt update to the user - data only needs to travel one direction, and there may be no lag between server update and data sending. But, in order to maintain a larger number of concurrent users, you will need a large number of Threads in the thread pool. This can eat a lot of resources on the server and slow all your requests and responses down, as each long lasting Thread fights for CPU cycles and memory.
And if you do run into thread pool starvation, a user may need to wait quite a while for a Thread to be freed (unlike the short requests, the pushlet type request can be maintained for an any length of time - so the time until one gets freed may be completely unpredictable). So you will need to walk the fine line between ensuring you have a Thread for every likely concurrent user, and having few enough Threads that the ones you do have can get the CPU time they need.
> If you are afraid of idiling,
> then you can send mouse and keyboard activites
> telling your code that stream is still used,
> otherwise you can enforce closing it. AFAK Google is
> also using the same technology for google mail chat.
No, Google is using AJAX, this is the client side javascript - making requests to server via XMLHttpRequest idea (I think Google may actually be using hidden iFrames instead of XMLHttpRequest, not sure but it is the same idea...). That is to say, they are using many short requests to the server - everytime the user interacts with the page - rather than single long requests.
http://news.com.com/Will+AJAX+help+Google+clean+up/2100-1032_3-5621010.html
http://en.wikipedia.org/wiki/AJAX
