Seam Remoting - No Response

[funkymike]

I've been experiencing a phenomenon with Seam remoting (v2.1.1) where the response is sometimes not sent back to the client.  I've enabled debug and can see the request going out but then nothing.

Here's what I know so far

• Most of the time (maybe 9/10 times) it works just fine


• It appears to only happen the second time an identical request is sent (but not always when an identical request is sent)


• With debug turned on I can see the request being sent in the debug console


• The backing bean is being called successfully


• No response is received in the debug console

Has anyone else encountered this or does anyone know of a way to at least time out the request if there is no response after xxx time has passed?

Thanks for any help!

[cash1981]

I have never experiences this. Are you calling the component with newInstance or getInstance? The latter is synchronized and garanties singleton, and that is maybe what you need.

Try putting breakpoint in the method and see line for line how it is performed and where it stops. Much easier to debug problems using breakpoints.

[funkymike]

Thanks Shervin.  The Java method is always returning correctly, so I went on to debug the JavaScript.

Looking at seam/resource/remoting/resource/remote.js in FireBug (see snippet below) I can see the execution path entering Seam.Remoting.execute(), going into Seam.Remoting.sendAjaxRequest(), setting the timeout for asyncReq.onreadystatechange (lines 650 - 655), sending the request (line 662) and then only sometimes going to Seam.Remoting.requestCallback (line 671).

I'm pretty sure this is a race condition between the Java method returning and something in the JavaScript (not sure if its the setTimeout(), the state change, or what on the JS side).  The java methods are returning quickly (less then 20 ms), but if I slow them down by a few hundred milliseconds (by calling Thread.sleep(xxx)) then the response is always processed normally and everything is fine.

Any ideas?  I guess I have an ugly workaround with Thread.sleep(), but I don't really like that.

611 Seam.Remoting.execute = function(component, methodName, params, callback, exceptionHandler)
612 {
613  var call = Seam.Remoting.createCall(component, methodName, params, callback, exceptionHandler);
614
615  if (Seam.Remoting.inBatch)
616  {
617  Seam.Remoting.batchedCalls[Seam.Remoting.batchedCalls.length] = call;
618  }
619  else
620  {
621  // Marshal the request
622  var envelope = Seam.Remoting.createEnvelope(Seam.Remoting.createHeader(), call.data);
623  Seam.Remoting.pendingCalls.put(call.id, call);
624  call.asyncReq = Seam.Remoting.sendAjaxRequest(envelope, Seam.Remoting.PATH_EXECUTE, Seam.Remoting.processResponse, false);
625  }
626
627  return call;
628 }
629
630 Seam.Remoting.sendAjaxRequest = function(envelope, path, callback, silent)
631 {
632  Seam.Remoting.log("Request packet:\n" + envelope);
633
634  if (!silent)
635  Seam.Remoting.displayLoadingMessage();
636
637  var asyncReq;
638
639  if (window.XMLHttpRequest)
640  {
641  asyncReq = new XMLHttpRequest();
642  if (asyncReq.overrideMimeType)
643  asyncReq.overrideMimeType('text/xml');
644  }
645  else
646  asyncReq = new ActiveXObject("Microsoft.XMLHTTP");
647
648  var rcb = Seam.Remoting.requestCallback;
649
650  window.setTimeout(function() {
651  asyncReq.onreadystatechange = function() {
652  if (rcb) rcb(asyncReq, callback);
653  }
654  }, 0);
655
656  if (Seam.Remoting.encodedSessionId)
657  {
658  path += ';jsessionid=' + Seam.Remoting.encodedSessionId;
659  }
660
661  asyncReq.open("POST", Seam.Remoting.resourcePath + path, true);
662  asyncReq.send(envelope);
663  return asyncReq;
664 } 
665
666 Seam.Remoting.setCallback = function(component, methodName, callback)
667 {
668  component.__callback[methodName] = callback;
669 }
670 
671 Seam.Remoting.requestCallback = function(req, callback)
672 {
673  if (req.readyState == 4)
674  {
675  var inScope = typeof(Seam) == "undefined" ? false : true;
676
677  if (inScope) Seam.Remoting.hideLoadingMessage();
678
679  window.setTimeout(function() {
680  req.onreadystatechange = function() {};
681  }, 0);
682
683  if (req.status == 200)
684  { 
685  if (inScope) Seam.Remoting.log("Response packet:\n" + req.responseText);
686
687  if (callback)
688  {
689  // The following code deals with a Firefox security issue. It reparses the XML
690  // response if accessing the documentElement throws an exception
691  try
692  {
693  req.responseXML.documentElement;
694  callback(req.responseXML);
695  }
696  catch (ex)
697  {
698  try
699  {
700  // Try it the IE way first...
701  var doc = new ActiveXObject("Microsoft.XMLDOM");
702  doc.async = "false";
703  doc.loadXML(req.responseText);
704  callback(doc);
705  }
706  catch (e)
707  {
708  // If that fails, use standards
709  var parser = new DOMParser();
710  callback(parser.parseFromString(req.responseText, "text/xml"));
711  }
712  }
713  }
714  }
715  else
716  alert("There was an error processing your request. Error code: " + req.status);
717  }
718 } 

Thanks again for any help!

[funkymike]

Sorry, forgot to mention that I'm seeing the same thing with Seam.Component.newInstance and Seam.Component.getInstance.

[cash1981]

Are you using callback? I guess you are since you are testing that nothing is sent back to the client. I obviously also don't like the thread sleep stack.

It may very well be that there is a bug with the remoting in seam, I am no expert on it, however Shane might be the one to know what might be going wrong here.

[funkymike]

Yes, I'm using a callback function, but its failing before the callback function is called.

[yoga80.yogesh.srikrishnan.rackspace.com]

Is there any fix for this? Iam having the exact same issue?Any help would be much appreciated.

[yoga80.yogesh.srikrishnan.rackspace.com]

found out the exact reason
Lines 650 to 654 on remote.js is the reason

window.setTimeout(function() {
651  asyncReq.onreadystatechange = function() {
652  if (rcb) rcb(asyncReq, callback);
653  }
654  }, 0)
655
656  if (Seam.Remoting.encodedSessionId)
657  {
658  path += ';jsessionid=' + Seam.Remoting.encodedSessionId;
659  }
660
661  asyncReq.open("POST", Seam.Remoting.resourcePath + path, true);
662  asyncReq.send(envelope);
663  return asyncReq;

At times the execution happens even before the asyncReq.onreadystatechange is set.
Therafore the actual server response is not handled at all.Code should be

651  asyncReq.onreadystatechange = function() {
652  if (rcb) rcb(asyncReq, callback);
653  };

without any window.setTimeout , thus forcing the onreadystatechange to have a value.
New version of seam looks like having the issue fixed.

[cash1981]

Should be easy enough to make the patch your self.
Just change it and run ant target and create new jars.

[cash1981]

You should also create a jira and upload a patch for it. I know you say it is fixed in trunk, but the fix should also be propagated to correct Seam 2 branch.
Also it is better to have this fix in jira then this forum.

[shane.bryzak]

This was already fixed in the Seam22 branch.

[shane.bryzak]

Argh formatting got me.. I mean Seam_2_2.

[funkymike]

Thanks for letting us know, Shane.  Do you happen to know if it was fixed with 2.1.2?  I'm currently running 2.1.1.

[shane.bryzak]

It looks like it was.  Here's the fisheye history:

http://fisheye.jboss.org/browse/Seam/branches/community/Seam_2_1/src/remoting/org/jboss/seam/remoting/remote.js

Pretty sure it was this revision that contained the fix:

http://fisheye.jboss.org/browse/Seam/branches/community/Seam_2_1/src/remoting/org/jboss/seam/remoting/remote.js?r1=9536&r2=9869

[funkymike]

I copied the changes from 2.1.2 into the jar for 2.1.1 locally and it works perfectly now.
Thanks!