On 2/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
[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.
good point
Even if we could hot redeploy stuff, would you? Most would minimise risk by
testing the new configuration first rather than hot deploying.
my answer is a highly qualified yes (but more later)
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.
depends on the nature of the application and environment
if the J2EE server is in a corporate enterprise environment serving
low volume applications to an intranet, the answer is yes, it
definitely is used in production. it's very useful to hot redeploy a
single application without disrupting the rest
(i'll expand later)
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.
this would definitely be useful for the reasons you outlined above
hot deployment is more useful when moving into the world of mail applications.
consider (for example), a james instance serving SMTP and POP3 to a
corporate intranet. let's suppose that it's running as a plugin within
geronimo. it would be more reasonable if the connectors used as
message destinations by J2EE applications were not part of the base
james configuration but were bundled up into mail applications jars
with their configuration. in this case, it seems unreasonable to stop
serving corporate emails just so because some enterprise application
needs to reconfigure their mailets.
ISTM hot deployment is necessary for mail applications but not for the
base configuration
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
