Bugzilla – Full Text Bug Listing
| Summary: | Solution should only contact p2 updates site when the install button is clicked. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] MPC | Reporter: | Nathan Gervais <nathan> | ||||
| Component: | Install | Assignee: | Project Inbox <mpc.install-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ian.skerrett, jkrause | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.0.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Nathan Gervais
This feature relates to the SOW, where it is specified: bq. Before each entry is shown, a ?quick validation? runs to ensure that it is very likely to install successfully. The idea is that we don't want to enable the install button for solutions that definitely aren't available. Furthermore the request provides a mechanism for vendors to count how many "impressions" are made, ie: how many times they're displayed in the marketplace client UI. Requests made by p2 to verify availability consist of an HTTP HEAD request for the following resources, in this order: # content.jar # content.xml # site.xml In other words, the overhead for servers should be minimal. Benefits include: # users are not presented with an option to install things where there is no update site # solution providers can count the number of times their solutions are presented to users I propose that we close this issue as won't fix, since it's intended design, has negligible negative impact while providing tangible benefits. (In reply to comment #1) > This feature relates to the SOW, where it is specified: > > bq. Before each entry is shown, a ?quick validation? runs to ensure that it is > very likely to install successfully. > > The idea is that we don't want to enable the install button for solutions that > definitely aren't available. Furthermore the request provides a mechanism for > vendors to count how many "impressions" are made, ie: how many times they're > displayed in the marketplace client UI. > > Requests made by p2 to verify availability consist of an HTTP HEAD request for > the following resources, in this order: > # content.jar > # content.xml > # site.xml > > In other words, the overhead for servers should be minimal. > > Benefits include: > # users are not presented with an option to install things where there is no > update site > # solution providers can count the number of times their solutions are > presented to users > > I propose that we close this issue as won't fix, since it's intended design, > has negligible negative impact while providing tangible benefits. I think the main concern is that we could start to create DOS against some of the solutions update sites. What about showing the Install button and only when the user selects the Install does it do the p2 check? *** Bug 313002 has been marked as a duplicate of this bug. *** Just throwing in some data points. The marketplace website currently gets roughly 15K visits per day, it does not seem unlikely to get similar traffic with the marketplace client. Based on this number a solution showing up as a featured listing could get up to 45K head requests to its update site url, considering bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=313004 it could be up to 75K requests. That seems like a lot of traffic only for checking in advance. Especially for the launch of the marketplace client this could become a problem, because interest will be high and we may overload the providers sites. Also it seems impossible to navigate to a different catagory while the check for the availability is going on. A single listing with an updatesite responding with big delay would hamper the usability of the marketplace client. (In reply to comment #4) > Also it seems impossible to navigate to a different catagory while the check > for the availability is going on. A single listing with an updatesite > responding with big delay would hamper the usability of the marketplace client. David, how do we handle non-responding update sites in general? (In reply to comment #4) > Based on this number a solution showing up as a featured listing could get up to > 45K head requests to its update site url, considering bug > https://bugs.eclipse.org/bugs/show_bug.cgi?id=313004 it could be up to 75K > requests. That seems like a lot of traffic only for checking in advance. I agree, it's a lot of traffic -- but consider that it's not much different than a single web page with a CSS and a couple of graphics. Also since these are HEAD requests, no data is transferred other than the HTTP status line and HTTP headers. > Especially for the launch of the marketplace client this could become a problem, > because interest will be high and we may overload the providers sites. I really doubt that provider sides will be overloaded by 75K HEAD requests per day, and they _do_ have a mechanism for opting out by removing their update site from the marketplace. > Also it seems impossible to navigate to a different catagory while the check for > the availability is going on. A single listing with an updatesite responding > with big delay would hamper the usability of the marketplace client. This is indeed a problem. The user can cancel the site verifier however they may not realize that they can. It's certainly possible to disable the site verifier prior to Helios. It's a tradeoff that should be considered carefully. Maybe you could make the availability checking configurable (by the extension point). For our marketplace the updates sites are available by design because they are created by us. We run a verification on our server, so running the verifier at every client for every listed solution is a significant overhead in our use case. And we may end up with 1M+ HEAD requests to our site per day just for checking something that we know exists. Jochen, you brought up a good point: this is something that should occur on the server, not on the client. A simple process on the server could verify availability and eliminate excessive web traffic. In addition, the server could also track and report on impressions (the number of times a solution is displayed) by tracking responses returned by the REST API. I recommend that we disable the site verifier in its current form for all catalogs and look at a server-side solution. Ian? (In reply to comment #8) > Jochen, you brought up a good point: this is something that should occur on the > server, not on the client. A simple process on the server could verify > availability and eliminate excessive web traffic. In addition, the server > could also track and report on impressions (the number of times a solution is > displayed) by tracking responses returned by the REST API. > > I recommend that we disable the site verifier in its current form for all > catalogs and look at a server-side solution. Ian? I can see why this is better to do on the server. However, we are too late for us to get that working for Helios. I don't want to have a lesser user experience because of this. How about we do the check when the user hits Install? Therefore, the Install button would always be available but once it is selected we do the check and raise an error message then? fixed: buttons are enabled, and site verification occurs when the provisioning operation is resolved. Created attachment 169156 [details]
mylyn/context/zip
thx for fixing this. It is a huge improvement in the user experience of the market place. |