-
Notifications
You must be signed in to change notification settings - Fork 136
[MRESOLVER-7] Download dependency POMs in parallel v2 #10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There changes need to be separate issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also be a separate issue.
@michael-o what changes i should move? all 3 commits? |
The subpackage and version bumps. |
ok, I updated this PR to contain only MRESOLVER-7 and created a new #11 for dependencies update and #12 to move the dependency collector to submodule (#10 must be tested/merged first) |
It looks like this has bit-rotted again. It'd be really nice to get this in. Some classes have moved into a sub-package in #12, so now package-private visibilities are getting in the way. I wanted to try it out and see how much difference to speed it made, so I just quickly undid #12. For me it seems to roughly double the speed of artifact fetch. It'll probably make a much bigger difference on higher latency links. Nice work! |
…allel dep resolution
@mikehearn What needs to be changed to make classes accesible for this PR? I'll change it. |
@slachiewicz I maybe wrote gibberish, I am working on five projects in parallel and simply lost track. Don't take my request as imperative. |
and I’m just trying to help:) |
Hi guys, are there any plans for this to be merged anytime soon? We have a bit project which might benefit from this. Is there anything more needed to be done? |
@steve-todorov Did you try the patch yourself? Unfortunately, there is a very little amount of people working on Resolver right now. I am personally too busy. There is so much new code that I have trouble to understand it, especially because I am not fully comfortable with the Resolver code. But I am still looking into it. @slachiewicz Can you rebase again? |
I did rebase code and I compile few projects with clean repo - it looks good and fast. |
For what it's worth I've been testing it locally a fair bit and it's been working fine. However I had to fork Maven Resolver and add a few commits on top to get it working as well as I wanted it to: https://github.com/mikehearn/maven-resolver/commits/master Specifically, I had to roll back a change that conflicted with this PR, and then I added this commit: to avoid creating non-daemon threads. |
Thx @mikehearn for tests and suggestion to use cachedThreadPool. I made small modification to use 5 core threads and max to 10 thread. Could you test new version? |
Can someone tell why the daemon threads along with the cached pool is necessary? |
ok, finaly i reuse in f195414 existing code used to create threads (org.eclipse.aether.util.concurrency.WorkerThreadFactory) in org.eclipse.aether.internal.impl.DefaultMetadataResolver#getExecutor |
Is this one now complete and can be reviewed again by me? |
yes, it’s final version :) |
I will drop cf1a1f7 because this is a different issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you passing DefaultDependencyCollectionContext
around where you have an interface for? The callers should be decoupled form the implementations.
/** | ||
* Setup executor with 5 daemon threads in pool, max to 10 concurrent and keep alive to 10 sec inactivity. | ||
*/ | ||
private ExecutorService executor = createExecutorService( 5, 10, 10 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last arg is 10L
.
private static final ThreadGroup THREAD_GROUP = new ThreadGroup( "Maven Resolver dependency resolution" ); | ||
|
||
/** | ||
* Setup executor with 5 daemon threads in pool, max to 10 concurrent and keep alive to 10 sec inactivity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
10 sec
to > 10 s
.
Maven master fails with:
Please review. |
@slachiewicz I'd like to publish MRESOLVER in a couple of days. Can you have a look at the PR again please? |
Dependencies are now processed asynchronously by an Executor Cherry-pick commit from PR#2 Nov 1, 2016
Logic aligned with DefaultMetadataResolver and BasicRepositoryConnector Executors
That use of DDCC is hard to remove without extending resolver-api and its jhard to understand how this work. I’m able to reproduce this bug but no idea about reason. I’ll look into this more later. |
Testcase: Expected: Actual: Can be related to https://issues.apache.org/jira/browse/MRESOLVER-9 |
While I understand MRESOLVER-9 I do not understand this failure. How can this happen if we don't have any changes in dep resolution, do we? Do I need to merge MRESOLVER-9 first? |
@slachiewicz, do you want to take another look at it. We want to roll 1.3.1 next week. I'd be cool if we could include this. My last questions are still open. |
@slachiewicz, do you think you can take on this? You know the change best by now. |
Unfortunately not for this release - I need more time to isolate a problem. |
No issue, take your time. |
Hi @slachiewicz ! Were you able to get back to this? A lot of people would love to get this PR merged, see https://stackoverflow.com/questions/32299902/parallel-downloads-of-maven-artifacts/43832592 . :) |
Hi @slachiewicz, I'm very interested in this PR, what is blocking it ? What can I do to help ? |
@juliendemaziere. Time issues. You can work on it if you like, I'll be happy to review it. |
FYI, I've looked at this issue again after all this time, and I've got it working now locally, including the entire maven-integration-testing suite. It looks like the missing bit is indeed related to https://issues.apache.org/jira/browse/MRESOLVER-9. I'm going to submit a new PR based on this one. Thanks to @slachiewicz and everyone else who kept the candle burning! |
@hwellmann, what exact missing bit? |
@hwellmann, why is #30 necessary for this PR? |
It fixes the failing test org.apache.maven.project.inheritance.t06.ProjectInheritanceTest observed by @slachiewicz in October 2018 as well as some failing tests from maven-integration-testing when using a build of Maven with this verion of Maven Resolver. |
Can this one be closed in favor of #30? |
Yes, of course. |
Resolve #817 |
Resolve #1397 |
Resolve #817 |
Rebased version of@hwellmann pull #2
I do not know if it's faster now, but I managed to compile the Maven project successfully and the it-core-tests completed correctly.