Bug 368168 - Rich UI proxy optimization
Summary: Rich UI proxy optimization
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: EDT (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard: RUI_Optimization
Keywords:
Depends on:
Blocks: 367818
  Show dependency tree
 
Reported: 2012-01-09 10:04 EST by Tony Chen CLA
Modified: 2017-02-23 14:20 EST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Chen CLA 2012-01-09 10:04:12 EST
This bug is extracted from Bug 367818 - JS Runtime optimization

Requirement form Will. 
1) Do we *always* have to go back to the proxy for every request? The browser
allows requests back to the same server the page came from (obviously), so if
the RUI app needs to call some service (not dedicated, obviously) or get some
resource from the same server, we should not have to go through our proxy. (I
think)

2) What, if any improvements, can be made in the proxy code itself to make it
run more optimally. For example, in bug 364666 (support for Google App Engine),
I talk about how our proxy spawns a thread for every request it handles. This
does not seem efficient (since the request into the proxy is already running in
its own thread), but I know Joe had some reasons why he thought this was
necessary (I have added him to this bug).
Comment 1 Tony Chen CLA 2012-01-09 10:13:13 EST
Hi Joe, 

I assigned this to you for initial investigation because I think you know the proxy best. If you think another person can handle this better, please reassign. 

I took a quick look at the code. When we are calling Rest service, a new thread is created to read response. It seemed to be related to controlling of timeouts. Not sure if there's other reasons for that.
Comment 2 Joseph Vincens CLA 2012-01-11 12:51:17 EST
> 2) What, if any improvements, can be made in the proxy code itself to make it
> run more optimally. For example, in bug 364666 (support for Google App Engine),
> I talk about how our proxy spawns a thread for every request it handles. This
> does not seem efficient (since the request into the proxy is already running in
> its own thread), but I know Joe had some reasons why he thought this was
> necessary (I have added him to this bug).

Timeout was added way back in CE. The implementation reads the data in a thread thread and the main thread handles the timeout. 

We currently don't support timeout as an annotation, a user has to add a header value to the service invocation request to set the timeout. ~50% of the RBD applications I see use timeout so we may want to support the annotation.

The HTTP connection object we are using has a read timeout but it says:"Some non-standard implementation of this method ignores the specified timeout." and it gives a way determine if it's supported. 

To support Google App Engine we can't spawn a thread so the simple solution is to use the read timeout. If  HTTP connection is a non standard HTTP connection that does not support the timeout and someone tries to use a timeout we will throw an exception stating timeout is not supported.
Comment 3 Brian Svihovec CLA 2012-01-23 16:29:41 EST
This enhancement is a place holder for the design documents associated with any Rich UI Proxy optimization.  All work items should be created as separate tasks in bugzilla.