[ https://issues.jboss.org/browse/WFCORE-829?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-829: ----------------------------------------- I'm not overly concerned about the locking, as the upload is really an inherent part of whatever other op is going to use the uploaded content (e.g. the deployment add op.) I believe if the CLI were used for this instead of a pure HTTP client, the upload would happen as part of the execution of the deployment add itself. (IIRC the CLI attaches the content as a stream.) That said, the temp file idea is interesting. It could perhaps be used with the deployment add handlers itself too, i.e. to get the over-the-network part of the upload out of the lock. HOWEVER, while looking at this further since writing the above I'm confused about the initial report. Looking at DomainApiUploadHandler (which deals with the HTTP part of this) in both EAP 6 and WildFly it looks like the effect is to store the uploaded content to a temp file and then invoke the management op with the temp file attached as a stream. So the basic effect should already be what you suggest. So what is taking 5 mins without the lock held? Just the local FS copy from that temp file to the repo? The .lock file idea is less tempting. Mostly because it adds complexity. If the system crashes in the middle of upload, the .lock file will be left around. Using a file in the jboss.server.tmp.dir is less of an issue as that dir gets wiped on reboot. -- This message was sent by Atlassian JIRA (v6.3.15#6346)