Here is a full stack trace: it starts from the resolver and then goes lala and errors out? https://gist.github.com/cstamas/af2285ce6e672ecb19be7f1047d0493b
On Sat, Dec 21, 2024 at 4:48 PM Tamás Cservenák <[email protected]> wrote: > > Howdy, > > Thanks for recording, I will take a peek. > > But the problem really is that I cannot reproduce this. Moreover, you > have some extensions in place that do interfere with Resolver, for > example what is this? > > Stack Trace > ... > boolean com.hubspot.mercedes.MercedesHelper.shouldSkipUpdate(LocalRepository, > UpdateCheck) 1 100 % > void > com.hubspot.mercedes.maven.MercedesUpdateCheckManager.checkMetadata(RepositorySystemSession, > UpdateCheck) 1 100 % > List > org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(SyncContext, > SyncContext, Collection, RepositorySystemSession, Collection) 1 100 % > List > org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(RepositorySystemSession, > Collection) 1 100 % > VersionResult > org.apache.maven.internal.impl.resolver.DefaultVersionResolver.resolveVersion(RepositorySystemSession, > VersionRequest) 1 100 % > > It seems this is some component that "takes over" Resolver classes... > > So without these, I cannot tell much > > Thanks > T > > On Sat, Dec 21, 2024 at 4:42 PM Peter Teixeira > <[email protected]> wrote: > > > > Thanks for your patience in looking into this. I built and ran maven from > > current master (575ad37) and it looks the > > same performance-wise as rc1 / rc2. > > > > > > recording-575ad37.jfr > > <https://drive.google.com/open?id=1MAKmTx0CvLqWQd-SNeumAFEUDrMYz-2O> > > > > > > I really don't know enough about Maven to interpret the call-graphs here, > > unfortunately. The reason that I suspected the resolver > > is because if I patched the resolver version back (specifically by applying > > > > ``` > > diff --git a/apache-maven/pom.xml b/apache-maven/pom.xml > > index 12c6fc2986..9408c78acc 100644 > > --- a/apache-maven/pom.xml > > +++ b/apache-maven/pom.xml > > @@ -137,7 +137,7 @@ under the License. > > <dependency> > > <groupId>org.apache.maven.resolver</groupId> > > <artifactId>maven-resolver-tools</artifactId> > > - <version>${resolverVersion}</version> > > + <version>2.0.4</version> > > <scope>test</scope> > > <exclusions> > > <exclusion> > > diff --git a/pom.xml b/pom.xml > > index 97354843ee..1828b8d7fc 100644 > > --- a/pom.xml > > +++ b/pom.xml > > @@ -162,7 +162,7 @@ under the License. > > <plexusInterpolationVersion>1.27</plexusInterpolationVersion> > > <plexusTestingVersion>1.4.0</plexusTestingVersion> > > <plexusXmlVersion>4.0.4</plexusXmlVersion> > > - <resolverVersion>2.0.4</resolverVersion> > > + <resolverVersion>2.0.2</resolverVersion> > > <securityDispatcherVersion>4.0.2</securityDispatcherVersion> > > <sisuVersion>0.9.0.M3</sisuVersion> > > <slf4jVersion>2.0.16</slf4jVersion> > > ``` > > > > to the maven-4.0.0-rc-1 tag and then building that) I get back the more > > normal build speed > > > > > > recording-patch.jfr > > <https://drive.google.com/open?id=1lMQlzJHJaImg-IQVAjL4JkxSbZoDw0VF> > > > > > > Anyway, I do really appreciate you looking into this. I don't want to take > > up too much of your weekend, > > so if you think this is specific consequence of your build setup or if > > you'd rather wait for a shareable reproducer > > for this I'll be happy to go back to that. > > > > Peter > > > > > > On Sat, Dec 21, 2024 at 9:57 AM Tamás Cservenák <[email protected]> wrote: > > > > > Peter, > > > > > > to me it looks like the issue is _not_ in resolver, it looks more like > > > it is in Maven itself. > > > Could you try out the latest master build of Maven? > > > I can build it for you and share it with you, if you are ok with that. > > > Or, just check out https://github.com/apache/maven > > > <https://github.com/apache/maven> > > > and build it? > > > > > > Thanks > > > T > > > > > > On Sat, Dec 21, 2024 at 2:37 PM Peter Teixeira > > > <[email protected]> wrote: > > > > > > > > Hello! Thanks for taking the time to look into this. I'd definitely be > > > > willing to believe that this > > > > is strange going on with these builds, but I'll keep working on getting > > > an > > > > actual reproducer set up. > > > > > > > > I didn't have any luck with setting the http protocol back to 2. I *did* > > > > wind up running Maven with > > > > JFR (via `MAVEN_OPTS="$MAVEN_OPTS > > > > -XX:StartFlightRecording=filename=recording.jfr" mvn dependency:tree`) > > > > to see if I could collect some timing data, in case you think that'd be > > > > worth looking into. > > > > > > > > recording-rc1.jfr > > > > <https://drive.google.com/open?id=1fyzhR5Avgrg15sFpv5Pt3z5fiuubTLpx > > > <https://drive.google.com/open?id=1fyzhR5Avgrg15sFpv5Pt3z5fiuubTLpx> > > > > > > > > > > > > recording-beta5.jfr > > > > <https://drive.google.com/open?id=1VtoKbI8WNTC_JDZgssG-AGAv1jUeKQg4 > > > <https://drive.google.com/open?id=1VtoKbI8WNTC_JDZgssG-AGAv1jUeKQg4> > > > > > > > > > > > > > > > > Thanks for your help! > > > > Peter Teixeira > > > > > > > > On Sat, Dec 21, 2024 at 7:42 AM Tamás Cservenák <[email protected]> > > > wrote: > > > > > > > > > Found a slightly bigger tree: > > > > > https://gist.github.com/cstamas/c255de93292ecbf1f6f0597ac58624a8 > > > <https://gist.github.com/cstamas/c255de93292ecbf1f6f0597ac58624a8> > > > > > <https://gist.github.com/cstamas/c255de93292ecbf1f6f0597ac58624a8 > > > <https://gist.github.com/cstamas/c255de93292ecbf1f6f0597ac58624a8> > > > > > > > > > > > > > > Still no noticeable diff, especially not in order of magnitude like > > > > > seconds vs minutes... > > > > > > > > > > Something else is going on... > > > > > > > > > > Thanks > > > > > T > > > > > > > > > > On Sat, Dec 21, 2024 at 1:34 PM Tamás Cservenák <[email protected]> > > > > > wrote: > > > > > > > > > > > > Still shooting in the dark... > > > > > > but just to rule out any mischief in any plugin, > > > > > > I used my own code, and ran it with 3.9.9 and 4.0.0-rc-1 on a > > > > > > project > > > > > > I could find, that has fairly big(ger) tree: > > > > > > > > > > > > https://gist.github.com/cstamas/c2751bd8c18eb553f3c38d839c60fc67 > > > <https://gist.github.com/cstamas/c2751bd8c18eb553f3c38d839c60fc67> > > > > > <https://gist.github.com/cstamas/c2751bd8c18eb553f3c38d839c60fc67 > > > <https://gist.github.com/cstamas/c2751bd8c18eb553f3c38d839c60fc67> > > > > > > > > > > > > > > > > As you see, both finished in almost exactly the same duration... > > > > > > So this is not a resolver collection for sure. > > > > > > > > > > > > Thanks > > > > > > T > > > > > > > > > > > > On Sat, Dec 21, 2024 at 1:24 PM Tamás Cservenák <[email protected] > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > > > one obvious thing comes to my mind: > > > > > > > Maven 4.0.0-rc-1 uses Resolver 2.0.4, not 2.0.3. > > > > > > > > > > > > > > And one big change in Resolver 2.0.4 was backing from HTTP/2 > > > protocol > > > > > > > to HTTP/1.1 transport for default JDK > > > > > > > (that, in the scenario of getting a lot of small data like Maven > > > > > > > metadata are, does matter). > > > > > > > > > > > > > > Can you rerun your commands with added following parameter: > > > > > > > -Daether.transport.jdk.httpVersion=HTTP_2 > > > > > > > > > > > > > > This will re-enable HTTP/2 for JDK transport. > > > > > > > > > > > > > > Thanks > > > > > > > T > > > > > > > > > > > > > > On Sat, Dec 21, 2024 at 3:06 AM Peter Teixeira > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > First, I sincerely apologize that I don't have a reproducer for > > > > > this, but I > > > > > > > > did want to say something before the full release of Maven 4. > > > > > > > > > > > > > > > > It seems like for certain dependency tree setups, dependency > > > > > resolution got > > > > > > > > much much slower between Maven 4-beta-5 and Maven 4-rc-1. I > > > > > specifically > > > > > > > > think this was introduced in maven-resolver 2.0.3, and building > > > Maven > > > > > > > > 4-rc-1 patching back to maven-resolver 2.0.2 restores the > > > behavior I > > > > > was > > > > > > > > seeing before. > > > > > > > > > > > > > > > > I have a gist > > > > > > > > < > > > > > https://gist.github.com/PtrTeixeira/b7ad68d2e58c6a2277206b2b6328dc16 > > > <https://gist.github.com/PtrTeixeira/b7ad68d2e58c6a2277206b2b6328dc16> > > > > > <https://gist.github.com/PtrTeixeira/b7ad68d2e58c6a2277206b2b6328dc16 > > > <https://gist.github.com/PtrTeixeira/b7ad68d2e58c6a2277206b2b6328dc16> > > > >> > > > > > of > > > > > > > > the behavior that I'm seeing; for Maven 3 & Maven 4-beta-5, > > > running > > > > > `mvn > > > > > > > > dependency:tree` on this module takes seconds. For Maven 4-rc-1 > > > and > > > > > Maven > > > > > > > > 4-rc-2, it takes over a minute. > > > > > > > > > > > > > > > > For some background context, at work almost all libraries are > > > used at > > > > > > > > `1.0-SNAPSHOT` versions and are managed in a single parent-pom. > > > I'm > > > > > seeing > > > > > > > > this behavior across many repositories at work, so it's not > > > something > > > > > > > > specific to this module. While trying to reproduce this, I did > > > > > establish > > > > > > > > that it doesn't seem to be specifically a result of the depth of > > > the > > > > > > > > dependency tree or the total number of dependencies in the > > > > > dependency tree. > > > > > > > > > > > > > > > > Please let me know if there's any other information that I can > > > give > > > > > you to > > > > > > > > help identify this or track this down; I know this isn't a lot > > > > > > > > of > > > > > > > > information to go on, but this is enough of a performance change > > > > > that I > > > > > > > > wanted to say something before Maven 4 gets fully released. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Peter Teixeira > > > > > > > > > > > > > > > > -- > > > > > > > > We're committed to your privacy. HubSpot utilizes both public > > > > > information > > > > > > > > and/or the information you provide to us to contact you about > > > > > > > > our > > > > > relevant > > > > > > > > content, products, and services. You may unsubscribe > > > > > > > > <mailto:[email protected] > > > ?subject=unsubscribe&body=unsubscribe> > > > > > from > > > > > > > > these communications at any time. For more information, check > > > out our > > > > > > > > Privacy Policy <https://legal.hubspot.com/privacy-policy>. > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > -- > > > > We're committed to your privacy. HubSpot utilizes both public > > > > information > > > > and/or the information you provide to us to contact you about our > > > relevant > > > > content, products, and services. You may unsubscribe > > > > <mailto:[email protected]?subject=unsubscribe&body=unsubscribe> from > > > > these communications at any time. For more information, check out our > > > > Privacy Policy <https://legal.hubspot.com/privacy-policy>. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > -- > > We're committed to your privacy. HubSpot utilizes both public information > > and/or the information you provide to us to contact you about our relevant > > content, products, and services. You may unsubscribe > > <mailto:[email protected]?subject=unsubscribe&body=unsubscribe> from > > these communications at any time. For more information, check out our > > Privacy Policy <https://legal.hubspot.com/privacy-policy>. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
