[EMAIL PROTECTED] wrote: > > > On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > > Unfortunately I think that hot redeployable mailets are far away, > > the biggest issue is that you would have to move all "in process" > messages to a save point that you know will allow them to continue > after you have changed the whole processing pipeline beyond > recognition. This means that it is probably never going to be possible > to have live config changes, but what we should look at is the ability > to restart the spoolmanager without blocking inbound traffic. > > d.
Funny, I began to draft a response which beginning "I don't see this as being architecturally too hard". While listing the sequence of steps we would need to perform it dawned on me that from a pragmatic point of view, hot redployment is really unnecesary. Even if we could hot redeploy stuff, would you? Most would minimise risk by testing the new configuration first rather than hot deploying. Some J2EE servers offer hot redployment, but few use it in production environment. It's more a marketing selling point than a practical solution. I'll admit its useful in development as it allows a quicker turn around. In production, IP redirection switching between the current and new server instance is often the preferred solution. This simple solution could work for James too. The principle things to solve would be: 1) A new "drain and close" mode whereby new messages are rejected, all in process messages are processed until the the pipeline is empty, then the server shuts down. 2) Resolution of synchronization issues which will occur when both the new and old server are writing to the same message stores during the drain period. This is a further case of issues previously raised about multiple James server instances delivering to a single backend store. With these two issues resolved a simple script could be used to bring up the new server with a new and already tested configuration, switch the IP redirection to point to this server, then "drain and close" the old server. This solution may not be as elegant as true hot redeploy, but does have the benefit of simplicity. Cheers -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
