jgneff commented on PR #4206:
URL: https://github.com/apache/netbeans/pull/4206#issuecomment-1154475557

   Below are a few more notes from my tests while they're still fresh in my 
mind.
   
   ### Proxy connection reuse
   
   The connection counts in the set of tables in my prior comment above are 
from the perspective of the `ConfigureProxy` class, obtained from Ant debug log 
messages. Yet multiple `ConfigureProxy` connections can be carried by a single 
persistent *keep-alive* proxy connection.
   
   The tables below, on the other hand, show the counts of actual connections 
made through the proxy server to an external host, obtained directly from the 
access log of the Squid proxy server. The proxy access logs for each of the six 
tests below are available in the following archive:
   
   
[squid-access-logs.tar.gz](https://github.com/apache/netbeans/files/8894676/squid-access-logs.tar.gz)
 - Squid access logs for the tables below
   
   #### BEFORE
   
   The table below lists the number of connection made through the proxy server 
to each external host before the changes in this pull request. The columns 
contain the connection counts when `http_proxy` is set, when `https_proxy` is 
set, and when both environment variables are set.
   
   | Proxy Connections       | *http_proxy* | *https_proxy* | Both Variables |
   |-------------------------|-------------:|--------------:|---------------:|
   | gitbox.apache.org       |            2 |             2 |              3 |
   | netbeans.osuosl.org     |           11 |            22 |            109 |
   | services.gradle.org     |            1 |             1 |              2 |
   | downloads.gradle-dn.com |            1 |             1 |              1 |
   | repo.gradle.org         |            1 |             1 |              2 |
   | repo1.maven.org         |            1 |            20 |            468 |
   | **Total connections**   |       **17** |        **47** |        **585** |
   | Unused connections      |       *none* |        *none* |        **546** |
   
   #### AFTER
   
   The table below lists the same information after the changes in this pull 
request.
   
   | Proxy Connections       | *http_proxy* | *https_proxy* | Both Variables |
   |-------------------------|-------------:|--------------:|---------------:|
   | gitbox.apache.org       |            2 |             2 |              2 |
   | netbeans.osuosl.org     |           11 |            11 |             11 |
   | services.gradle.org     |            1 |             1 |              1 |
   | downloads.gradle-dn.com |            1 |             1 |              1 |
   | repo.gradle.org         |            1 |             1 |              1 |
   | repo1.maven.org         |            1 |             1 |              1 |
   | **Total connections**   |       **17** |        **17** |         **17** |
   | Unused connections      |       *none* |        *none* |         *none* |
   
   Notice that there's a large reduction in the number of proxy connections 
made, and no excess unused connections are made at all. I suspect that the 
single thread used in the pull request is allowing the Java runtime to reuse 
the *keep-alive* proxy connections, keeping them to a minimum.
   
   Making the requests sequential through the proxy *keep-alive* connections, 
though, does not affect the build time:
   
   | Build Time      | *http_proxy* | *https_proxy* | Both Variables |
   |-----------------|-------------:|--------------:|---------------:|
   | Before this PR  |      10m 42s |        9m 39s |         9m 33s |
   | After this PR   |       9m 36s |        9m 43s |         9m  5s |
   
   ### A partial workaround
   
   The first table above suggests a workaround for the original problem of the 
build failing when both environment variables are set. The build fails because 
the external host tells it to back off on the excess connections by sending a 
response of "503 Service Unavailable."
   
   The workaround is to remove one of the proxy variables from the environment 
before starting the build:
   
   ```bash
   unset https_proxy
   ant -Dmetabuild.branch=master
   ```
   
   It's only a partial workaround because:
   
   * the build still tries to make direct connections even when it's told to 
use a proxy server, and
   * the build might not take full advantage of the HTTP 1.1 *keep-alive* 
connections because up to three different threads are used to open connections 
through the proxy server.
   
   ### Frequency of failures
   
   Now that I have a workaround, I expect the original problem to be rare. The 
screenshot below shows that the NetBeans builds on Launchpad almost always 
failed over the past six months:
   
   
![latest-builds](https://user-images.githubusercontent.com/1413266/173450229-e915a0ee-d5d8-4df2-9031-8e5f8c879a8e.png)
   
   For future searches, the error messages in the build logs are illustrated by 
the following two samples:
   
   ```
   [downloadbinaries] Could not download ...
     ...
   java.io.IOException: Skipping download from
     https://netbeans.osuosl.org/binaries/
       EC2751668FDF959F31F88FAF3A03C9A28F3E6746-
       wordlist-en_GB-large-2017.08.24.zip
     due to response code 503
   
   [downloadbinaries] Could not download ...
     ...
   java.io.IOException: Skipping download from
     https://netbeans.osuosl.org/binaries/
       89BC047153217F5254506F4C622A771A78883CBC-
       ValidationAPI-b26b94cc001a41ab9138496b11e2ae256a159ffd.jar
     due to response code 503
   ```
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to