I'm building an application using Google App Engine. The application consists of several servlets, one of which has a static member object that holds a lot of internal state. Multiple Android phones contact this servlet, causing the servlet to update the state of the static member object. However, when multiple phones happen to talk to the server at the same time, I get synchronization issues in which the static object is being modified by multiple threads at once. I've tried throwing in some synchronized blocks, but this does not seem to help.
I think the reason has something to do with how App Engine spawns threads for HTTP requests, but I'm not sure. What's the standard way to synchronize access to shared objects in App Engine? Thanks!
Your GAE app can be started on different servers, there can be, and will be few instances at one time. Any instance can be started or killed at any time, without any notice before. So, any in-memory state is useless.
You have to use or memcache service, or database instead.
Related
In a Node project with many .js files, suppose I have a file that manages expensive state: it provides a json blob that it regularly fetches from the web in short intervals. Its data is cached and is requested internally far more than its update interval.
let provider = require('./config-provider.js');
let config = provider.get(); // returns locally cached JSON blob
Suppose the above code exists in 10 different files in my application. This is going to create 10 different instances of this updater, all making expensive web calls to update the config.
I would like to reference a single instance of this config provider across my app. However, this seems to break the modular design of Node apps.
I could always use a global object, but this is obviously frowned upon.
Another solution is to make a complex web of parent / child references across my application. This also seems messy.
Is there some suggested best practice for referencing a single stateful module across the span of one's Node application?
In this case you should use the "singleton" pattern as described here. I also find this code example useful. Notice that some developers frown upon singletons in Node JS as discussed here.
Regardless, this pattern makes sense in your case, as you said:
I would like to reference a single instance of this config provider across my app
Other Important Consideration
Besides coding, when you deploy your application to production, you have to consider if you want this single instance replicated as well. For example, if you deploy 3 Node JS instances, do you still want a single instance handling all your JSON blobs? Or is it OK to have it replicated 3 times as well?
A while back I had a scheduling module deployed with 5 Node JS instances. Obviously I couldn't have the scheduler fire the same job 5 times, so it had its own separate instance AND the scheduling module itself was a singleton. I bring this up because there's a clear distinction between singleton objects and how Node JS can be deployed multiple times.
I hope this helps.
I have a large application context consisting of many context files, using autowiring and package scans, starting up web services, establishing connections to databases and and external legacy system etc. I have been thinking on how to improve context loading times since it takes a while without really taking up CPU. Is there a way to tell application context to initialize using multiple threads? In theory it should be possible since we have dependencies already defined. I'd like the resources (db, web services and legacy connections) to be initialized in parallel.
There's one option that comes in my mind and I'm not sure if it will work, as I've never tried doing this (in my view, if an app takes too long to start up is a sign that it has to be broken down in smaller components, where each component is an app on its own right).
The solution that I think might work is to have a hierarchy of context files, so you can instantiate the parent application context and then instantiate each one of the child context concurrently. The problem with this approach is that you cannot have dependencies between child contexts, but you can have indirect ones (e.g. The parent context has an event dispatcher then classes in one context listen to events triggered from the parent context, and another child context triggers events on the parent context).
I have a simple node.js server app built that I'm hoping to test out soon. It's single threaded and works fine without any child processing whatsoever. My problem is that the server box has multiple cores and the simplest way I can think to utilize them is by running multiple instances of the server app. However this would require them all to be on the same domain name and so some sort of request routing is required. I personally don't have much experience with servers in general and don't know if this is a task for node.js to perform or some other less complicated program (or more complicated.) If there is a node.js mechanism to solve this, for example, if one running instance can send incoming requests to the next instance, than how would I detect when this needs to happen? Transversely, if I use some other program how will it manage to detect when it needs to start talking to a new instance?
Node.js includes built-in support for managing a cluster of instances of your application to take advantage of multiple cores via the cluster module.
The question is pretty much in the title, but I will elaborate.
I have a Silverlight application that acts as a slightly extended user interface.
The main part of my program will run on a server to keep the shared database coherent.
This is where my question comes in: Will two clients calling a WCF service each get a thread inside that service OR will they get a full AppDomain each?
The difference is that if the first is the case they can share the DB easily, but in the second scenario they cannot - as I understand it.
EDIT: This is because the DB makes use of the Identity Map pattern [Fowler] where objects used are saved in physical memory (static singleton variable) - multiple AppDomains would mess that up.
(I asked my university teacher and searched quite a bit before asking this, seemingly, simple question)
The threading model for WCF services is determined by the ConcurrencyMode you configure for your service: http://msdn.microsoft.com/en-us/library/system.servicemodel.concurrencymode.aspx.
Regarding AppDomains - that depends entirely on how you're hosting your service. If you're running a ServiceHost of your own, manually, there will always be exactly 1 AppDomain on the server side, unless you decide to start managing and spinning up your own.
If you're hosting inside IIS...it's up to IIS how it handles requests. It may reuse 1 AppDomain, it may spin up multiple AppDomains (unless you override the setting in the web.config to permit only 1 AppDomain per worker process), or it may spin up multiple physical worker processes (which inherently implies multiple AppDomains) if you have web garden mode enabled.
All this said, I'm not sure exactly why this would affect your data access strategy. Multiple threads or AppDomains should have no problem sharing a DB.
So the first app that people usually build with SocketIO and Node is usually a chatting app. This chatting app basically has 1 Node server that will broadcast to multiple clients. In the Node code, you would have something like.
//Psuedocode
for(client in clients){
if(client != messageSender){
user.send(message);
}
}
This is great for a low number of users, but I see a problem with this. First of all, there is a single point of failure which is the Node server. Second of all, the app will slow down as the number of clients grow. What is there to do then when we reach this bottleneck? Is there an architecture (horizontal/vertical scaling) that can be used to alleviate this problem?
For that "one day" when your chat app needs multiple, fault-tolerant node servers, and you want to use socket.io to cross communicate between the server and the client, there is a node.js module that fits the bill.
https://github.com/hookio/hook.io
It's basically an event emitting framework to cross communicate between multiple "things" -- such as multiple node servers.
It's relatively complicated to use, compared to most modules, which is understandable since this is a complex problem to solve.
That being said, you'd probably have to have a few thousand simultaneous users and lots of other problems before you begin to have problems with this.
Another thing you can do, is try to develop your application in a way so that if a connection is lost (which happens all the time anyway), eg. server goes down, client has network issues (eg. mobile user), etc, your application should be able to handle that and recover from such issues gracefully.
Since Node.js has a single event-loop thread, this single point of failure is written into its DNA. Even reloading a server after code changes require this thread to be stopped.
There are however a lot of tools available to handle such failures gracefully. You could use forever; a simple CLI tool for ensuring that a given script runs continuously. Other options include distribute and up. Distribute is a load balancing middleware for Node. Up builds on top of Distribute to offer zero downtime reloads using either a JavaScript API or command line interface:
Further reading I find you just need to use Redis Store with Socket.io to maintain connection references between two or more processes/ servers. These options have already been discussed extensively here and here.
There's also the option of using socket.io-clusterhub if you don't intend to use the Redis store.