Re: Class loader leak using maven artifacts

[Rodrigo Bourbon]

I found out that wagon was actually disabled in the old version of the
application that used aether 1.0.2.v20150114 and maven 3.3.9, so it seems
definitely scoped just to wagon.

On Thu, Nov 2, 2023 at 9:06 PM Rodrigo Bourbon 
wrote:

> The application explicitly uses wagon, I should have mentioned that. It
> extends the RepositorySystemSupplier to set it as one of the transports
> and the provider is really simple, it just overrides the lookup method
> like this (the class loader hack is in place):
>
> @Override
> public Wagon lookup(String roleHint) throws Exception {
>   final Thread currentThread = currentThread();
>   final ClassLoader originalClassLoader = 
> currentThread.getContextClassLoader();
>   currentThread.setContextClassLoader(null);
>
>   try {
> if ("https".equals(roleHint)) {
>   return new HttpWagon();
> } else if ("http".equals(roleHint)) {
>   return new HttpWagon();
> }
> throw new IllegalArgumentException("No wagon available for " + roleHint);
>   } finally {
> currentThread.setContextClassLoader(originalClassLoader);
>   }
> }
>
> And we also have an implementation of WagonConfigurator with some custom
> configurations. I just came across this wagon thing and I'm reading about
> it, should I be able to fully replace it with the new default transport
> given that get, head, and put methods are neglected by it?
>
>
> On Thu, Nov 2, 2023 at 7:47 PM Tamás Cservenák 
> wrote:
>
>> 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 > .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.
>> >
>>
>

Re: Class loader leak using maven artifacts

[Rodrigo Bourbon]

The application explicitly uses wagon, I should have mentioned that. It
extends the RepositorySystemSupplier to set it as one of the transports and
the provider is really simple, it just overrides the lookup method like
this (the class loader hack is in place):

@Override
public Wagon lookup(String roleHint) throws Exception {
  final Thread currentThread = currentThread();
  final ClassLoader originalClassLoader = currentThread.getContextClassLoader();
  currentThread.setContextClassLoader(null);

  try {
if ("https".equals(roleHint)) {
  return new HttpWagon();
} else if ("http".equals(roleHint)) {
  return new HttpWagon();
}
throw new IllegalArgumentException("No wagon available for " + roleHint);
  } finally {
currentThread.setContextClassLoader(originalClassLoader);
  }
}

And we also have an implementation of WagonConfigurator with some custom
configurations. I just came across this wagon thing and I'm reading about
it, should I be able to fully replace it with the new default transport
given that get, head, and put methods are neglected by it?


On Thu, Nov 2, 2023 at 7:47 PM Tamás Cservenák  wrote:

> 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  .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.
> >
>

Re: Class loader leak using maven artifacts

[Tamás Cservenák]

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 
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
> .
> 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.
>

Class loader leak using maven artifacts

[Rodrigo Bourbon]

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
.
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.

[ANN] Maven PMD Plugin 3.21.2 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
PMD Plugin version 3.21.2.


https://maven.apache.org/plugins/maven-pmd-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-pmd-plugin
  3.21.2



Release Notes - Maven PMD Plugin - Version 3.21.2

** Bug
* [MPMD-370] - Remove remaining uses of FileReader
* [MPMD-371] - Using two ruleset files with same name in different 
directories

* [MPMD-382] - Regression in report rendering
* [MPMD-384] - maven-pmd-plugin is dowloading transitive 
dependencies of unmanaged version


** Dependency upgrade
* [MPMD-380] - Prefer apache commons and JDK to Plexus utils
* [MPMD-387] - Upgrade to Parent 40


Enjoy,

-The Apache Maven team

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: how to disable http 100-continue with 3.9 http-transport ?

[Stefan CORDES]

Hi Benjamin,
thanks for the hint, but still

mvn deploy -Daether.connector.basic.parallelPut=false
and
mvn deploy -Daether.connector.http.preemptivePutAuth=false
are failing as they send the
http-outgoing-0 >> Expect: 100-continue
header to our nexus(proxy)

Hi T,
> Is it documented somewhere that Nexus3 does not support http-continue?
There is nothing like that but our Nexus is listening on 8081 and we have some 
"http proxy" before on 443 which I now try to find out what proxy it is and 
what version.
(we have nexus+proxy self hosted)

Gruß,
Stefan

-Original Message-
From: Benjamin Marwell 
Sent: Friday, October 27, 2023 8:13 PM
To: Maven Users List 
Subject: Re: how to disable http 100-continue with 3.9 http-transport ?

Hi,

Disabling parallel put works for me.

https://maven.apache.org/resolver/configuration.html


On Fri, 27 Oct 2023, 20:08 Tamás Cservenák,  wrote:

> Howdy,
>
> Are you sure you have to disable use of http-continue? Isn't this
> something "legacy" or hack that you try to carry on maybe?
>
> Is it documented somewhere that Nexus3 does not support http-continue?
>
> If you have support contract, I'd ask your provider about this first...
>
> Thanks
> T
>
> On Fri, Oct 27, 2023, 18:37 Stefan CORDES  .invalid>
> wrote:
>
> > Hi,
> > we configured the 3.8 wagon transport to not send a http-continue as
> > this fails with our nexus3 to store the artifacts.
> >
> > Switching to maven 3.9 the new transport is taken where I cannot
> > find how to disable the http 100
> >
> >
> >
> https://github.com/apache/maven-resolver/blob/master/maven-resolver-tr
> ansport-http/src/main/java/org/eclipse/aether/transport/http/LocalStat
> e.java#L82
> >
> > How can I disable sending
> > [DEBUG] org.apache.http.headers - http-outgoing-0 >> Expect:
> > 100-continue while using mvn deploy?
> >
> > Gruß,
> > Stefan
> >
> > P.S.:
> > Nexus http response is 500 with http-continue and nexus.log shows
> >
> > 2023-10-27 18:19:57,155+0200 WARN  [qtp804177152-23427]  x
> > org.sonatype.nexus.repository.httpbridge.internal.ViewServlet -
> > Failure
> > servicing: PUT
> >
> /repository/Snapshots/com/canda/mule4/x-mule4-template/1.0.0-local-SNA
> PSHOT/x-mule4-template-1.0.0-local-20231027.161836-1-mule-application.
> jar
> > org.sonatype.nexus.blobstore.api.BlobStoreException: BlobId:
> > tmp$d7b33f72-f9be-4fc8-b444-73d98adde3f1, java.io.IOException:
> > java.util.concurrent.TimeoutException: Idle timeout expired:
> > 3/3 ms, Cause: java.util.concurrent.TimeoutException: Idle timeout 
> > expired:
> > 3/3 ms
> > at
> >
> org.sonatype.nexus.blobstore.file.FileBlobStore.tryCreate(FileBlobStor
> e.java:438)
> > at
> >
> org.sonatype.nexus.blobstore.file.FileBlobStore.create(FileBlobStore.j
> ava:368)
> > at
> >
> org.sonatype.nexus.blobstore.file.FileBlobStore.doCreate(FileBlobStore
> .java:348)
> > at
> >
> org.sonatype.nexus.blobstore.metrics.BlobStoreAnalyticsInterceptor.inv
> oke(BlobStoreAnalyticsInterceptor.java:60)
> > at
> >
> org.sonatype.nexus.blobstore.BlobStoreSupport.create(BlobStoreSupport.
> java:125)
> > at
> >
> org.sonatype.nexus.common.stateguard.MethodInvocationAction.run(Method
> InvocationAction.java:39)
> > at
> >
> org.sonatype.nexus.common.stateguard.StateGuard$GuardImpl.run(StateGua
> rd.java:272)
> > at
> >
> org.sonatype.nexus.common.stateguard.GuardedInterceptor.invoke(Guarded
> Interceptor.java:54)
> > at
> >
> org.sonatype.nexus.blobstore.BlobStoreSupport.create(BlobStoreSupport.
> java:109)
> > at
> >
> org.sonatype.nexus.common.stateguard.MethodInvocationAction.run(Method
> InvocationAction.java:39)
> > at
> >
> org.sonatype.nexus.common.stateguard.StateGuard$GuardImpl.run(StateGua
> rd.java:272)
> > at
> >
> org.sonatype.nexus.common.stateguard.GuardedInterceptor.invoke(Guarded
> Interceptor.java:54)
> > at
> >
> org.sonatype.nexus.repository.storage.StorageFacetImpl.createTempBlob(
> StorageFacetImpl.java:266)
> > at
> >
> org.sonatype.nexus.repository.storage.StorageFacetImpl.createTempBlob(
> StorageFacetImpl.java:277)
> >
> >
> > C Services GmbH & Co. OHG | Wanheimer Straße 70 | D-40468
> > Düsseldorf |
> > Sitz: Düsseldorf | Registergericht: Düsseldorf HRA 12655 | Telefon:
> > +49
> > (211) 9872-01
> > Persönlich haftende Gesellschafter: C Retail GmbH | Sitz:
> > Baar/Schweiz
> |
> > UID: CHE-116.290.471
> > Geschäftsführung: Giny Boer, Christoph Hammer FRM Participations
> > S.A. | Sitz: Strassen/Luxemburg | Handels- und Firmenregister
> > Luxemburg: B 58158
> > Verwaltungsratsmitglieder: Dr. Christian Bank, Remco Gerlof, Dr.
> > Franz-Josef Leuchtenberg
> > Hinweise zur Verarbeitung Ihrer Daten finden Sie unter:
> > www.c-a.com/GDPR
> <
> > http://www.c-a.com/GDPR>
> >
>

C Services GmbH & Co. OHG | Wanheimer Straße 70 | D-40468