Bugzilla – Full Text Bug Listing
| Summary: | Proxy settings specified in system properties randomly disregarded | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Michal Ruzicka <michal.ruza> |
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 369764 | ||
A plausible hypothesis as to what causes the problem goes follows: - There is a component in buckminster which uses the proxy settings defined in the system properties. (This is a hypothesis but from the looks of it is seems it might be p2.) - There is another component in buckminster which use proxy settings defined in the eclipse/workspace preferences. (This is a fact, such component is for instance 'org.eclipse.jsch.core') - The Platform proxy API code - which is used to access the proxy settings in the eclipse/workspace preferences - sets (during its initialization) the system properties defining the proxy settings such that they mirror the proxy settings defined in the eclipse/workspace preferences (possibly unsetting the respective system properties if there is no proxy settings defined in the preferences). (This is a fact, see for instance org.eclipse.core.internal.net.ProxyType.updateHttpSystemProperties()) - Now a scenario that would lead up to the problem is as follows: * prerequisites: system properties define some proxy settings, eclipse/workspace preferences don't define any proxy settings * a component which uses the proxy settings defined in the system properties retrieves a resource from a remote location without issues because it used the proxy settings defined in the system properties * a component which uses the proxy settings defined in the eclipse/workspace preferences prepares to retrieve a resource from a remote location and checks the proxy settings defined in the preferences by consulting the Platform proxy API which in turn causes the system properties defining the proxy settings to be unset to match the (empty) information in the preferences. The retrieval of the resource then goes on without using any proxy and may even eventually succeed provided that the resource to be retrieved is by accident located on a "non proxy host" (as used to be defined for instance by the http.nonProxyHosts system property before it was unset) * a component which uses the proxy settings defined in the system properties tries to retrieve a resource from a remote location and fails because the system properties defining the proxy settings are unset by now From the above it is clear the problem depends on the order in which certain network operations are performed and given the volatile nature of the network operations, this order is not guaranteed to remain unchanged leading to the random manifestation of the problem. To solve the problem a new command - importproxysettings - was added to buckminster which mirrors the proxy settings defined in the system properties to the eclipse/workspace preferences ensuring that both of the places contain the same information and thus the system properties are never unset by the Platform proxy API code. The crucial thing when using this command is that is must run before the Platform proxy API code is initialized so the that it has a chance to process the proxy settings system properties before they are overriden by the Platform proxy API code. The change was committed in: http://git.eclipse.org/c/buckminster/buckminster.git/commit/?id=ef47f65dcf69f8b3236e75256874e13ad7378602 |
It sometimes happen that proxy settings specified in the system properties are randomly disregarded during a resolution/materialization. In an extreme case it's been observed that a download of one artifact from a p2 repository was attempted with taking the proxy settings into account (i.e. the download was attempted through the proxy) while download of another artifact from the same p2 repository was attempted without taking the settings into account (i.e. directly). It seems that the problem is only triggered if there is a mismatch between the proxy settings defined in the system properties and eclipse/workspace preferences, typically manifested by warnings like these: INFO: System property http.proxyHost has been set to proxy.eclipse.org by an external source. This value will be overwritten using the values from the preferences INFO: System property http.proxyPort has been set to 9898 by an external source. This value will be overwritten using the values from the preferences INFO: System property http.nonProxyHosts has been set to "*.eclipse.org" by an external source. This value will be overwritten using the values from the preferences INFO: System property https.proxyHost has been set to proxy.eclipse.org by an external source. This value will be overwritten using the values from the preferences INFO: System property https.proxyPort has been set to 9898 by an external source. This value will be overwritten using the values from the preferences INFO: System property https.nonProxyHosts has been set to "*.eclipse.org" by an external source. This value will be overwritten using the values from the preferences STEPS TO REPRODUCE Note that the manifestation of the problem is not deterministic thus the steps given below may not trigger it each time. 1) define system proxy properties such that they don't match the proxy settings in the eclipse/workspace preferences 2) try several resolutions/materializations 3) observe the usage of the proxy