Hi Marcel, This is looking good. But I’m a bit concerned about “Level 1” - If you have a dozen workspaces, I don’t think I’m the only one, you will still produce excessive error reports. Also I do keep hitting the same error again and again, but choose to not send (because I know the reason). However I’m pretty sure I have reported it in the past. Anyway, the code I’m running is on Mylyn snapshot builds, which I guess only a few is executing. Could that be the reason why it’s not ignored?
Best regards, Torkild > 12. jun. 2015 kl. 20.21 skrev Marcel Bruch <marcel.br...@codetrails.com>: > > Denis, > > there are four (4) + one (1) mechanisms in place that will / can limit the > traffic to dev.eclipse.org/recommenders: > > Level 1: A local, persistent, per-workspace history that remembers what was > send before. If an error is logged that has the same fingerprint as an > already sent report, it is skipped. This should prevent clients to send the > same error over and over again. > > Level 2: A “known errors database” that get’s downloaded from eclipse.org on > IDE startup. If an error is logged in the IDE which was marked as “ignored” > in the known-errors database, it won’t be send. No network traffic will > happen. The server-side generates this database on demand and set’s every > problem to ignore that was reported by more than 50 users. > > Level 3: The “emergency” power OFF switch [1]. On startup, we check whether a > certain system status URL is reachable. If that fails, the system deactivates > the reporter until next restart of Eclipse. > > Level 4: If Eclipse is started with > ‑Dorg.eclipse.epp.logging.aeri.ui.skipReports=true, no errors will be sent. > EPP packages may add this into the eclipse.ini in worst case. > > Level 5: I’m not sure what exactly would happen if the firewall blocks access > the service. But I assume we catch every exception and log it gracefully as a > warning. So this looks like Level 5 to me. > > However, the traffic may still be large - especially in the first days. In > that case I’m happy to pull the plug via Option 3 or Level 4 by rebuilding > the EPP packages. Or 5 if you don’t see any other option. Or we start with > just one EPP (e.g. Committers and or Java) package for the release and add > more until we are sure it works. I think we have all options in your hands to > control it on various levels. > > > Regarding Reporting to Bugzilla: Yes, the traffic goes to > dev.eclipse.org/recommenders/* If this server is shut down, nothing can ever > go to Bugzilla. > > I hope I'll keep my account for a while… still crossing fingers, though. > > Best, > Marcel > > > [1] > https://git.eclipse.org/c/epp/org.eclipse.epp.logging.git/tree/bundles/org.eclipse.epp.logging.aeri.ui/src/org/eclipse/epp/internal/logging/aeri/ui/log/CheckServerAvailabilityJob.java#n51 > > >> On 12 Jun 2015, at 19:57, Denis Roy <denis....@eclipse.org> wrote: >> >> >>>> >>>> On 06/12/2015 01:15 AM, Marcel Bruch wrote: >>>>> We are now looking forward to the first two weeks of the Mars release >>>>> and cross fingers that we don’t get flooded. >>>> >>>> Marcel, >>>> >>>> Do we have an OFF switch somewhere so that we can turn these things off if >>>> we see we're going to get flooded? >>> >>> Have we...? >>> Do you...? >> >> >> I have a big "OFF" switch called a firewall, but I'm not sure how that will >> manifest itself in Eclipse if the error reporter cannot connect to its home >> site. >> >> Also, just so I understand, the 1000's of daily reports (which could become >> 100,000's of daily reports on June 25) are all reports against the >> recommenders server, right? Not Bugzilla bugs, right? The latter could see >> the OFF switch extended to your user account :) >> >> I will be at ECE to collect on any wrongdoings you do to your fellow >> committers. >> >> In all seriousness, let me know if there's anything I can do to make sure >> we're prepared for what is about to come. >> >> >> Denis >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- > Codetrails GmbH > The knowledge transfer company > > Robert-Bosch-Str. 7, 64293 Darmstadt > Phone: +49-6151-276-7092 > Mobile: +49-179-131-7721 > http://www.codetrails.com/ > > Managing Director: Dr. Marcel Bruch > Handelsregister: Darmstadt HRB 91940 > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Torkild Ulvøy Resheim Consultant / Eclipse Committer / Senior Software Developer Itema AS - http://itema.no
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
