Implementing pseudo simultaneously and interruptible async RPC

5 views
Skip to first unread message

Andre Freller

unread,
Jan 9, 2007, 12:21:38 PM1/9/07
to Google-Web-Tool...@googlegroups.com
I'm working now on a site that needs both simultaneously and interruptible
async rpc methods. My first though was to build 1 rpc method that receives
requests and execute them in threads on the server. Then I realize that if
data sent or received is long I could run in to some problem since during
transfers all other requests and responses will be freezed. So I have to break
the request and the response in smaller buckets.

The idea is to maintain a hash of calls on both client and server side, split
information after serialization transmit smaller chunks of data and reassemble
them before de-serialization. This would allow us to interrupt any of the
calls by sending its signature to the server and would also allow many
simultaneously calls.

After poking around in GWT's code I realize that this could be done in
user/rebind/rpc/ProxyCreator and/or user/client/impl/HTTPRequestImpl at
the client side but I still can't figure where to look for the server side.

Am i missing something? Do you guys think this is reasonable/doable?
Any suggestions of other solutions for the same problem?

Regards,
Andre Freller

Rob Jellinghaus

unread,
Jan 10, 2007, 2:28:05 PM1/10/07
to Google Web Toolkit Contributors
I can't see how this could be done generically. On the server side,
GWT calls the service method synchronously. There's no way for GWT to
receive "partial results" from the service method on the server side --
the method returns only when it's entirely done, and until it's
entirely done, there's nothing to return!

GWT *already* allows many simultaneous pending calls to different
service methods AFAIK (or am I wrong about that?). If what you want is
just to allow multiple service requests to be pending concurrently (and
potentially return out of sequence), then that's very different from
splitting up the data of a single request!

Perhaps I'm not clear on what you're asking for, but by my
interpretation, you seem to be asking for something that in general is
not well defined.

Cheers,
Rob

Andre Freller

unread,
Jan 11, 2007, 8:01:50 AM1/11/07
to Google-Web-Tool...@googlegroups.com
Hi Rob,

I thought of implementing a pooling system. As far as the client still have pending data, it ask the server if any data is available. This would also allow server push events. My main problems is that when browser is receiving data it becomes unresponsive! Perhaps what I really need is multitasking....

Regards,
Andre

Miguel Méndez

unread,
Jan 11, 2007, 9:08:28 AM1/11/07
to Google-Web-Tool...@googlegroups.com
Hello Andre,

Are you saying that it is taking you too long to process the data returned by the server?  How much data are you sending to the client?
--
Miguel

Andre Freller

unread,
Jan 11, 2007, 9:34:01 AM1/11/07
to Google-Web-Tool...@googlegroups.com
Hi Miguel,

Too long is very relative. During transmission of data the browser stop responding to clicks during few seconds. But since I have to send 10 simultaneous request, and each request may return between 5 to 60 lines I may end receiving on the worst case 600 lines. The hole process could take a couple of minutes and during this period the browser becomes unresponsive many times for few seconds. So I thought to break the transmission to smaller blocks. Probably the overall time would be bigger, but the interface would be more  friendly.

Regards,
Andre

Miguel Méndez

unread,
Jan 11, 2007, 10:23:18 AM1/11/07
to Google-Web-Tool...@googlegroups.com
Hey Andre,

FWIW, you could break the transmission into smaller blocks by modifying the granularity of the API that your RemoteService exposes.  If its behavior was to return the next n items relative to some starting location, then you could tailor the size of the response to the situation.  Then you could request just enough data to get your UI up and running and load the remaining data in the background or on demand, etc.

Hope that helps,


On 1/11/07, Andre Freller <andre....@gmail.com> wrote:



--
Miguel
Reply all
Reply to author
Forward
0 new messages