Nexus-repository-p2 plugin: How to prevent constant polling of proxied repository?

Hi,

I am using Nexus OSS 3.19.1-01 with the nexus-repository-p2 plugin to proxy some p2 repositories hosted at download.eclipse.org. Unfortunately, now my Nexus log is filled with entries like the following:

2019-11-26 12:15:10,009+0100 INFO  [qtp864905650-1880]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond
2019-11-26 12:15:10,010+0100 INFO  [qtp864905650-1880]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - Retrying request to {s}->https://download.eclipse.org:443
2019-11-26 12:15:11,779+0100 INFO  [qtp864905650-1878]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond
2019-11-26 12:15:11,780+0100 INFO  [qtp864905650-1878]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - Retrying request to {s}->https://download.eclipse.org:443
2019-11-26 12:15:15,031+0100 INFO  [qtp864905650-1863]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond
2019-11-26 12:15:15,031+0100 INFO  [qtp864905650-1863]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - Retrying request to {s}->https://download.eclipse.org:443
2019-11-26 12:15:18,421+0100 INFO  [qtp864905650-1881]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - I/O exception (java.net.SocketException) caught when processing request to {s}->https://download.eclipse.org:443: Connection reset
2019-11-26 12:15:18,421+0100 INFO  [qtp864905650-1881]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - Retrying request to {s}->https://download.eclipse.org:443
2019-11-26 12:15:26,453+0100 INFO  [qtp864905650-1723]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {s}->https://download.eclipse.org:443: The target server failed to respond
2019-11-26 12:15:26,454+0100 INFO  [qtp864905650-1723]  *UNKNOWN org.apache.http.impl.execchain.RetryExec - Retrying request to {s}->https://download.eclipse.org:443

In other words, my Nexus is constantly busy polling download.eclipse.org and being rejected (maybe even because it polls too much…), which seems bad, not just for Nexus but also for download.eclipse.org.

The proxy repositories are all configured like this:

  • Blocked: off
  • Auto blocking enabled: off (this being on was my first suspect for causing the endless stream o requests)
  • Maximum component age: -1
  • Maximum metadata age: 10080 = 1 week (also tried with -1, but couldn’t find any information whether -1 was actually interpreted as “forever” for maximum metadata age)
  • Not found cache enabled: on
  • Not found cache TTL: 10080 = 1 week

But even setting Blocked to on doesn’t cause the constant polling to go away.

What am I missing?

This is a community forum, not a support site. If you have a paid license for our product then use the support system at https://support.sonatype.com. If you are using the free version, you could try raising an issue in the “dev - nexus” project at https://issues.sonatype.org.

Regards,

Rich

I do realize that this is a community forum. And, honestly, I think this question is appropriate here:

After all, I am not saying that Nexus has a bug (where an issue tracker like https://issues.sonatype.org would be more appropriate), but merely that it doesn’t behave as expected. This may be a bug but just as likely it is me misreading how a configuration option like maximum metadata age or auto blocking enabled is supposed to work. Maybe a fellow Nexus user can help me out here or has been facing similar issues.

(That being said, if you really think this kind of question is off-topic, then please add a pinned message to the category spelling out what kind of questions you want and what you don’t want. Personally, I have a hard time telling why my question is inappropriate and, e.g., this one is not.)

Filing a bug would be best, so we can get your logs and configuration.

Rich

Hi Rich.

A colleague and I have investigated this further: The problem seems to be solely with the nexus-repository-p2 plug-in, i.e., it occurs only with proxied p2 repositories. Is https://issues.sonatype.org/ still the right issue tracker then? Or should I file a bug at GitHub?

That being said, we found out that the underlying problem is that Nexus never experiences cache hits for the proxied p2 repository: On a GET to, say, plugins/com.ibm.icu_64.2.0.v20190507-1337.jar.pack.gz it fetches the resource from upstream and store it. This is as expected and I can see the cached resource in the repository browser. But on the very next GET to the same resource, there is a cache miss for the resource Nexus just stored; it hence has to fetch (and store) the resource from upstream again. :frowning:

Good point. The p2 plugin is in transition, we’re working on pulling it into the product, but that hasn’t been done yet. So github is the right place for now.

Race condition. :slight_smile:

Just filed https://issues.sonatype.org/browse/NEXUS-22013, as I don’t feel good about putting a 47 MB support ZIP where all the world can see it. Maybe there is nothing sensitive in any of the logs, but it is really hard to tell when your uncompressed nexus.log is >700 MB (was toying around with some of the log levels). And Jira has the nice Security Level: Reporter and Sonatype default.