[
https://issues.apache.org/jira/browse/MRESOLVER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689210#comment-17689210
]
ASF GitHub Bot commented on MRESOLVER-319:
------------------------------------------
cstamas opened a new pull request, #245:
URL: https://github.com/apache/maven-resolver/pull/245
In the mean time turns out we have two important "implementation details" to
obey, and behave correctly:
* we need ONE transport to happen (go thru pipe fully) before we can pour
the rest onto transport
The HTTP transporter is equipped with "shared" caches for auth that is
heavily used by HttpClient to make decisions (ie. about re-attempting request).
Current code is quite complicated, but auth sharing happens when one transfer
task is done, and that step "inseminates" the cache to be used by others (and
skip the auth dance from that point onwards). Similar step happens by transfer
by issuing OPTIONS to remote to discover does it deals with WebDAV server or
not (is MKCOL dance needed or not). All these states are once task is done
shared and remembered for the lifetime of session (per remote repository).
Hence, to obey these rules, simple fix is applied: FIRST transfer is sent thru
pipe alone fully, and once is done, the REST is pushed in parallel, as at that
point, all the auth caches and DAV state of remote repositry are already
discovered by first one. This simple "trick" should not introduce big
performance loss for parallel vs sequential deploy.
* we must ensure proper ordering, that was not ensured by origina
implementation
Clients when going for metadata are getting them as G -> A -> V (the longest
chain in case of snapshot maven plugin). Hence, we must ensure we deploy the
opposite order, and we start deploying next group ONLY when we are fully done
with previous group. Not ensuring this would leave a window of opportunity of
failed build, where for example A level md is present, but V level not yet.
---
https://issues.apache.org/jira/browse/MRESOLVER-319
> Support parallel deploy
> -----------------------
>
> Key: MRESOLVER-319
> URL: https://issues.apache.org/jira/browse/MRESOLVER-319
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.5
>
>
> Basic connector is able to perform parallel fetches. In same way, connector
> should be improved to perform parallel uploads.
> The new feature should be "dormant" by default (as every new feature), but
> user should be able to enable it via configuration.
> Two important implementation details:
> * we need ONE transport to go from beginning to end thru the pipe (to init
> transporter fully)
> * metadata needs to be ordered V->A->G->ROOT as clients go opposite order (to
> not let any window of opportunity of failed build)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
