Thanks much for the response.
We get the 500 error immediately from the server. The payload is
coming as blank (empty value or "") in the RemoteServiceServlet.
Hence the GWT code is intentionally throwing the 500 error. The point
that I cant understand is why the payload is not reaching the server
though it has dispatched from the browser? I could see the request
details in the Firebug (Netspeed section)
One more point is that , if I restrict the number of connections to a
single host as 1 (in firefox using about:config), the 500 error doesnt
appear as all RPC requests to the server are then sequenced. Well this
also doesnt give me a clue as to why simultaneous requests messes up
the payload when it reaches the server.
Retry may be a solution but I feel that its a workaround (last option).
Wondering if GWT optimizes in some way like if there are 4 RPC's sent
to same service in backend, does GWT merge the payload into one
request??
Thanks
Viju
FWIW, your RPC calls just happen to use the HTTP protocol.
500 responses are not unusual (especially most recently).
If its immediate then you've pushing the limit of the browser's capacity;
at 30 seconds, its a harddeadline exception.
The browser is single threaded and has a limited number of open
connections to the same host (2 or 4 I think). It is relatively easy
for a click happy user to overwhelm a long duration RPC handler.
Using push/pull libraries like Comet or Facebook take up capacity too.
Viju: We are not using the Comet or any of the push technolgies in the
application
I've successfully used Microsoft's Fiddler proxy and HttpFox to trace
communication request/response issues both locally and on production
instances.
I suggest building in a simple retry solution and make sure your RPCs
are discrete.
On Tue, Sep 28, 2010 at 9:00 PM, andy stevko <andy.stevko@gmail.com> wrote:
> FWIW, your RPC calls just happen to use the HTTP protocol.
> 500 responses are not unusual (especially most recently).
>
> If its immediate then you've pushing the limit of the browser's capacity;
> at 30 seconds, its a harddeadline exception.
>
> The browser is single threaded and has a limited number of open connections
> to the same host (2 or 4 I think). It is relatively easy for a click happy
> user to overwhelm a long duration RPC handler.
> Using push/pull libraries like Comet or Facebook take up capacity too.
>
> I've successfully used Microsoft's Fiddler proxy and HttpFox to trace
> communication request/response issues both locally and on production
> instances.
> I suggest building in a simple retry solution and make sure your RPCs are
> discrete.
>
>
>
> On Mon, Sep 27, 2010 at 10:19 AM, GWTViju <vvbiju2005@googlemail.com> wrote:
>>
>> e are using GWT 2.0.3 and Spring in the backend. Facing the below
>> issue in IE(6,7,8) as well as Firefox. A proxy is placed between the
>> Browser and the Application Server.
>>
>> In our application, we make multiple RPC calls to display the page.
>> The scenario is described below
>>
>> RPC A and RPC B is executed when a menu is clicked. RPC A and RPC B
>> are triggered in parallel.
>> When RPC A completes successfully, RPC C call is triggered.
>> When RPC B completes successfully, RPC D call is triggered.
>>
>> The RPC C and RPC D are not triggered in the onSuccess method. The
>> onSuccess transfers command to the browser, browser does some display
>> work and then fires off the associated RPC..
>> The UI event then fires the RPC C and RPC D to the server.
>>
>> In some cases (not always), I get 'Error : 500:Server response is
>> invalid. Please re-try or contact admin.'
>>
>> I added some debug statements in my servlet and found that in such
>> error scenarios, the payload is returned as Empty.
>> The content length however gives a valid number like 199 or 223.
>> From the browser, I checked the request and the request has the
>> expected payload.
>>
>> 1. Is there an issue in chaining the RPC invocations to the server ,
>> in my case, 4 RPC calls are made.
>>
>> 2. Has anyone seen a case in which the RPC request sent from the
>> browser is lost before it reaches the server?
>>
>>
>> Any help would be useful.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment