Hi Rodrigo, If you have "that uses maven programmatically to resolve dependencies" and you updated it to Maven 3.9.4, then there is something more you have, as Maven 3.9 demotes wagon as "primary" transport. Given your analysis still shows wagon classes, it means your code explicitly uses Wagon. Can you share some source maybe?
Thanks T On Thu, Nov 2, 2023, 23:09 Rodrigo Bourbon <rbour...@salesforce.com.invalid> wrote: > Hi, I have an application that uses maven programmatically to resolve > dependencies and I noticed that the class loader used to load the maven and > maven-resolver artifacts is being retained in memory because of the > connection manager created in > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.createConnManager() > while getting the SSLSocketFactory > <https://github.com/apache/maven-wagon/blob/wagon-3.4.2/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L384>. > To fix it I set the context class loader to null before creating the > HttpWagon and it worked partially. I no longer get a strong reference on > my class loader but I see it in "Pending finalization" state forever, so > it's never actually deallocated. The reason seems to be an SSL socket that > it's not being closed properly as shown in the image below. > [image: image.png] > > After searching where that socket comes from I see that it's again related > to the AbstractHttpClientWagon while executing metadata resolution, but I > can't manage to find when it's being leaked. > This started happening after I changed to newer versions, I'm using > maven-resolver > 1.9.15 and maven 3.9.4 and previously I was using aether 1.0.2.v20150114 > and maven 3.3.9. > > Any ideas on what might be going on? Thanks in advance. >
