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

Bug 368168

Summary:	Rich UI proxy optimization
Product:	z_Archived	Reporter:	Tony Chen <chenzhh>
Component:	EDT	Assignee:	Project Inbox <edt.javagen-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	chenzhh, jvincens, mayunf, smythew, svihovec, zhuzhi
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	RUI_Optimization
Bug Depends on:
Bug Blocks:	367818

Description Tony Chen

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

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

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

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.