Synchronous Calls with RPC??
1,524 views
Skip to first unread message
fomba collins
May 14, 2010, 11:05:32 AM5/14/10
to GWT Group
Hi, Is there a way of making synchronous calls in GWT using RPC. I actually need something on the client side to ensure that the asynchronous processing in rpc is complete. Can Anyone help? |
--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Olivier Monaco
May 14, 2010, 11:41:12 AM5/14/10
to Google Web Toolkit
Hi,
Doing synchronous call is globally a bad idea. What is your exact
need?
Olivier
Doing synchronous call is globally a bad idea. What is your exact
need?
Olivier
Travis
May 14, 2010, 11:56:13 AM5/14/10
to Google Web Toolkit, Dariush S Shirazi
We have implemented synchronous calls in our project, but we had to
make changes to the source code of GWT and create our own
distribution. It has been working well for us, but try and limit its
use to short calls to the server that run quickly since it will freeze
up all browsers completely except for FF. I did a long test run by
putting the server thread to sleep for a minute. All browsers handled
this a little differently with IE reporting (Not Responding) until the
request returned and Safari actually canceling the request after about
10 seconds.
For these reasons I understand why the GWT team is hesitant if not
down right opposed to making this functionality part of the toolkit,
but it certainly has made our code cleaner and easier to code and
comprehend when it is useful.
From our standpoint it would be nice if this was standard in GWT so I
don't need to keep patching every new release of the framework.
How many other projects out there using GWT could benefit from this
functionality?
What does the GWT team think about adding this functionality to the
toolkit.
make changes to the source code of GWT and create our own
distribution. It has been working well for us, but try and limit its
use to short calls to the server that run quickly since it will freeze
up all browsers completely except for FF. I did a long test run by
putting the server thread to sleep for a minute. All browsers handled
this a little differently with IE reporting (Not Responding) until the
request returned and Safari actually canceling the request after about
10 seconds.
For these reasons I understand why the GWT team is hesitant if not
down right opposed to making this functionality part of the toolkit,
but it certainly has made our code cleaner and easier to code and
comprehend when it is useful.
From our standpoint it would be nice if this was standard in GWT so I
don't need to keep patching every new release of the framework.
How many other projects out there using GWT could benefit from this
functionality?
What does the GWT team think about adding this functionality to the
toolkit.
fomba collins
May 14, 2010, 12:02:03 PM5/14/10
to google-we...@googlegroups.com
I have a method that uses the response of an asynchronous call. Here is it:
for(int i=0;i<listeOfApplications.size();i++) {
menuItem.setText(listeOfApplications.get(i).toString());
MenuSetup ms1 = new MenuSetup(menu, menuItem); ms1.getSubMenus(); } During each iteraton, the getSubMenus() method has to be called. The getSubMenus() is as follows:
public void getSubMenus(){
try { con.getSubMenus(menuItem.getText(), new AsyncCallback<ArrayList<String>>() {
public void onFailure(Throwable caught) { System.out.println("Remote Procedure Call apps- Failure");
}
public void onSuccess(ArrayList<String> result) { Menu men = new Menu(); for(int i =0; i< result.size();i++) { MenuItem menuItem1 = new MenuItem(result.get(i)); menuItem1.addSelectionListener(menuListener); men.add(menuItem1); } menuItem.setSubMenu(men); menu.add(menuItem);
} }); } catch (Exception e) { e.printStackTrace(); }
}
Now, for each iteration on the listeOfApplications list, the getSubMenus() is to be called. But what happens here is that all the iterations take place before the getSubMenus() method starts execution.
Is there a way to know on the client side that the execution of the asynchronous call has ended? I need this to control my iterations. I have tried wait(); but it does not work. Help!!!
--- On Fri, 5/14/10, Olivier Monaco <olivier...@free.fr> wrote: |
|
|
|
|
|
Gursel Koca
May 14, 2010, 11:12:55 AM5/14/10
to Google Web Toolkit
kozura
May 14, 2010, 3:42:31 PM5/14/10
to Google Web Toolkit
For all those instinctively pushing for synchronous RPC whenever
somebody "needs" it, please! This is exactly a case where synchronous
network calls would be very bad, and just providing them because it's
"easier to understand" or whatever would mean people would design very
poor applications that don't consider network latency. If you think
async from the beginning of your app design, there's practically no
cases where you "need" sync RPC; whereas if it was provided, people
would design apps like they were standalone, which is very difficult
to retrofit with async once you realize it's hanging everywhere...
Fomba, you wouldn't want a synchronous call here because your code
would stall on every iteration of the loop for a round trip call to
your server. The onSuccess call *is* the indication to the client
that the async call has ended. If you really need to know when all
calls have ended and your menu is complete in this code, you could add
a counter or something that you increment when making the call and
decrement on every onSuccess, and do something special once it reaches
0. Better performance-wise thought would be to consider making this a
single call to get all the menus at once in a slightly more advanced
data structure, instead of many server calls done here.
somebody "needs" it, please! This is exactly a case where synchronous
network calls would be very bad, and just providing them because it's
"easier to understand" or whatever would mean people would design very
poor applications that don't consider network latency. If you think
async from the beginning of your app design, there's practically no
cases where you "need" sync RPC; whereas if it was provided, people
would design apps like they were standalone, which is very difficult
to retrofit with async once you realize it's hanging everywhere...
Fomba, you wouldn't want a synchronous call here because your code
would stall on every iteration of the loop for a round trip call to
your server. The onSuccess call *is* the indication to the client
that the async call has ended. If you really need to know when all
calls have ended and your menu is complete in this code, you could add
a counter or something that you increment when making the call and
decrement on every onSuccess, and do something special once it reaches
0. Better performance-wise thought would be to consider making this a
single call to get all the menus at once in a slightly more advanced
data structure, instead of many server calls done here.
Stefan Bachert
May 15, 2010, 11:00:05 AM5/15/10
to Google Web Toolkit
Hi,
when the RPC is complete you get an event
They are rare situations in which synchronous calls are appropriate.
One was discussed and contributed recently by mmoossen
http://code.google.com/p/google-web-toolkit/issues/detail?id=4898
Stefan Bachert
http://gwtworld.de
when the RPC is complete you get an event
They are rare situations in which synchronous calls are appropriate.
One was discussed and contributed recently by mmoossen
http://code.google.com/p/google-web-toolkit/issues/detail?id=4898
Stefan Bachert
http://gwtworld.de
mmoossen
May 16, 2010, 2:39:54 AM5/16/10
to Google Web Toolkit
Hi,
Despite that i wrote the patch for sync-rpc, I completely agree with
kozura that in this case sync-rpc would be a bad idea.
BUT, who cares? if fomba wants to use it, it is up to him, if his
application is not responsive it is his problem not mine.
(this reminds me the apple-adobe conflict:
http://sixrevisions.com/web-development/issues-with-apples-decision-to-block-flash/,
2nd point)
HTH
Michael
Despite that i wrote the patch for sync-rpc, I completely agree with
kozura that in this case sync-rpc would be a bad idea.
BUT, who cares? if fomba wants to use it, it is up to him, if his
application is not responsive it is his problem not mine.
(this reminds me the apple-adobe conflict:
http://sixrevisions.com/web-development/issues-with-apples-decision-to-block-flash/,
2nd point)
HTH
Michael
Olivier Monaco
May 16, 2010, 3:39:52 PM5/16/10
to Google Web Toolkit
Michael,
I'm totally disagreed with you. When you choose to answer here, you
choose to give a good one. When you know someone is going the wrong
way, don't let him going to far. Fighting against problems is not a
good way to learn, you also need to have references.
Please, read again the following: http://www.catb.org/~esr/faqs/smart-questions.html#id383614
"If you're going to answer the question at all, give good value. Don't
suggest kludgy workarounds when somebody is using the wrong tool or
approach. Suggest good tools. Reframe the question."
Regards,
Olivier
On 16 mai, 08:39, mmoossen <mmoos...@gmail.com> wrote:
> Hi,
>
> Despite that i wrote the patch for sync-rpc, I completely agree with
> kozura that in this case sync-rpc would be a bad idea.
> BUT, who cares? if fomba wants to use it, it is up to him, if his
> application is not responsive it is his problem not mine.
> (this reminds me the apple-adobe conflict:http://sixrevisions.com/web-development/issues-with-apples-decision-t...,
I'm totally disagreed with you. When you choose to answer here, you
choose to give a good one. When you know someone is going the wrong
way, don't let him going to far. Fighting against problems is not a
good way to learn, you also need to have references.
Please, read again the following: http://www.catb.org/~esr/faqs/smart-questions.html#id383614
"If you're going to answer the question at all, give good value. Don't
suggest kludgy workarounds when somebody is using the wrong tool or
approach. Suggest good tools. Reframe the question."
Regards,
Olivier
On 16 mai, 08:39, mmoossen <mmoos...@gmail.com> wrote:
> Hi,
>
> Despite that i wrote the patch for sync-rpc, I completely agree with
> kozura that in this case sync-rpc would be a bad idea.
> BUT, who cares? if fomba wants to use it, it is up to him, if his
> application is not responsive it is his problem not mine.
mmoossen
May 17, 2010, 2:37:09 AM5/17/10
to Google Web Toolkit
i completely agree with you Oliver!
i said already that i think that sync-rpc is a really bad idea in this
case. which was already addressed in detail by you and others.
my point was against the spirit of the gwt team to do not give the
developer the choice to use sync requests if he wants to.
it is like never letting a child to cross the street alone instead of
teaching him to watch out.
what we need is better developers and the way to achieve that is to do
mistakes and be willing to learn, and not a tool that tells you "i do
not allow you to do that because it *might* be a bad idea"...
regards,
Michael
i said already that i think that sync-rpc is a really bad idea in this
case. which was already addressed in detail by you and others.
my point was against the spirit of the gwt team to do not give the
developer the choice to use sync requests if he wants to.
it is like never letting a child to cross the street alone instead of
teaching him to watch out.
what we need is better developers and the way to achieve that is to do
mistakes and be willing to learn, and not a tool that tells you "i do
not allow you to do that because it *might* be a bad idea"...
regards,
Michael
Olivier Monaco
May 17, 2010, 3:15:43 AM5/17/10
to Google Web Toolkit
Ok, I see what you mean. I'm not sure about adding this feature but
maybe a better documentation about the "bad" idea of
maybe a better documentation about the "bad" idea of
Olivier Monaco
May 17, 2010, 3:49:45 AM5/17/10
to Google Web Toolkit
(Sorry, my message was incomplete)
Ok, I see what you mean. I'm not sure about adding this feature but
maybe a better documentation about the "bad" idea of using sync
request.
Olivier
Ok, I see what you mean. I'm not sure about adding this feature but
request.
Olivier
Sripathi Krishnan
May 17, 2010, 4:46:34 AM5/17/10
to google-we...@googlegroups.com
I'm not sure about adding this feature but
maybe a better documentation about the "bad" idea of using sync
request.
kozura
May 17, 2010, 10:55:13 AM5/17/10
to Google Web Toolkit
Many languages restrict what you can do when that thing is practically
never a good idea given their design model - Java doesn't let you
access pointers so developers can stick their scissors in the
proverbial pointer-arithmetic electrical outlet. Even your issue had
nothing to do with the async nature of RPC, but rather with an error
popping up, and your solution was to wait for the RPC call to return
before allowing the browser to continue - a hack to solve your issue.
I've yet to see an example where sync is a good choice, much less a
requirement. Just as the GUI interface reflects the asynchronous
nature of user interaction, so the GWT RPC interface reflects the
unreliable async nature of client-server communication; a synchronous
option simply does not match the model!
Here's where I disagree with the "give them the choice" argument. If
GWT were to provide such a feature, new developers would use it (seems
much easier!), design large applications around it in their local dev
environment, and instead of learning from it when the deployed app
runs into problems, would demand new features to try to make that
programming model work. It's not a smooth slope of "ok now lets go
more advanced and switch from sync to async"...retrofitting is hard
and ugly! Instead GWT forces you to understand this issue up front,
when you can do a better clean design that fits the problem.
On May 17, 12:37 am, mmoossen <mmoos...@gmail.com> wrote:
> i completely agree with you Oliver!
>
> i said already that i think that sync-rpc is a really bad idea in this
> case. which was already addressed in detail by you and others.
>
> my point was against the spirit of the gwt team to do not give the
> developer the choice to use sync requests if he wants to.
> it is like never letting a child to cross the street alone instead of
> teaching him to watch out.
>
> what we need is better developers and the way to achieve that is to do
> mistakes and be willing to learn, and not a tool that tells you "i do
> not allow you to do that because it *might* be a bad idea"...
>
> regards,
> Michael
>
never a good idea given their design model - Java doesn't let you
access pointers so developers can stick their scissors in the
proverbial pointer-arithmetic electrical outlet. Even your issue had
nothing to do with the async nature of RPC, but rather with an error
popping up, and your solution was to wait for the RPC call to return
before allowing the browser to continue - a hack to solve your issue.
I've yet to see an example where sync is a good choice, much less a
requirement. Just as the GUI interface reflects the asynchronous
nature of user interaction, so the GWT RPC interface reflects the
unreliable async nature of client-server communication; a synchronous
option simply does not match the model!
Here's where I disagree with the "give them the choice" argument. If
GWT were to provide such a feature, new developers would use it (seems
much easier!), design large applications around it in their local dev
environment, and instead of learning from it when the deployed app
runs into problems, would demand new features to try to make that
programming model work. It's not a smooth slope of "ok now lets go
more advanced and switch from sync to async"...retrofitting is hard
and ugly! Instead GWT forces you to understand this issue up front,
when you can do a better clean design that fits the problem.
On May 17, 12:37 am, mmoossen <mmoos...@gmail.com> wrote:
> i completely agree with you Oliver!
>
> i said already that i think that sync-rpc is a really bad idea in this
> case. which was already addressed in detail by you and others.
>
> my point was against the spirit of the gwt team to do not give the
> developer the choice to use sync requests if he wants to.
> it is like never letting a child to cross the street alone instead of
> teaching him to watch out.
>
> what we need is better developers and the way to achieve that is to do
> mistakes and be willing to learn, and not a tool that tells you "i do
> not allow you to do that because it *might* be a bad idea"...
>
> regards,
> Michael
>
mmoossen
May 17, 2010, 4:33:14 PM5/17/10
to Google Web Toolkit
i still see many people trying actually to use async calls only
because they do not have any choice and without understanding the idea
(and trying to fit async calls in sync design)..
i think that if beginners could start with sync requests, and see the
problems with them, they will better learn and appreciate async
requests.
for me the best would that GWT gives you the possibility to use sync
calls but of course with big enough warnings. as javadocs like this:
DO not use this unless you REALLY know what you are doing. the
recommended way is to use async calls + a link to a good online
explanation, etc...
and btw thanks to everyone for discussing, i think that discussing
here this kind of issues is just the best for everyone ;)
regards,
Michael
because they do not have any choice and without understanding the idea
(and trying to fit async calls in sync design)..
i think that if beginners could start with sync requests, and see the
problems with them, they will better learn and appreciate async
requests.
for me the best would that GWT gives you the possibility to use sync
calls but of course with big enough warnings. as javadocs like this:
DO not use this unless you REALLY know what you are doing. the
recommended way is to use async calls + a link to a good online
explanation, etc...
and btw thanks to everyone for discussing, i think that discussing
here this kind of issues is just the best for everyone ;)
regards,
Michael
Carl Pritchett
May 28, 2010, 12:36:23 AM5/28/10
to Google Web Toolkit
I'm on the "synchronous calls are the wrong approach" side, but what
would really be useful would be some utility classes that allowed
"synchronous like" approaches.
Specifically :
- an async batcher that given a list of async services calls all at
once and then executes a specified action when all return (it keeps an
internal count of async calls returned)
- a serialized async batcher that calls a list of async services one
at a time and then executes a specified action when the last one
returns (each callback triggers the next async call)
So you could block all (or part) of the UI with a modal overlay, call
the async batcher and set the return action to fire an event to
unblock the UI.
I found this pattern helpful when loading data from different services
while making the user wait till all the data has arrived. It can be a
bit more flexible that building lots of services (and the returned
objects) into one call.
Regards,
Carl
would really be useful would be some utility classes that allowed
"synchronous like" approaches.
Specifically :
- an async batcher that given a list of async services calls all at
once and then executes a specified action when all return (it keeps an
internal count of async calls returned)
- a serialized async batcher that calls a list of async services one
at a time and then executes a specified action when the last one
returns (each callback triggers the next async call)
So you could block all (or part) of the UI with a modal overlay, call
the async batcher and set the return action to fire an event to
unblock the UI.
I found this pattern helpful when loading data from different services
while making the user wait till all the data has arrived. It can be a
bit more flexible that building lots of services (and the returned
objects) into one call.
Regards,
Carl
Olivier Monaco
May 28, 2010, 10:04:47 AM5/28/10
to Google Web Toolkit
Carl,
Your proposal is interesting. But as a user, if I have to wait, I
leave... So many be an application needing some "wait a minute" popup
is not a good approach for the future. Imagine your browser putting a
popup each time a page is loading. Tabs will become useless, multi-
core computer too and so one...
Okay, it's not easy to do such application without popups. And I'm the
first to use popup ;). But it can be really, really better.
Olivier
Your proposal is interesting. But as a user, if I have to wait, I
leave... So many be an application needing some "wait a minute" popup
is not a good approach for the future. Imagine your browser putting a
popup each time a page is loading. Tabs will become useless, multi-
core computer too and so one...
Okay, it's not easy to do such application without popups. And I'm the
first to use popup ;). But it can be really, really better.
Olivier
Carl Pritchett
Jun 9, 2010, 7:28:21 PM6/9/10
to Google Web Toolkit
> Your proposal is interesting. But as a user, if I have to wait, I
> leave... So many be an application needing some "wait a minute" popup
> is not a good approach for the future.
I wouldn't popup (block user interaction) over the whole page! Just
> leave... So many be an application needing some "wait a minute" popup
> is not a good approach for the future.
the component that needs to load. In fact you don't even need to block
user interaction. I just do it in my application because (for example)
the user has clicked refresh on a component and any interaction with
the refreshing component would be invalid. So in my case partial
blocking the UI is better for the user - they can go on interacting
with other parts of the app (we have a multiple "portal like" windows)
Carl.
Craigo
Jun 9, 2010, 9:14:03 PM6/9/10
to Google Web Toolkit
+1.
When the user presses "load / submit / ..." on my app, I enable the
glass pane, and they have to wait until the submit has completed
successfully. I see nothing wrong with this approach:
PopupPanel loadingDialog = new PopupPanel();
loadingDialog.setWidget(loadingImageAnimation);
loadingDialog.setGlassEnabled(true);
loadingDialog.center();
.. do the work
onSuccess and onFailure callback
loadingDialog.hide();
When the user presses "load / submit / ..." on my app, I enable the
glass pane, and they have to wait until the submit has completed
successfully. I see nothing wrong with this approach:
PopupPanel loadingDialog = new PopupPanel();
loadingDialog.setWidget(loadingImageAnimation);
loadingDialog.setGlassEnabled(true);
loadingDialog.center();
.. do the work
onSuccess and onFailure callback
loadingDialog.hide();
Olivier Monaco
Jun 10, 2010, 5:45:47 AM6/10/10
to Google Web Toolkit
I'm okay for blocking one part of the application or the whole for
global processing (login...). What I dislike is application blocking
me when I just ask for a little component to upgrade. Like if you have
a iGoogle page and click refresh on one widget block all widgets ;).
Olivier
global processing (login...). What I dislike is application blocking
me when I just ask for a little component to upgrade. Like if you have
a iGoogle page and click refresh on one widget block all widgets ;).
Olivier
Reply all
Reply to author
Forward
0 new messages