Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70164

Maven project intermittently requests invalid artifact url

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • maven-plugin
    • None
    • AWS EC2 instance, RHEL8.6, JDK 11.0.9, Maven 3.6.2, Jenkins 2.361.2, Maven integration plugin 3.20

      I have a number of maven jobs which have recently started failing. The issue only seems to reproduce after a new build node has been launched:

       

      • EC2 plugin launches a new node 
      • Maven job starts
      • logs: Replacing all maven server entries not found in credentials list is true
        then fails see attached mavenJobFailure.txt
      • the corresponding log from nexus is showing that the url is malformed, the request received is not asking for the maven-metadata.xml
        x.x.x.x - - [25/Nov/2022:04:48:46 +0000] "GET /repository/maven-public/com/abc/def/myproject-parent/1.0.1-SNAPSHOT/myproject-parent-1.0.1-SNAPSHOT.pom HTTP/1.1" 404 - 1884 3 "Apache-Maven/3.8.3 (Java 11.0.9; Linux 4.18.0-372.9.1.el8.x86_64)"

      After the failure, a new job kicks off 10s later and the downloads the same artifact correctly

          [JENKINS-70164] Maven project intermittently requests invalid artifact url

          Geoff added a comment -

          Update on the issue:

          Thanks to wireshark amongst other tool I've been able to trace what happens on start up on the AWS machines spawned by the ec2 plugin. 

           

          • Machine starts
          • Java build starts
          • Jenkins attempts to parse poms and request them from our Nexus repo
          • The jenkins node attempts to TCP handshake with nexus
          • Occasionally the TCP connection is not established due to the kernel level max retries being reached, it then attempts to connect again via a different port
          • The load on Nexus has by this time reduced and the handshake is completed
          • The HTTP GET request sent is for the versioned artifact rather than for the maven-metadata.xml which would allow it to download the correctly timestamped pom 

           

          If the TCP handshake is completed without reattempting to connect via another port then the HTTP GET request are as you would expect. 

           

          Obviously the underlying cause is the fact the repo is unable to repond to the requests fast enough, but it is causing unexpected behaviour in jenkins.

           

          Geoff added a comment - Update on the issue: Thanks to wireshark amongst other tool I've been able to trace what happens on start up on the AWS machines spawned by the ec2 plugin.    Machine starts Java build starts Jenkins attempts to parse poms and request them from our Nexus repo The jenkins node attempts to TCP handshake with nexus Occasionally the TCP connection is not established due to the kernel level max retries being reached, it then attempts to connect again via a different port The load on Nexus has by this time reduced and the handshake is completed The HTTP GET request sent is for the versioned artifact rather than for the maven-metadata.xml which would allow it to download the correctly timestamped pom    If the TCP handshake is completed without reattempting to connect via another port then the HTTP GET request are as you would expect.    Obviously the underlying cause is the fact the repo is unable to repond to the requests fast enough, but it is causing unexpected behaviour in jenkins.  

            Unassigned Unassigned
            geoffgray Geoff
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: