Monday, September 16, 2002

Perfect balance... Perfect balance. As our portal product at some point will be clustered, I've begun thinking about load-balancing. The normal approach seems to be to use a concentrator thingy in front of all the webservers, which delegates to them based on a round-robin (maybe with weighting) scheme. That sounds stupid to me. Wouldn't it be better if the webservers hooked up into the load-balancer (LB) and told it: here, I have 5 threads, so please don't send more than 5 requests to me at a time. When all servers have done this, the LB will have a bunch of "tokens" that it can use to dispatch requests into the cluster. When a request is dispatched a token is removed. When the request has finished rendering the token is added again to the LB. The LB can also check rendering times in order to automatically prioritize what servers to call. If I'm not completely wrong this should provide perfect load-balancing, since there's no guessing going on: the LB always knows which server to dispatch to. The hooking up could be implemented using Jini (i.e. no configuration necessary), and the "token-counter" in the webserver could be done as a servlet filter. Shouldn't be that hard to do. What do you think? Is this "old news"? Is there an LB available already that works along this way? If not, would it make sense to build one like this? [Random thoughts] In practice just having a clever load balancer that dynamically changes its weightings to different servers based on their responsiveness would be my preference. Also to really get optimal performance with a modern servlet engine, it'd be using async IO, so you'd want the servlet engines to have plenty of requests buffered up so that as soon as a worker thread is available its ready to dispatch. i.e. even if there's only 5 worker threads, under heavy load you'd want at least 7 to 10 requests dispatched to the engine so that as soon as a worker thread is free, it has a request to process. Based on the behaviour of the Servlet engines the LB should be able to deduce how many concurrent requests per engine seems like an optimal number, changing this number based on experience. (e.g. one thread in a servlet engine could block indefinitely). 2:24:09 PM    comment []

More on Messenger Messenger looks cool . Firstly, have you seen Messenger? Its an easy to use JMS facade that does pooling for you together with a simple lightweight JMS application server for managing subscriptions designed for the web tier, so no EJB required. So you can write Message Driven Objects which are lightweight non-EJB equivalents of MDBs. With Messenger you can even use to Servlets or JSP to process JMS messages :-). So its an ideal way of integrating the use of JMS into the web tier without requiring an EJB container. Secondly Jelly supports Messenger and will ultimately have libraries for performing HTTP, SMTP and WSDL interactions. The werkflow project is integrating Jelly support (as I hope OSWorkflow will also), so working with JMS, HTTP, SMTP or SOAP from inside a workflow should be pretty trivial. Hopefully there can be some investigation into connecting (say) Messenger and werkflow and/or OSWorkflow so that workflows can define JMS and SOAP service subscriptions (rather like BPEL does) and that can generate the necessary plumbing to consume messages and create and manage workflow instances. [James Strachan] This is awesome! I was just looking for a JMS provider that could run in a servlet engine the other day, and came up empty! This could open up a whole new class of federated content web apps. I'll have to take a look to see if you can do things like set up durable subscribers to topics.... This could allow a web app to subscribe to content from another web app and get it whenever it's online. This all ties in with the RSS syndication somehow.... [Jason Carreira] The Quality of Service, such as durable subscription, whether you want queue semantics (only 1 consumer gets each message) or topic semantics (all consumers get each message) are all configured via the XML deployment descriptor. Most decent JMS providers should work fine inside a servlet engine. e.g. my employers JMS provider, SpiritWave works totally fine in an applet, application, servlet or EJB server. 2:05:10 PM    comment []

Maven blindness? My 2 cents on Maven-blindness First off Maven has some very cool features. In fact I use it on a project. However, I don't think everything should use it and here's why: It seems to take longer to run a simple build with Maven. The startup time can be irritating. It doesn't seem to handle zip files well. It can be a pain mapping libs from the repo directory to an IDE like ( IDEA ) It can really over-complicate a small project Please don't mavenize WebWork! But I do thing adding just the DVSL (Velocity) doc generation to WebWork would be nice. Of course you don't need maven for this [Miceda] 1. Maven isn't even at 1.0 yet. By 1.0 I'm sure it will be at least as fast as Ant. 2. In what way? 3. There are plugins for most major IDE's that automatically generate the project descriptors for the IDE. Works for eclipse, jbuilder and IDEA I think. Type maven -g and look for your IDE in the list. 4. The Jakarta Commons project contains many small projects. Using Ant they are a PITA to build. With Maven they are a breeze, just type 'maven'. I guess its a subjective thing though. Once you've learnt Ant you're gonna find it easy to use. I'm sure the same will be true of Maven once you've used it a bit. Finally a project can if it wishes support both an Ant build system and a Maven build. If you were to Maven-ize a project you're not taking anything away or loosing anything. Also a Maven-ized project can auto-generate an Ant build file so that Ant users can still build your project using vanilla Ant. The auto-generation uses the Maven descriptor to download all the dependent jars and set the correct classpath etc. 8:24:48 AM    comment []