I've got an application that works as follows. The main thing it does is handle user request. Handling a user request entails doing a bunch of processing, then finally returning the result to the user. It is important that the total time to process a user request be as small as possible.
There is also a configuration interface used by admins. The admin can make a change to configuration that affects what processing is done on user requests as described above. The information in stored in the config database has to be "compiled" into fairly elaborate in-memory structure that handles the user request processing; computing this in- memory structure from the configuration info takes time (much longer than processing a user request). It is a goal that the time to "compile" the configuration info into the in-memory structure *not* be on the critical path of processing a user request. Here's the problem. When the admin changes the config info, it's easy enough to update the in-memory structure for the instance that happened to process the admin's request. But in order to avoid start- up latency in processing user requests, I've got three "always on" instances (which is the minimum number of always on instances -- you can't ask for just one). How can I get the other instances to realize that the config has changed and that their in-memory structure needs to be recalculated? Non-solution: on each user request, check the database to see if the config has changed. This is not acceptable, because if the database *has* changed then that user request will incur the latency to update the in-memory structure. Non-solution: just like the previous non-solution, but use a memcache. I believe this has the same latency problem, just delayed until after the memcache entry expires. Lousy solution: redeploy the app after a config change. That works because it restarts all instances, but it defeats the purpose of making the config something that can be changed by an admin through UI screens rather than wired into the code. If I could direct a request to *all* deployed instances (or, equivalently, to a specific instance coupled with the ability to enumerate all of the instance IDs), then it would be easy for me to "kick" each instance after the config change. But as far as I know, there's no way to do that. I'm sure others have encountered a similar scenario. Any suggestions? Thanks in advance. Ken Traub -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
