Web 2.0 Archives
I'm going on vacation next week, so I ended up pushing an extremely rough, alpha-quality rough draft of the asynchronous distributed cache I blogged about earlier in the week. I told you I wouldn't be able to stay away from it! I also made some tweaks this morning that eek out a few more milliseconds by reusing message sending objects, which eliminates the overhead of creating new channels all the time (though that operation is not particularly "expensive" to begin with). I'll be replacing the existing code in the session manager with code that uses this new distributed cache. This should boost performance in the session manager too, since I wasn't focussed on getting the object send/receive code working as efficiently as possible. By breaking out this particular bit of code, I was able to isolate it and boost its performance.
Part of what I've been doing with the cloud-friendly Tomcat session manager is basically implementing my own asynchronous distributed object cache. At the moment, this functionality is tightly coupled to what I'm doing inside the session Store. But in making some changes recently to add Spring Security integration and make working with Spring Security 3.0 a little easier, I noticed that there's a lot of what I'm doing inside the session Store that could simply be abstracted into its own package and used as a standalone distributed cache.
Although I've blogged quite a bit about the cloud-based utilities I've been writing, releasing as OpenSource on GitHub, and working with here at the world's largest Pizza Hut franchisee, there's still plenty we're doing to deploy Web 2.0 apps that I haven't spent much time talking about. We've traditionally been a little tight-lipped about our application development because, quite frankly, there was no one to talk to about it. No one really cared much what a company they've never heard of does internally to develop applications for their own users.
One of the things everyone who deploys artifacts into the cloud has to deal with is the issue of classloading. If you have multiple nodes out there, listening to your RabbitMQ server, waiting to do work, you have to have pre-deployed all the dependencies you need. This means some system to either copy them out there automatically (in the case of deployable artifacts), or you simply have to copy the JAR files into a lib/ directory somewhere that the listener has access to.
None of these solutions is ideal.
In troubleshooting some problems I was having deploying my cloud-based session manager, I quickly grew frustrated by having to tail log files in three or four windows at once. With no real ability to filter what I was looking for, my important log messages would get buried under the truckloads of other DEBUG-level messages being dumped into those log files. I simply needed a better way to aggregate and monitor my log files.
