Here's the problem:
I'd like to expose a page within a site which is able to report some log lines.
The site is a java spring 3.0 web application.
Theoretically there are two ways to get the job done:
1- the server pushes the lines to be logged whenever they are ready.
2- the client does a polling for new lines.
I'd prefer the first way but I really don't know if it is feasible or not.
I imagine the scenario as follows:
the client REQUESTs the "consolle page"
the server RESPONSEs such page
END TRANSACTION
the server REQUESTs (or what?) the updates...
the client... ?
And finally, what techonolgy suits best my requirements? I suppose JSP are not enough maybe some javascript?
I've implemented similar things in the past using timed polling with AJAX.
Your console page would run some javascript/jQuery that polls the server every so often via an AJAX request, and if it receives new data, appends (or prepends, whichever you like) it to your console box, or div, or whatever it is you're using.
Last I checked (which was quite a while back), this is how Facebook chat worked (though it's probably changed since then).
There are push implementations you could use (check out HTML5 Websockets, that might help), but AJAX polling is probably the simplest solution for something like this.
Related
I am developing a servlet based application. One situation is that a client requests some data from a database which is sent back in the form of html. The client will modify this data and then sent it back to the server. Now the twist starts. There is not a single client. So multiple clients can request the same data. So what I am doing is that when the first client makes a request, this request is stored somewhere so that when the next user makes the same request he is denied the data.
Now suppose the first user gets the data and 2nd is denied. Now while the first user is on the html page which allows him to modify the data. I want to send continuous javascript async post requests at a fixed interval to inform the server that the client is active.
At the server side I need a thread or something which can keep waiting in a loop for the javascript async requests and if the request is not received within the fixed time then the thread removes the saved request so that future requests to the data will be accepted.
I have searched the entire day and looked at things like async servlets, ServletContext listener and scheduledExecutorservice. I dont want to use scheduledExecutorService as it is invoked at app startUp which I dont want to do since this specific situation is a minor part of the code and to handle it I dont want something running all the time. I need some background service which keeps running even after the server has returned requested data.
Servlets won't fulfill your requirements, therefore you should use WebSockets.
As per my understanding, you are trying to push data from the server, therefore you need to a push architecture instead of pull architecture (Servlets are based upon pull architecture).
Java has native support of WebSockets
You can find several tutorials on how to use WebSockets in a Java Web Application.
Here is a link to a basic WebSockets Tutorial.
Hope this helps
Maybe I'm overthinking this but I'd like some advice. Customers can place an order inside my GWT application and on a secondary computer I want to monitor those submittals inside th eGWT application and flash an alarm every time an order is submitted, provided the user has OK'd this. I cant figure out the best way to do this. Orders are submitted to a mysql database if that makes any difference. Does anyone have a suggestion on what to do or try?
There are two options: 1) polling or 2) pushing which would allow your server (in the servlet handling the GWT request) to notify you (after the order is successfully placed).
In 1) polling, the client (meaning the browser you are using to monitor the app) will periodically call the server to see if there is data waiting. It may be more resource intensive as many calls are made for infrequent data. It may also be slower due to the delay between calls. If only your monitoring client is calling though it wouldn't be so resource intensive.
In 2) pushing, the client will make a request and the request will be held open until there is data. It is less resource intensive and can be faster. Once data is returned, the client sends another request (this is long polling). Alternatively, streaming is an option where the server doesn't sent a complete request and just keeps sending data. This streaming option requires a specific client-/browser-specific implementation though. If it's just you monitoring though, you should know the client and could set it up specifically for that.
See the demo project in GWT Event Service
Here is the documentation (user manual) for it.
Also see GWT Server Push FAQ
There are other ways of doing it other than GWT Event Service of course. Just google "GWT server push" and you'll find comet, DWR, etc., and if you are using Google's App Engine the Channel API
I'm working on a browser game with the play framework, and I definitely need longpolling, but I don't quite understand how to use it. WebSockets would be perfect for this, but it's not supported by that many browsers yet.
Here's what I want to do: When the user logs in, and navigates to the play game controller, I want to start a connection, and keep it open. I want to do this for all users that are online, so I can show a list of them on the site, so they can play with each other. I've looked at the documentation, but I don't understand how I could implement it in my case. Because there simply isn't anything I want to calculate (in the example they're generating a pdf) I just want the connection to stay open.
What I'm also wondering is, how I should keep track of all these open connections? Right now, I just have an online column in my users table in the database, which I update. SO everytime someone connects I have to update the database. Are there better ways to do this, or is this fine?
And lastly, assuming all of the above works. When player A, selects player B to play with: how do I notify player B of this? Do I just send some JSON code, and change the page with javascript, on player B's side, or do I send him to a totally different page? I'm not sure how to communicate when the two connections are established and the game has started.
Firstly, I think you need to appreciate the difference between Websockets and Long Polling.
Websockets creates a connection and keeps it open until the browser terminates the session, via some javascript or the user moving on from the page. This would give you the desired nature of what you are requesting. Looking at the Chat example in the Play download will show you how an entire Chat application is handled using Websockets.
Further to Pere's answer regarding Play's statelessness. The Play creators have suggested that a single Websocket connection, regardless of how long it is open for and how many requests are sent back and forther, is considered to be a single transaction. Therefore, saving to the database in between each Websocket request is not needed (again, you can see that nothing is saved in the Chat example). Using this method, you would be expected to save the details when the Websocket is finally closed, or indeed all Websockets, depending on your use-case.
Long Polling on the other hand opens a connection to the server, and the server simply waits until there is something to send back to the client. If you need to push any data to the server, you would do this as a separate AJAX request, so you would effectively have two requests open at once. You don't necessarily know when a user logs off, unless you send a request just as they leave the page, to let the server know they have gone, but this is not always successful. Long Polling can work, but it is not as neat a solution as Websockets, but as you say, this is not widely supported yet.
My suggestion would be to study the Chat example (as it has a Long Polling and Websockets version). This will be the most effective way to get up and running with your requirements.
As for your final query regarding how to notify the other player. In Long Polling, you would simply respond to the suspended request with some JSON. With websockets, you would send an event back to the client. Again, both approaches can be pretty clearly figured out from the Chat example.
I have also written a Blog post on Websockets, which may help you understand this process a little better.
On the Websocket part, as you can see here (1st answer) the support is not so bad, and you have a Javascript fallback if there is some problem with the browser. This would simplify your scenario, as long polling may be more complicated to manage.
On the issue of keeping track, as Play is stateless you have to store the flag in the database and remove it when they close the connection. Otherwise you are breaking the statelessness.
About the notification, you have to send some message to B, but don't move them to another page as it may be confusing and cause bad user experience. Use Json to pop some message (in a div) alerting them of the game starting or the request to play.
I'm not using the "play" framework.
But I've been lately researching and tinkering with http-based long polling. Websockets, if available, is much more appropriate for realtime messages!
As for long-polling, I found that using a "cargo truck" analogy helped me reason about long-polling quite effectively. Here's a little note I wrote on the subject:
http://dvb.omino.com/blog/2011/http-comet-realtime-messages/
Perhaps you or future greppers may find it useful.
You might also want to take a look at the Juggernaut project which is based on node.js and Redis and gives you a "realtime connection between your servers and your client browsers". When using a Java Redis client like Jedis, you should easily be able to integrate the whole thing with the Play framework!
Which good ways exists to reload front page by server every time that new article placed by editor in front page for (news popular website like fox.com, cnn.com)?
Thanks
You are looking for some asynchronous client/server communication.
You can either periodically poll the server (query it every x time unit), can result in wasted queries (in form of HTTP requests) and subsequently waste bandwidth, if lots of polls find no new data.
Or use what has been dubbed as "server push" which leaves an HTTP connection open for the server to push the updates back to the browser, without polling.
GWT and GWT-RPC:
Since you are on Java, I recommend you have a look at GWT, will simplify your "AJAX" work with its GWT-RPC. In GWT you use Java language on both the server-side and the client-side (compiled to JavaScript), and will handle all the implementation details on the asynchronous communication under the hood.
To do the polling here, you can have a timer on the client-side (on the webpage) that will call a method that you have written on the server to give the data, can either be a String that represents some news, or even encapsulate it into a News class, with title, summary, body, and timestamp etc. The News class will then have to be in a shared (between client and server) Java package, so the implementation can be used on both sides without having you duplicating code.
GWT Comet:
This gwt-comet library provides an
efficient Comet implementation for
GWT.
The library implements Comet by
streaming messages over long lived
HTTP requests to minimise latency and
bandwidth requirements and maximise
the throughput. This is opposed to
many other implementations which use
polling or long polling techniques.
http://code.google.com/p/gwt-comet/
What you want is an AJAX call on your front page that queries the server for new articles every few minutes and if the server returns a new article the Javascript should then display it to the page.
The poor man's alternative to AJAX (sheesh, does every two-bit Web site have to be Web 2.0 these days??) is simply inserting an HTML refresh command into the page. This is documented all over the Web; I Google for it whenever I need it, and keep forgetting how.
It's dead simple and works even if the user has JavaScript disabled. On the downside, it does refresh the entire page.
In a server-side application running on Tomcat, I am generating full HTML pages (with header) based on random user-requested sites pulled down from the Internet. The client-side application uses asynchronous callbacks for requesting processing of a particular web page. Since processing can take a while, I want to inform the user about progress via polling, hence the callbacks.
On server-side, after the web page is retrieved, it is processed and an "enhanced" version is created. Then this version has to go back to the user.
Displaying the page as part of the page of the client-side application is not an option.
Currently, the server generates a temporary file and sends back a link to it. This is clearly suboptimal.
The next best solution I can come up with inolves creating a caching-DB that stores the HTML content together with its md5-sums or sha1-ids and then sends back a link to a servlet, with the hash-ID as an argument. The servlet then requests the site from the caching-DB.
Is there any better solution? If not, which DB-backend would you propose? I'm thinking of SQLite. Part of the problem to be solved is: how do I push a page <html> to </html> back to client side?
If true persistence isn't required how about using something more temporal like memcached instead of SQL? Calling semantics are pretty clean and easy - and of course you can expire the data manually, ttl, or # restart.
Instead of creating a temporary file, filling it up, and then sending a link, you can create a memory buffer, fill it up, and then send that as the response (serve it with mime-type 'text/html'). If you don't want to send page-buffers immediately, you can save them for later in the user's session. If you're worried of taking up too much memory that way, you may want to keep only a certain number of page-buffers around in memory, and write the rest to disk for later retrieval. Using a DB sounds like overkill (after all, there's no relational information involved) - but it would solve the caching problem nicely.