https://issues.apache.org/bugzilla/show_bug.cgi?id=45989
Mark Thomas <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #3 from Mark Thomas <[EMAIL PROTECTED]> 2008-11-01 17:56:32 PST ---
The farm deployer should be fixed - see bug45851.
The issue here is one of timing between the network copy and the deployer
thread.
We could check that the file isn't changing in size but that is no guarantee.
A work around that would reduce, but not eliminate the chances of this
happening is:
- upload the war to a different directory
- copy the war locally which should be a lot faster
Approaches that would work:
- use the manager app - the context is marked as serviced which prevents the
background process trying to deploy it
- use JMX to mark the context as serviced before you start the copy and unmark
after the copy completes
- use a simple cluster and take each node down for upgrade
- use the (now fixed) farm deployer with a cluster
I can't see a reliable way to make this work and given that there are a number
of methods provided that would allow this to work I am going to mark this one
as won't fix.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
