Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 414852

Summary:	[Shell] Prevent unnecessary parse calls in orion.shell.type support
Product:	[ECD] Orion	Reporter:	Maciej Bendkowski <maciej.bendkowski>
Component:	Client	Assignee:	Grant Gayed <grant_gayed>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3
Version:	4.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Maciej Bendkowski

2013-08-12 05:54:11 EDT

Massive use of parse calls hinders creating a proper cache strategy. I have a use case, where in order to compute proposals I have to make a xhr call. Unfortunately, at the first tab hit I noticed that the parse method is called... four times. Since each one of those calls has to return a proper result I cannot eliminate the inevitable massive xhr calls in that case (at least not in a gentle way).

Comment 1 Grant Gayed

2013-08-14 15:27:02 EDT

Your plug-in's #parse implementation has a "context" argument with a lastParseTimestamp value, whose purpose is to help with caching decisions.  Its value is 0 for the initial #parse call, and in subsequent calls is set to the timestamp of the last #parse invocation.

In your case you would initiate the xhr on the first invocation (lastParseTimestamp === 0) and return a promise.  The next three #parse invocations, assuming the xhr has not returned yet, would just return promises.  When your xhr resolves then the promises can all be resolved.  If you cache the xhr result then you may not need to initiate a new xhr on the next #parse invocation, depending on whether you think the time interval has been too short to have likely made a difference.

I agree that four #parse invocations seems excessive.  They're originating from GCLI, and I have not examined whether there's a reliable way to identify seemingly redundant #parse's in order to hide them from plug-ins.  In the meantime the use of lastParseTimestamp should help you with managing these extra invocations.

Comment 2 Maciej Bendkowski

2013-08-16 05:54:46 EDT

(In reply to comment #1) 
> In your case you would initiate the xhr on the first invocation
> (lastParseTimestamp === 0) and return a promise.  The next three #parse
> invocations, assuming the xhr has not returned yet, would just return
> promises.  When your xhr resolves then the promises can all be resolved.  If
> you cache the xhr result then you may not need to initiate a new xhr on the
> next #parse invocation, depending on whether you think the time interval has
> been too short to have likely made a difference.

This would be great, but those four initial calls have all the lastParseTimestamp set to 0. This way I can't distinguish between them in a 'gentle' way. It could be done using a hack to actually share the promise object, however manual thread synchronization is JS is NOT a desirable solution here..

Comment 3 John Arthorne

2015-05-05 16:19:28 EDT

Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see:


https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html