You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (Jira)" <ji...@apache.org> on 2020/10/17 16:38:00 UTC

[jira] [Closed] (MNG-6976) --no-transfer-progress variant to diagnose download issue

     [ https://issues.apache.org/jira/browse/MNG-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Osipov closed MNG-6976.
-------------------------------
    Resolution: Won't Fix

Closing for the following reasons:
* First proposal requires to track a lot of information and analyze them asynchronously in Maven Resolver, not Maven. This is a lot of work. Unless someone creates a PR, no change will come from use, trust me.
* I have provided a solution for filtering out download information.

> --no-transfer-progress variant to diagnose download issue
> ---------------------------------------------------------
>
>                 Key: MNG-6976
>                 URL: https://issues.apache.org/jira/browse/MNG-6976
>             Project: Maven
>          Issue Type: Improvement
>          Components: Command Line, Logging
>    Affects Versions: 3.6.3
>            Reporter: Jesse Glick
>            Priority: Major
>
> {{-ntp}} is very welcome as a way to cut down on log spam. This is especially significant in a CI environment where Maven is being run in a virgin container/VM with no initial local repository, typically with a settings file directing downloads to some local mirror: every {{mvn}} command's output would otherwise be 99% transfer messages, making it very difficult to find real messages in the middle.
> The problem comes if there is a serious delay or even hang in some transfer. Without {{-ntp}}, you could guess that a build was stuck waiting for an overloaded Nexus server or the like just by scanning a timestamped log file and noticing that some big artifact had been requested but never served, or that thousands of little artifacts are being served but take a second each, etc. With {{-ntp}}, it is less obvious what is going wrong: there is no information about which artifact download is stuck, what the URL of the server it is stuck on is, or even whether Maven is waiting for a download at all (perhaps it is doing something unrelated).
> Suggestions:
> * Amend {{-ntp}} (or introduce an argument or a variant) so that if a particular artifact download is in progress for, say, 10s that a warning is emitted with the download URL. Or, if a whole block of downloads during some artifact resolution phase is taking more than, say, 5m, print a warning summarizing the server(s) in use, the number of artifacts requested vs. retrieved, etc.
> * Offer a convenient way to capture the sort of logging produced by {{-B}} without {{-ntp}} (i.e., one line per artifact requested or retrieved) but direct this to a file rather than the stdout/stderr of the {{mvn}} process, so it does not overwhelm a CI log yet can be inspected on demand.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)