I see your point. Having a cross-workspaces history was something we discussed 
lately but I had not enough time to think it through and implement it. The 
request was closed as won fix because there are several alternatives:

If 50 users reported the same error, it will be added to the remote error 
database as “ignorable log message” automatically.
On the server-ui, If you mark the problem as log message in the error 
reporter’s web ui, it will be added to the remote errors database as “ignorable 
log message” as well.
On the client-ui, If you check the “this is a log message” checkbox in the 
details dialog, we can use that info to add this problem to the “ignorable log 
message” list as well.
The latter hasn’t been implemented yet but since this is a server-side change, 
it can be implemented quickly. You may not want to wait for 50 other users, but 
you may be okay with option 2 or 3?


If you (or anyone else) thinks a cross-workspaces history is required, please 
reopen [1] and add yourself to cc. If a reasonable amount of committers think 
this is required, we can rethink the wontfix for SR1.


Thanks,
Marcel

https://bugs.eclipse.org/bugs/show_bug.cgi?id=468929 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=468929>



> On 12 Jun 2015, at 20:54, Torkild Ulvøy Resheim <torki...@gmail.com> wrote:
> 
> 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
> 
> 
> _______________________________________________
> 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

Attachment: 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

Reply via email to