AsyncCallback Not Getting Called

56 views
Skip to first unread message

peter

unread,
Sep 1, 2006, 12:46:18 PM9/1/06
to Google Web Toolkit
I have a GWT 1.1.10 RPC application where the AsyncCallback is
occasionally not getting called. It does work 90% of the time so I
know the basic design works. When it fails, I see that the servlet
method associated with the callback gets called, but the callback
method is not called. Here are simplified version of my client file
that makes the RPC and the server side file that has the RPC method.
Has anyone else experienced this behavior? Do you have suggestions on
how to better architect this design?


CLIENT SIDE FILE: "UpdateGrid.java"
public class UpdateGrid implements EntryPoint {

/** This is the entry point method. */
public void onModuleLoad() {

UpdateServiceAsync updateSvc =
(UpdateServiceAsync)GWT.create(UpdateService.class);
ServiceDefTarget target = (ServiceDefTarget) updateSvc;
String staticResponseURL = "/app/updateService";
target.setServiceEntryPoint(staticResponseURL);

final AsyncCallback updateCallback = new AsyncCallback() {
// Method called on successful callback
public void onSuccess (Object result) {
// Update the status field
udpateStatus("Rx ("+((ArrayList)result).size()+")");

// Call the updateService again
UpdateServiceAsync updateSvc =
(UpdateServiceAsync)
GWT.create(UpdateService.class);
ServiceDefTarget endpoint =
(ServiceDefTarget) updateSvc;
endpoint.setServiceEntryPoint("/app/updateService");
updateSvc.updateRows("0",this);
}

// Method called on callback failed
public void onFailure (Throwable ex) {
RootPanel.get().add(new HTML(ex.toString()));
}
};
}

// call the service
updateSvc.updateRows("0",updateCallback);

// update the message panel
public void udpateStatus(String msg){
RootPanel status = RootPanel.get("gwtStatus");
if(status !=null){
Label label= (Label)status.iterator().next();
String currentMsg = label.getText();
label.setText(msg);
label.setStyleName("status");
}
}
}

SERVER SIDE FILE: "UpdateServiceImpl.java"
public ArrayList updateRows(String viewID){
ArrayList updates = new ArrayList();
try {
// if there are no new updates, sleep for a while
while(incomingUpdates.size() == 0){
try {
Thread.sleep(Math.max(0, 500));
} catch (InterruptedException e){ }
}

// we must have new updates, so deal with them
Iterator updateItr = null;
synchronized (this) {
updateItr = new ArrayList(incomingUpdates).iterator();
incomingUpdates.clear();
}

// create new TableRows for each update
while(updateItr.hasNext()){
UpdateHolder uh = (UpdateHolder)updateItr.next();
// create the new TableRow for the update
TableRow tr = convertUpdate(tr);
System.out.println("- update ADDED");
updates.add(tr);
}

// return this array to the client callback method
return updates;

} catch(Exception e){
logger.log(Level.SEVERE,"Bad happenings",e);
}

return null;
}

peter

unread,
Sep 7, 2006, 12:05:04 PM9/7/06
to Google Web Toolkit
It's been a week without any comment on this problem. It seems like it
is an issue with GWT, but it would be good to get some feedback. If it
is a GWT problem, it's obviously a serious one.

Can anyone give me suggestions on how to debug this one? How can I
test for dropped messages between the server and client?

Jason Essington

unread,
Sep 7, 2006, 12:44:37 PM9/7/06
to Google-We...@googlegroups.com
peter

I use a tcp monitor to see the data going back and forth to the
server, and I also use firebug (in firefox) to monitor the RPC requests.

is it possible that your callbacks are going out of scope or getting
destroyed (is that even possible) prior to receiving a response?

I've not noticed any dropped responses in my application.

-jason

peter

unread,
Sep 8, 2006, 8:38:52 AM9/8/06
to Google Web Toolkit
Thanks for the reply Jason. Which TCP monitor do you use? The few
I've tried don't cut it. It appears that the callbacks are getting
"destroyed" but I need to prove it.

In my application, the client continually sends RPC requests and gets
callbacks every few seconds. Maybe the callback frequency has
something to do with it.

Jason Essington

unread,
Sep 8, 2006, 10:37:13 AM9/8/06
to Google-We...@googlegroups.com
Peter

I use the tcpmon monitor from the apache axis project. It is a
standalone java monitor.
However, firebug seems to do just as good a job when just looking at
the RPC request/response cycle.

are you running in hosted or web mode? Since I'm developing on OS X,
I only ever run in web mode.

BTW there is also an IRC channel ##GWT on freenode if you want more
interactive conversations.

-jason

peter

unread,
Sep 11, 2006, 11:43:53 AM9/11/06
to Google Web Toolkit
I was not aware of the IRC channel so I'm now on board witht that -
thanks. My application is also running in web mode. I'm going to try
to try to resolve this with Firebug today. Hopefully the problem
resides in my code and not GWT.

Miguel Méndez

unread,
Sep 11, 2006, 3:41:54 PM9/11/06
to Google-We...@googlegroups.com
Hello Peter,

Have you checked the server logs to see if an exception is being reported?  We have had a similar report on the following thread: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/7258100506803a3c.  You might want to read it and then check your server logs to see if there are any commonalities.  I would be interested in hearing what you find.

Thanks,

peter

unread,
Sep 22, 2006, 10:55:59 AM9/22/06
to Google Web Toolkit
Hi Miguel -

Sorry for not responding earlier. The problem was that the servlet
method updateRows() was holding the connection open by waiting for new
update objects:


while(incomingUpdates.size() == 0){
try {
Thread.sleep(Math.max(0, 500));
} catch (InterruptedException e){ }
}

When someone hit the browser refresh, the RPC mechanism would sometimes
get screwed up.

I resolved this problem by moving the wait to the client side. Now the
client polls the server and server responds immediately with whatever
it has. The original code was just a poor design.

Miguel Méndez

unread,
Sep 26, 2006, 9:01:39 AM9/26/06
to Google-We...@googlegroups.com
Glad to hear that you got it sorted out.

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