I have a Java Servlet which writes a message to the database. Some other tier picks up this message from the DB and processes it and updates the status of this message in the database. Meanwhile in the servlet, I have to keep polling the database to get an update on status of the message which was written earlier.
How can I implement a Callback instead of polls so that unnecessary database queries are avoided?
I suppose you're talking about server push technologies. I suggest you to use HTML5 websockets for this. Use your same servlet with a websocket to communicate between both ends.
There are so many examples out there.
Java WebSockets - In this example he uses jetty, but you can
use jboss or tomcat for this.
StackOverFlow post describe the same.
pushing data for multiple clients from a server via websockets
try above links and it is worth for trying.
Related
I'm working on multiplayer, I can at the moment send data to the client, however, my server can't seem to receive data from the client.
I have a feeling I'm missing something in my Async Networking event, but I'm unsure. Here is a sample of the server to client code and what I'm trying to do.
the listeners are just lists, I can't post any more links to images so I hope this is enough.
Connection Listener Code
Server Async
OnNetworkAsyncEvent
serverSendClientID
clientDataListener
serverDataListener
ClientHandler create
serverHandler create
Found out what was wrong, the serverHandler needed to have an else statement then run through the data listener scripts as it was only checking the servers own socket.
Are Meteor.methods they only way to call server-side functions from the client?
http://docs.meteor.com/#/full/meteor_methods
the docs don't make it clear that they are they only way, but the fact that they exist seems to imply they are the only way. What is their purpose?
There are several ways to communicate back and forth between the server and client in Meteor :
Using Meteor.methods to perform Remote Method Invokation on the server, these calls are initiated by the client, ask for a computation to be performed on the server and receive a result.
Using the Pub/Sub mechanism, the server publishes a set of data and the client is subscribing to a subset of this data, being notified in real-time of data-updates taking place in the server and thus receiving modifications.
Using plain old HTTP requests with the HTTP module.
So Meteor.methods are not the only way to execute some code on the server upon a client request.
Their purpose is usually to update the database by providing new values for server-side collections, as a matter of fact, client-side collection inserts and updates are implemented as Meteor.methods.
The Pub/Sub mechanism is used to propagate DB updates to every connected client and to make sure they receive only the minimal subset they need.
The HTTP communication is used by the server to send the initial source code (HTML/JS/CSS) of the app on load time as well as performing standard operations such as requesting and downloading a file.
Having watched Meteor Framework screencast. I noticed that changing the database seamlessly changes the data in browser. Usually AJAX, just reloads a part of page every few seconds but here I didn't noticed browser reloading. How did they achieve that in Meteor? Is it Node.js dependent?
UPDATE: Toby Catlin poses another interesting question. How does Meteor handle different browsers?
They use both Session and Meteor.autosubscribe (from Meteor API) to ensure that changes are reflected on the clients.
These Meteor APIs use XHR (XMLHttpRequest) by SockJS. SockJS is WebSocket emulation utility. So when something changes on the server, SockJS ensures that an XHR is sent, and the changed data is in the JSON response.
Yes, Meteor is fully dependent on Node.js. From the Meteor docs:
A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container, and all the supporting HTML fragments, CSS rules, and static assets. Meteor automates the packaging and transmission of these different components. And, it is quite flexible about how you choose to structure those components in your file tree.
The only server asset is JavaScript. Meteor gathers all your JavaScript files, excluding anything under the client and public subdirectories, and loads them into a Node.js server instance inside a fiber. In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.
Sources: http://docs.meteor.com/ and https://github.com/meteor/meteor
There are a few techniques that allow the server to push data into the browser without the browser needing to request it. The term for such technology is Comet [wikipedia.org] and most techniques are related to AJAX (there was a bleach called Comet and a cleaning product called Ajax). There are a number of connection types: long polling, streaming XHR, forever frame, server-send-events and websockets. Socket.IO is a nice library that provides connection types to streaming servers.
You do need a server that will support Comet connections. You can google for current ones but off the top of my head: node.js, tornado, cometd, orbited, Jetty streaming
I would guess that Metor would use different connection types depending of the capabilities of the browser, eg websocket for Chrome and long polling for IE. If anyone can give a more specific answer i would be interested
I have an ASP.NET Webform which currently calls a Java WebService. The ASP.NET Webform is created/maintained inhouse, whereas the Java WS is a package solution where we only have a WS interface to the application.
The problem is, that the Java WS is sometimes slow to respond due to system load etc. and there is nothing I can do about this. So currently at the moment there is a long delay on the ASP.NET Webform sometimes if the Java-WS is slow to respond, sometimes causing ASP.NET to reach its timeout value and throw the connection.
I need to ensure data connectivity between these two applications, which I can do by increasing the timeout value, but I cannot have the ASP.NET form wait longer than a couple of seconds.
This is where the idea of a queuing system comes into place.
My idea is, to have the ASP.NET form build the soap request and then queue it in a local queue, where then a Daemon runs and fires off the requests at the Java-WS.
Before I start building something from scratch I need a couple of pointers.
Is my solution viable ?
Are there any libraries etc already out there that I can achieve this functionality with ?
Is there a better way of achieving what i am looking for ?
You can create a WindowsService hosting a WCF service.
Your web app can them call the WCF methods of your Windows Service.
Your windows service can call the java web service methods asynchronously, using the
begin/End pattern
Your windows service can even store the answers of the java web service, and expose them through another WCF methods. For example you could have this methods in your WCF service:
1) a method that allows to call inderectly a java web service and returnd an identifier for this call
2) another method that returns the java web service call result by presenting the identifier of the call
You can even use AJAX to call the WCF methods of your Windows Service.
You have two separate problems:
Your web form needs to learn to send a request to a service and later poll to get the results of that service. You can do this by writing a simple intermediate service (in WCF, please) which would have two operations: one to call the Java service asynchronously, and the other to find out whether the async call has completed, and return the results if it has.
You may need to persistently queue up requests to the Java service. The easiest way to do this, if performance isn't a top concern (and it seems not to be), is to break the intermediate service in #1 into two: one half calls the other half using a WCF MSMQ binding. This will transparently use MSMQ as a transport, causing queued requests to stay in the queue until they are pulled out by the second half. The second half would be written as a Windows service so that it comes up on system boot and starts emptying the queue.
you could use MSMQ for queuing up the requests from you client.
Bear in mind that MSMQ doesn't handle anything for you - it's just a transport.
All it does is take MSMQ messages and deliver them to MSMQ queues.
The creation of the original messages and the processing of the delivered messages is all handled in your own code on the sending and receiving machines: the destination machine would have to have MSMQ installed plus a custom service running to pick them up and process them
Anyway there is a librays for interop with MSQM using JAVA : http://msmqjava.codeplex.com/
Another way could be you can create a queue on one of your windows box and then create a service that pick up the messages form the Queue and foreward them to the Java service
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.