Incomplete reply from server

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Incomplete reply from server

gregorcok
Thanks.  I've put some breakpoints in engine.js and found some interesting behavior.   I added a breakpoint in the xhr:stateChange function and see that it is triggered BEFORE my service gets its response from our server.  How is that possible?   As I look at that breakpoint I see from the WebSphere log file that I'm tailing, that the response eventually comes back from the server and I see that the DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in our web.xml) show that the response is received


[9/24/15 12:35:49:398 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): throw 'allowScriptTagRemoting is false.';
[9/24/15 12:35:49:398 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): //#DWR-INSERT
[9/24/15 12:35:49:399 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): //#DWR-REPLY
[9/24/15 12:35:49:416 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): //#DWR-START#
[9/24/15 12:35:49:417 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): (function(){
if(!window.dwr)return;
var dwr=window.dwr._[0];
[9/24/15 12:35:49:421 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject("URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",errorMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogress",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInfo:"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",branchName:"URS Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
...
companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
[9/24/15 12:35:49:422 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): })();
[9/24/15 12:35:49:476 EDT] 00000078 accessLog     I org.directwebremoting.util.DebuggingPrintWriter printBuffer out(-2120569120): //#DWR-END#


at this point I'm still looking at the breakpoint that has javascript caught in the xhr:stateChange function and see that the req.responseText is of course empty (because its stateChange was triggered too early) and when I hit Continue the eventual error "Incomplete reply from server" is thrown.  But a reply was received from the server - out of sync with the stateChange being triggered.

Is there some timeout that is triggering the xhr:stateChange function before my java interface completes and returns with the response?   How can I make further sense of this?  


Thanks,
Gregor Okorn,

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Wednesday, September 23, 2015 14:40 PM
To: [hidden email]
Subject: [dwr-users] Re: Anyone have DWR3 working on multiple portlets on a single portal page?

Mike is right, and I gave you bad advice earlier.  If you put your breakpoint in validate you can inspect the batch.map and the replies that have been received.

On 2015-09-23 12:10, Mike Wilson wrote:

> Technically there is always a batch as DWR creates an implicit batch
> for you.
> There is no need to debug the Java side; most efficient way to see
> what is happening is to load your site in a browser with Firebug,
> Developer Tools or similar, open up engine.js in the script pane,
> search for the "Incomplete" error message and set a JS breakpoint
> there.
>
> Best regards
> Mike
>
> Okorn, Gregor C. wrote:
>
> I started out using this new technique in our Dojo AMD portal where we
> don't have multiple portlets on a single page (yet) just to make sure
> I have the syntax of setting it up correctly before I try it in our
> pre-AMD multi-portlet-per-page portal, and after a few corrections
> with my dojoConfig and require declaration, it appears to be working.
> I'm now using AMD to include the engine.js and my interface. Thanks.
>
> I've seen it succeed with a couple dwr calls, but on one it throws the
> "Incomplete reply from server". Previously with DWR2 it would
> sometimes throw the "No data received from server" error, but now it's
> saying that the reply is incomplete? I've added a breakpoint to my
> java side interface and no exception is thrown from there. I see that
> the javascript error is happening during the middle of the server side
> call from my java interface. I see also that the engine.js explains
> that the "Incomplete reply from server" is thrown when it doesn't
> receive all the responses that were sent during a batch call - but I
> don't set up a batch for this dwr call. I've downloaded the DWR3
> source code so I can try to debug what is causing this. Where in the
> source code should I place a breakpoint for this "Incomplete reply
> from server" javascript response?
>
> Thanks for your help.
>
> Gregor Okorn,
>
> FROM: Okorn, Gregor C. [mailto:[hidden email]]
> SENT: Monday, September 21, 2015 14:11 PM
> TO: [hidden email]
> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
> on a single portal page?
>
> I'm reading that additional link and it is useful. Thanks. I'll be
> implementing this preferred technique in both the AMD and pre-AMD Dojo
> implementations we have. Looking forward to it going smoothly and
> being clean. Will report my results when it's ready. Thanks again.
>
> Regards,
>
> Gregor Okorn,
>
> FROM: Mike Wilson [mailto:[hidden email]]
> SENT: Monday, September 21, 2015 13:50 PM
> TO: [hidden email]
> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
> on a single portal page?
>
> I hear that you understood this perfectly. Key is not to pollute the
> global namespace and instead let the AMD module loader map these
> "anonymous" modules to each other through local variables (function
> parameters). Then each DWR instance will work in isolation in the
> browser and will not interfere with the others.
>
> You still need to ensure that script paths published by the different
> DWR servlets map to the URL space in a managable way (maybe your
> portlet container rewrites paths for all local servlets?) and that the
> AMD loader knows about these paths.
>
> Here's a link to discussion where another DWR user successfully set
> things up in Liferay:
>
> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession-
> addScript-tp6334142p6466106.html
> [1]
>
> Reading backwards from the linked post may provide useful info.
>
> Best regards
>
> Mike
>
> Okorn, Gregor C. wrote:
>
> Wow - great information. Thank you. Your link to your AMD
> implementation looks promising for our project. Our project has three
> separate parts, each contained in their own virtual portal, and when
> we recently started the third part I updated from our older Dojo
> pre-AMD library to the newer Dojo AMD library, and so should be able
> to apply the DWR AMD solution in our project's third part. The first
> two parts might still benefit from the pre-AMD Dojo module option for
> integrating DWR like your link describes. I'll investigate these new
> options and see if it solves our problem. From what I read from that
> link so far, I would be able to have each portlet safely include its
> own proper engine.js along with the interfaces it needs and not have
> to implement the work-around of extracting out a single engine.js that
> is shared by multiple portlets. That will be great if that's true and
> if I can get it to work as intended.
>
> Thanks!
>
> Gregor Okorn,
>
> FROM: Mike Wilson [mailto:[hidden email]]
> SENT: Monday, September 21, 2015 11:39 AM
> TO: [hidden email]
> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
> on a single portal page?
>
> While I don't have any portlet example to prove this point,
> historically portlet problems have usually revolved around JavaScript
> collisions. Ie, the different engine.js inclusions overwriting each
> other. If this is not what you are seeing then ignore the following
> advice.
>
> DWR (2 and 3) supports to have its servlet instantiated multiple times
> with different configuration and dwr.xml in the same webapp. This is
> analogous to each portlet having its own DWR servlet.
>
> DWR's js-files can then be consumed in a couple of different ways. You
> can use the standard <script> include but this is limited to
> connecting to one DWR servlet as it defines objects in the global js
> namespace that will collide if another engine.js is included this way.
>
>
> If you instead use the AMD script mechanism (requirejs and similar)
> there are no global objects defined in JS so you can include any
> number of DWR servlets' scripts in the same page. You can read up on
> DWR's AMD integration here:
> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>
> To sum up, I think the problems you are seeing is that your DWR2
> workaround is not working in DWR3, but I think you should be able to
> get things working by using official DWR3 functionality and not using
> hacks or workarounds. But l could certainly be wrong :-)
>
> Best regards
>
> Mike
>
> Okorn, Gregor C. wrote:
>
> Hello,
>
> Is there anyone out there that has successfully configured their
> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets on
> a single portal page?? We're using WebSphere and our home page has
> over seven portlets. Up until now we have been using DWR2.0.5 and
> extracted the served engine.js file to a common location for all
> portlets to share so that each portlet would not try to include its
> own engine.js. Including multiple engine.js files won't work. That had
> been working to the extent that each portlet was able to make DWR
> calls independent of the other portlets and the calls generally
> succeeded in completing successfully.
>
> We're upgrading to DWR3 and I have been struggling to get the same
> configuration to work. Do I need to go back to DWR2 or is there any
> evidence - any example of someone else already successfully using DWR3
> in multiple portlets on a single portal page?
>
> I get the feeling that DWR3 is simply not able to handle this
> scenario. Both DWR3 and DWR2 work great with a single portlet, but
> only DWR2 works with multiple portlets. I've been experimenting and
> struggling for over two weeks trying to upgrade to DWR3 with one
> roadblock after another. Is it possible? Is there any example of this
> scenario out there for me to review? DWR3 in multiple portlets on a
> single portal page. Each portlet has its own dwr.xml with its own set
> of interfaces. Each portlet makes service calls using DWR to populate
> its content and does so without worrying about other portlets possibly
> making calls at the same time at startup. Is this possible? Is there a
> single example to verify that this scenario can work?
>
> Will greatly appreciate any pointer to that elusive example.
>
> Gregor Okorn,
>
>
>
> Links:
> ------
> [1]
> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession-
> addScript-tp6334142p6466106.html [2]
> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
DWR makes a 1 time call to the server (engine.js -
dwr.engine.transport.send) before you first call.  Is your application
available publicly for us to take a look?

On 2015-09-24 10:47, Okorn, Gregor C. wrote:

> Thanks.  I've put some breakpoints in engine.js and found some
> interesting behavior.   I added a breakpoint in the xhr:stateChange
> function and see that it is triggered BEFORE my service gets its
> response from our server.  How is that possible?   As I look at that
> breakpoint I see from the WebSphere log file that I'm tailing, that
> the response eventually comes back from the server and I see that the
> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
> our web.xml) show that the response is received
>
>
> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): throw 'allowScriptTagRemoting is false.';
> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-INSERT
> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-REPLY
> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-START#
> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): (function(){
> if(!window.dwr)return;
> var dwr=window.dwr._[0];
> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120):
> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject("URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",errorMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogress",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInfo:"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",branchName:"URS
> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
> ...
> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): })();
> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-END#
>
>
> at this point I'm still looking at the breakpoint that has javascript
> caught in the xhr:stateChange function and see that the
> req.responseText is of course empty (because its stateChange was
> triggered too early) and when I hit Continue the eventual error
> "Incomplete reply from server" is thrown.  But a reply was received
> from the server - out of sync with the stateChange being triggered.
>
> Is there some timeout that is triggering the xhr:stateChange function
> before my java interface completes and returns with the response?
> How can I make further sense of this?
>
>
> Thanks,
> Gregor Okorn,
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Wednesday, September 23, 2015 14:40 PM
> To: [hidden email]
> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
> on a single portal page?
>
> Mike is right, and I gave you bad advice earlier.  If you put your
> breakpoint in validate you can inspect the batch.map and the replies
> that have been received.
>
> On 2015-09-23 12:10, Mike Wilson wrote:
>> Technically there is always a batch as DWR creates an implicit batch
>> for you.
>> There is no need to debug the Java side; most efficient way to see
>> what is happening is to load your site in a browser with Firebug,
>> Developer Tools or similar, open up engine.js in the script pane,
>> search for the "Incomplete" error message and set a JS breakpoint
>> there.
>>
>> Best regards
>> Mike
>>
>> Okorn, Gregor C. wrote:
>>
>> I started out using this new technique in our Dojo AMD portal where we
>> don't have multiple portlets on a single page (yet) just to make sure
>> I have the syntax of setting it up correctly before I try it in our
>> pre-AMD multi-portlet-per-page portal, and after a few corrections
>> with my dojoConfig and require declaration, it appears to be working.
>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>
>> I've seen it succeed with a couple dwr calls, but on one it throws the
>> "Incomplete reply from server". Previously with DWR2 it would
>> sometimes throw the "No data received from server" error, but now it's
>> saying that the reply is incomplete? I've added a breakpoint to my
>> java side interface and no exception is thrown from there. I see that
>> the javascript error is happening during the middle of the server side
>> call from my java interface. I see also that the engine.js explains
>> that the "Incomplete reply from server" is thrown when it doesn't
>> receive all the responses that were sent during a batch call - but I
>> don't set up a batch for this dwr call. I've downloaded the DWR3
>> source code so I can try to debug what is causing this. Where in the
>> source code should I place a breakpoint for this "Incomplete reply
>> from server" javascript response?
>>
>> Thanks for your help.
>>
>> Gregor Okorn,
>>
>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>> SENT: Monday, September 21, 2015 14:11 PM
>> TO: [hidden email]
>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
>> on a single portal page?
>>
>> I'm reading that additional link and it is useful. Thanks. I'll be
>> implementing this preferred technique in both the AMD and pre-AMD Dojo
>> implementations we have. Looking forward to it going smoothly and
>> being clean. Will report my results when it's ready. Thanks again.
>>
>> Regards,
>>
>> Gregor Okorn,
>>
>> FROM: Mike Wilson [mailto:[hidden email]]
>> SENT: Monday, September 21, 2015 13:50 PM
>> TO: [hidden email]
>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
>> on a single portal page?
>>
>> I hear that you understood this perfectly. Key is not to pollute the
>> global namespace and instead let the AMD module loader map these
>> "anonymous" modules to each other through local variables (function
>> parameters). Then each DWR instance will work in isolation in the
>> browser and will not interfere with the others.
>>
>> You still need to ensure that script paths published by the different
>> DWR servlets map to the URL space in a managable way (maybe your
>> portlet container rewrites paths for all local servlets?) and that the
>> AMD loader knows about these paths.
>>
>> Here's a link to discussion where another DWR user successfully set
>> things up in Liferay:
>>
>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession-
>> addScript-tp6334142p6466106.html
>> [1]
>>
>> Reading backwards from the linked post may provide useful info.
>>
>> Best regards
>>
>> Mike
>>
>> Okorn, Gregor C. wrote:
>>
>> Wow - great information. Thank you. Your link to your AMD
>> implementation looks promising for our project. Our project has three
>> separate parts, each contained in their own virtual portal, and when
>> we recently started the third part I updated from our older Dojo
>> pre-AMD library to the newer Dojo AMD library, and so should be able
>> to apply the DWR AMD solution in our project's third part. The first
>> two parts might still benefit from the pre-AMD Dojo module option for
>> integrating DWR like your link describes. I'll investigate these new
>> options and see if it solves our problem. From what I read from that
>> link so far, I would be able to have each portlet safely include its
>> own proper engine.js along with the interfaces it needs and not have
>> to implement the work-around of extracting out a single engine.js that
>> is shared by multiple portlets. That will be great if that's true and
>> if I can get it to work as intended.
>>
>> Thanks!
>>
>> Gregor Okorn,
>>
>> FROM: Mike Wilson [mailto:[hidden email]]
>> SENT: Monday, September 21, 2015 11:39 AM
>> TO: [hidden email]
>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
>> on a single portal page?
>>
>> While I don't have any portlet example to prove this point,
>> historically portlet problems have usually revolved around JavaScript
>> collisions. Ie, the different engine.js inclusions overwriting each
>> other. If this is not what you are seeing then ignore the following
>> advice.
>>
>> DWR (2 and 3) supports to have its servlet instantiated multiple times
>> with different configuration and dwr.xml in the same webapp. This is
>> analogous to each portlet having its own DWR servlet.
>>
>> DWR's js-files can then be consumed in a couple of different ways. You
>> can use the standard <script> include but this is limited to
>> connecting to one DWR servlet as it defines objects in the global js
>> namespace that will collide if another engine.js is included this way.
>>
>>
>> If you instead use the AMD script mechanism (requirejs and similar)
>> there are no global objects defined in JS so you can include any
>> number of DWR servlets' scripts in the same page. You can read up on
>> DWR's AMD integration here:
>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>
>> To sum up, I think the problems you are seeing is that your DWR2
>> workaround is not working in DWR3, but I think you should be able to
>> get things working by using official DWR3 functionality and not using
>> hacks or workarounds. But l could certainly be wrong :-)
>>
>> Best regards
>>
>> Mike
>>
>> Okorn, Gregor C. wrote:
>>
>> Hello,
>>
>> Is there anyone out there that has successfully configured their
>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets on
>> a single portal page?? We're using WebSphere and our home page has
>> over seven portlets. Up until now we have been using DWR2.0.5 and
>> extracted the served engine.js file to a common location for all
>> portlets to share so that each portlet would not try to include its
>> own engine.js. Including multiple engine.js files won't work. That had
>> been working to the extent that each portlet was able to make DWR
>> calls independent of the other portlets and the calls generally
>> succeeded in completing successfully.
>>
>> We're upgrading to DWR3 and I have been struggling to get the same
>> configuration to work. Do I need to go back to DWR2 or is there any
>> evidence - any example of someone else already successfully using DWR3
>> in multiple portlets on a single portal page?
>>
>> I get the feeling that DWR3 is simply not able to handle this
>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>> only DWR2 works with multiple portlets. I've been experimenting and
>> struggling for over two weeks trying to upgrade to DWR3 with one
>> roadblock after another. Is it possible? Is there any example of this
>> scenario out there for me to review? DWR3 in multiple portlets on a
>> single portal page. Each portlet has its own dwr.xml with its own set
>> of interfaces. Each portlet makes service calls using DWR to populate
>> its content and does so without worrying about other portlets possibly
>> making calls at the same time at startup. Is this possible? Is there a
>> single example to verify that this scenario can work?
>>
>> Will greatly appreciate any pointer to that elusive example.
>>
>> Gregor Okorn,
>>
>>
>>
>> Links:
>> ------
>> [1]
>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession-
>> addScript-tp6334142p6466106.html [2]
>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok
Thanks for the response.   I'm not sure what you mean.  At what point does DWR make that call to your DwrServlet server?   I search through the engine.js and see four different places where there is a dwr.engine.transport.send function being called, and three places where a dwr.engine.transport.send2 function is being called.  You're saying that this function is called 1 time before my first call?   What does "my first call" refer to?  The call to my java method through the interface javascript object?   Is that what you mean?

Unfortunately the application is not available publicly; that would be great if I could have you take a live look at it.  If there's any particular information that I could share, I'd be happy to try through here.

Thanks for your help,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, September 25, 2015 8:01 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

DWR makes a 1 time call to the server (engine.js -
dwr.engine.transport.send) before you first call.  Is your application available publicly for us to take a look?

On 2015-09-24 10:47, Okorn, Gregor C. wrote:

> Thanks.  I've put some breakpoints in engine.js and found some
> interesting behavior.   I added a breakpoint in the xhr:stateChange
> function and see that it is triggered BEFORE my service gets its
> response from our server.  How is that possible?   As I look at that
> breakpoint I see from the WebSphere log file that I'm tailing, that
> the response eventually comes back from the server and I see that the
> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
> our web.xml) show that the response is received
>
>
> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): throw 'allowScriptTagRemoting is false.';
> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-INSERT
> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-REPLY
> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-START#
> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): (function(){
> if(!window.dwr)return;
> var dwr=window.dwr._[0];
> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120):
> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject(
> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",erro
> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogres
> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInfo
> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",br
> anchName:"URS
> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
> ...
> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): })();
> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
> org.directwebremoting.util.DebuggingPrintWriter printBuffer
> out(-2120569120): //#DWR-END#
>
>
> at this point I'm still looking at the breakpoint that has javascript
> caught in the xhr:stateChange function and see that the
> req.responseText is of course empty (because its stateChange was
> triggered too early) and when I hit Continue the eventual error
> "Incomplete reply from server" is thrown.  But a reply was received
> from the server - out of sync with the stateChange being triggered.
>
> Is there some timeout that is triggering the xhr:stateChange function
> before my java interface completes and returns with the response?
> How can I make further sense of this?
>
>
> Thanks,
> Gregor Okorn,
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Wednesday, September 23, 2015 14:40 PM
> To: [hidden email]
> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
> on a single portal page?
>
> Mike is right, and I gave you bad advice earlier.  If you put your
> breakpoint in validate you can inspect the batch.map and the replies
> that have been received.
>
> On 2015-09-23 12:10, Mike Wilson wrote:
>> Technically there is always a batch as DWR creates an implicit batch
>> for you.
>> There is no need to debug the Java side; most efficient way to see
>> what is happening is to load your site in a browser with Firebug,
>> Developer Tools or similar, open up engine.js in the script pane,
>> search for the "Incomplete" error message and set a JS breakpoint
>> there.
>>
>> Best regards
>> Mike
>>
>> Okorn, Gregor C. wrote:
>>
>> I started out using this new technique in our Dojo AMD portal where
>> we don't have multiple portlets on a single page (yet) just to make
>> sure I have the syntax of setting it up correctly before I try it in
>> our pre-AMD multi-portlet-per-page portal, and after a few
>> corrections with my dojoConfig and require declaration, it appears to be working.
>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>
>> I've seen it succeed with a couple dwr calls, but on one it throws
>> the "Incomplete reply from server". Previously with DWR2 it would
>> sometimes throw the "No data received from server" error, but now
>> it's saying that the reply is incomplete? I've added a breakpoint to
>> my java side interface and no exception is thrown from there. I see
>> that the javascript error is happening during the middle of the
>> server side call from my java interface. I see also that the
>> engine.js explains that the "Incomplete reply from server" is thrown
>> when it doesn't receive all the responses that were sent during a
>> batch call - but I don't set up a batch for this dwr call. I've
>> downloaded the DWR3 source code so I can try to debug what is causing
>> this. Where in the source code should I place a breakpoint for this
>> "Incomplete reply from server" javascript response?
>>
>> Thanks for your help.
>>
>> Gregor Okorn,
>>
>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>> SENT: Monday, September 21, 2015 14:11 PM
>> TO: [hidden email]
>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>> portlets on a single portal page?
>>
>> I'm reading that additional link and it is useful. Thanks. I'll be
>> implementing this preferred technique in both the AMD and pre-AMD
>> Dojo implementations we have. Looking forward to it going smoothly
>> and being clean. Will report my results when it's ready. Thanks again.
>>
>> Regards,
>>
>> Gregor Okorn,
>>
>> FROM: Mike Wilson [mailto:[hidden email]]
>> SENT: Monday, September 21, 2015 13:50 PM
>> TO: [hidden email]
>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>> portlets on a single portal page?
>>
>> I hear that you understood this perfectly. Key is not to pollute the
>> global namespace and instead let the AMD module loader map these
>> "anonymous" modules to each other through local variables (function
>> parameters). Then each DWR instance will work in isolation in the
>> browser and will not interfere with the others.
>>
>> You still need to ensure that script paths published by the different
>> DWR servlets map to the URL space in a managable way (maybe your
>> portlet container rewrites paths for all local servlets?) and that
>> the AMD loader knows about these paths.
>>
>> Here's a link to discussion where another DWR user successfully set
>> things up in Liferay:
>>
>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession
>> -
>> addScript-tp6334142p6466106.html
>> [1]
>>
>> Reading backwards from the linked post may provide useful info.
>>
>> Best regards
>>
>> Mike
>>
>> Okorn, Gregor C. wrote:
>>
>> Wow - great information. Thank you. Your link to your AMD
>> implementation looks promising for our project. Our project has three
>> separate parts, each contained in their own virtual portal, and when
>> we recently started the third part I updated from our older Dojo
>> pre-AMD library to the newer Dojo AMD library, and so should be able
>> to apply the DWR AMD solution in our project's third part. The first
>> two parts might still benefit from the pre-AMD Dojo module option for
>> integrating DWR like your link describes. I'll investigate these new
>> options and see if it solves our problem. From what I read from that
>> link so far, I would be able to have each portlet safely include its
>> own proper engine.js along with the interfaces it needs and not have
>> to implement the work-around of extracting out a single engine.js
>> that is shared by multiple portlets. That will be great if that's
>> true and if I can get it to work as intended.
>>
>> Thanks!
>>
>> Gregor Okorn,
>>
>> FROM: Mike Wilson [mailto:[hidden email]]
>> SENT: Monday, September 21, 2015 11:39 AM
>> TO: [hidden email]
>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>> portlets on a single portal page?
>>
>> While I don't have any portlet example to prove this point,
>> historically portlet problems have usually revolved around JavaScript
>> collisions. Ie, the different engine.js inclusions overwriting each
>> other. If this is not what you are seeing then ignore the following
>> advice.
>>
>> DWR (2 and 3) supports to have its servlet instantiated multiple
>> times with different configuration and dwr.xml in the same webapp.
>> This is analogous to each portlet having its own DWR servlet.
>>
>> DWR's js-files can then be consumed in a couple of different ways.
>> You can use the standard <script> include but this is limited to
>> connecting to one DWR servlet as it defines objects in the global js
>> namespace that will collide if another engine.js is included this way.
>>
>>
>> If you instead use the AMD script mechanism (requirejs and similar)
>> there are no global objects defined in JS so you can include any
>> number of DWR servlets' scripts in the same page. You can read up on
>> DWR's AMD integration here:
>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>
>> To sum up, I think the problems you are seeing is that your DWR2
>> workaround is not working in DWR3, but I think you should be able to
>> get things working by using official DWR3 functionality and not using
>> hacks or workarounds. But l could certainly be wrong :-)
>>
>> Best regards
>>
>> Mike
>>
>> Okorn, Gregor C. wrote:
>>
>> Hello,
>>
>> Is there anyone out there that has successfully configured their
>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>> on a single portal page?? We're using WebSphere and our home page has
>> over seven portlets. Up until now we have been using DWR2.0.5 and
>> extracted the served engine.js file to a common location for all
>> portlets to share so that each portlet would not try to include its
>> own engine.js. Including multiple engine.js files won't work. That
>> had been working to the extent that each portlet was able to make DWR
>> calls independent of the other portlets and the calls generally
>> succeeded in completing successfully.
>>
>> We're upgrading to DWR3 and I have been struggling to get the same
>> configuration to work. Do I need to go back to DWR2 or is there any
>> evidence - any example of someone else already successfully using
>> DWR3 in multiple portlets on a single portal page?
>>
>> I get the feeling that DWR3 is simply not able to handle this
>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>> only DWR2 works with multiple portlets. I've been experimenting and
>> struggling for over two weeks trying to upgrade to DWR3 with one
>> roadblock after another. Is it possible? Is there any example of this
>> scenario out there for me to review? DWR3 in multiple portlets on a
>> single portal page. Each portlet has its own dwr.xml with its own set
>> of interfaces. Each portlet makes service calls using DWR to populate
>> its content and does so without worrying about other portlets
>> possibly making calls at the same time at startup. Is this possible?
>> Is there a single example to verify that this scenario can work?
>>
>> Will greatly appreciate any pointer to that elusive example.
>>
>> Gregor Okorn,
>>
>>
>>
>> Links:
>> ------
>> [1]
>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession
>> -
>> addScript-tp6334142p6466106.html [2]
>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
Let me rephrase that, each time a call is initiated
(YourDWRInterface.method()) send is called.  The first time send is
called per page DWR makes an additional call to the server to retrieve
the dwr session id.  All subsequent calls delegate to send2.  It is
normal to see stateChange called several times.  If you place a
breakpoint lower down in stateChange you will see we break out of it
under certain status conditions.  Per your original email it is likely
that the first time stateChange is called the status is 0, and we are
breaking out of it.  If you want to debug the incomplete reply error, I
would start at the source of it:

Line 2438:
} else if (repliesReceived < batch.map.callCount) {
     dwr.engine._handleError(batch, { name:"dwr.engine.incompleteReply",
message:"Incomplete reply from server" });
}

Inspect repliesReceived, batch.map etc. in the debugger.

On 2015-09-25 06:23, Okorn, Gregor C. wrote:

> Thanks for the response.   I'm not sure what you mean.  At what point
> does DWR make that call to your DwrServlet server?   I search through
> the engine.js and see four different places where there is a
> dwr.engine.transport.send function being called, and three places
> where a dwr.engine.transport.send2 function is being called.  You're
> saying that this function is called 1 time before my first call?
> What does "my first call" refer to?  The call to my java method
> through the interface javascript object?   Is that what you mean?
>
> Unfortunately the application is not available publicly; that would be
> great if I could have you take a live look at it.  If there's any
> particular information that I could share, I'd be happy to try through
> here.
>
> Thanks for your help,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 8:01 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> DWR makes a 1 time call to the server (engine.js -
> dwr.engine.transport.send) before you first call.  Is your application
> available publicly for us to take a look?
>
> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>> Thanks.  I've put some breakpoints in engine.js and found some
>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>> function and see that it is triggered BEFORE my service gets its
>> response from our server.  How is that possible?   As I look at that
>> breakpoint I see from the WebSphere log file that I'm tailing, that
>> the response eventually comes back from the server and I see that the
>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
>> our web.xml) show that the response is received
>>
>>
>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-INSERT
>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-REPLY
>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-START#
>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): (function(){
>> if(!window.dwr)return;
>> var dwr=window.dwr._[0];
>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120):
>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject(
>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",erro
>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogres
>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInfo
>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",br
>> anchName:"URS
>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>> ...
>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): })();
>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-END#
>>
>>
>> at this point I'm still looking at the breakpoint that has javascript
>> caught in the xhr:stateChange function and see that the
>> req.responseText is of course empty (because its stateChange was
>> triggered too early) and when I hit Continue the eventual error
>> "Incomplete reply from server" is thrown.  But a reply was received
>> from the server - out of sync with the stateChange being triggered.
>>
>> Is there some timeout that is triggering the xhr:stateChange function
>> before my java interface completes and returns with the response?
>> How can I make further sense of this?
>>
>>
>> Thanks,
>> Gregor Okorn,
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Wednesday, September 23, 2015 14:40 PM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple portlets
>> on a single portal page?
>>
>> Mike is right, and I gave you bad advice earlier.  If you put your
>> breakpoint in validate you can inspect the batch.map and the replies
>> that have been received.
>>
>> On 2015-09-23 12:10, Mike Wilson wrote:
>>> Technically there is always a batch as DWR creates an implicit batch
>>> for you.
>>> There is no need to debug the Java side; most efficient way to see
>>> what is happening is to load your site in a browser with Firebug,
>>> Developer Tools or similar, open up engine.js in the script pane,
>>> search for the "Incomplete" error message and set a JS breakpoint
>>> there.
>>>
>>> Best regards
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> I started out using this new technique in our Dojo AMD portal where
>>> we don't have multiple portlets on a single page (yet) just to make
>>> sure I have the syntax of setting it up correctly before I try it in
>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>> corrections with my dojoConfig and require declaration, it appears to
>>> be working.
>>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>>
>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>> the "Incomplete reply from server". Previously with DWR2 it would
>>> sometimes throw the "No data received from server" error, but now
>>> it's saying that the reply is incomplete? I've added a breakpoint to
>>> my java side interface and no exception is thrown from there. I see
>>> that the javascript error is happening during the middle of the
>>> server side call from my java interface. I see also that the
>>> engine.js explains that the "Incomplete reply from server" is thrown
>>> when it doesn't receive all the responses that were sent during a
>>> batch call - but I don't set up a batch for this dwr call. I've
>>> downloaded the DWR3 source code so I can try to debug what is causing
>>> this. Where in the source code should I place a breakpoint for this
>>> "Incomplete reply from server" javascript response?
>>>
>>> Thanks for your help.
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 14:11 PM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>> implementing this preferred technique in both the AMD and pre-AMD
>>> Dojo implementations we have. Looking forward to it going smoothly
>>> and being clean. Will report my results when it's ready. Thanks
>>> again.
>>>
>>> Regards,
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Mike Wilson [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 13:50 PM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> I hear that you understood this perfectly. Key is not to pollute the
>>> global namespace and instead let the AMD module loader map these
>>> "anonymous" modules to each other through local variables (function
>>> parameters). Then each DWR instance will work in isolation in the
>>> browser and will not interfere with the others.
>>>
>>> You still need to ensure that script paths published by the different
>>> DWR servlets map to the URL space in a managable way (maybe your
>>> portlet container rewrites paths for all local servlets?) and that
>>> the AMD loader knows about these paths.
>>>
>>> Here's a link to discussion where another DWR user successfully set
>>> things up in Liferay:
>>>
>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession
>>> -
>>> addScript-tp6334142p6466106.html
>>> [1]
>>>
>>> Reading backwards from the linked post may provide useful info.
>>>
>>> Best regards
>>>
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> Wow - great information. Thank you. Your link to your AMD
>>> implementation looks promising for our project. Our project has three
>>> separate parts, each contained in their own virtual portal, and when
>>> we recently started the third part I updated from our older Dojo
>>> pre-AMD library to the newer Dojo AMD library, and so should be able
>>> to apply the DWR AMD solution in our project's third part. The first
>>> two parts might still benefit from the pre-AMD Dojo module option for
>>> integrating DWR like your link describes. I'll investigate these new
>>> options and see if it solves our problem. From what I read from that
>>> link so far, I would be able to have each portlet safely include its
>>> own proper engine.js along with the interfaces it needs and not have
>>> to implement the work-around of extracting out a single engine.js
>>> that is shared by multiple portlets. That will be great if that's
>>> true and if I can get it to work as intended.
>>>
>>> Thanks!
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Mike Wilson [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 11:39 AM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> While I don't have any portlet example to prove this point,
>>> historically portlet problems have usually revolved around JavaScript
>>> collisions. Ie, the different engine.js inclusions overwriting each
>>> other. If this is not what you are seeing then ignore the following
>>> advice.
>>>
>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>> times with different configuration and dwr.xml in the same webapp.
>>> This is analogous to each portlet having its own DWR servlet.
>>>
>>> DWR's js-files can then be consumed in a couple of different ways.
>>> You can use the standard <script> include but this is limited to
>>> connecting to one DWR servlet as it defines objects in the global js
>>> namespace that will collide if another engine.js is included this
>>> way.
>>>
>>>
>>> If you instead use the AMD script mechanism (requirejs and similar)
>>> there are no global objects defined in JS so you can include any
>>> number of DWR servlets' scripts in the same page. You can read up on
>>> DWR's AMD integration here:
>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>
>>> To sum up, I think the problems you are seeing is that your DWR2
>>> workaround is not working in DWR3, but I think you should be able to
>>> get things working by using official DWR3 functionality and not using
>>> hacks or workarounds. But l could certainly be wrong :-)
>>>
>>> Best regards
>>>
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> Hello,
>>>
>>> Is there anyone out there that has successfully configured their
>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>>> on a single portal page?? We're using WebSphere and our home page has
>>> over seven portlets. Up until now we have been using DWR2.0.5 and
>>> extracted the served engine.js file to a common location for all
>>> portlets to share so that each portlet would not try to include its
>>> own engine.js. Including multiple engine.js files won't work. That
>>> had been working to the extent that each portlet was able to make DWR
>>> calls independent of the other portlets and the calls generally
>>> succeeded in completing successfully.
>>>
>>> We're upgrading to DWR3 and I have been struggling to get the same
>>> configuration to work. Do I need to go back to DWR2 or is there any
>>> evidence - any example of someone else already successfully using
>>> DWR3 in multiple portlets on a single portal page?
>>>
>>> I get the feeling that DWR3 is simply not able to handle this
>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>> only DWR2 works with multiple portlets. I've been experimenting and
>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>> roadblock after another. Is it possible? Is there any example of this
>>> scenario out there for me to review? DWR3 in multiple portlets on a
>>> single portal page. Each portlet has its own dwr.xml with its own set
>>> of interfaces. Each portlet makes service calls using DWR to populate
>>> its content and does so without worrying about other portlets
>>> possibly making calls at the same time at startup. Is this possible?
>>> Is there a single example to verify that this scenario can work?
>>>
>>> Will greatly appreciate any pointer to that elusive example.
>>>
>>> Gregor Okorn,
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSession
>>> -
>>> addScript-tp6334142p6466106.html [2]
>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok
Appreciate the clarification.   I do see that the first call made when I open the page is the _System.generateId, which doesn't get called again until I refresh the page.  And I see that it retrieves the DWRSESSIONID value that is then used in all subsequent calls.  I also see that the stateChange function handles multiple status values and can break out without error in depending on the state.  

I've added a breakpoint where you suggested and am examining the repliesReceived, batch.map, and other fields but am unsure what to make of the fact that the stateChange is getting called before my interface method returns.  This is happening well after the initial startup phase, long after the generateId call is made and received.  It happens during any random occurrence of our interface calls.  You mentioned that these subsequent calls are made through the send2 function but when the breakpoint is hit for this "Incomplete reply from server" the Firebug stacktrace shows:

dwr.engine.batch.validate(batch=Object { type="object"})engine.js (line 2445)
dwr.engine.transport.complete(batch=Object { type="object"})engine.js (line 1568)
dwr.engine.transport.xhr.stateChange(batch=Object { type="object"})engine.js (line 1796)
dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js (line 1664)

where the earliest (last in list) call is rooted in the send function, not the send2 function.  Is that expected?

Here's Firebug's display of the Function closure's variables and values where the breakpoint hit:

batch Object { async={...},  charsProcessed={...},  handlers={...},  more...}
   async  true
   charsProcessed 0
   handlers [Object { callbackScope=Window,  exceptionScope=Window,  callback=function(),  more...}]
   isPoll false
   map Object { callCount=1,  nextReverseAjaxIndex=0,  c0-scriptName="UrsRegWizardDataHandler",  more...}
   paramCount 169
   preHooks null
   postHooks []
   timeout 0
   errorHandler null
   globalErrorHandler Object { compassErrorHandler=compassErrorHandler(),  showDetails=showDetails(),  showErrorsDialog=showErrorsDialog()}
   warningHandler function(warnString, exObj)
   textHtmlHandler null
   globalTextHtmlHandler null
   headers Object {}
   attributes Object {}
   path "/UrsRegistrationWizard/dwr"
   completed false
   transport Object { httpMethod="POST",  XMLHTTP=[6],  send=function(),  more...}
   req XMLHttpRequest { readyState=4,  timeout=0,  withCredentials=false,  more...}
   mode "/call/plaincall/"
arguments Object { type="object"}
repliesReceived 0
i 1

That stateChange function should only get called when the browser has detected a change in the XmlHttpRequest  -  right?  If my interface method hasn't yet explicitly returned or thrown an exception, then how can the stateChange callback get triggered prematurely?  I'm trying to find a clue in by examining the fields at the breakpoint and parent execution chain, but I don't know what I'm missing.

Thanks again,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, September 25, 2015 9:11 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

Let me rephrase that, each time a call is initiated
(YourDWRInterface.method()) send is called.  The first time send is called per page DWR makes an additional call to the server to retrieve the dwr session id.  All subsequent calls delegate to send2.  It is normal to see stateChange called several times.  If you place a breakpoint lower down in stateChange you will see we break out of it under certain status conditions.  Per your original email it is likely that the first time stateChange is called the status is 0, and we are breaking out of it.  If you want to debug the incomplete reply error, I would start at the source of it:

Line 2438:
} else if (repliesReceived < batch.map.callCount) {
     dwr.engine._handleError(batch, { name:"dwr.engine.incompleteReply",
message:"Incomplete reply from server" }); }

Inspect repliesReceived, batch.map etc. in the debugger.

On 2015-09-25 06:23, Okorn, Gregor C. wrote:

> Thanks for the response.   I'm not sure what you mean.  At what point
> does DWR make that call to your DwrServlet server?   I search through
> the engine.js and see four different places where there is a
> dwr.engine.transport.send function being called, and three places
> where a dwr.engine.transport.send2 function is being called.  You're
> saying that this function is called 1 time before my first call?
> What does "my first call" refer to?  The call to my java method
> through the interface javascript object?   Is that what you mean?
>
> Unfortunately the application is not available publicly; that would be
> great if I could have you take a live look at it.  If there's any
> particular information that I could share, I'd be happy to try through
> here.
>
> Thanks for your help,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 8:01 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> DWR makes a 1 time call to the server (engine.js -
> dwr.engine.transport.send) before you first call.  Is your application
> available publicly for us to take a look?
>
> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>> Thanks.  I've put some breakpoints in engine.js and found some
>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>> function and see that it is triggered BEFORE my service gets its
>> response from our server.  How is that possible?   As I look at that
>> breakpoint I see from the WebSphere log file that I'm tailing, that
>> the response eventually comes back from the server and I see that the
>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
>> our web.xml) show that the response is received
>>
>>
>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-INSERT
>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-REPLY
>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-START#
>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): (function(){
>> if(!window.dwr)return;
>> var dwr=window.dwr._[0];
>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120):
>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>> (
>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>> o
>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>> s
>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>> o
>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>> r
>> anchName:"URS
>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>> ...
>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): })();
>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-END#
>>
>>
>> at this point I'm still looking at the breakpoint that has javascript
>> caught in the xhr:stateChange function and see that the
>> req.responseText is of course empty (because its stateChange was
>> triggered too early) and when I hit Continue the eventual error
>> "Incomplete reply from server" is thrown.  But a reply was received
>> from the server - out of sync with the stateChange being triggered.
>>
>> Is there some timeout that is triggering the xhr:stateChange function
>> before my java interface completes and returns with the response?
>> How can I make further sense of this?
>>
>>
>> Thanks,
>> Gregor Okorn,
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Wednesday, September 23, 2015 14:40 PM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>> portlets on a single portal page?
>>
>> Mike is right, and I gave you bad advice earlier.  If you put your
>> breakpoint in validate you can inspect the batch.map and the replies
>> that have been received.
>>
>> On 2015-09-23 12:10, Mike Wilson wrote:
>>> Technically there is always a batch as DWR creates an implicit batch
>>> for you.
>>> There is no need to debug the Java side; most efficient way to see
>>> what is happening is to load your site in a browser with Firebug,
>>> Developer Tools or similar, open up engine.js in the script pane,
>>> search for the "Incomplete" error message and set a JS breakpoint
>>> there.
>>>
>>> Best regards
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> I started out using this new technique in our Dojo AMD portal where
>>> we don't have multiple portlets on a single page (yet) just to make
>>> sure I have the syntax of setting it up correctly before I try it in
>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>> corrections with my dojoConfig and require declaration, it appears
>>> to be working.
>>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>>
>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>> the "Incomplete reply from server". Previously with DWR2 it would
>>> sometimes throw the "No data received from server" error, but now
>>> it's saying that the reply is incomplete? I've added a breakpoint to
>>> my java side interface and no exception is thrown from there. I see
>>> that the javascript error is happening during the middle of the
>>> server side call from my java interface. I see also that the
>>> engine.js explains that the "Incomplete reply from server" is thrown
>>> when it doesn't receive all the responses that were sent during a
>>> batch call - but I don't set up a batch for this dwr call. I've
>>> downloaded the DWR3 source code so I can try to debug what is
>>> causing this. Where in the source code should I place a breakpoint
>>> for this "Incomplete reply from server" javascript response?
>>>
>>> Thanks for your help.
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 14:11 PM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>> implementing this preferred technique in both the AMD and pre-AMD
>>> Dojo implementations we have. Looking forward to it going smoothly
>>> and being clean. Will report my results when it's ready. Thanks
>>> again.
>>>
>>> Regards,
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Mike Wilson [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 13:50 PM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> I hear that you understood this perfectly. Key is not to pollute the
>>> global namespace and instead let the AMD module loader map these
>>> "anonymous" modules to each other through local variables (function
>>> parameters). Then each DWR instance will work in isolation in the
>>> browser and will not interfere with the others.
>>>
>>> You still need to ensure that script paths published by the
>>> different DWR servlets map to the URL space in a managable way
>>> (maybe your portlet container rewrites paths for all local
>>> servlets?) and that the AMD loader knows about these paths.
>>>
>>> Here's a link to discussion where another DWR user successfully set
>>> things up in Liferay:
>>>
>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>> n
>>> -
>>> addScript-tp6334142p6466106.html
>>> [1]
>>>
>>> Reading backwards from the linked post may provide useful info.
>>>
>>> Best regards
>>>
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> Wow - great information. Thank you. Your link to your AMD
>>> implementation looks promising for our project. Our project has
>>> three separate parts, each contained in their own virtual portal,
>>> and when we recently started the third part I updated from our older
>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should be
>>> able to apply the DWR AMD solution in our project's third part. The
>>> first two parts might still benefit from the pre-AMD Dojo module
>>> option for integrating DWR like your link describes. I'll
>>> investigate these new options and see if it solves our problem. From
>>> what I read from that link so far, I would be able to have each
>>> portlet safely include its own proper engine.js along with the
>>> interfaces it needs and not have to implement the work-around of
>>> extracting out a single engine.js that is shared by multiple
>>> portlets. That will be great if that's true and if I can get it to work as intended.
>>>
>>> Thanks!
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Mike Wilson [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 11:39 AM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> While I don't have any portlet example to prove this point,
>>> historically portlet problems have usually revolved around
>>> JavaScript collisions. Ie, the different engine.js inclusions
>>> overwriting each other. If this is not what you are seeing then
>>> ignore the following advice.
>>>
>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>> times with different configuration and dwr.xml in the same webapp.
>>> This is analogous to each portlet having its own DWR servlet.
>>>
>>> DWR's js-files can then be consumed in a couple of different ways.
>>> You can use the standard <script> include but this is limited to
>>> connecting to one DWR servlet as it defines objects in the global js
>>> namespace that will collide if another engine.js is included this
>>> way.
>>>
>>>
>>> If you instead use the AMD script mechanism (requirejs and similar)
>>> there are no global objects defined in JS so you can include any
>>> number of DWR servlets' scripts in the same page. You can read up on
>>> DWR's AMD integration here:
>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>
>>> To sum up, I think the problems you are seeing is that your DWR2
>>> workaround is not working in DWR3, but I think you should be able to
>>> get things working by using official DWR3 functionality and not
>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>
>>> Best regards
>>>
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> Hello,
>>>
>>> Is there anyone out there that has successfully configured their
>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>>> on a single portal page?? We're using WebSphere and our home page
>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>> and extracted the served engine.js file to a common location for all
>>> portlets to share so that each portlet would not try to include its
>>> own engine.js. Including multiple engine.js files won't work. That
>>> had been working to the extent that each portlet was able to make
>>> DWR calls independent of the other portlets and the calls generally
>>> succeeded in completing successfully.
>>>
>>> We're upgrading to DWR3 and I have been struggling to get the same
>>> configuration to work. Do I need to go back to DWR2 or is there any
>>> evidence - any example of someone else already successfully using
>>> DWR3 in multiple portlets on a single portal page?
>>>
>>> I get the feeling that DWR3 is simply not able to handle this
>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>> only DWR2 works with multiple portlets. I've been experimenting and
>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>> roadblock after another. Is it possible? Is there any example of
>>> this scenario out there for me to review? DWR3 in multiple portlets
>>> on a single portal page. Each portlet has its own dwr.xml with its
>>> own set of interfaces. Each portlet makes service calls using DWR to
>>> populate its content and does so without worrying about other
>>> portlets possibly making calls at the same time at startup. Is this possible?
>>> Is there a single example to verify that this scenario can work?
>>>
>>> Will greatly appreciate any pointer to that elusive example.
>>>
>>> Gregor Okorn,
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>> n
>>> -
>>> addScript-tp6334142p6466106.html [2]
>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok
Forgot to point out that the final condition before the error was handled was true because the repliesReceived was 0 and the batch.map.callCount was 1.  In this situation the stateChange saw some values that did not let it break out  - but let it go as far as handling this error.

Thanks,
Gregor Okorn,
Leidos, [hidden email], cell 571-247-5490


-----Original Message-----
From: Okorn, Gregor C. [mailto:[hidden email]]
Sent: Friday, September 25, 2015 14:20 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

Appreciate the clarification.   I do see that the first call made when I open the page is the _System.generateId, which doesn't get called again until I refresh the page.  And I see that it retrieves the DWRSESSIONID value that is then used in all subsequent calls.  I also see that the stateChange function handles multiple status values and can break out without error in depending on the state.  

I've added a breakpoint where you suggested and am examining the repliesReceived, batch.map, and other fields but am unsure what to make of the fact that the stateChange is getting called before my interface method returns.  This is happening well after the initial startup phase, long after the generateId call is made and received.  It happens during any random occurrence of our interface calls.  You mentioned that these subsequent calls are made through the send2 function but when the breakpoint is hit for this "Incomplete reply from server" the Firebug stacktrace shows:

dwr.engine.batch.validate(batch=Object { type="object"})engine.js (line 2445) dwr.engine.transport.complete(batch=Object { type="object"})engine.js (line 1568) dwr.engine.transport.xhr.stateChange(batch=Object { type="object"})engine.js (line 1796) dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js (line 1664)

where the earliest (last in list) call is rooted in the send function, not the send2 function.  Is that expected?

Here's Firebug's display of the Function closure's variables and values where the breakpoint hit:

batch Object { async={...},  charsProcessed={...},  handlers={...},  more...}
   async  true
   charsProcessed 0
   handlers [Object { callbackScope=Window,  exceptionScope=Window,  callback=function(),  more...}]
   isPoll false
   map Object { callCount=1,  nextReverseAjaxIndex=0,  c0-scriptName="UrsRegWizardDataHandler",  more...}
   paramCount 169
   preHooks null
   postHooks []
   timeout 0
   errorHandler null
   globalErrorHandler Object { compassErrorHandler=compassErrorHandler(),  showDetails=showDetails(),  showErrorsDialog=showErrorsDialog()}
   warningHandler function(warnString, exObj)
   textHtmlHandler null
   globalTextHtmlHandler null
   headers Object {}
   attributes Object {}
   path "/UrsRegistrationWizard/dwr"
   completed false
   transport Object { httpMethod="POST",  XMLHTTP=[6],  send=function(),  more...}
   req XMLHttpRequest { readyState=4,  timeout=0,  withCredentials=false,  more...}
   mode "/call/plaincall/"
arguments Object { type="object"}
repliesReceived 0
i 1

That stateChange function should only get called when the browser has detected a change in the XmlHttpRequest  -  right?  If my interface method hasn't yet explicitly returned or thrown an exception, then how can the stateChange callback get triggered prematurely?  I'm trying to find a clue in by examining the fields at the breakpoint and parent execution chain, but I don't know what I'm missing.

Thanks again,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, September 25, 2015 9:11 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

Let me rephrase that, each time a call is initiated
(YourDWRInterface.method()) send is called.  The first time send is called per page DWR makes an additional call to the server to retrieve the dwr session id.  All subsequent calls delegate to send2.  It is normal to see stateChange called several times.  If you place a breakpoint lower down in stateChange you will see we break out of it under certain status conditions.  Per your original email it is likely that the first time stateChange is called the status is 0, and we are breaking out of it.  If you want to debug the incomplete reply error, I would start at the source of it:

Line 2438:
} else if (repliesReceived < batch.map.callCount) {
     dwr.engine._handleError(batch, { name:"dwr.engine.incompleteReply",
message:"Incomplete reply from server" }); }

Inspect repliesReceived, batch.map etc. in the debugger.

On 2015-09-25 06:23, Okorn, Gregor C. wrote:

> Thanks for the response.   I'm not sure what you mean.  At what point
> does DWR make that call to your DwrServlet server?   I search through
> the engine.js and see four different places where there is a
> dwr.engine.transport.send function being called, and three places
> where a dwr.engine.transport.send2 function is being called.  You're
> saying that this function is called 1 time before my first call?
> What does "my first call" refer to?  The call to my java method
> through the interface javascript object?   Is that what you mean?
>
> Unfortunately the application is not available publicly; that would be
> great if I could have you take a live look at it.  If there's any
> particular information that I could share, I'd be happy to try through
> here.
>
> Thanks for your help,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 8:01 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> DWR makes a 1 time call to the server (engine.js -
> dwr.engine.transport.send) before you first call.  Is your application
> available publicly for us to take a look?
>
> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>> Thanks.  I've put some breakpoints in engine.js and found some
>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>> function and see that it is triggered BEFORE my service gets its
>> response from our server.  How is that possible?   As I look at that
>> breakpoint I see from the WebSphere log file that I'm tailing, that
>> the response eventually comes back from the server and I see that the
>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
>> our web.xml) show that the response is received
>>
>>
>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-INSERT
>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-REPLY
>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-START#
>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): (function(){
>> if(!window.dwr)return;
>> var dwr=window.dwr._[0];
>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120):
>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>> (
>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>> o
>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>> s
>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>> o
>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>> r
>> anchName:"URS
>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>> ...
>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): })();
>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>> out(-2120569120): //#DWR-END#
>>
>>
>> at this point I'm still looking at the breakpoint that has javascript
>> caught in the xhr:stateChange function and see that the
>> req.responseText is of course empty (because its stateChange was
>> triggered too early) and when I hit Continue the eventual error
>> "Incomplete reply from server" is thrown.  But a reply was received
>> from the server - out of sync with the stateChange being triggered.
>>
>> Is there some timeout that is triggering the xhr:stateChange function
>> before my java interface completes and returns with the response?
>> How can I make further sense of this?
>>
>>
>> Thanks,
>> Gregor Okorn,
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Wednesday, September 23, 2015 14:40 PM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>> portlets on a single portal page?
>>
>> Mike is right, and I gave you bad advice earlier.  If you put your
>> breakpoint in validate you can inspect the batch.map and the replies
>> that have been received.
>>
>> On 2015-09-23 12:10, Mike Wilson wrote:
>>> Technically there is always a batch as DWR creates an implicit batch
>>> for you.
>>> There is no need to debug the Java side; most efficient way to see
>>> what is happening is to load your site in a browser with Firebug,
>>> Developer Tools or similar, open up engine.js in the script pane,
>>> search for the "Incomplete" error message and set a JS breakpoint
>>> there.
>>>
>>> Best regards
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> I started out using this new technique in our Dojo AMD portal where
>>> we don't have multiple portlets on a single page (yet) just to make
>>> sure I have the syntax of setting it up correctly before I try it in
>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>> corrections with my dojoConfig and require declaration, it appears
>>> to be working.
>>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>>
>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>> the "Incomplete reply from server". Previously with DWR2 it would
>>> sometimes throw the "No data received from server" error, but now
>>> it's saying that the reply is incomplete? I've added a breakpoint to
>>> my java side interface and no exception is thrown from there. I see
>>> that the javascript error is happening during the middle of the
>>> server side call from my java interface. I see also that the
>>> engine.js explains that the "Incomplete reply from server" is thrown
>>> when it doesn't receive all the responses that were sent during a
>>> batch call - but I don't set up a batch for this dwr call. I've
>>> downloaded the DWR3 source code so I can try to debug what is
>>> causing this. Where in the source code should I place a breakpoint
>>> for this "Incomplete reply from server" javascript response?
>>>
>>> Thanks for your help.
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 14:11 PM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>> implementing this preferred technique in both the AMD and pre-AMD
>>> Dojo implementations we have. Looking forward to it going smoothly
>>> and being clean. Will report my results when it's ready. Thanks
>>> again.
>>>
>>> Regards,
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Mike Wilson [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 13:50 PM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> I hear that you understood this perfectly. Key is not to pollute the
>>> global namespace and instead let the AMD module loader map these
>>> "anonymous" modules to each other through local variables (function
>>> parameters). Then each DWR instance will work in isolation in the
>>> browser and will not interfere with the others.
>>>
>>> You still need to ensure that script paths published by the
>>> different DWR servlets map to the URL space in a managable way
>>> (maybe your portlet container rewrites paths for all local
>>> servlets?) and that the AMD loader knows about these paths.
>>>
>>> Here's a link to discussion where another DWR user successfully set
>>> things up in Liferay:
>>>
>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>> n
>>> -
>>> addScript-tp6334142p6466106.html
>>> [1]
>>>
>>> Reading backwards from the linked post may provide useful info.
>>>
>>> Best regards
>>>
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> Wow - great information. Thank you. Your link to your AMD
>>> implementation looks promising for our project. Our project has
>>> three separate parts, each contained in their own virtual portal,
>>> and when we recently started the third part I updated from our older
>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should be
>>> able to apply the DWR AMD solution in our project's third part. The
>>> first two parts might still benefit from the pre-AMD Dojo module
>>> option for integrating DWR like your link describes. I'll
>>> investigate these new options and see if it solves our problem. From
>>> what I read from that link so far, I would be able to have each
>>> portlet safely include its own proper engine.js along with the
>>> interfaces it needs and not have to implement the work-around of
>>> extracting out a single engine.js that is shared by multiple
>>> portlets. That will be great if that's true and if I can get it to work as intended.
>>>
>>> Thanks!
>>>
>>> Gregor Okorn,
>>>
>>> FROM: Mike Wilson [mailto:[hidden email]]
>>> SENT: Monday, September 21, 2015 11:39 AM
>>> TO: [hidden email]
>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> While I don't have any portlet example to prove this point,
>>> historically portlet problems have usually revolved around
>>> JavaScript collisions. Ie, the different engine.js inclusions
>>> overwriting each other. If this is not what you are seeing then
>>> ignore the following advice.
>>>
>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>> times with different configuration and dwr.xml in the same webapp.
>>> This is analogous to each portlet having its own DWR servlet.
>>>
>>> DWR's js-files can then be consumed in a couple of different ways.
>>> You can use the standard <script> include but this is limited to
>>> connecting to one DWR servlet as it defines objects in the global js
>>> namespace that will collide if another engine.js is included this
>>> way.
>>>
>>>
>>> If you instead use the AMD script mechanism (requirejs and similar)
>>> there are no global objects defined in JS so you can include any
>>> number of DWR servlets' scripts in the same page. You can read up on
>>> DWR's AMD integration here:
>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>
>>> To sum up, I think the problems you are seeing is that your DWR2
>>> workaround is not working in DWR3, but I think you should be able to
>>> get things working by using official DWR3 functionality and not
>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>
>>> Best regards
>>>
>>> Mike
>>>
>>> Okorn, Gregor C. wrote:
>>>
>>> Hello,
>>>
>>> Is there anyone out there that has successfully configured their
>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>>> on a single portal page?? We're using WebSphere and our home page
>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>> and extracted the served engine.js file to a common location for all
>>> portlets to share so that each portlet would not try to include its
>>> own engine.js. Including multiple engine.js files won't work. That
>>> had been working to the extent that each portlet was able to make
>>> DWR calls independent of the other portlets and the calls generally
>>> succeeded in completing successfully.
>>>
>>> We're upgrading to DWR3 and I have been struggling to get the same
>>> configuration to work. Do I need to go back to DWR2 or is there any
>>> evidence - any example of someone else already successfully using
>>> DWR3 in multiple portlets on a single portal page?
>>>
>>> I get the feeling that DWR3 is simply not able to handle this
>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>> only DWR2 works with multiple portlets. I've been experimenting and
>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>> roadblock after another. Is it possible? Is there any example of
>>> this scenario out there for me to review? DWR3 in multiple portlets
>>> on a single portal page. Each portlet has its own dwr.xml with its
>>> own set of interfaces. Each portlet makes service calls using DWR to
>>> populate its content and does so without worrying about other
>>> portlets possibly making calls at the same time at startup. Is this possible?
>>> Is there a single example to verify that this scenario can work?
>>>
>>> Will greatly appreciate any pointer to that elusive example.
>>>
>>> Gregor Okorn,
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1]
>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>> n
>>> -
>>> addScript-tp6334142p6466106.html [2]
>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
In reply to this post by gregorcok
For each remote DWR call:
dwr.engine.transport.send is called first.
dwr.engine.transport.send2 is called next - this is where a transport is
determined (xhr, iframe).

You can place a breakpoint in these methods and see this.
Once the transport is determined to be xhr then xhr.send is called.

That is all expected.  The stateChange function is called at various
times.  I don't beleive it is accurate assuming there is a problem just
because it is called before your data is returned is not accurate (if
you download the dwrdemo.war you will see this happening).

As I said before, you need to focus on the source of the problem.  We
know the error is thrown when: repliesReceived < batch.map.callCount

What is repliesReceived?  What is batch.map.callCount?  Inspect
batch.map.  It will contain an object with a property indicating the
remote DWR method names called, from there you should be able to
determine what calls were made and what call has not returned.


On 2015-09-25 12:19, Okorn, Gregor C. wrote:

> Appreciate the clarification.   I do see that the first call made when
> I open the page is the _System.generateId, which doesn't get called
> again until I refresh the page.  And I see that it retrieves the
> DWRSESSIONID value that is then used in all subsequent calls.  I also
> see that the stateChange function handles multiple status values and
> can break out without error in depending on the state.
>
> I've added a breakpoint where you suggested and am examining the
> repliesReceived, batch.map, and other fields but am unsure what to
> make of the fact that the stateChange is getting called before my
> interface method returns.  This is happening well after the initial
> startup phase, long after the generateId call is made and received.
> It happens during any random occurrence of our interface calls.  You
> mentioned that these subsequent calls are made through the send2
> function but when the breakpoint is hit for this "Incomplete reply
> from server" the Firebug stacktrace shows:
>
> dwr.engine.batch.validate(batch=Object { type="object"})engine.js (line
> 2445)
> dwr.engine.transport.complete(batch=Object { type="object"})engine.js
> (line 1568)
> dwr.engine.transport.xhr.stateChange(batch=Object {
> type="object"})engine.js (line 1796)
> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js
> (line 1664)
>
> where the earliest (last in list) call is rooted in the send function,
> not the send2 function.  Is that expected?
>
> Here's Firebug's display of the Function closure's variables and
> values where the breakpoint hit:
>
> batch Object { async={...},  charsProcessed={...},  handlers={...},  
> more...}
>    async  true
>    charsProcessed 0
>    handlers [Object { callbackScope=Window,  exceptionScope=Window,
> callback=function(),  more...}]
>    isPoll false
>    map Object { callCount=1,  nextReverseAjaxIndex=0,
> c0-scriptName="UrsRegWizardDataHandler",  more...}
>    paramCount 169
>    preHooks null
>    postHooks []
>    timeout 0
>    errorHandler null
>    globalErrorHandler Object {
> compassErrorHandler=compassErrorHandler(),  showDetails=showDetails(),
>  showErrorsDialog=showErrorsDialog()}
>    warningHandler function(warnString, exObj)
>    textHtmlHandler null
>    globalTextHtmlHandler null
>    headers Object {}
>    attributes Object {}
>    path "/UrsRegistrationWizard/dwr"
>    completed false
>    transport Object { httpMethod="POST",  XMLHTTP=[6],
> send=function(),  more...}
>    req XMLHttpRequest { readyState=4,  timeout=0,
> withCredentials=false,  more...}
>    mode "/call/plaincall/"
> arguments Object { type="object"}
> repliesReceived 0
> i 1
>
> That stateChange function should only get called when the browser has
> detected a change in the XmlHttpRequest  -  right?  If my interface
> method hasn't yet explicitly returned or thrown an exception, then how
> can the stateChange callback get triggered prematurely?  I'm trying to
> find a clue in by examining the fields at the breakpoint and parent
> execution chain, but I don't know what I'm missing.
>
> Thanks again,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 9:11 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> Let me rephrase that, each time a call is initiated
> (YourDWRInterface.method()) send is called.  The first time send is
> called per page DWR makes an additional call to the server to retrieve
> the dwr session id.  All subsequent calls delegate to send2.  It is
> normal to see stateChange called several times.  If you place a
> breakpoint lower down in stateChange you will see we break out of it
> under certain status conditions.  Per your original email it is likely
> that the first time stateChange is called the status is 0, and we are
> breaking out of it.  If you want to debug the incomplete reply error,
> I would start at the source of it:
>
> Line 2438:
> } else if (repliesReceived < batch.map.callCount) {
>      dwr.engine._handleError(batch, {
> name:"dwr.engine.incompleteReply",
> message:"Incomplete reply from server" }); }
>
> Inspect repliesReceived, batch.map etc. in the debugger.
>
> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>> Thanks for the response.   I'm not sure what you mean.  At what point
>> does DWR make that call to your DwrServlet server?   I search through
>> the engine.js and see four different places where there is a
>> dwr.engine.transport.send function being called, and three places
>> where a dwr.engine.transport.send2 function is being called.  You're
>> saying that this function is called 1 time before my first call?
>> What does "my first call" refer to?  The call to my java method
>> through the interface javascript object?   Is that what you mean?
>>
>> Unfortunately the application is not available publicly; that would be
>> great if I could have you take a live look at it.  If there's any
>> particular information that I could share, I'd be happy to try through
>> here.
>>
>> Thanks for your help,
>> Gregor Okorn,
>>
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Friday, September 25, 2015 8:01 AM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Incomplete reply from server
>>
>> DWR makes a 1 time call to the server (engine.js -
>> dwr.engine.transport.send) before you first call.  Is your application
>> available publicly for us to take a look?
>>
>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>> Thanks.  I've put some breakpoints in engine.js and found some
>>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>>> function and see that it is triggered BEFORE my service gets its
>>> response from our server.  How is that possible?   As I look at that
>>> breakpoint I see from the WebSphere log file that I'm tailing, that
>>> the response eventually comes back from the server and I see that the
>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
>>> our web.xml) show that the response is received
>>>
>>>
>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-INSERT
>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-REPLY
>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-START#
>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): (function(){
>>> if(!window.dwr)return;
>>> var dwr=window.dwr._[0];
>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120):
>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>> (
>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>> o
>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>> s
>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>> o
>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>> r
>>> anchName:"URS
>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>> ...
>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): })();
>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-END#
>>>
>>>
>>> at this point I'm still looking at the breakpoint that has javascript
>>> caught in the xhr:stateChange function and see that the
>>> req.responseText is of course empty (because its stateChange was
>>> triggered too early) and when I hit Continue the eventual error
>>> "Incomplete reply from server" is thrown.  But a reply was received
>>> from the server - out of sync with the stateChange being triggered.
>>>
>>> Is there some timeout that is triggering the xhr:stateChange function
>>> before my java interface completes and returns with the response?
>>> How can I make further sense of this?
>>>
>>>
>>> Thanks,
>>> Gregor Okorn,
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]]
>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>> To: [hidden email]
>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> Mike is right, and I gave you bad advice earlier.  If you put your
>>> breakpoint in validate you can inspect the batch.map and the replies
>>> that have been received.
>>>
>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>> Technically there is always a batch as DWR creates an implicit batch
>>>> for you.
>>>> There is no need to debug the Java side; most efficient way to see
>>>> what is happening is to load your site in a browser with Firebug,
>>>> Developer Tools or similar, open up engine.js in the script pane,
>>>> search for the "Incomplete" error message and set a JS breakpoint
>>>> there.
>>>>
>>>> Best regards
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> I started out using this new technique in our Dojo AMD portal where
>>>> we don't have multiple portlets on a single page (yet) just to make
>>>> sure I have the syntax of setting it up correctly before I try it in
>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>> corrections with my dojoConfig and require declaration, it appears
>>>> to be working.
>>>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>>>
>>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>>> the "Incomplete reply from server". Previously with DWR2 it would
>>>> sometimes throw the "No data received from server" error, but now
>>>> it's saying that the reply is incomplete? I've added a breakpoint to
>>>> my java side interface and no exception is thrown from there. I see
>>>> that the javascript error is happening during the middle of the
>>>> server side call from my java interface. I see also that the
>>>> engine.js explains that the "Incomplete reply from server" is thrown
>>>> when it doesn't receive all the responses that were sent during a
>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>> downloaded the DWR3 source code so I can try to debug what is
>>>> causing this. Where in the source code should I place a breakpoint
>>>> for this "Incomplete reply from server" javascript response?
>>>>
>>>> Thanks for your help.
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>>> implementing this preferred technique in both the AMD and pre-AMD
>>>> Dojo implementations we have. Looking forward to it going smoothly
>>>> and being clean. Will report my results when it's ready. Thanks
>>>> again.
>>>>
>>>> Regards,
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> I hear that you understood this perfectly. Key is not to pollute the
>>>> global namespace and instead let the AMD module loader map these
>>>> "anonymous" modules to each other through local variables (function
>>>> parameters). Then each DWR instance will work in isolation in the
>>>> browser and will not interfere with the others.
>>>>
>>>> You still need to ensure that script paths published by the
>>>> different DWR servlets map to the URL space in a managable way
>>>> (maybe your portlet container rewrites paths for all local
>>>> servlets?) and that the AMD loader knows about these paths.
>>>>
>>>> Here's a link to discussion where another DWR user successfully set
>>>> things up in Liferay:
>>>>
>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>> n
>>>> -
>>>> addScript-tp6334142p6466106.html
>>>> [1]
>>>>
>>>> Reading backwards from the linked post may provide useful info.
>>>>
>>>> Best regards
>>>>
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> Wow - great information. Thank you. Your link to your AMD
>>>> implementation looks promising for our project. Our project has
>>>> three separate parts, each contained in their own virtual portal,
>>>> and when we recently started the third part I updated from our older
>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should be
>>>> able to apply the DWR AMD solution in our project's third part. The
>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>> option for integrating DWR like your link describes. I'll
>>>> investigate these new options and see if it solves our problem. From
>>>> what I read from that link so far, I would be able to have each
>>>> portlet safely include its own proper engine.js along with the
>>>> interfaces it needs and not have to implement the work-around of
>>>> extracting out a single engine.js that is shared by multiple
>>>> portlets. That will be great if that's true and if I can get it to
>>>> work as intended.
>>>>
>>>> Thanks!
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> While I don't have any portlet example to prove this point,
>>>> historically portlet problems have usually revolved around
>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>> overwriting each other. If this is not what you are seeing then
>>>> ignore the following advice.
>>>>
>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>> times with different configuration and dwr.xml in the same webapp.
>>>> This is analogous to each portlet having its own DWR servlet.
>>>>
>>>> DWR's js-files can then be consumed in a couple of different ways.
>>>> You can use the standard <script> include but this is limited to
>>>> connecting to one DWR servlet as it defines objects in the global js
>>>> namespace that will collide if another engine.js is included this
>>>> way.
>>>>
>>>>
>>>> If you instead use the AMD script mechanism (requirejs and similar)
>>>> there are no global objects defined in JS so you can include any
>>>> number of DWR servlets' scripts in the same page. You can read up on
>>>> DWR's AMD integration here:
>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>
>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>> workaround is not working in DWR3, but I think you should be able to
>>>> get things working by using official DWR3 functionality and not
>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>
>>>> Best regards
>>>>
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> Hello,
>>>>
>>>> Is there anyone out there that has successfully configured their
>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>>>> on a single portal page?? We're using WebSphere and our home page
>>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>>> and extracted the served engine.js file to a common location for all
>>>> portlets to share so that each portlet would not try to include its
>>>> own engine.js. Including multiple engine.js files won't work. That
>>>> had been working to the extent that each portlet was able to make
>>>> DWR calls independent of the other portlets and the calls generally
>>>> succeeded in completing successfully.
>>>>
>>>> We're upgrading to DWR3 and I have been struggling to get the same
>>>> configuration to work. Do I need to go back to DWR2 or is there any
>>>> evidence - any example of someone else already successfully using
>>>> DWR3 in multiple portlets on a single portal page?
>>>>
>>>> I get the feeling that DWR3 is simply not able to handle this
>>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>>> only DWR2 works with multiple portlets. I've been experimenting and
>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>> roadblock after another. Is it possible? Is there any example of
>>>> this scenario out there for me to review? DWR3 in multiple portlets
>>>> on a single portal page. Each portlet has its own dwr.xml with its
>>>> own set of interfaces. Each portlet makes service calls using DWR to
>>>> populate its content and does so without worrying about other
>>>> portlets possibly making calls at the same time at startup. Is this
>>>> possible?
>>>> Is there a single example to verify that this scenario can work?
>>>>
>>>> Will greatly appreciate any pointer to that elusive example.
>>>>
>>>> Gregor Okorn,
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1]
>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>> n
>>>> -
>>>> addScript-tp6334142p6466106.html [2]
>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok
Understood.  In this error the repliesReceived is 0 and the batch.map.callCount is 1.  The batch.map shows that the c0-methodName is the expected method that I'm calling "getURSRegistrationNextPage" but the java debug prints from that method have not yet printed to prove that that method has actually completed yet.  That's what doesn't make sense.  The error's batch.map says that the method is the same one that hasn't actually returned yet.  That's what makes me wonder how can the stateChange callback get triggered if the interface method "getURSRegistrationNextPage" hasn't yet returned?

Regards,
Gregor Okorn,
Leidos, [hidden email], cell 571-247-5490


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, September 25, 2015 15:09 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

For each remote DWR call:
dwr.engine.transport.send is called first.
dwr.engine.transport.send2 is called next - this is where a transport is determined (xhr, iframe).

You can place a breakpoint in these methods and see this.
Once the transport is determined to be xhr then xhr.send is called.

That is all expected.  The stateChange function is called at various times.  I don't beleive it is accurate assuming there is a problem just because it is called before your data is returned is not accurate (if you download the dwrdemo.war you will see this happening).

As I said before, you need to focus on the source of the problem.  We know the error is thrown when: repliesReceived < batch.map.callCount

What is repliesReceived?  What is batch.map.callCount?  Inspect batch.map.  It will contain an object with a property indicating the remote DWR method names called, from there you should be able to determine what calls were made and what call has not returned.


On 2015-09-25 12:19, Okorn, Gregor C. wrote:

> Appreciate the clarification.   I do see that the first call made when
> I open the page is the _System.generateId, which doesn't get called
> again until I refresh the page.  And I see that it retrieves the
> DWRSESSIONID value that is then used in all subsequent calls.  I also
> see that the stateChange function handles multiple status values and
> can break out without error in depending on the state.
>
> I've added a breakpoint where you suggested and am examining the
> repliesReceived, batch.map, and other fields but am unsure what to
> make of the fact that the stateChange is getting called before my
> interface method returns.  This is happening well after the initial
> startup phase, long after the generateId call is made and received.
> It happens during any random occurrence of our interface calls.  You
> mentioned that these subsequent calls are made through the send2
> function but when the breakpoint is hit for this "Incomplete reply
> from server" the Firebug stacktrace shows:
>
> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
> (line
> 2445)
> dwr.engine.transport.complete(batch=Object { type="object"})engine.js
> (line 1568) dwr.engine.transport.xhr.stateChange(batch=Object {
> type="object"})engine.js (line 1796)
> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js
> (line 1664)
>
> where the earliest (last in list) call is rooted in the send function,
> not the send2 function.  Is that expected?
>
> Here's Firebug's display of the Function closure's variables and
> values where the breakpoint hit:
>
> batch Object { async={...},  charsProcessed={...},  handlers={...},  
> more...}
>    async  true
>    charsProcessed 0
>    handlers [Object { callbackScope=Window,  exceptionScope=Window,
> callback=function(),  more...}]
>    isPoll false
>    map Object { callCount=1,  nextReverseAjaxIndex=0,
> c0-scriptName="UrsRegWizardDataHandler",  more...}
>    paramCount 169
>    preHooks null
>    postHooks []
>    timeout 0
>    errorHandler null
>    globalErrorHandler Object {
> compassErrorHandler=compassErrorHandler(),  showDetails=showDetails(),  
> showErrorsDialog=showErrorsDialog()}
>    warningHandler function(warnString, exObj)
>    textHtmlHandler null
>    globalTextHtmlHandler null
>    headers Object {}
>    attributes Object {}
>    path "/UrsRegistrationWizard/dwr"
>    completed false
>    transport Object { httpMethod="POST",  XMLHTTP=[6],
> send=function(),  more...}
>    req XMLHttpRequest { readyState=4,  timeout=0,
> withCredentials=false,  more...}
>    mode "/call/plaincall/"
> arguments Object { type="object"}
> repliesReceived 0
> i 1
>
> That stateChange function should only get called when the browser has
> detected a change in the XmlHttpRequest  -  right?  If my interface
> method hasn't yet explicitly returned or thrown an exception, then how
> can the stateChange callback get triggered prematurely?  I'm trying to
> find a clue in by examining the fields at the breakpoint and parent
> execution chain, but I don't know what I'm missing.
>
> Thanks again,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 9:11 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> Let me rephrase that, each time a call is initiated
> (YourDWRInterface.method()) send is called.  The first time send is
> called per page DWR makes an additional call to the server to retrieve
> the dwr session id.  All subsequent calls delegate to send2.  It is
> normal to see stateChange called several times.  If you place a
> breakpoint lower down in stateChange you will see we break out of it
> under certain status conditions.  Per your original email it is likely
> that the first time stateChange is called the status is 0, and we are
> breaking out of it.  If you want to debug the incomplete reply error,
> I would start at the source of it:
>
> Line 2438:
> } else if (repliesReceived < batch.map.callCount) {
>      dwr.engine._handleError(batch, {
> name:"dwr.engine.incompleteReply",
> message:"Incomplete reply from server" }); }
>
> Inspect repliesReceived, batch.map etc. in the debugger.
>
> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>> Thanks for the response.   I'm not sure what you mean.  At what point
>> does DWR make that call to your DwrServlet server?   I search through
>> the engine.js and see four different places where there is a
>> dwr.engine.transport.send function being called, and three places
>> where a dwr.engine.transport.send2 function is being called.  You're
>> saying that this function is called 1 time before my first call?
>> What does "my first call" refer to?  The call to my java method
>> through the interface javascript object?   Is that what you mean?
>>
>> Unfortunately the application is not available publicly; that would
>> be great if I could have you take a live look at it.  If there's any
>> particular information that I could share, I'd be happy to try
>> through here.
>>
>> Thanks for your help,
>> Gregor Okorn,
>>
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Friday, September 25, 2015 8:01 AM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Incomplete reply from server
>>
>> DWR makes a 1 time call to the server (engine.js -
>> dwr.engine.transport.send) before you first call.  Is your
>> application available publicly for us to take a look?
>>
>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>> Thanks.  I've put some breakpoints in engine.js and found some
>>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>>> function and see that it is triggered BEFORE my service gets its
>>> response from our server.  How is that possible?   As I look at that
>>> breakpoint I see from the WebSphere log file that I'm tailing, that
>>> the response eventually comes back from the server and I see that
>>> the DWR debug prints (enabled with the "accessLogLevel" set to
>>> "CALL" in our web.xml) show that the response is received
>>>
>>>
>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-INSERT
>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-REPLY
>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-START#
>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): (function(){
>>> if(!window.dwr)return;
>>> var dwr=window.dwr._[0];
>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120):
>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObjec
>>> t
>>> (
>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",er
>>> r
>>> o
>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogr
>>> e
>>> s
>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddIn
>>> f
>>> o
>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",
>>> b
>>> r
>>> anchName:"URS
>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>> ...
>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): })();
>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-END#
>>>
>>>
>>> at this point I'm still looking at the breakpoint that has
>>> javascript caught in the xhr:stateChange function and see that the
>>> req.responseText is of course empty (because its stateChange was
>>> triggered too early) and when I hit Continue the eventual error
>>> "Incomplete reply from server" is thrown.  But a reply was received
>>> from the server - out of sync with the stateChange being triggered.
>>>
>>> Is there some timeout that is triggering the xhr:stateChange
>>> function before my java interface completes and returns with the response?
>>> How can I make further sense of this?
>>>
>>>
>>> Thanks,
>>> Gregor Okorn,
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]]
>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>> To: [hidden email]
>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> Mike is right, and I gave you bad advice earlier.  If you put your
>>> breakpoint in validate you can inspect the batch.map and the replies
>>> that have been received.
>>>
>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>> Technically there is always a batch as DWR creates an implicit
>>>> batch for you.
>>>> There is no need to debug the Java side; most efficient way to see
>>>> what is happening is to load your site in a browser with Firebug,
>>>> Developer Tools or similar, open up engine.js in the script pane,
>>>> search for the "Incomplete" error message and set a JS breakpoint
>>>> there.
>>>>
>>>> Best regards
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> I started out using this new technique in our Dojo AMD portal where
>>>> we don't have multiple portlets on a single page (yet) just to make
>>>> sure I have the syntax of setting it up correctly before I try it
>>>> in our pre-AMD multi-portlet-per-page portal, and after a few
>>>> corrections with my dojoConfig and require declaration, it appears
>>>> to be working.
>>>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>>>
>>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>>> the "Incomplete reply from server". Previously with DWR2 it would
>>>> sometimes throw the "No data received from server" error, but now
>>>> it's saying that the reply is incomplete? I've added a breakpoint
>>>> to my java side interface and no exception is thrown from there. I
>>>> see that the javascript error is happening during the middle of the
>>>> server side call from my java interface. I see also that the
>>>> engine.js explains that the "Incomplete reply from server" is
>>>> thrown when it doesn't receive all the responses that were sent
>>>> during a batch call - but I don't set up a batch for this dwr call.
>>>> I've downloaded the DWR3 source code so I can try to debug what is
>>>> causing this. Where in the source code should I place a breakpoint
>>>> for this "Incomplete reply from server" javascript response?
>>>>
>>>> Thanks for your help.
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>>> implementing this preferred technique in both the AMD and pre-AMD
>>>> Dojo implementations we have. Looking forward to it going smoothly
>>>> and being clean. Will report my results when it's ready. Thanks
>>>> again.
>>>>
>>>> Regards,
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> I hear that you understood this perfectly. Key is not to pollute
>>>> the global namespace and instead let the AMD module loader map
>>>> these "anonymous" modules to each other through local variables
>>>> (function parameters). Then each DWR instance will work in
>>>> isolation in the browser and will not interfere with the others.
>>>>
>>>> You still need to ensure that script paths published by the
>>>> different DWR servlets map to the URL space in a managable way
>>>> (maybe your portlet container rewrites paths for all local
>>>> servlets?) and that the AMD loader knows about these paths.
>>>>
>>>> Here's a link to discussion where another DWR user successfully set
>>>> things up in Liferay:
>>>>
>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessi
>>>> o
>>>> n
>>>> -
>>>> addScript-tp6334142p6466106.html
>>>> [1]
>>>>
>>>> Reading backwards from the linked post may provide useful info.
>>>>
>>>> Best regards
>>>>
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> Wow - great information. Thank you. Your link to your AMD
>>>> implementation looks promising for our project. Our project has
>>>> three separate parts, each contained in their own virtual portal,
>>>> and when we recently started the third part I updated from our
>>>> older Dojo pre-AMD library to the newer Dojo AMD library, and so
>>>> should be able to apply the DWR AMD solution in our project's third
>>>> part. The first two parts might still benefit from the pre-AMD Dojo
>>>> module option for integrating DWR like your link describes. I'll
>>>> investigate these new options and see if it solves our problem.
>>>> From what I read from that link so far, I would be able to have
>>>> each portlet safely include its own proper engine.js along with the
>>>> interfaces it needs and not have to implement the work-around of
>>>> extracting out a single engine.js that is shared by multiple
>>>> portlets. That will be great if that's true and if I can get it to
>>>> work as intended.
>>>>
>>>> Thanks!
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> While I don't have any portlet example to prove this point,
>>>> historically portlet problems have usually revolved around
>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>> overwriting each other. If this is not what you are seeing then
>>>> ignore the following advice.
>>>>
>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>> times with different configuration and dwr.xml in the same webapp.
>>>> This is analogous to each portlet having its own DWR servlet.
>>>>
>>>> DWR's js-files can then be consumed in a couple of different ways.
>>>> You can use the standard <script> include but this is limited to
>>>> connecting to one DWR servlet as it defines objects in the global
>>>> js namespace that will collide if another engine.js is included
>>>> this way.
>>>>
>>>>
>>>> If you instead use the AMD script mechanism (requirejs and similar)
>>>> there are no global objects defined in JS so you can include any
>>>> number of DWR servlets' scripts in the same page. You can read up
>>>> on DWR's AMD integration here:
>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>
>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>> workaround is not working in DWR3, but I think you should be able
>>>> to get things working by using official DWR3 functionality and not
>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>
>>>> Best regards
>>>>
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> Hello,
>>>>
>>>> Is there anyone out there that has successfully configured their
>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>>>> on a single portal page?? We're using WebSphere and our home page
>>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>>> and extracted the served engine.js file to a common location for
>>>> all portlets to share so that each portlet would not try to include
>>>> its own engine.js. Including multiple engine.js files won't work.
>>>> That had been working to the extent that each portlet was able to
>>>> make DWR calls independent of the other portlets and the calls
>>>> generally succeeded in completing successfully.
>>>>
>>>> We're upgrading to DWR3 and I have been struggling to get the same
>>>> configuration to work. Do I need to go back to DWR2 or is there any
>>>> evidence - any example of someone else already successfully using
>>>> DWR3 in multiple portlets on a single portal page?
>>>>
>>>> I get the feeling that DWR3 is simply not able to handle this
>>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>>> only DWR2 works with multiple portlets. I've been experimenting and
>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>> roadblock after another. Is it possible? Is there any example of
>>>> this scenario out there for me to review? DWR3 in multiple portlets
>>>> on a single portal page. Each portlet has its own dwr.xml with its
>>>> own set of interfaces. Each portlet makes service calls using DWR
>>>> to populate its content and does so without worrying about other
>>>> portlets possibly making calls at the same time at startup. Is this
>>>> possible?
>>>> Is there a single example to verify that this scenario can work?
>>>>
>>>> Will greatly appreciate any pointer to that elusive example.
>>>>
>>>> Gregor Okorn,
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1]
>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessi
>>>> o
>>>> n
>>>> -
>>>> addScript-tp6334142p6466106.html [2]
>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
In reply to this post by gregorcok
That's helpful.  Per my last email, what is in batch.map?  Is it the
method you expected to see?  How often does this happen?  Does it happen
in all browsers?  When it happens are you the only one using the portal
(on a local machine)?

On 2015-09-25 12:57, Okorn, Gregor C. wrote:

> Forgot to point out that the final condition before the error was
> handled was true because the repliesReceived was 0 and the
> batch.map.callCount was 1.  In this situation the stateChange saw some
> values that did not let it break out  - but let it go as far as
> handling this error.
>
> Thanks,
> Gregor Okorn,
> Leidos, [hidden email], cell 571-247-5490
>
>
> -----Original Message-----
> From: Okorn, Gregor C. [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 14:20 PM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> Appreciate the clarification.   I do see that the first call made when
> I open the page is the _System.generateId, which doesn't get called
> again until I refresh the page.  And I see that it retrieves the
> DWRSESSIONID value that is then used in all subsequent calls.  I also
> see that the stateChange function handles multiple status values and
> can break out without error in depending on the state.
>
> I've added a breakpoint where you suggested and am examining the
> repliesReceived, batch.map, and other fields but am unsure what to
> make of the fact that the stateChange is getting called before my
> interface method returns.  This is happening well after the initial
> startup phase, long after the generateId call is made and received.
> It happens during any random occurrence of our interface calls.  You
> mentioned that these subsequent calls are made through the send2
> function but when the breakpoint is hit for this "Incomplete reply
> from server" the Firebug stacktrace shows:
>
> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
> (line 2445) dwr.engine.transport.complete(batch=Object {
> type="object"})engine.js (line 1568)
> dwr.engine.transport.xhr.stateChange(batch=Object {
> type="object"})engine.js (line 1796)
> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js
> (line 1664)
>
> where the earliest (last in list) call is rooted in the send function,
> not the send2 function.  Is that expected?
>
> Here's Firebug's display of the Function closure's variables and
> values where the breakpoint hit:
>
> batch Object { async={...},  charsProcessed={...},  handlers={...},  
> more...}
>    async  true
>    charsProcessed 0
>    handlers [Object { callbackScope=Window,  exceptionScope=Window,
> callback=function(),  more...}]
>    isPoll false
>    map Object { callCount=1,  nextReverseAjaxIndex=0,
> c0-scriptName="UrsRegWizardDataHandler",  more...}
>    paramCount 169
>    preHooks null
>    postHooks []
>    timeout 0
>    errorHandler null
>    globalErrorHandler Object {
> compassErrorHandler=compassErrorHandler(),  showDetails=showDetails(),
>  showErrorsDialog=showErrorsDialog()}
>    warningHandler function(warnString, exObj)
>    textHtmlHandler null
>    globalTextHtmlHandler null
>    headers Object {}
>    attributes Object {}
>    path "/UrsRegistrationWizard/dwr"
>    completed false
>    transport Object { httpMethod="POST",  XMLHTTP=[6],
> send=function(),  more...}
>    req XMLHttpRequest { readyState=4,  timeout=0,
> withCredentials=false,  more...}
>    mode "/call/plaincall/"
> arguments Object { type="object"}
> repliesReceived 0
> i 1
>
> That stateChange function should only get called when the browser has
> detected a change in the XmlHttpRequest  -  right?  If my interface
> method hasn't yet explicitly returned or thrown an exception, then how
> can the stateChange callback get triggered prematurely?  I'm trying to
> find a clue in by examining the fields at the breakpoint and parent
> execution chain, but I don't know what I'm missing.
>
> Thanks again,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 9:11 AM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> Let me rephrase that, each time a call is initiated
> (YourDWRInterface.method()) send is called.  The first time send is
> called per page DWR makes an additional call to the server to retrieve
> the dwr session id.  All subsequent calls delegate to send2.  It is
> normal to see stateChange called several times.  If you place a
> breakpoint lower down in stateChange you will see we break out of it
> under certain status conditions.  Per your original email it is likely
> that the first time stateChange is called the status is 0, and we are
> breaking out of it.  If you want to debug the incomplete reply error,
> I would start at the source of it:
>
> Line 2438:
> } else if (repliesReceived < batch.map.callCount) {
>      dwr.engine._handleError(batch, {
> name:"dwr.engine.incompleteReply",
> message:"Incomplete reply from server" }); }
>
> Inspect repliesReceived, batch.map etc. in the debugger.
>
> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>> Thanks for the response.   I'm not sure what you mean.  At what point
>> does DWR make that call to your DwrServlet server?   I search through
>> the engine.js and see four different places where there is a
>> dwr.engine.transport.send function being called, and three places
>> where a dwr.engine.transport.send2 function is being called.  You're
>> saying that this function is called 1 time before my first call?
>> What does "my first call" refer to?  The call to my java method
>> through the interface javascript object?   Is that what you mean?
>>
>> Unfortunately the application is not available publicly; that would be
>> great if I could have you take a live look at it.  If there's any
>> particular information that I could share, I'd be happy to try through
>> here.
>>
>> Thanks for your help,
>> Gregor Okorn,
>>
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Friday, September 25, 2015 8:01 AM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Incomplete reply from server
>>
>> DWR makes a 1 time call to the server (engine.js -
>> dwr.engine.transport.send) before you first call.  Is your application
>> available publicly for us to take a look?
>>
>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>> Thanks.  I've put some breakpoints in engine.js and found some
>>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>>> function and see that it is triggered BEFORE my service gets its
>>> response from our server.  How is that possible?   As I look at that
>>> breakpoint I see from the WebSphere log file that I'm tailing, that
>>> the response eventually comes back from the server and I see that the
>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
>>> our web.xml) show that the response is received
>>>
>>>
>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-INSERT
>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-REPLY
>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-START#
>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): (function(){
>>> if(!window.dwr)return;
>>> var dwr=window.dwr._[0];
>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120):
>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>> (
>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>> o
>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>> s
>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>> o
>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>> r
>>> anchName:"URS
>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>> ...
>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): })();
>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>> out(-2120569120): //#DWR-END#
>>>
>>>
>>> at this point I'm still looking at the breakpoint that has javascript
>>> caught in the xhr:stateChange function and see that the
>>> req.responseText is of course empty (because its stateChange was
>>> triggered too early) and when I hit Continue the eventual error
>>> "Incomplete reply from server" is thrown.  But a reply was received
>>> from the server - out of sync with the stateChange being triggered.
>>>
>>> Is there some timeout that is triggering the xhr:stateChange function
>>> before my java interface completes and returns with the response?
>>> How can I make further sense of this?
>>>
>>>
>>> Thanks,
>>> Gregor Okorn,
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]]
>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>> To: [hidden email]
>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>> portlets on a single portal page?
>>>
>>> Mike is right, and I gave you bad advice earlier.  If you put your
>>> breakpoint in validate you can inspect the batch.map and the replies
>>> that have been received.
>>>
>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>> Technically there is always a batch as DWR creates an implicit batch
>>>> for you.
>>>> There is no need to debug the Java side; most efficient way to see
>>>> what is happening is to load your site in a browser with Firebug,
>>>> Developer Tools or similar, open up engine.js in the script pane,
>>>> search for the "Incomplete" error message and set a JS breakpoint
>>>> there.
>>>>
>>>> Best regards
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> I started out using this new technique in our Dojo AMD portal where
>>>> we don't have multiple portlets on a single page (yet) just to make
>>>> sure I have the syntax of setting it up correctly before I try it in
>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>> corrections with my dojoConfig and require declaration, it appears
>>>> to be working.
>>>> I'm now using AMD to include the engine.js and my interface. Thanks.
>>>>
>>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>>> the "Incomplete reply from server". Previously with DWR2 it would
>>>> sometimes throw the "No data received from server" error, but now
>>>> it's saying that the reply is incomplete? I've added a breakpoint to
>>>> my java side interface and no exception is thrown from there. I see
>>>> that the javascript error is happening during the middle of the
>>>> server side call from my java interface. I see also that the
>>>> engine.js explains that the "Incomplete reply from server" is thrown
>>>> when it doesn't receive all the responses that were sent during a
>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>> downloaded the DWR3 source code so I can try to debug what is
>>>> causing this. Where in the source code should I place a breakpoint
>>>> for this "Incomplete reply from server" javascript response?
>>>>
>>>> Thanks for your help.
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>>> implementing this preferred technique in both the AMD and pre-AMD
>>>> Dojo implementations we have. Looking forward to it going smoothly
>>>> and being clean. Will report my results when it's ready. Thanks
>>>> again.
>>>>
>>>> Regards,
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> I hear that you understood this perfectly. Key is not to pollute the
>>>> global namespace and instead let the AMD module loader map these
>>>> "anonymous" modules to each other through local variables (function
>>>> parameters). Then each DWR instance will work in isolation in the
>>>> browser and will not interfere with the others.
>>>>
>>>> You still need to ensure that script paths published by the
>>>> different DWR servlets map to the URL space in a managable way
>>>> (maybe your portlet container rewrites paths for all local
>>>> servlets?) and that the AMD loader knows about these paths.
>>>>
>>>> Here's a link to discussion where another DWR user successfully set
>>>> things up in Liferay:
>>>>
>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>> n
>>>> -
>>>> addScript-tp6334142p6466106.html
>>>> [1]
>>>>
>>>> Reading backwards from the linked post may provide useful info.
>>>>
>>>> Best regards
>>>>
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> Wow - great information. Thank you. Your link to your AMD
>>>> implementation looks promising for our project. Our project has
>>>> three separate parts, each contained in their own virtual portal,
>>>> and when we recently started the third part I updated from our older
>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should be
>>>> able to apply the DWR AMD solution in our project's third part. The
>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>> option for integrating DWR like your link describes. I'll
>>>> investigate these new options and see if it solves our problem. From
>>>> what I read from that link so far, I would be able to have each
>>>> portlet safely include its own proper engine.js along with the
>>>> interfaces it needs and not have to implement the work-around of
>>>> extracting out a single engine.js that is shared by multiple
>>>> portlets. That will be great if that's true and if I can get it to
>>>> work as intended.
>>>>
>>>> Thanks!
>>>>
>>>> Gregor Okorn,
>>>>
>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>> TO: [hidden email]
>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> While I don't have any portlet example to prove this point,
>>>> historically portlet problems have usually revolved around
>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>> overwriting each other. If this is not what you are seeing then
>>>> ignore the following advice.
>>>>
>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>> times with different configuration and dwr.xml in the same webapp.
>>>> This is analogous to each portlet having its own DWR servlet.
>>>>
>>>> DWR's js-files can then be consumed in a couple of different ways.
>>>> You can use the standard <script> include but this is limited to
>>>> connecting to one DWR servlet as it defines objects in the global js
>>>> namespace that will collide if another engine.js is included this
>>>> way.
>>>>
>>>>
>>>> If you instead use the AMD script mechanism (requirejs and similar)
>>>> there are no global objects defined in JS so you can include any
>>>> number of DWR servlets' scripts in the same page. You can read up on
>>>> DWR's AMD integration here:
>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>
>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>> workaround is not working in DWR3, but I think you should be able to
>>>> get things working by using official DWR3 functionality and not
>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>
>>>> Best regards
>>>>
>>>> Mike
>>>>
>>>> Okorn, Gregor C. wrote:
>>>>
>>>> Hello,
>>>>
>>>> Is there anyone out there that has successfully configured their
>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>>>> on a single portal page?? We're using WebSphere and our home page
>>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>>> and extracted the served engine.js file to a common location for all
>>>> portlets to share so that each portlet would not try to include its
>>>> own engine.js. Including multiple engine.js files won't work. That
>>>> had been working to the extent that each portlet was able to make
>>>> DWR calls independent of the other portlets and the calls generally
>>>> succeeded in completing successfully.
>>>>
>>>> We're upgrading to DWR3 and I have been struggling to get the same
>>>> configuration to work. Do I need to go back to DWR2 or is there any
>>>> evidence - any example of someone else already successfully using
>>>> DWR3 in multiple portlets on a single portal page?
>>>>
>>>> I get the feeling that DWR3 is simply not able to handle this
>>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>>> only DWR2 works with multiple portlets. I've been experimenting and
>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>> roadblock after another. Is it possible? Is there any example of
>>>> this scenario out there for me to review? DWR3 in multiple portlets
>>>> on a single portal page. Each portlet has its own dwr.xml with its
>>>> own set of interfaces. Each portlet makes service calls using DWR to
>>>> populate its content and does so without worrying about other
>>>> portlets possibly making calls at the same time at startup. Is this
>>>> possible?
>>>> Is there a single example to verify that this scenario can work?
>>>>
>>>> Will greatly appreciate any pointer to that elusive example.
>>>>
>>>> Gregor Okorn,
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1]
>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>> n
>>>> -
>>>> addScript-tp6334142p6466106.html [2]
>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
Do you always see this for the same remote call and does it happen
everytime?  Do you have a callback specified?

On 2015-09-25 13:28, [hidden email] wrote:

> That's helpful.  Per my last email, what is in batch.map?  Is it the
> method you expected to see?  How often does this happen?  Does it
> happen in all browsers?  When it happens are you the only one using
> the portal (on a local machine)?
>
> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>> Forgot to point out that the final condition before the error was
>> handled was true because the repliesReceived was 0 and the
>> batch.map.callCount was 1.  In this situation the stateChange saw some
>> values that did not let it break out  - but let it go as far as
>> handling this error.
>>
>> Thanks,
>> Gregor Okorn,
>> Leidos, [hidden email], cell 571-247-5490
>>
>>
>> -----Original Message-----
>> From: Okorn, Gregor C. [mailto:[hidden email]]
>> Sent: Friday, September 25, 2015 14:20 PM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Incomplete reply from server
>>
>> Appreciate the clarification.   I do see that the first call made when
>> I open the page is the _System.generateId, which doesn't get called
>> again until I refresh the page.  And I see that it retrieves the
>> DWRSESSIONID value that is then used in all subsequent calls.  I also
>> see that the stateChange function handles multiple status values and
>> can break out without error in depending on the state.
>>
>> I've added a breakpoint where you suggested and am examining the
>> repliesReceived, batch.map, and other fields but am unsure what to
>> make of the fact that the stateChange is getting called before my
>> interface method returns.  This is happening well after the initial
>> startup phase, long after the generateId call is made and received.
>> It happens during any random occurrence of our interface calls.  You
>> mentioned that these subsequent calls are made through the send2
>> function but when the breakpoint is hit for this "Incomplete reply
>> from server" the Firebug stacktrace shows:
>>
>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>> (line 2445) dwr.engine.transport.complete(batch=Object {
>> type="object"})engine.js (line 1568)
>> dwr.engine.transport.xhr.stateChange(batch=Object {
>> type="object"})engine.js (line 1796)
>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js
>> (line 1664)
>>
>> where the earliest (last in list) call is rooted in the send function,
>> not the send2 function.  Is that expected?
>>
>> Here's Firebug's display of the Function closure's variables and
>> values where the breakpoint hit:
>>
>> batch Object { async={...},  charsProcessed={...},  handlers={...},  
>> more...}
>>    async  true
>>    charsProcessed 0
>>    handlers [Object { callbackScope=Window,  exceptionScope=Window,
>> callback=function(),  more...}]
>>    isPoll false
>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>    paramCount 169
>>    preHooks null
>>    postHooks []
>>    timeout 0
>>    errorHandler null
>>    globalErrorHandler Object {
>> compassErrorHandler=compassErrorHandler(),  showDetails=showDetails(),
>>  showErrorsDialog=showErrorsDialog()}
>>    warningHandler function(warnString, exObj)
>>    textHtmlHandler null
>>    globalTextHtmlHandler null
>>    headers Object {}
>>    attributes Object {}
>>    path "/UrsRegistrationWizard/dwr"
>>    completed false
>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>> send=function(),  more...}
>>    req XMLHttpRequest { readyState=4,  timeout=0,
>> withCredentials=false,  more...}
>>    mode "/call/plaincall/"
>> arguments Object { type="object"}
>> repliesReceived 0
>> i 1
>>
>> That stateChange function should only get called when the browser has
>> detected a change in the XmlHttpRequest  -  right?  If my interface
>> method hasn't yet explicitly returned or thrown an exception, then how
>> can the stateChange callback get triggered prematurely?  I'm trying to
>> find a clue in by examining the fields at the breakpoint and parent
>> execution chain, but I don't know what I'm missing.
>>
>> Thanks again,
>> Gregor Okorn,
>>
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Friday, September 25, 2015 9:11 AM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Incomplete reply from server
>>
>> Let me rephrase that, each time a call is initiated
>> (YourDWRInterface.method()) send is called.  The first time send is
>> called per page DWR makes an additional call to the server to retrieve
>> the dwr session id.  All subsequent calls delegate to send2.  It is
>> normal to see stateChange called several times.  If you place a
>> breakpoint lower down in stateChange you will see we break out of it
>> under certain status conditions.  Per your original email it is likely
>> that the first time stateChange is called the status is 0, and we are
>> breaking out of it.  If you want to debug the incomplete reply error,
>> I would start at the source of it:
>>
>> Line 2438:
>> } else if (repliesReceived < batch.map.callCount) {
>>      dwr.engine._handleError(batch, {
>> name:"dwr.engine.incompleteReply",
>> message:"Incomplete reply from server" }); }
>>
>> Inspect repliesReceived, batch.map etc. in the debugger.
>>
>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>> Thanks for the response.   I'm not sure what you mean.  At what point
>>> does DWR make that call to your DwrServlet server?   I search through
>>> the engine.js and see four different places where there is a
>>> dwr.engine.transport.send function being called, and three places
>>> where a dwr.engine.transport.send2 function is being called.  You're
>>> saying that this function is called 1 time before my first call?
>>> What does "my first call" refer to?  The call to my java method
>>> through the interface javascript object?   Is that what you mean?
>>>
>>> Unfortunately the application is not available publicly; that would
>>> be
>>> great if I could have you take a live look at it.  If there's any
>>> particular information that I could share, I'd be happy to try
>>> through
>>> here.
>>>
>>> Thanks for your help,
>>> Gregor Okorn,
>>>
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]]
>>> Sent: Friday, September 25, 2015 8:01 AM
>>> To: [hidden email]
>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>
>>> DWR makes a 1 time call to the server (engine.js -
>>> dwr.engine.transport.send) before you first call.  Is your
>>> application
>>> available publicly for us to take a look?
>>>
>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>>>> function and see that it is triggered BEFORE my service gets its
>>>> response from our server.  How is that possible?   As I look at that
>>>> breakpoint I see from the WebSphere log file that I'm tailing, that
>>>> the response eventually comes back from the server and I see that
>>>> the
>>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL" in
>>>> our web.xml) show that the response is received
>>>>
>>>>
>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120): //#DWR-INSERT
>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120): //#DWR-REPLY
>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120): //#DWR-START#
>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120): (function(){
>>>> if(!window.dwr)return;
>>>> var dwr=window.dwr._[0];
>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120):
>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>>> (
>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>>> o
>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>>> s
>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>>> o
>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>>> r
>>>> anchName:"URS
>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>> ...
>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120): })();
>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>> out(-2120569120): //#DWR-END#
>>>>
>>>>
>>>> at this point I'm still looking at the breakpoint that has
>>>> javascript
>>>> caught in the xhr:stateChange function and see that the
>>>> req.responseText is of course empty (because its stateChange was
>>>> triggered too early) and when I hit Continue the eventual error
>>>> "Incomplete reply from server" is thrown.  But a reply was received
>>>> from the server - out of sync with the stateChange being triggered.
>>>>
>>>> Is there some timeout that is triggering the xhr:stateChange
>>>> function
>>>> before my java interface completes and returns with the response?
>>>> How can I make further sense of this?
>>>>
>>>>
>>>> Thanks,
>>>> Gregor Okorn,
>>>>
>>>> -----Original Message-----
>>>> From: [hidden email] [mailto:[hidden email]]
>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>> To: [hidden email]
>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>> portlets on a single portal page?
>>>>
>>>> Mike is right, and I gave you bad advice earlier.  If you put your
>>>> breakpoint in validate you can inspect the batch.map and the replies
>>>> that have been received.
>>>>
>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>> Technically there is always a batch as DWR creates an implicit
>>>>> batch
>>>>> for you.
>>>>> There is no need to debug the Java side; most efficient way to see
>>>>> what is happening is to load your site in a browser with Firebug,
>>>>> Developer Tools or similar, open up engine.js in the script pane,
>>>>> search for the "Incomplete" error message and set a JS breakpoint
>>>>> there.
>>>>>
>>>>> Best regards
>>>>> Mike
>>>>>
>>>>> Okorn, Gregor C. wrote:
>>>>>
>>>>> I started out using this new technique in our Dojo AMD portal where
>>>>> we don't have multiple portlets on a single page (yet) just to make
>>>>> sure I have the syntax of setting it up correctly before I try it
>>>>> in
>>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>>> corrections with my dojoConfig and require declaration, it appears
>>>>> to be working.
>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>> Thanks.
>>>>>
>>>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>>>> the "Incomplete reply from server". Previously with DWR2 it would
>>>>> sometimes throw the "No data received from server" error, but now
>>>>> it's saying that the reply is incomplete? I've added a breakpoint
>>>>> to
>>>>> my java side interface and no exception is thrown from there. I see
>>>>> that the javascript error is happening during the middle of the
>>>>> server side call from my java interface. I see also that the
>>>>> engine.js explains that the "Incomplete reply from server" is
>>>>> thrown
>>>>> when it doesn't receive all the responses that were sent during a
>>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>>> downloaded the DWR3 source code so I can try to debug what is
>>>>> causing this. Where in the source code should I place a breakpoint
>>>>> for this "Incomplete reply from server" javascript response?
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>> Gregor Okorn,
>>>>>
>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>> TO: [hidden email]
>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>> portlets on a single portal page?
>>>>>
>>>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>>>> implementing this preferred technique in both the AMD and pre-AMD
>>>>> Dojo implementations we have. Looking forward to it going smoothly
>>>>> and being clean. Will report my results when it's ready. Thanks
>>>>> again.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Gregor Okorn,
>>>>>
>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>> TO: [hidden email]
>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>> portlets on a single portal page?
>>>>>
>>>>> I hear that you understood this perfectly. Key is not to pollute
>>>>> the
>>>>> global namespace and instead let the AMD module loader map these
>>>>> "anonymous" modules to each other through local variables (function
>>>>> parameters). Then each DWR instance will work in isolation in the
>>>>> browser and will not interfere with the others.
>>>>>
>>>>> You still need to ensure that script paths published by the
>>>>> different DWR servlets map to the URL space in a managable way
>>>>> (maybe your portlet container rewrites paths for all local
>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>
>>>>> Here's a link to discussion where another DWR user successfully set
>>>>> things up in Liferay:
>>>>>
>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>> n
>>>>> -
>>>>> addScript-tp6334142p6466106.html
>>>>> [1]
>>>>>
>>>>> Reading backwards from the linked post may provide useful info.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Mike
>>>>>
>>>>> Okorn, Gregor C. wrote:
>>>>>
>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>> implementation looks promising for our project. Our project has
>>>>> three separate parts, each contained in their own virtual portal,
>>>>> and when we recently started the third part I updated from our
>>>>> older
>>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should
>>>>> be
>>>>> able to apply the DWR AMD solution in our project's third part. The
>>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>>> option for integrating DWR like your link describes. I'll
>>>>> investigate these new options and see if it solves our problem.
>>>>> From
>>>>> what I read from that link so far, I would be able to have each
>>>>> portlet safely include its own proper engine.js along with the
>>>>> interfaces it needs and not have to implement the work-around of
>>>>> extracting out a single engine.js that is shared by multiple
>>>>> portlets. That will be great if that's true and if I can get it to
>>>>> work as intended.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Gregor Okorn,
>>>>>
>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>> TO: [hidden email]
>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>> portlets on a single portal page?
>>>>>
>>>>> While I don't have any portlet example to prove this point,
>>>>> historically portlet problems have usually revolved around
>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>> overwriting each other. If this is not what you are seeing then
>>>>> ignore the following advice.
>>>>>
>>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>>> times with different configuration and dwr.xml in the same webapp.
>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>
>>>>> DWR's js-files can then be consumed in a couple of different ways.
>>>>> You can use the standard <script> include but this is limited to
>>>>> connecting to one DWR servlet as it defines objects in the global
>>>>> js
>>>>> namespace that will collide if another engine.js is included this
>>>>> way.
>>>>>
>>>>>
>>>>> If you instead use the AMD script mechanism (requirejs and similar)
>>>>> there are no global objects defined in JS so you can include any
>>>>> number of DWR servlets' scripts in the same page. You can read up
>>>>> on
>>>>> DWR's AMD integration here:
>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>
>>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>>> workaround is not working in DWR3, but I think you should be able
>>>>> to
>>>>> get things working by using official DWR3 functionality and not
>>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>>
>>>>> Best regards
>>>>>
>>>>> Mike
>>>>>
>>>>> Okorn, Gregor C. wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Is there anyone out there that has successfully configured their
>>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple portlets
>>>>> on a single portal page?? We're using WebSphere and our home page
>>>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>>>> and extracted the served engine.js file to a common location for
>>>>> all
>>>>> portlets to share so that each portlet would not try to include its
>>>>> own engine.js. Including multiple engine.js files won't work. That
>>>>> had been working to the extent that each portlet was able to make
>>>>> DWR calls independent of the other portlets and the calls generally
>>>>> succeeded in completing successfully.
>>>>>
>>>>> We're upgrading to DWR3 and I have been struggling to get the same
>>>>> configuration to work. Do I need to go back to DWR2 or is there any
>>>>> evidence - any example of someone else already successfully using
>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>
>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>>>> only DWR2 works with multiple portlets. I've been experimenting and
>>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>>> roadblock after another. Is it possible? Is there any example of
>>>>> this scenario out there for me to review? DWR3 in multiple portlets
>>>>> on a single portal page. Each portlet has its own dwr.xml with its
>>>>> own set of interfaces. Each portlet makes service calls using DWR
>>>>> to
>>>>> populate its content and does so without worrying about other
>>>>> portlets possibly making calls at the same time at startup. Is this
>>>>> possible?
>>>>> Is there a single example to verify that this scenario can work?
>>>>>
>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>>
>>>>> Links:
>>>>> ------
>>>>> [1]
>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>> n
>>>>> -
>>>>> addScript-tp6334142p6466106.html [2]
>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
If you notice at the bottom of stateChange there is a call to
dwr.engine._executeScript(toEval).  This will call the callback and
complete the batch (among other things).  For some reason your callback
is not executing and the batch is not being completed.  If you have a
callback specified I would check it for errors.

On 2015-09-25 13:31, [hidden email] wrote:

> Do you always see this for the same remote call and does it happen
> everytime?  Do you have a callback specified?
>
> On 2015-09-25 13:28, [hidden email] wrote:
>> That's helpful.  Per my last email, what is in batch.map?  Is it the
>> method you expected to see?  How often does this happen?  Does it
>> happen in all browsers?  When it happens are you the only one using
>> the portal (on a local machine)?
>>
>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>> Forgot to point out that the final condition before the error was
>>> handled was true because the repliesReceived was 0 and the
>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>> some
>>> values that did not let it break out  - but let it go as far as
>>> handling this error.
>>>
>>> Thanks,
>>> Gregor Okorn,
>>> Leidos, [hidden email], cell 571-247-5490
>>>
>>>
>>> -----Original Message-----
>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>> Sent: Friday, September 25, 2015 14:20 PM
>>> To: [hidden email]
>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>
>>> Appreciate the clarification.   I do see that the first call made
>>> when
>>> I open the page is the _System.generateId, which doesn't get called
>>> again until I refresh the page.  And I see that it retrieves the
>>> DWRSESSIONID value that is then used in all subsequent calls.  I also
>>> see that the stateChange function handles multiple status values and
>>> can break out without error in depending on the state.
>>>
>>> I've added a breakpoint where you suggested and am examining the
>>> repliesReceived, batch.map, and other fields but am unsure what to
>>> make of the fact that the stateChange is getting called before my
>>> interface method returns.  This is happening well after the initial
>>> startup phase, long after the generateId call is made and received.
>>> It happens during any random occurrence of our interface calls.  You
>>> mentioned that these subsequent calls are made through the send2
>>> function but when the breakpoint is hit for this "Incomplete reply
>>> from server" the Firebug stacktrace shows:
>>>
>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>> type="object"})engine.js (line 1568)
>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>> type="object"})engine.js (line 1796)
>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js
>>> (line 1664)
>>>
>>> where the earliest (last in list) call is rooted in the send
>>> function,
>>> not the send2 function.  Is that expected?
>>>
>>> Here's Firebug's display of the Function closure's variables and
>>> values where the breakpoint hit:
>>>
>>> batch Object { async={...},  charsProcessed={...},  handlers={...},  
>>> more...}
>>>    async  true
>>>    charsProcessed 0
>>>    handlers [Object { callbackScope=Window,  exceptionScope=Window,
>>> callback=function(),  more...}]
>>>    isPoll false
>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>    paramCount 169
>>>    preHooks null
>>>    postHooks []
>>>    timeout 0
>>>    errorHandler null
>>>    globalErrorHandler Object {
>>> compassErrorHandler=compassErrorHandler(),  
>>> showDetails=showDetails(),
>>>  showErrorsDialog=showErrorsDialog()}
>>>    warningHandler function(warnString, exObj)
>>>    textHtmlHandler null
>>>    globalTextHtmlHandler null
>>>    headers Object {}
>>>    attributes Object {}
>>>    path "/UrsRegistrationWizard/dwr"
>>>    completed false
>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>> send=function(),  more...}
>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>> withCredentials=false,  more...}
>>>    mode "/call/plaincall/"
>>> arguments Object { type="object"}
>>> repliesReceived 0
>>> i 1
>>>
>>> That stateChange function should only get called when the browser has
>>> detected a change in the XmlHttpRequest  -  right?  If my interface
>>> method hasn't yet explicitly returned or thrown an exception, then
>>> how
>>> can the stateChange callback get triggered prematurely?  I'm trying
>>> to
>>> find a clue in by examining the fields at the breakpoint and parent
>>> execution chain, but I don't know what I'm missing.
>>>
>>> Thanks again,
>>> Gregor Okorn,
>>>
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]]
>>> Sent: Friday, September 25, 2015 9:11 AM
>>> To: [hidden email]
>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>
>>> Let me rephrase that, each time a call is initiated
>>> (YourDWRInterface.method()) send is called.  The first time send is
>>> called per page DWR makes an additional call to the server to
>>> retrieve
>>> the dwr session id.  All subsequent calls delegate to send2.  It is
>>> normal to see stateChange called several times.  If you place a
>>> breakpoint lower down in stateChange you will see we break out of it
>>> under certain status conditions.  Per your original email it is
>>> likely
>>> that the first time stateChange is called the status is 0, and we are
>>> breaking out of it.  If you want to debug the incomplete reply error,
>>> I would start at the source of it:
>>>
>>> Line 2438:
>>> } else if (repliesReceived < batch.map.callCount) {
>>>      dwr.engine._handleError(batch, {
>>> name:"dwr.engine.incompleteReply",
>>> message:"Incomplete reply from server" }); }
>>>
>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>
>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>> point
>>>> does DWR make that call to your DwrServlet server?   I search
>>>> through
>>>> the engine.js and see four different places where there is a
>>>> dwr.engine.transport.send function being called, and three places
>>>> where a dwr.engine.transport.send2 function is being called.  You're
>>>> saying that this function is called 1 time before my first call?
>>>> What does "my first call" refer to?  The call to my java method
>>>> through the interface javascript object?   Is that what you mean?
>>>>
>>>> Unfortunately the application is not available publicly; that would
>>>> be
>>>> great if I could have you take a live look at it.  If there's any
>>>> particular information that I could share, I'd be happy to try
>>>> through
>>>> here.
>>>>
>>>> Thanks for your help,
>>>> Gregor Okorn,
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [hidden email] [mailto:[hidden email]]
>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>> To: [hidden email]
>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>
>>>> DWR makes a 1 time call to the server (engine.js -
>>>> dwr.engine.transport.send) before you first call.  Is your
>>>> application
>>>> available publicly for us to take a look?
>>>>
>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>> interesting behavior.   I added a breakpoint in the xhr:stateChange
>>>>> function and see that it is triggered BEFORE my service gets its
>>>>> response from our server.  How is that possible?   As I look at
>>>>> that
>>>>> breakpoint I see from the WebSphere log file that I'm tailing, that
>>>>> the response eventually comes back from the server and I see that
>>>>> the
>>>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL"
>>>>> in
>>>>> our web.xml) show that the response is received
>>>>>
>>>>>
>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120): //#DWR-INSERT
>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120): //#DWR-REPLY
>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120): //#DWR-START#
>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120): (function(){
>>>>> if(!window.dwr)return;
>>>>> var dwr=window.dwr._[0];
>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120):
>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>>>> (
>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>>>> o
>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>>>> s
>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>>>> o
>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>>>> r
>>>>> anchName:"URS
>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>> ...
>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120): })();
>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>> out(-2120569120): //#DWR-END#
>>>>>
>>>>>
>>>>> at this point I'm still looking at the breakpoint that has
>>>>> javascript
>>>>> caught in the xhr:stateChange function and see that the
>>>>> req.responseText is of course empty (because its stateChange was
>>>>> triggered too early) and when I hit Continue the eventual error
>>>>> "Incomplete reply from server" is thrown.  But a reply was received
>>>>> from the server - out of sync with the stateChange being triggered.
>>>>>
>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>> function
>>>>> before my java interface completes and returns with the response?
>>>>> How can I make further sense of this?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Gregor Okorn,
>>>>>
>>>>> -----Original Message-----
>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>> portlets on a single portal page?
>>>>>
>>>>> Mike is right, and I gave you bad advice earlier.  If you put your
>>>>> breakpoint in validate you can inspect the batch.map and the
>>>>> replies
>>>>> that have been received.
>>>>>
>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>> batch
>>>>>> for you.
>>>>>> There is no need to debug the Java side; most efficient way to see
>>>>>> what is happening is to load your site in a browser with Firebug,
>>>>>> Developer Tools or similar, open up engine.js in the script pane,
>>>>>> search for the "Incomplete" error message and set a JS breakpoint
>>>>>> there.
>>>>>>
>>>>>> Best regards
>>>>>> Mike
>>>>>>
>>>>>> Okorn, Gregor C. wrote:
>>>>>>
>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>> where
>>>>>> we don't have multiple portlets on a single page (yet) just to
>>>>>> make
>>>>>> sure I have the syntax of setting it up correctly before I try it
>>>>>> in
>>>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>>>> corrections with my dojoConfig and require declaration, it appears
>>>>>> to be working.
>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>> Thanks.
>>>>>>
>>>>>> I've seen it succeed with a couple dwr calls, but on one it throws
>>>>>> the "Incomplete reply from server". Previously with DWR2 it would
>>>>>> sometimes throw the "No data received from server" error, but now
>>>>>> it's saying that the reply is incomplete? I've added a breakpoint
>>>>>> to
>>>>>> my java side interface and no exception is thrown from there. I
>>>>>> see
>>>>>> that the javascript error is happening during the middle of the
>>>>>> server side call from my java interface. I see also that the
>>>>>> engine.js explains that the "Incomplete reply from server" is
>>>>>> thrown
>>>>>> when it doesn't receive all the responses that were sent during a
>>>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>>>> downloaded the DWR3 source code so I can try to debug what is
>>>>>> causing this. Where in the source code should I place a breakpoint
>>>>>> for this "Incomplete reply from server" javascript response?
>>>>>>
>>>>>> Thanks for your help.
>>>>>>
>>>>>> Gregor Okorn,
>>>>>>
>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>> TO: [hidden email]
>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>> portlets on a single portal page?
>>>>>>
>>>>>> I'm reading that additional link and it is useful. Thanks. I'll be
>>>>>> implementing this preferred technique in both the AMD and pre-AMD
>>>>>> Dojo implementations we have. Looking forward to it going smoothly
>>>>>> and being clean. Will report my results when it's ready. Thanks
>>>>>> again.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Gregor Okorn,
>>>>>>
>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>> TO: [hidden email]
>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>> portlets on a single portal page?
>>>>>>
>>>>>> I hear that you understood this perfectly. Key is not to pollute
>>>>>> the
>>>>>> global namespace and instead let the AMD module loader map these
>>>>>> "anonymous" modules to each other through local variables
>>>>>> (function
>>>>>> parameters). Then each DWR instance will work in isolation in the
>>>>>> browser and will not interfere with the others.
>>>>>>
>>>>>> You still need to ensure that script paths published by the
>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>
>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>> set
>>>>>> things up in Liferay:
>>>>>>
>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>> n
>>>>>> -
>>>>>> addScript-tp6334142p6466106.html
>>>>>> [1]
>>>>>>
>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> Okorn, Gregor C. wrote:
>>>>>>
>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>> implementation looks promising for our project. Our project has
>>>>>> three separate parts, each contained in their own virtual portal,
>>>>>> and when we recently started the third part I updated from our
>>>>>> older
>>>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should
>>>>>> be
>>>>>> able to apply the DWR AMD solution in our project's third part.
>>>>>> The
>>>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>>>> option for integrating DWR like your link describes. I'll
>>>>>> investigate these new options and see if it solves our problem.
>>>>>> From
>>>>>> what I read from that link so far, I would be able to have each
>>>>>> portlet safely include its own proper engine.js along with the
>>>>>> interfaces it needs and not have to implement the work-around of
>>>>>> extracting out a single engine.js that is shared by multiple
>>>>>> portlets. That will be great if that's true and if I can get it to
>>>>>> work as intended.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Gregor Okorn,
>>>>>>
>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>> TO: [hidden email]
>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>> portlets on a single portal page?
>>>>>>
>>>>>> While I don't have any portlet example to prove this point,
>>>>>> historically portlet problems have usually revolved around
>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>> ignore the following advice.
>>>>>>
>>>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>>>> times with different configuration and dwr.xml in the same webapp.
>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>
>>>>>> DWR's js-files can then be consumed in a couple of different ways.
>>>>>> You can use the standard <script> include but this is limited to
>>>>>> connecting to one DWR servlet as it defines objects in the global
>>>>>> js
>>>>>> namespace that will collide if another engine.js is included this
>>>>>> way.
>>>>>>
>>>>>>
>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>> similar)
>>>>>> there are no global objects defined in JS so you can include any
>>>>>> number of DWR servlets' scripts in the same page. You can read up
>>>>>> on
>>>>>> DWR's AMD integration here:
>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>
>>>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>>>> workaround is not working in DWR3, but I think you should be able
>>>>>> to
>>>>>> get things working by using official DWR3 functionality and not
>>>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> Okorn, Gregor C. wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Is there anyone out there that has successfully configured their
>>>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple
>>>>>> portlets
>>>>>> on a single portal page?? We're using WebSphere and our home page
>>>>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>>>>> and extracted the served engine.js file to a common location for
>>>>>> all
>>>>>> portlets to share so that each portlet would not try to include
>>>>>> its
>>>>>> own engine.js. Including multiple engine.js files won't work. That
>>>>>> had been working to the extent that each portlet was able to make
>>>>>> DWR calls independent of the other portlets and the calls
>>>>>> generally
>>>>>> succeeded in completing successfully.
>>>>>>
>>>>>> We're upgrading to DWR3 and I have been struggling to get the same
>>>>>> configuration to work. Do I need to go back to DWR2 or is there
>>>>>> any
>>>>>> evidence - any example of someone else already successfully using
>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>
>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet, but
>>>>>> only DWR2 works with multiple portlets. I've been experimenting
>>>>>> and
>>>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>>>> roadblock after another. Is it possible? Is there any example of
>>>>>> this scenario out there for me to review? DWR3 in multiple
>>>>>> portlets
>>>>>> on a single portal page. Each portlet has its own dwr.xml with its
>>>>>> own set of interfaces. Each portlet makes service calls using DWR
>>>>>> to
>>>>>> populate its content and does so without worrying about other
>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>> this possible?
>>>>>> Is there a single example to verify that this scenario can work?
>>>>>>
>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Links:
>>>>>> ------
>>>>>> [1]
>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>> n
>>>>>> -
>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
With the new AMD set-up that Mike recommended you have engine.js defined
in each portlet, correct?  Do you still have engine.js fined at the
portal level?  If so, make sure you remove it.  Make sure you have a
clean set-up with engine.js defined only in the portlets.

I would have to dig into this a bit deeper but it is possible that we
have a scope issue with XHR (stateChange ), and that it is picking up
other portlets.  But before we dig deeper, please answer my other
questions as they could also be the cause.

On 2015-09-25 13:38, [hidden email] wrote:

> If you notice at the bottom of stateChange there is a call to
> dwr.engine._executeScript(toEval).  This will call the callback and
> complete the batch (among other things).  For some reason your
> callback is not executing and the batch is not being completed.  If
> you have a callback specified I would check it for errors.
>
> On 2015-09-25 13:31, [hidden email] wrote:
>> Do you always see this for the same remote call and does it happen
>> everytime?  Do you have a callback specified?
>>
>> On 2015-09-25 13:28, [hidden email] wrote:
>>> That's helpful.  Per my last email, what is in batch.map?  Is it the
>>> method you expected to see?  How often does this happen?  Does it
>>> happen in all browsers?  When it happens are you the only one using
>>> the portal (on a local machine)?
>>>
>>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>>> Forgot to point out that the final condition before the error was
>>>> handled was true because the repliesReceived was 0 and the
>>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>>> some
>>>> values that did not let it break out  - but let it go as far as
>>>> handling this error.
>>>>
>>>> Thanks,
>>>> Gregor Okorn,
>>>> Leidos, [hidden email], cell 571-247-5490
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>>> Sent: Friday, September 25, 2015 14:20 PM
>>>> To: [hidden email]
>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>
>>>> Appreciate the clarification.   I do see that the first call made
>>>> when
>>>> I open the page is the _System.generateId, which doesn't get called
>>>> again until I refresh the page.  And I see that it retrieves the
>>>> DWRSESSIONID value that is then used in all subsequent calls.  I
>>>> also
>>>> see that the stateChange function handles multiple status values and
>>>> can break out without error in depending on the state.
>>>>
>>>> I've added a breakpoint where you suggested and am examining the
>>>> repliesReceived, batch.map, and other fields but am unsure what to
>>>> make of the fact that the stateChange is getting called before my
>>>> interface method returns.  This is happening well after the initial
>>>> startup phase, long after the generateId call is made and received.
>>>> It happens during any random occurrence of our interface calls.  You
>>>> mentioned that these subsequent calls are made through the send2
>>>> function but when the breakpoint is hit for this "Incomplete reply
>>>> from server" the Firebug stacktrace shows:
>>>>
>>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>>> type="object"})engine.js (line 1568)
>>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>>> type="object"})engine.js (line 1796)
>>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js
>>>> (line 1664)
>>>>
>>>> where the earliest (last in list) call is rooted in the send
>>>> function,
>>>> not the send2 function.  Is that expected?
>>>>
>>>> Here's Firebug's display of the Function closure's variables and
>>>> values where the breakpoint hit:
>>>>
>>>> batch Object { async={...},  charsProcessed={...},  handlers={...},  
>>>> more...}
>>>>    async  true
>>>>    charsProcessed 0
>>>>    handlers [Object { callbackScope=Window,  
>>>> exceptionScope=Window,
>>>> callback=function(),  more...}]
>>>>    isPoll false
>>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>>    paramCount 169
>>>>    preHooks null
>>>>    postHooks []
>>>>    timeout 0
>>>>    errorHandler null
>>>>    globalErrorHandler Object {
>>>> compassErrorHandler=compassErrorHandler(),  
>>>> showDetails=showDetails(),
>>>>  showErrorsDialog=showErrorsDialog()}
>>>>    warningHandler function(warnString, exObj)
>>>>    textHtmlHandler null
>>>>    globalTextHtmlHandler null
>>>>    headers Object {}
>>>>    attributes Object {}
>>>>    path "/UrsRegistrationWizard/dwr"
>>>>    completed false
>>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>>> send=function(),  more...}
>>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>>> withCredentials=false,  more...}
>>>>    mode "/call/plaincall/"
>>>> arguments Object { type="object"}
>>>> repliesReceived 0
>>>> i 1
>>>>
>>>> That stateChange function should only get called when the browser
>>>> has
>>>> detected a change in the XmlHttpRequest  -  right?  If my interface
>>>> method hasn't yet explicitly returned or thrown an exception, then
>>>> how
>>>> can the stateChange callback get triggered prematurely?  I'm trying
>>>> to
>>>> find a clue in by examining the fields at the breakpoint and parent
>>>> execution chain, but I don't know what I'm missing.
>>>>
>>>> Thanks again,
>>>> Gregor Okorn,
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [hidden email] [mailto:[hidden email]]
>>>> Sent: Friday, September 25, 2015 9:11 AM
>>>> To: [hidden email]
>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>
>>>> Let me rephrase that, each time a call is initiated
>>>> (YourDWRInterface.method()) send is called.  The first time send is
>>>> called per page DWR makes an additional call to the server to
>>>> retrieve
>>>> the dwr session id.  All subsequent calls delegate to send2.  It is
>>>> normal to see stateChange called several times.  If you place a
>>>> breakpoint lower down in stateChange you will see we break out of it
>>>> under certain status conditions.  Per your original email it is
>>>> likely
>>>> that the first time stateChange is called the status is 0, and we
>>>> are
>>>> breaking out of it.  If you want to debug the incomplete reply
>>>> error,
>>>> I would start at the source of it:
>>>>
>>>> Line 2438:
>>>> } else if (repliesReceived < batch.map.callCount) {
>>>>      dwr.engine._handleError(batch, {
>>>> name:"dwr.engine.incompleteReply",
>>>> message:"Incomplete reply from server" }); }
>>>>
>>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>>
>>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>>> point
>>>>> does DWR make that call to your DwrServlet server?   I search
>>>>> through
>>>>> the engine.js and see four different places where there is a
>>>>> dwr.engine.transport.send function being called, and three places
>>>>> where a dwr.engine.transport.send2 function is being called.  
>>>>> You're
>>>>> saying that this function is called 1 time before my first call?
>>>>> What does "my first call" refer to?  The call to my java method
>>>>> through the interface javascript object?   Is that what you mean?
>>>>>
>>>>> Unfortunately the application is not available publicly; that would
>>>>> be
>>>>> great if I could have you take a live look at it.  If there's any
>>>>> particular information that I could share, I'd be happy to try
>>>>> through
>>>>> here.
>>>>>
>>>>> Thanks for your help,
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> DWR makes a 1 time call to the server (engine.js -
>>>>> dwr.engine.transport.send) before you first call.  Is your
>>>>> application
>>>>> available publicly for us to take a look?
>>>>>
>>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>>> interesting behavior.   I added a breakpoint in the
>>>>>> xhr:stateChange
>>>>>> function and see that it is triggered BEFORE my service gets its
>>>>>> response from our server.  How is that possible?   As I look at
>>>>>> that
>>>>>> breakpoint I see from the WebSphere log file that I'm tailing,
>>>>>> that
>>>>>> the response eventually comes back from the server and I see that
>>>>>> the
>>>>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL"
>>>>>> in
>>>>>> our web.xml) show that the response is received
>>>>>>
>>>>>>
>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-INSERT
>>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-REPLY
>>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-START#
>>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): (function(){
>>>>>> if(!window.dwr)return;
>>>>>> var dwr=window.dwr._[0];
>>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120):
>>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>>>>> (
>>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>>>>> o
>>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>>>>> s
>>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>>>>> o
>>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>>>>> r
>>>>>> anchName:"URS
>>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>>> ...
>>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): })();
>>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-END#
>>>>>>
>>>>>>
>>>>>> at this point I'm still looking at the breakpoint that has
>>>>>> javascript
>>>>>> caught in the xhr:stateChange function and see that the
>>>>>> req.responseText is of course empty (because its stateChange was
>>>>>> triggered too early) and when I hit Continue the eventual error
>>>>>> "Incomplete reply from server" is thrown.  But a reply was
>>>>>> received
>>>>>> from the server - out of sync with the stateChange being
>>>>>> triggered.
>>>>>>
>>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>>> function
>>>>>> before my java interface completes and returns with the response?
>>>>>> How can I make further sense of this?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>> portlets on a single portal page?
>>>>>>
>>>>>> Mike is right, and I gave you bad advice earlier.  If you put your
>>>>>> breakpoint in validate you can inspect the batch.map and the
>>>>>> replies
>>>>>> that have been received.
>>>>>>
>>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>>> batch
>>>>>>> for you.
>>>>>>> There is no need to debug the Java side; most efficient way to
>>>>>>> see
>>>>>>> what is happening is to load your site in a browser with Firebug,
>>>>>>> Developer Tools or similar, open up engine.js in the script pane,
>>>>>>> search for the "Incomplete" error message and set a JS breakpoint
>>>>>>> there.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Mike
>>>>>>>
>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>
>>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>>> where
>>>>>>> we don't have multiple portlets on a single page (yet) just to
>>>>>>> make
>>>>>>> sure I have the syntax of setting it up correctly before I try it
>>>>>>> in
>>>>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>>>>> corrections with my dojoConfig and require declaration, it
>>>>>>> appears
>>>>>>> to be working.
>>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>>> Thanks.
>>>>>>>
>>>>>>> I've seen it succeed with a couple dwr calls, but on one it
>>>>>>> throws
>>>>>>> the "Incomplete reply from server". Previously with DWR2 it would
>>>>>>> sometimes throw the "No data received from server" error, but now
>>>>>>> it's saying that the reply is incomplete? I've added a breakpoint
>>>>>>> to
>>>>>>> my java side interface and no exception is thrown from there. I
>>>>>>> see
>>>>>>> that the javascript error is happening during the middle of the
>>>>>>> server side call from my java interface. I see also that the
>>>>>>> engine.js explains that the "Incomplete reply from server" is
>>>>>>> thrown
>>>>>>> when it doesn't receive all the responses that were sent during a
>>>>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>>>>> downloaded the DWR3 source code so I can try to debug what is
>>>>>>> causing this. Where in the source code should I place a
>>>>>>> breakpoint
>>>>>>> for this "Incomplete reply from server" javascript response?
>>>>>>>
>>>>>>> Thanks for your help.
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>>> TO: [hidden email]
>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> I'm reading that additional link and it is useful. Thanks. I'll
>>>>>>> be
>>>>>>> implementing this preferred technique in both the AMD and pre-AMD
>>>>>>> Dojo implementations we have. Looking forward to it going
>>>>>>> smoothly
>>>>>>> and being clean. Will report my results when it's ready. Thanks
>>>>>>> again.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>>> TO: [hidden email]
>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> I hear that you understood this perfectly. Key is not to pollute
>>>>>>> the
>>>>>>> global namespace and instead let the AMD module loader map these
>>>>>>> "anonymous" modules to each other through local variables
>>>>>>> (function
>>>>>>> parameters). Then each DWR instance will work in isolation in the
>>>>>>> browser and will not interfere with the others.
>>>>>>>
>>>>>>> You still need to ensure that script paths published by the
>>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>>
>>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>>> set
>>>>>>> things up in Liferay:
>>>>>>>
>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>> n
>>>>>>> -
>>>>>>> addScript-tp6334142p6466106.html
>>>>>>> [1]
>>>>>>>
>>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>
>>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>>> implementation looks promising for our project. Our project has
>>>>>>> three separate parts, each contained in their own virtual portal,
>>>>>>> and when we recently started the third part I updated from our
>>>>>>> older
>>>>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should
>>>>>>> be
>>>>>>> able to apply the DWR AMD solution in our project's third part.
>>>>>>> The
>>>>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>>>>> option for integrating DWR like your link describes. I'll
>>>>>>> investigate these new options and see if it solves our problem.
>>>>>>> From
>>>>>>> what I read from that link so far, I would be able to have each
>>>>>>> portlet safely include its own proper engine.js along with the
>>>>>>> interfaces it needs and not have to implement the work-around of
>>>>>>> extracting out a single engine.js that is shared by multiple
>>>>>>> portlets. That will be great if that's true and if I can get it
>>>>>>> to work as intended.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>>> TO: [hidden email]
>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> While I don't have any portlet example to prove this point,
>>>>>>> historically portlet problems have usually revolved around
>>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>>> ignore the following advice.
>>>>>>>
>>>>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>>>>> times with different configuration and dwr.xml in the same
>>>>>>> webapp.
>>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>>
>>>>>>> DWR's js-files can then be consumed in a couple of different
>>>>>>> ways.
>>>>>>> You can use the standard <script> include but this is limited to
>>>>>>> connecting to one DWR servlet as it defines objects in the global
>>>>>>> js
>>>>>>> namespace that will collide if another engine.js is included this
>>>>>>> way.
>>>>>>>
>>>>>>>
>>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>>> similar)
>>>>>>> there are no global objects defined in JS so you can include any
>>>>>>> number of DWR servlets' scripts in the same page. You can read up
>>>>>>> on
>>>>>>> DWR's AMD integration here:
>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>>
>>>>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>>>>> workaround is not working in DWR3, but I think you should be able
>>>>>>> to
>>>>>>> get things working by using official DWR3 functionality and not
>>>>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Is there anyone out there that has successfully configured their
>>>>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple
>>>>>>> portlets
>>>>>>> on a single portal page?? We're using WebSphere and our home page
>>>>>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>>>>>> and extracted the served engine.js file to a common location for
>>>>>>> all
>>>>>>> portlets to share so that each portlet would not try to include
>>>>>>> its
>>>>>>> own engine.js. Including multiple engine.js files won't work.
>>>>>>> That
>>>>>>> had been working to the extent that each portlet was able to make
>>>>>>> DWR calls independent of the other portlets and the calls
>>>>>>> generally
>>>>>>> succeeded in completing successfully.
>>>>>>>
>>>>>>> We're upgrading to DWR3 and I have been struggling to get the
>>>>>>> same
>>>>>>> configuration to work. Do I need to go back to DWR2 or is there
>>>>>>> any
>>>>>>> evidence - any example of someone else already successfully using
>>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>>
>>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet,
>>>>>>> but
>>>>>>> only DWR2 works with multiple portlets. I've been experimenting
>>>>>>> and
>>>>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>>>>> roadblock after another. Is it possible? Is there any example of
>>>>>>> this scenario out there for me to review? DWR3 in multiple
>>>>>>> portlets
>>>>>>> on a single portal page. Each portlet has its own dwr.xml with
>>>>>>> its
>>>>>>> own set of interfaces. Each portlet makes service calls using DWR
>>>>>>> to
>>>>>>> populate its content and does so without worrying about other
>>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>>> this possible?
>>>>>>> Is there a single example to verify that this scenario can work?
>>>>>>>
>>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Links:
>>>>>>> ------
>>>>>>> [1]
>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>> n
>>>>>>> -
>>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok
Thanks for the response and questions.  The batch.map shows the method I'm expecting to see.  It doesn't always happen on the same remote call.  It has happened on various calls at random times.  All of our remote calls do have callbacks awaiting a response.  I'm testing this on my local development machine.   I'm currently unable to open the page with Chrome; and with IE I'm unable to get it to stop asking me if I'm wanting to leave the page or stay on the page.  We do have the app configured to prompt the user if he tries to navigate away from the page by closing the browser or hitting the refresh or back button; we're using the browser's built-in mechanism, and when I try to open the page with IE it constantly prompts me for that answer.   So - I've been unable to test this behavior on my local machine with anything other than Firefox.  On our shared development server however, which is still using DWR2, we are still seeing the similar error "No data received from server" with the same amount of randomness from all browsers.

I've implemented the update to DWR3 and AMD loading, but this app is not a portlet.  This is a standalone web app that I'm testing DWR3 with AMD on first - before I attempt to update our portlets with it.  There is just the one engine.js being loaded.  

I think that answers all your questions.  I hope they are helpful in offering any clue as to what I could try next to debug this.  Thanks again for your help.

Gregor Okorn,


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, September 25, 2015 16:01 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

With the new AMD set-up that Mike recommended you have engine.js defined in each portlet, correct?  Do you still have engine.js fined at the portal level?  If so, make sure you remove it.  Make sure you have a clean set-up with engine.js defined only in the portlets.

I would have to dig into this a bit deeper but it is possible that we have a scope issue with XHR (stateChange ), and that it is picking up other portlets.  But before we dig deeper, please answer my other questions as they could also be the cause.

On 2015-09-25 13:38, [hidden email] wrote:

> If you notice at the bottom of stateChange there is a call to
> dwr.engine._executeScript(toEval).  This will call the callback and
> complete the batch (among other things).  For some reason your
> callback is not executing and the batch is not being completed.  If
> you have a callback specified I would check it for errors.
>
> On 2015-09-25 13:31, [hidden email] wrote:
>> Do you always see this for the same remote call and does it happen
>> everytime?  Do you have a callback specified?
>>
>> On 2015-09-25 13:28, [hidden email] wrote:
>>> That's helpful.  Per my last email, what is in batch.map?  Is it the
>>> method you expected to see?  How often does this happen?  Does it
>>> happen in all browsers?  When it happens are you the only one using
>>> the portal (on a local machine)?
>>>
>>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>>> Forgot to point out that the final condition before the error was
>>>> handled was true because the repliesReceived was 0 and the
>>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>>> some values that did not let it break out  - but let it go as far
>>>> as handling this error.
>>>>
>>>> Thanks,
>>>> Gregor Okorn,
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>>> Sent: Friday, September 25, 2015 14:20 PM
>>>> To: [hidden email]
>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>
>>>> Appreciate the clarification.   I do see that the first call made
>>>> when
>>>> I open the page is the _System.generateId, which doesn't get called
>>>> again until I refresh the page.  And I see that it retrieves the
>>>> DWRSESSIONID value that is then used in all subsequent calls.  I
>>>> also see that the stateChange function handles multiple status
>>>> values and can break out without error in depending on the state.
>>>>
>>>> I've added a breakpoint where you suggested and am examining the
>>>> repliesReceived, batch.map, and other fields but am unsure what to
>>>> make of the fact that the stateChange is getting called before my
>>>> interface method returns.  This is happening well after the initial
>>>> startup phase, long after the generateId call is made and received.
>>>> It happens during any random occurrence of our interface calls.  
>>>> You mentioned that these subsequent calls are made through the
>>>> send2 function but when the breakpoint is hit for this "Incomplete
>>>> reply from server" the Firebug stacktrace shows:
>>>>
>>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>>> type="object"})engine.js (line 1568)
>>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>>> type="object"})engine.js (line 1796)
>>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.
>>>> js
>>>> (line 1664)
>>>>
>>>> where the earliest (last in list) call is rooted in the send
>>>> function, not the send2 function.  Is that expected?
>>>>
>>>> Here's Firebug's display of the Function closure's variables and
>>>> values where the breakpoint hit:
>>>>
>>>> batch Object { async={...},  charsProcessed={...},  handlers={...},  
>>>> more...}
>>>>    async  true
>>>>    charsProcessed 0
>>>>    handlers [Object { callbackScope=Window,  
>>>> exceptionScope=Window,
>>>> callback=function(),  more...}]
>>>>    isPoll false
>>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>>    paramCount 169
>>>>    preHooks null
>>>>    postHooks []
>>>>    timeout 0
>>>>    errorHandler null
>>>>    globalErrorHandler Object {
>>>> compassErrorHandler=compassErrorHandler(),
>>>> showDetails=showDetails(),
>>>>  showErrorsDialog=showErrorsDialog()}
>>>>    warningHandler function(warnString, exObj)
>>>>    textHtmlHandler null
>>>>    globalTextHtmlHandler null
>>>>    headers Object {}
>>>>    attributes Object {}
>>>>    path "/UrsRegistrationWizard/dwr"
>>>>    completed false
>>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>>> send=function(),  more...}
>>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>>> withCredentials=false,  more...}
>>>>    mode "/call/plaincall/"
>>>> arguments Object { type="object"}
>>>> repliesReceived 0
>>>> i 1
>>>>
>>>> That stateChange function should only get called when the browser
>>>> has detected a change in the XmlHttpRequest  -  right?  If my
>>>> interface method hasn't yet explicitly returned or thrown an
>>>> exception, then how can the stateChange callback get triggered
>>>> prematurely?  I'm trying to find a clue in by examining the fields
>>>> at the breakpoint and parent execution chain, but I don't know what
>>>> I'm missing.
>>>>
>>>> Thanks again,
>>>> Gregor Okorn,
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [hidden email] [mailto:[hidden email]]
>>>> Sent: Friday, September 25, 2015 9:11 AM
>>>> To: [hidden email]
>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>
>>>> Let me rephrase that, each time a call is initiated
>>>> (YourDWRInterface.method()) send is called.  The first time send is
>>>> called per page DWR makes an additional call to the server to
>>>> retrieve the dwr session id.  All subsequent calls delegate to
>>>> send2.  It is normal to see stateChange called several times.  If
>>>> you place a breakpoint lower down in stateChange you will see we
>>>> break out of it under certain status conditions.  Per your original
>>>> email it is likely that the first time stateChange is called the
>>>> status is 0, and we are breaking out of it.  If you want to debug
>>>> the incomplete reply error, I would start at the source of it:
>>>>
>>>> Line 2438:
>>>> } else if (repliesReceived < batch.map.callCount) {
>>>>      dwr.engine._handleError(batch, {
>>>> name:"dwr.engine.incompleteReply",
>>>> message:"Incomplete reply from server" }); }
>>>>
>>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>>
>>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>>> point
>>>>> does DWR make that call to your DwrServlet server?   I search
>>>>> through
>>>>> the engine.js and see four different places where there is a
>>>>> dwr.engine.transport.send function being called, and three places
>>>>> where a dwr.engine.transport.send2 function is being called.  
>>>>> You're
>>>>> saying that this function is called 1 time before my first call?
>>>>> What does "my first call" refer to?  The call to my java method
>>>>> through the interface javascript object?   Is that what you mean?
>>>>>
>>>>> Unfortunately the application is not available publicly; that would
>>>>> be
>>>>> great if I could have you take a live look at it.  If there's any
>>>>> particular information that I could share, I'd be happy to try
>>>>> through
>>>>> here.
>>>>>
>>>>> Thanks for your help,
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> DWR makes a 1 time call to the server (engine.js -
>>>>> dwr.engine.transport.send) before you first call.  Is your
>>>>> application
>>>>> available publicly for us to take a look?
>>>>>
>>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>>> interesting behavior.   I added a breakpoint in the
>>>>>> xhr:stateChange
>>>>>> function and see that it is triggered BEFORE my service gets its
>>>>>> response from our server.  How is that possible?   As I look at
>>>>>> that
>>>>>> breakpoint I see from the WebSphere log file that I'm tailing,
>>>>>> that
>>>>>> the response eventually comes back from the server and I see that
>>>>>> the
>>>>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL"
>>>>>> in
>>>>>> our web.xml) show that the response is received
>>>>>>
>>>>>>
>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-INSERT
>>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-REPLY
>>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-START#
>>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): (function(){
>>>>>> if(!window.dwr)return;
>>>>>> var dwr=window.dwr._[0];
>>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120):
>>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>>>>> (
>>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>>>>> o
>>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>>>>> s
>>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>>>>> o
>>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>>>>> r
>>>>>> anchName:"URS
>>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>>> ...
>>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): })();
>>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>> out(-2120569120): //#DWR-END#
>>>>>>
>>>>>>
>>>>>> at this point I'm still looking at the breakpoint that has
>>>>>> javascript
>>>>>> caught in the xhr:stateChange function and see that the
>>>>>> req.responseText is of course empty (because its stateChange was
>>>>>> triggered too early) and when I hit Continue the eventual error
>>>>>> "Incomplete reply from server" is thrown.  But a reply was
>>>>>> received
>>>>>> from the server - out of sync with the stateChange being
>>>>>> triggered.
>>>>>>
>>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>>> function
>>>>>> before my java interface completes and returns with the response?
>>>>>> How can I make further sense of this?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>> portlets on a single portal page?
>>>>>>
>>>>>> Mike is right, and I gave you bad advice earlier.  If you put your
>>>>>> breakpoint in validate you can inspect the batch.map and the
>>>>>> replies
>>>>>> that have been received.
>>>>>>
>>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>>> batch
>>>>>>> for you.
>>>>>>> There is no need to debug the Java side; most efficient way to
>>>>>>> see
>>>>>>> what is happening is to load your site in a browser with Firebug,
>>>>>>> Developer Tools or similar, open up engine.js in the script pane,
>>>>>>> search for the "Incomplete" error message and set a JS breakpoint
>>>>>>> there.
>>>>>>>
>>>>>>> Best regards
>>>>>>> Mike
>>>>>>>
>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>
>>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>>> where
>>>>>>> we don't have multiple portlets on a single page (yet) just to
>>>>>>> make
>>>>>>> sure I have the syntax of setting it up correctly before I try it
>>>>>>> in
>>>>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>>>>> corrections with my dojoConfig and require declaration, it
>>>>>>> appears
>>>>>>> to be working.
>>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>>> Thanks.
>>>>>>>
>>>>>>> I've seen it succeed with a couple dwr calls, but on one it
>>>>>>> throws
>>>>>>> the "Incomplete reply from server". Previously with DWR2 it would
>>>>>>> sometimes throw the "No data received from server" error, but now
>>>>>>> it's saying that the reply is incomplete? I've added a breakpoint
>>>>>>> to
>>>>>>> my java side interface and no exception is thrown from there. I
>>>>>>> see
>>>>>>> that the javascript error is happening during the middle of the
>>>>>>> server side call from my java interface. I see also that the
>>>>>>> engine.js explains that the "Incomplete reply from server" is
>>>>>>> thrown
>>>>>>> when it doesn't receive all the responses that were sent during a
>>>>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>>>>> downloaded the DWR3 source code so I can try to debug what is
>>>>>>> causing this. Where in the source code should I place a
>>>>>>> breakpoint
>>>>>>> for this "Incomplete reply from server" javascript response?
>>>>>>>
>>>>>>> Thanks for your help.
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>>> TO: [hidden email]
>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> I'm reading that additional link and it is useful. Thanks. I'll
>>>>>>> be
>>>>>>> implementing this preferred technique in both the AMD and pre-AMD
>>>>>>> Dojo implementations we have. Looking forward to it going
>>>>>>> smoothly
>>>>>>> and being clean. Will report my results when it's ready. Thanks
>>>>>>> again.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>>> TO: [hidden email]
>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> I hear that you understood this perfectly. Key is not to pollute
>>>>>>> the
>>>>>>> global namespace and instead let the AMD module loader map these
>>>>>>> "anonymous" modules to each other through local variables
>>>>>>> (function
>>>>>>> parameters). Then each DWR instance will work in isolation in the
>>>>>>> browser and will not interfere with the others.
>>>>>>>
>>>>>>> You still need to ensure that script paths published by the
>>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>>
>>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>>> set
>>>>>>> things up in Liferay:
>>>>>>>
>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>> n
>>>>>>> -
>>>>>>> addScript-tp6334142p6466106.html
>>>>>>> [1]
>>>>>>>
>>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>
>>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>>> implementation looks promising for our project. Our project has
>>>>>>> three separate parts, each contained in their own virtual portal,
>>>>>>> and when we recently started the third part I updated from our
>>>>>>> older
>>>>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so should
>>>>>>> be
>>>>>>> able to apply the DWR AMD solution in our project's third part.
>>>>>>> The
>>>>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>>>>> option for integrating DWR like your link describes. I'll
>>>>>>> investigate these new options and see if it solves our problem.
>>>>>>> From
>>>>>>> what I read from that link so far, I would be able to have each
>>>>>>> portlet safely include its own proper engine.js along with the
>>>>>>> interfaces it needs and not have to implement the work-around of
>>>>>>> extracting out a single engine.js that is shared by multiple
>>>>>>> portlets. That will be great if that's true and if I can get it
>>>>>>> to work as intended.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>>> TO: [hidden email]
>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> While I don't have any portlet example to prove this point,
>>>>>>> historically portlet problems have usually revolved around
>>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>>> ignore the following advice.
>>>>>>>
>>>>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>>>>> times with different configuration and dwr.xml in the same
>>>>>>> webapp.
>>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>>
>>>>>>> DWR's js-files can then be consumed in a couple of different
>>>>>>> ways.
>>>>>>> You can use the standard <script> include but this is limited to
>>>>>>> connecting to one DWR servlet as it defines objects in the global
>>>>>>> js
>>>>>>> namespace that will collide if another engine.js is included this
>>>>>>> way.
>>>>>>>
>>>>>>>
>>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>>> similar)
>>>>>>> there are no global objects defined in JS so you can include any
>>>>>>> number of DWR servlets' scripts in the same page. You can read up
>>>>>>> on
>>>>>>> DWR's AMD integration here:
>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>>
>>>>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>>>>> workaround is not working in DWR3, but I think you should be able
>>>>>>> to
>>>>>>> get things working by using official DWR3 functionality and not
>>>>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Is there anyone out there that has successfully configured their
>>>>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple
>>>>>>> portlets
>>>>>>> on a single portal page?? We're using WebSphere and our home page
>>>>>>> has over seven portlets. Up until now we have been using DWR2.0.5
>>>>>>> and extracted the served engine.js file to a common location for
>>>>>>> all
>>>>>>> portlets to share so that each portlet would not try to include
>>>>>>> its
>>>>>>> own engine.js. Including multiple engine.js files won't work.
>>>>>>> That
>>>>>>> had been working to the extent that each portlet was able to make
>>>>>>> DWR calls independent of the other portlets and the calls
>>>>>>> generally
>>>>>>> succeeded in completing successfully.
>>>>>>>
>>>>>>> We're upgrading to DWR3 and I have been struggling to get the
>>>>>>> same
>>>>>>> configuration to work. Do I need to go back to DWR2 or is there
>>>>>>> any
>>>>>>> evidence - any example of someone else already successfully using
>>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>>
>>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet,
>>>>>>> but
>>>>>>> only DWR2 works with multiple portlets. I've been experimenting
>>>>>>> and
>>>>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>>>>> roadblock after another. Is it possible? Is there any example of
>>>>>>> this scenario out there for me to review? DWR3 in multiple
>>>>>>> portlets
>>>>>>> on a single portal page. Each portlet has its own dwr.xml with
>>>>>>> its
>>>>>>> own set of interfaces. Each portlet makes service calls using DWR
>>>>>>> to
>>>>>>> populate its content and does so without worrying about other
>>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>>> this possible?
>>>>>>> Is there a single example to verify that this scenario can work?
>>>>>>>
>>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>>
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Links:
>>>>>>> ------
>>>>>>> [1]
>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>> n
>>>>>>> -
>>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
In reply to this post by david@butterdev.com
I did a bit of initial research and it appears the XHR object is
designed to operate in a global scope.  This is the likely issue.  If
you want to look at some of the other things I suggested it may be worth
a bit of time, just in case.  Mike and I need to talk to see if we can
work-around this for a portal environment.

On 2015-09-25 14:00, [hidden email] wrote:

> With the new AMD set-up that Mike recommended you have engine.js
> defined in each portlet, correct?  Do you still have engine.js fined
> at the portal level?  If so, make sure you remove it.  Make sure you
> have a clean set-up with engine.js defined only in the portlets.
>
> I would have to dig into this a bit deeper but it is possible that we
> have a scope issue with XHR (stateChange ), and that it is picking up
> other portlets.  But before we dig deeper, please answer my other
> questions as they could also be the cause.
>
> On 2015-09-25 13:38, [hidden email] wrote:
>> If you notice at the bottom of stateChange there is a call to
>> dwr.engine._executeScript(toEval).  This will call the callback and
>> complete the batch (among other things).  For some reason your
>> callback is not executing and the batch is not being completed.  If
>> you have a callback specified I would check it for errors.
>>
>> On 2015-09-25 13:31, [hidden email] wrote:
>>> Do you always see this for the same remote call and does it happen
>>> everytime?  Do you have a callback specified?
>>>
>>> On 2015-09-25 13:28, [hidden email] wrote:
>>>> That's helpful.  Per my last email, what is in batch.map?  Is it the
>>>> method you expected to see?  How often does this happen?  Does it
>>>> happen in all browsers?  When it happens are you the only one using
>>>> the portal (on a local machine)?
>>>>
>>>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>>>> Forgot to point out that the final condition before the error was
>>>>> handled was true because the repliesReceived was 0 and the
>>>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>>>> some
>>>>> values that did not let it break out  - but let it go as far as
>>>>> handling this error.
>>>>>
>>>>> Thanks,
>>>>> Gregor Okorn,
>>>>> Leidos, [hidden email], cell 571-247-5490
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 14:20 PM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> Appreciate the clarification.   I do see that the first call made
>>>>> when
>>>>> I open the page is the _System.generateId, which doesn't get called
>>>>> again until I refresh the page.  And I see that it retrieves the
>>>>> DWRSESSIONID value that is then used in all subsequent calls.  I
>>>>> also
>>>>> see that the stateChange function handles multiple status values
>>>>> and
>>>>> can break out without error in depending on the state.
>>>>>
>>>>> I've added a breakpoint where you suggested and am examining the
>>>>> repliesReceived, batch.map, and other fields but am unsure what to
>>>>> make of the fact that the stateChange is getting called before my
>>>>> interface method returns.  This is happening well after the initial
>>>>> startup phase, long after the generateId call is made and received.
>>>>> It happens during any random occurrence of our interface calls.  
>>>>> You
>>>>> mentioned that these subsequent calls are made through the send2
>>>>> function but when the breakpoint is hit for this "Incomplete reply
>>>>> from server" the Firebug stacktrace shows:
>>>>>
>>>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>>>> type="object"})engine.js (line 1568)
>>>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>>>> type="object"})engine.js (line 1796)
>>>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.js
>>>>> (line 1664)
>>>>>
>>>>> where the earliest (last in list) call is rooted in the send
>>>>> function,
>>>>> not the send2 function.  Is that expected?
>>>>>
>>>>> Here's Firebug's display of the Function closure's variables and
>>>>> values where the breakpoint hit:
>>>>>
>>>>> batch Object { async={...},  charsProcessed={...},  handlers={...},
>>>>>  more...}
>>>>>    async  true
>>>>>    charsProcessed 0
>>>>>    handlers [Object { callbackScope=Window,  
>>>>> exceptionScope=Window,
>>>>> callback=function(),  more...}]
>>>>>    isPoll false
>>>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>>>    paramCount 169
>>>>>    preHooks null
>>>>>    postHooks []
>>>>>    timeout 0
>>>>>    errorHandler null
>>>>>    globalErrorHandler Object {
>>>>> compassErrorHandler=compassErrorHandler(),  
>>>>> showDetails=showDetails(),
>>>>>  showErrorsDialog=showErrorsDialog()}
>>>>>    warningHandler function(warnString, exObj)
>>>>>    textHtmlHandler null
>>>>>    globalTextHtmlHandler null
>>>>>    headers Object {}
>>>>>    attributes Object {}
>>>>>    path "/UrsRegistrationWizard/dwr"
>>>>>    completed false
>>>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>>>> send=function(),  more...}
>>>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>>>> withCredentials=false,  more...}
>>>>>    mode "/call/plaincall/"
>>>>> arguments Object { type="object"}
>>>>> repliesReceived 0
>>>>> i 1
>>>>>
>>>>> That stateChange function should only get called when the browser
>>>>> has
>>>>> detected a change in the XmlHttpRequest  -  right?  If my interface
>>>>> method hasn't yet explicitly returned or thrown an exception, then
>>>>> how
>>>>> can the stateChange callback get triggered prematurely?  I'm trying
>>>>> to
>>>>> find a clue in by examining the fields at the breakpoint and parent
>>>>> execution chain, but I don't know what I'm missing.
>>>>>
>>>>> Thanks again,
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 9:11 AM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> Let me rephrase that, each time a call is initiated
>>>>> (YourDWRInterface.method()) send is called.  The first time send is
>>>>> called per page DWR makes an additional call to the server to
>>>>> retrieve
>>>>> the dwr session id.  All subsequent calls delegate to send2.  It is
>>>>> normal to see stateChange called several times.  If you place a
>>>>> breakpoint lower down in stateChange you will see we break out of
>>>>> it
>>>>> under certain status conditions.  Per your original email it is
>>>>> likely
>>>>> that the first time stateChange is called the status is 0, and we
>>>>> are
>>>>> breaking out of it.  If you want to debug the incomplete reply
>>>>> error,
>>>>> I would start at the source of it:
>>>>>
>>>>> Line 2438:
>>>>> } else if (repliesReceived < batch.map.callCount) {
>>>>>      dwr.engine._handleError(batch, {
>>>>> name:"dwr.engine.incompleteReply",
>>>>> message:"Incomplete reply from server" }); }
>>>>>
>>>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>>>
>>>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>>>> point
>>>>>> does DWR make that call to your DwrServlet server?   I search
>>>>>> through
>>>>>> the engine.js and see four different places where there is a
>>>>>> dwr.engine.transport.send function being called, and three places
>>>>>> where a dwr.engine.transport.send2 function is being called.  
>>>>>> You're
>>>>>> saying that this function is called 1 time before my first call?
>>>>>> What does "my first call" refer to?  The call to my java method
>>>>>> through the interface javascript object?   Is that what you mean?
>>>>>>
>>>>>> Unfortunately the application is not available publicly; that
>>>>>> would be
>>>>>> great if I could have you take a live look at it.  If there's any
>>>>>> particular information that I could share, I'd be happy to try
>>>>>> through
>>>>>> here.
>>>>>>
>>>>>> Thanks for your help,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>
>>>>>> DWR makes a 1 time call to the server (engine.js -
>>>>>> dwr.engine.transport.send) before you first call.  Is your
>>>>>> application
>>>>>> available publicly for us to take a look?
>>>>>>
>>>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>>>> interesting behavior.   I added a breakpoint in the
>>>>>>> xhr:stateChange
>>>>>>> function and see that it is triggered BEFORE my service gets its
>>>>>>> response from our server.  How is that possible?   As I look at
>>>>>>> that
>>>>>>> breakpoint I see from the WebSphere log file that I'm tailing,
>>>>>>> that
>>>>>>> the response eventually comes back from the server and I see that
>>>>>>> the
>>>>>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL"
>>>>>>> in
>>>>>>> our web.xml) show that the response is received
>>>>>>>
>>>>>>>
>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-INSERT
>>>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-REPLY
>>>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-START#
>>>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): (function(){
>>>>>>> if(!window.dwr)return;
>>>>>>> var dwr=window.dwr._[0];
>>>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120):
>>>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>>>>>> (
>>>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>>>>>> o
>>>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>>>>>> s
>>>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>>>>>> o
>>>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>>>>>> r
>>>>>>> anchName:"URS
>>>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>>>> ...
>>>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): })();
>>>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-END#
>>>>>>>
>>>>>>>
>>>>>>> at this point I'm still looking at the breakpoint that has
>>>>>>> javascript
>>>>>>> caught in the xhr:stateChange function and see that the
>>>>>>> req.responseText is of course empty (because its stateChange was
>>>>>>> triggered too early) and when I hit Continue the eventual error
>>>>>>> "Incomplete reply from server" is thrown.  But a reply was
>>>>>>> received
>>>>>>> from the server - out of sync with the stateChange being
>>>>>>> triggered.
>>>>>>>
>>>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>>>> function
>>>>>>> before my java interface completes and returns with the response?
>>>>>>> How can I make further sense of this?
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>>>> To: [hidden email]
>>>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> Mike is right, and I gave you bad advice earlier.  If you put
>>>>>>> your
>>>>>>> breakpoint in validate you can inspect the batch.map and the
>>>>>>> replies
>>>>>>> that have been received.
>>>>>>>
>>>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>>>> batch
>>>>>>>> for you.
>>>>>>>> There is no need to debug the Java side; most efficient way to
>>>>>>>> see
>>>>>>>> what is happening is to load your site in a browser with
>>>>>>>> Firebug,
>>>>>>>> Developer Tools or similar, open up engine.js in the script
>>>>>>>> pane,
>>>>>>>> search for the "Incomplete" error message and set a JS
>>>>>>>> breakpoint
>>>>>>>> there.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>>>> where
>>>>>>>> we don't have multiple portlets on a single page (yet) just to
>>>>>>>> make
>>>>>>>> sure I have the syntax of setting it up correctly before I try
>>>>>>>> it in
>>>>>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>>>>>> corrections with my dojoConfig and require declaration, it
>>>>>>>> appears
>>>>>>>> to be working.
>>>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> I've seen it succeed with a couple dwr calls, but on one it
>>>>>>>> throws
>>>>>>>> the "Incomplete reply from server". Previously with DWR2 it
>>>>>>>> would
>>>>>>>> sometimes throw the "No data received from server" error, but
>>>>>>>> now
>>>>>>>> it's saying that the reply is incomplete? I've added a
>>>>>>>> breakpoint to
>>>>>>>> my java side interface and no exception is thrown from there. I
>>>>>>>> see
>>>>>>>> that the javascript error is happening during the middle of the
>>>>>>>> server side call from my java interface. I see also that the
>>>>>>>> engine.js explains that the "Incomplete reply from server" is
>>>>>>>> thrown
>>>>>>>> when it doesn't receive all the responses that were sent during
>>>>>>>> a
>>>>>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>>>>>> downloaded the DWR3 source code so I can try to debug what is
>>>>>>>> causing this. Where in the source code should I place a
>>>>>>>> breakpoint
>>>>>>>> for this "Incomplete reply from server" javascript response?
>>>>>>>>
>>>>>>>> Thanks for your help.
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> I'm reading that additional link and it is useful. Thanks. I'll
>>>>>>>> be
>>>>>>>> implementing this preferred technique in both the AMD and
>>>>>>>> pre-AMD
>>>>>>>> Dojo implementations we have. Looking forward to it going
>>>>>>>> smoothly
>>>>>>>> and being clean. Will report my results when it's ready. Thanks
>>>>>>>> again.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> I hear that you understood this perfectly. Key is not to pollute
>>>>>>>> the
>>>>>>>> global namespace and instead let the AMD module loader map these
>>>>>>>> "anonymous" modules to each other through local variables
>>>>>>>> (function
>>>>>>>> parameters). Then each DWR instance will work in isolation in
>>>>>>>> the
>>>>>>>> browser and will not interfere with the others.
>>>>>>>>
>>>>>>>> You still need to ensure that script paths published by the
>>>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>>>
>>>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>>>> set
>>>>>>>> things up in Liferay:
>>>>>>>>
>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>>> n
>>>>>>>> -
>>>>>>>> addScript-tp6334142p6466106.html
>>>>>>>> [1]
>>>>>>>>
>>>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>>>> implementation looks promising for our project. Our project has
>>>>>>>> three separate parts, each contained in their own virtual
>>>>>>>> portal,
>>>>>>>> and when we recently started the third part I updated from our
>>>>>>>> older
>>>>>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so
>>>>>>>> should be
>>>>>>>> able to apply the DWR AMD solution in our project's third part.
>>>>>>>> The
>>>>>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>>>>>> option for integrating DWR like your link describes. I'll
>>>>>>>> investigate these new options and see if it solves our problem.
>>>>>>>> From
>>>>>>>> what I read from that link so far, I would be able to have each
>>>>>>>> portlet safely include its own proper engine.js along with the
>>>>>>>> interfaces it needs and not have to implement the work-around of
>>>>>>>> extracting out a single engine.js that is shared by multiple
>>>>>>>> portlets. That will be great if that's true and if I can get it
>>>>>>>> to work as intended.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> While I don't have any portlet example to prove this point,
>>>>>>>> historically portlet problems have usually revolved around
>>>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>>>> ignore the following advice.
>>>>>>>>
>>>>>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>>>>>> times with different configuration and dwr.xml in the same
>>>>>>>> webapp.
>>>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>>>
>>>>>>>> DWR's js-files can then be consumed in a couple of different
>>>>>>>> ways.
>>>>>>>> You can use the standard <script> include but this is limited to
>>>>>>>> connecting to one DWR servlet as it defines objects in the
>>>>>>>> global js
>>>>>>>> namespace that will collide if another engine.js is included
>>>>>>>> this
>>>>>>>> way.
>>>>>>>>
>>>>>>>>
>>>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>>>> similar)
>>>>>>>> there are no global objects defined in JS so you can include any
>>>>>>>> number of DWR servlets' scripts in the same page. You can read
>>>>>>>> up on
>>>>>>>> DWR's AMD integration here:
>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>>>
>>>>>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>>>>>> workaround is not working in DWR3, but I think you should be
>>>>>>>> able to
>>>>>>>> get things working by using official DWR3 functionality and not
>>>>>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Is there anyone out there that has successfully configured their
>>>>>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple
>>>>>>>> portlets
>>>>>>>> on a single portal page?? We're using WebSphere and our home
>>>>>>>> page
>>>>>>>> has over seven portlets. Up until now we have been using
>>>>>>>> DWR2.0.5
>>>>>>>> and extracted the served engine.js file to a common location for
>>>>>>>> all
>>>>>>>> portlets to share so that each portlet would not try to include
>>>>>>>> its
>>>>>>>> own engine.js. Including multiple engine.js files won't work.
>>>>>>>> That
>>>>>>>> had been working to the extent that each portlet was able to
>>>>>>>> make
>>>>>>>> DWR calls independent of the other portlets and the calls
>>>>>>>> generally
>>>>>>>> succeeded in completing successfully.
>>>>>>>>
>>>>>>>> We're upgrading to DWR3 and I have been struggling to get the
>>>>>>>> same
>>>>>>>> configuration to work. Do I need to go back to DWR2 or is there
>>>>>>>> any
>>>>>>>> evidence - any example of someone else already successfully
>>>>>>>> using
>>>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>>>
>>>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet,
>>>>>>>> but
>>>>>>>> only DWR2 works with multiple portlets. I've been experimenting
>>>>>>>> and
>>>>>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>>>>>> roadblock after another. Is it possible? Is there any example of
>>>>>>>> this scenario out there for me to review? DWR3 in multiple
>>>>>>>> portlets
>>>>>>>> on a single portal page. Each portlet has its own dwr.xml with
>>>>>>>> its
>>>>>>>> own set of interfaces. Each portlet makes service calls using
>>>>>>>> DWR to
>>>>>>>> populate its content and does so without worrying about other
>>>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>>>> this possible?
>>>>>>>> Is there a single example to verify that this scenario can work?
>>>>>>>>
>>>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Links:
>>>>>>>> ------
>>>>>>>> [1]
>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>>> n
>>>>>>>> -
>>>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
In reply to this post by gregorcok
"I've implemented the update to DWR3 and AMD loading, but this app is
not a portlet.  This is a standalone web app that I'm testing DWR3 with
AMD on first - before I attempt to update our portlets with it.  There
is just the one engine.js being loaded."

That is truly bizarre that you are seeing the incomplete reply error in
a stand-alone web-page.  At least in the portal environment it made a
bit of sense.  In one of my previous emails I gave you enough
information to track this down.  To re-iterate - at the bottom of
stateChange we call dwr.engine._executeScript(toEval).  This will
execute the script being returned from the server which should lead to a
call of dwr.engine.remote.handleCallback.  The handleCallback call is
critical because it marks the completion of the batch.  Narrow down your
break-points to handleCallback and examing the toEval that is passed to
_executeScript.

On 2015-09-25 14:16, Okorn, Gregor C. wrote:

> Thanks for the response and questions.  The batch.map shows the method
> I'm expecting to see.  It doesn't always happen on the same remote
> call.  It has happened on various calls at random times.  All of our
> remote calls do have callbacks awaiting a response.  I'm testing this
> on my local development machine.   I'm currently unable to open the
> page with Chrome; and with IE I'm unable to get it to stop asking me
> if I'm wanting to leave the page or stay on the page.  We do have the
> app configured to prompt the user if he tries to navigate away from
> the page by closing the browser or hitting the refresh or back button;
> we're using the browser's built-in mechanism, and when I try to open
> the page with IE it constantly prompts me for that answer.   So - I've
> been unable to test this behavior on my local machine with anything
> other than Firefox.  On our shared development server however, which
> is still using DWR2, we are still seeing the similar error "No data
> received from server" with the same amount of randomness from all
> browsers.
>
> I've implemented the update to DWR3 and AMD loading, but this app is
> not a portlet.  This is a standalone web app that I'm testing DWR3
> with AMD on first - before I attempt to update our portlets with it.
> There is just the one engine.js being loaded.
>
> I think that answers all your questions.  I hope they are helpful in
> offering any clue as to what I could try next to debug this.  Thanks
> again for your help.
>
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 16:01 PM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> With the new AMD set-up that Mike recommended you have engine.js
> defined in each portlet, correct?  Do you still have engine.js fined
> at the portal level?  If so, make sure you remove it.  Make sure you
> have a clean set-up with engine.js defined only in the portlets.
>
> I would have to dig into this a bit deeper but it is possible that we
> have a scope issue with XHR (stateChange ), and that it is picking up
> other portlets.  But before we dig deeper, please answer my other
> questions as they could also be the cause.
>
> On 2015-09-25 13:38, [hidden email] wrote:
>> If you notice at the bottom of stateChange there is a call to
>> dwr.engine._executeScript(toEval).  This will call the callback and
>> complete the batch (among other things).  For some reason your
>> callback is not executing and the batch is not being completed.  If
>> you have a callback specified I would check it for errors.
>>
>> On 2015-09-25 13:31, [hidden email] wrote:
>>> Do you always see this for the same remote call and does it happen
>>> everytime?  Do you have a callback specified?
>>>
>>> On 2015-09-25 13:28, [hidden email] wrote:
>>>> That's helpful.  Per my last email, what is in batch.map?  Is it the
>>>> method you expected to see?  How often does this happen?  Does it
>>>> happen in all browsers?  When it happens are you the only one using
>>>> the portal (on a local machine)?
>>>>
>>>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>>>> Forgot to point out that the final condition before the error was
>>>>> handled was true because the repliesReceived was 0 and the
>>>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>>>> some values that did not let it break out  - but let it go as far
>>>>> as handling this error.
>>>>>
>>>>> Thanks,
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 14:20 PM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> Appreciate the clarification.   I do see that the first call made
>>>>> when
>>>>> I open the page is the _System.generateId, which doesn't get called
>>>>> again until I refresh the page.  And I see that it retrieves the
>>>>> DWRSESSIONID value that is then used in all subsequent calls.  I
>>>>> also see that the stateChange function handles multiple status
>>>>> values and can break out without error in depending on the state.
>>>>>
>>>>> I've added a breakpoint where you suggested and am examining the
>>>>> repliesReceived, batch.map, and other fields but am unsure what to
>>>>> make of the fact that the stateChange is getting called before my
>>>>> interface method returns.  This is happening well after the initial
>>>>> startup phase, long after the generateId call is made and received.
>>>>> It happens during any random occurrence of our interface calls.
>>>>> You mentioned that these subsequent calls are made through the
>>>>> send2 function but when the breakpoint is hit for this "Incomplete
>>>>> reply from server" the Firebug stacktrace shows:
>>>>>
>>>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>>>> type="object"})engine.js (line 1568)
>>>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>>>> type="object"})engine.js (line 1796)
>>>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.
>>>>> js
>>>>> (line 1664)
>>>>>
>>>>> where the earliest (last in list) call is rooted in the send
>>>>> function, not the send2 function.  Is that expected?
>>>>>
>>>>> Here's Firebug's display of the Function closure's variables and
>>>>> values where the breakpoint hit:
>>>>>
>>>>> batch Object { async={...},  charsProcessed={...},  handlers={...},
>>>>> more...}
>>>>>    async  true
>>>>>    charsProcessed 0
>>>>>    handlers [Object { callbackScope=Window,
>>>>> exceptionScope=Window,
>>>>> callback=function(),  more...}]
>>>>>    isPoll false
>>>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>>>    paramCount 169
>>>>>    preHooks null
>>>>>    postHooks []
>>>>>    timeout 0
>>>>>    errorHandler null
>>>>>    globalErrorHandler Object {
>>>>> compassErrorHandler=compassErrorHandler(),
>>>>> showDetails=showDetails(),
>>>>>  showErrorsDialog=showErrorsDialog()}
>>>>>    warningHandler function(warnString, exObj)
>>>>>    textHtmlHandler null
>>>>>    globalTextHtmlHandler null
>>>>>    headers Object {}
>>>>>    attributes Object {}
>>>>>    path "/UrsRegistrationWizard/dwr"
>>>>>    completed false
>>>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>>>> send=function(),  more...}
>>>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>>>> withCredentials=false,  more...}
>>>>>    mode "/call/plaincall/"
>>>>> arguments Object { type="object"}
>>>>> repliesReceived 0
>>>>> i 1
>>>>>
>>>>> That stateChange function should only get called when the browser
>>>>> has detected a change in the XmlHttpRequest  -  right?  If my
>>>>> interface method hasn't yet explicitly returned or thrown an
>>>>> exception, then how can the stateChange callback get triggered
>>>>> prematurely?  I'm trying to find a clue in by examining the fields
>>>>> at the breakpoint and parent execution chain, but I don't know what
>>>>> I'm missing.
>>>>>
>>>>> Thanks again,
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 9:11 AM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> Let me rephrase that, each time a call is initiated
>>>>> (YourDWRInterface.method()) send is called.  The first time send is
>>>>> called per page DWR makes an additional call to the server to
>>>>> retrieve the dwr session id.  All subsequent calls delegate to
>>>>> send2.  It is normal to see stateChange called several times.  If
>>>>> you place a breakpoint lower down in stateChange you will see we
>>>>> break out of it under certain status conditions.  Per your original
>>>>> email it is likely that the first time stateChange is called the
>>>>> status is 0, and we are breaking out of it.  If you want to debug
>>>>> the incomplete reply error, I would start at the source of it:
>>>>>
>>>>> Line 2438:
>>>>> } else if (repliesReceived < batch.map.callCount) {
>>>>>      dwr.engine._handleError(batch, {
>>>>> name:"dwr.engine.incompleteReply",
>>>>> message:"Incomplete reply from server" }); }
>>>>>
>>>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>>>
>>>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>>>> point
>>>>>> does DWR make that call to your DwrServlet server?   I search
>>>>>> through
>>>>>> the engine.js and see four different places where there is a
>>>>>> dwr.engine.transport.send function being called, and three places
>>>>>> where a dwr.engine.transport.send2 function is being called.
>>>>>> You're
>>>>>> saying that this function is called 1 time before my first call?
>>>>>> What does "my first call" refer to?  The call to my java method
>>>>>> through the interface javascript object?   Is that what you mean?
>>>>>>
>>>>>> Unfortunately the application is not available publicly; that
>>>>>> would
>>>>>> be
>>>>>> great if I could have you take a live look at it.  If there's any
>>>>>> particular information that I could share, I'd be happy to try
>>>>>> through
>>>>>> here.
>>>>>>
>>>>>> Thanks for your help,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>
>>>>>> DWR makes a 1 time call to the server (engine.js -
>>>>>> dwr.engine.transport.send) before you first call.  Is your
>>>>>> application
>>>>>> available publicly for us to take a look?
>>>>>>
>>>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>>>> interesting behavior.   I added a breakpoint in the
>>>>>>> xhr:stateChange
>>>>>>> function and see that it is triggered BEFORE my service gets its
>>>>>>> response from our server.  How is that possible?   As I look at
>>>>>>> that
>>>>>>> breakpoint I see from the WebSphere log file that I'm tailing,
>>>>>>> that
>>>>>>> the response eventually comes back from the server and I see that
>>>>>>> the
>>>>>>> DWR debug prints (enabled with the "accessLogLevel" set to "CALL"
>>>>>>> in
>>>>>>> our web.xml) show that the response is received
>>>>>>>
>>>>>>>
>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-INSERT
>>>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-REPLY
>>>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-START#
>>>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): (function(){
>>>>>>> if(!window.dwr)return;
>>>>>>> var dwr=window.dwr._[0];
>>>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120):
>>>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newObject
>>>>>>> (
>>>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"",err
>>>>>>> o
>>>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inprogre
>>>>>>> s
>>>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchAddInf
>>>>>>> o
>>>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:"1",b
>>>>>>> r
>>>>>>> anchName:"URS
>>>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>>>> ...
>>>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): })();
>>>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-END#
>>>>>>>
>>>>>>>
>>>>>>> at this point I'm still looking at the breakpoint that has
>>>>>>> javascript
>>>>>>> caught in the xhr:stateChange function and see that the
>>>>>>> req.responseText is of course empty (because its stateChange was
>>>>>>> triggered too early) and when I hit Continue the eventual error
>>>>>>> "Incomplete reply from server" is thrown.  But a reply was
>>>>>>> received
>>>>>>> from the server - out of sync with the stateChange being
>>>>>>> triggered.
>>>>>>>
>>>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>>>> function
>>>>>>> before my java interface completes and returns with the response?
>>>>>>> How can I make further sense of this?
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>>>> To: [hidden email]
>>>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> Mike is right, and I gave you bad advice earlier.  If you put
>>>>>>> your
>>>>>>> breakpoint in validate you can inspect the batch.map and the
>>>>>>> replies
>>>>>>> that have been received.
>>>>>>>
>>>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>>>> batch
>>>>>>>> for you.
>>>>>>>> There is no need to debug the Java side; most efficient way to
>>>>>>>> see
>>>>>>>> what is happening is to load your site in a browser with
>>>>>>>> Firebug,
>>>>>>>> Developer Tools or similar, open up engine.js in the script
>>>>>>>> pane,
>>>>>>>> search for the "Incomplete" error message and set a JS
>>>>>>>> breakpoint
>>>>>>>> there.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>>>> where
>>>>>>>> we don't have multiple portlets on a single page (yet) just to
>>>>>>>> make
>>>>>>>> sure I have the syntax of setting it up correctly before I try
>>>>>>>> it
>>>>>>>> in
>>>>>>>> our pre-AMD multi-portlet-per-page portal, and after a few
>>>>>>>> corrections with my dojoConfig and require declaration, it
>>>>>>>> appears
>>>>>>>> to be working.
>>>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> I've seen it succeed with a couple dwr calls, but on one it
>>>>>>>> throws
>>>>>>>> the "Incomplete reply from server". Previously with DWR2 it
>>>>>>>> would
>>>>>>>> sometimes throw the "No data received from server" error, but
>>>>>>>> now
>>>>>>>> it's saying that the reply is incomplete? I've added a
>>>>>>>> breakpoint
>>>>>>>> to
>>>>>>>> my java side interface and no exception is thrown from there. I
>>>>>>>> see
>>>>>>>> that the javascript error is happening during the middle of the
>>>>>>>> server side call from my java interface. I see also that the
>>>>>>>> engine.js explains that the "Incomplete reply from server" is
>>>>>>>> thrown
>>>>>>>> when it doesn't receive all the responses that were sent during
>>>>>>>> a
>>>>>>>> batch call - but I don't set up a batch for this dwr call. I've
>>>>>>>> downloaded the DWR3 source code so I can try to debug what is
>>>>>>>> causing this. Where in the source code should I place a
>>>>>>>> breakpoint
>>>>>>>> for this "Incomplete reply from server" javascript response?
>>>>>>>>
>>>>>>>> Thanks for your help.
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> I'm reading that additional link and it is useful. Thanks. I'll
>>>>>>>> be
>>>>>>>> implementing this preferred technique in both the AMD and
>>>>>>>> pre-AMD
>>>>>>>> Dojo implementations we have. Looking forward to it going
>>>>>>>> smoothly
>>>>>>>> and being clean. Will report my results when it's ready. Thanks
>>>>>>>> again.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> I hear that you understood this perfectly. Key is not to pollute
>>>>>>>> the
>>>>>>>> global namespace and instead let the AMD module loader map these
>>>>>>>> "anonymous" modules to each other through local variables
>>>>>>>> (function
>>>>>>>> parameters). Then each DWR instance will work in isolation in
>>>>>>>> the
>>>>>>>> browser and will not interfere with the others.
>>>>>>>>
>>>>>>>> You still need to ensure that script paths published by the
>>>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>>>
>>>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>>>> set
>>>>>>>> things up in Liferay:
>>>>>>>>
>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>>> n
>>>>>>>> -
>>>>>>>> addScript-tp6334142p6466106.html
>>>>>>>> [1]
>>>>>>>>
>>>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>>>> implementation looks promising for our project. Our project has
>>>>>>>> three separate parts, each contained in their own virtual
>>>>>>>> portal,
>>>>>>>> and when we recently started the third part I updated from our
>>>>>>>> older
>>>>>>>> Dojo pre-AMD library to the newer Dojo AMD library, and so
>>>>>>>> should
>>>>>>>> be
>>>>>>>> able to apply the DWR AMD solution in our project's third part.
>>>>>>>> The
>>>>>>>> first two parts might still benefit from the pre-AMD Dojo module
>>>>>>>> option for integrating DWR like your link describes. I'll
>>>>>>>> investigate these new options and see if it solves our problem.
>>>>>>>> From
>>>>>>>> what I read from that link so far, I would be able to have each
>>>>>>>> portlet safely include its own proper engine.js along with the
>>>>>>>> interfaces it needs and not have to implement the work-around of
>>>>>>>> extracting out a single engine.js that is shared by multiple
>>>>>>>> portlets. That will be great if that's true and if I can get it
>>>>>>>> to work as intended.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> While I don't have any portlet example to prove this point,
>>>>>>>> historically portlet problems have usually revolved around
>>>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>>>> ignore the following advice.
>>>>>>>>
>>>>>>>> DWR (2 and 3) supports to have its servlet instantiated multiple
>>>>>>>> times with different configuration and dwr.xml in the same
>>>>>>>> webapp.
>>>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>>>
>>>>>>>> DWR's js-files can then be consumed in a couple of different
>>>>>>>> ways.
>>>>>>>> You can use the standard <script> include but this is limited to
>>>>>>>> connecting to one DWR servlet as it defines objects in the
>>>>>>>> global
>>>>>>>> js
>>>>>>>> namespace that will collide if another engine.js is included
>>>>>>>> this
>>>>>>>> way.
>>>>>>>>
>>>>>>>>
>>>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>>>> similar)
>>>>>>>> there are no global objects defined in JS so you can include any
>>>>>>>> number of DWR servlets' scripts in the same page. You can read
>>>>>>>> up
>>>>>>>> on
>>>>>>>> DWR's AMD integration here:
>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>>>
>>>>>>>> To sum up, I think the problems you are seeing is that your DWR2
>>>>>>>> workaround is not working in DWR3, but I think you should be
>>>>>>>> able
>>>>>>>> to
>>>>>>>> get things working by using official DWR3 functionality and not
>>>>>>>> using hacks or workarounds. But l could certainly be wrong :-)
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Is there anyone out there that has successfully configured their
>>>>>>>> portal (WebSphere, Liferay, etc) to use DWR3 with multiple
>>>>>>>> portlets
>>>>>>>> on a single portal page?? We're using WebSphere and our home
>>>>>>>> page
>>>>>>>> has over seven portlets. Up until now we have been using
>>>>>>>> DWR2.0.5
>>>>>>>> and extracted the served engine.js file to a common location for
>>>>>>>> all
>>>>>>>> portlets to share so that each portlet would not try to include
>>>>>>>> its
>>>>>>>> own engine.js. Including multiple engine.js files won't work.
>>>>>>>> That
>>>>>>>> had been working to the extent that each portlet was able to
>>>>>>>> make
>>>>>>>> DWR calls independent of the other portlets and the calls
>>>>>>>> generally
>>>>>>>> succeeded in completing successfully.
>>>>>>>>
>>>>>>>> We're upgrading to DWR3 and I have been struggling to get the
>>>>>>>> same
>>>>>>>> configuration to work. Do I need to go back to DWR2 or is there
>>>>>>>> any
>>>>>>>> evidence - any example of someone else already successfully
>>>>>>>> using
>>>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>>>
>>>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet,
>>>>>>>> but
>>>>>>>> only DWR2 works with multiple portlets. I've been experimenting
>>>>>>>> and
>>>>>>>> struggling for over two weeks trying to upgrade to DWR3 with one
>>>>>>>> roadblock after another. Is it possible? Is there any example of
>>>>>>>> this scenario out there for me to review? DWR3 in multiple
>>>>>>>> portlets
>>>>>>>> on a single portal page. Each portlet has its own dwr.xml with
>>>>>>>> its
>>>>>>>> own set of interfaces. Each portlet makes service calls using
>>>>>>>> DWR
>>>>>>>> to
>>>>>>>> populate its content and does so without worrying about other
>>>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>>>> this possible?
>>>>>>>> Is there a single example to verify that this scenario can work?
>>>>>>>>
>>>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Links:
>>>>>>>> ------
>>>>>>>> [1]
>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptSessio
>>>>>>>> n
>>>>>>>> -
>>>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok
We do see this same behavior in our portlets too, but applying the update to DWR3 is easier and quicker with our non-portlet app so that's where I'm starting.  

I added a breakpoint at the end of stateChange, at the call to dwr.engine._executeScript(toEval) and after testing for about 10 minutes I've seen twice that it has the "toEval" variable undefined - which then led to the  "Incomplete reply from server" error again.   That's a little bit of progress - I see that when that toEval is undefined then I'll get this "Incomplete reply from server".  When I try to step into that function with Firebug it's not letting me though.  How can that toEval be undefined at that point?

Thanks again for your help,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, September 25, 2015 16:31 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

"I've implemented the update to DWR3 and AMD loading, but this app is not a portlet.  This is a standalone web app that I'm testing DWR3 with AMD on first - before I attempt to update our portlets with it.  There is just the one engine.js being loaded."

That is truly bizarre that you are seeing the incomplete reply error in a stand-alone web-page.  At least in the portal environment it made a bit of sense.  In one of my previous emails I gave you enough information to track this down.  To re-iterate - at the bottom of stateChange we call dwr.engine._executeScript(toEval).  This will execute the script being returned from the server which should lead to a call of dwr.engine.remote.handleCallback.  The handleCallback call is critical because it marks the completion of the batch.  Narrow down your break-points to handleCallback and examing the toEval that is passed to _executeScript.

On 2015-09-25 14:16, Okorn, Gregor C. wrote:

> Thanks for the response and questions.  The batch.map shows the method
> I'm expecting to see.  It doesn't always happen on the same remote
> call.  It has happened on various calls at random times.  All of our
> remote calls do have callbacks awaiting a response.  I'm testing this
> on my local development machine.   I'm currently unable to open the
> page with Chrome; and with IE I'm unable to get it to stop asking me
> if I'm wanting to leave the page or stay on the page.  We do have the
> app configured to prompt the user if he tries to navigate away from
> the page by closing the browser or hitting the refresh or back button;
> we're using the browser's built-in mechanism, and when I try to open
> the page with IE it constantly prompts me for that answer.   So - I've
> been unable to test this behavior on my local machine with anything
> other than Firefox.  On our shared development server however, which
> is still using DWR2, we are still seeing the similar error "No data
> received from server" with the same amount of randomness from all
> browsers.
>
> I've implemented the update to DWR3 and AMD loading, but this app is
> not a portlet.  This is a standalone web app that I'm testing DWR3
> with AMD on first - before I attempt to update our portlets with it.
> There is just the one engine.js being loaded.
>
> I think that answers all your questions.  I hope they are helpful in
> offering any clue as to what I could try next to debug this.  Thanks
> again for your help.
>
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 16:01 PM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> With the new AMD set-up that Mike recommended you have engine.js
> defined in each portlet, correct?  Do you still have engine.js fined
> at the portal level?  If so, make sure you remove it.  Make sure you
> have a clean set-up with engine.js defined only in the portlets.
>
> I would have to dig into this a bit deeper but it is possible that we
> have a scope issue with XHR (stateChange ), and that it is picking up
> other portlets.  But before we dig deeper, please answer my other
> questions as they could also be the cause.
>
> On 2015-09-25 13:38, [hidden email] wrote:
>> If you notice at the bottom of stateChange there is a call to
>> dwr.engine._executeScript(toEval).  This will call the callback and
>> complete the batch (among other things).  For some reason your
>> callback is not executing and the batch is not being completed.  If
>> you have a callback specified I would check it for errors.
>>
>> On 2015-09-25 13:31, [hidden email] wrote:
>>> Do you always see this for the same remote call and does it happen
>>> everytime?  Do you have a callback specified?
>>>
>>> On 2015-09-25 13:28, [hidden email] wrote:
>>>> That's helpful.  Per my last email, what is in batch.map?  Is it
>>>> the method you expected to see?  How often does this happen?  Does
>>>> it happen in all browsers?  When it happens are you the only one
>>>> using the portal (on a local machine)?
>>>>
>>>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>>>> Forgot to point out that the final condition before the error was
>>>>> handled was true because the repliesReceived was 0 and the
>>>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>>>> some values that did not let it break out  - but let it go as far
>>>>> as handling this error.
>>>>>
>>>>> Thanks,
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 14:20 PM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> Appreciate the clarification.   I do see that the first call made
>>>>> when
>>>>> I open the page is the _System.generateId, which doesn't get
>>>>> called again until I refresh the page.  And I see that it
>>>>> retrieves the DWRSESSIONID value that is then used in all
>>>>> subsequent calls.  I also see that the stateChange function
>>>>> handles multiple status values and can break out without error in depending on the state.
>>>>>
>>>>> I've added a breakpoint where you suggested and am examining the
>>>>> repliesReceived, batch.map, and other fields but am unsure what to
>>>>> make of the fact that the stateChange is getting called before my
>>>>> interface method returns.  This is happening well after the
>>>>> initial startup phase, long after the generateId call is made and received.
>>>>> It happens during any random occurrence of our interface calls.
>>>>> You mentioned that these subsequent calls are made through the
>>>>> send2 function but when the breakpoint is hit for this "Incomplete
>>>>> reply from server" the Firebug stacktrace shows:
>>>>>
>>>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>>>> type="object"})engine.js (line 1568)
>>>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>>>> type="object"})engine.js (line 1796)
>>>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.
>>>>> js
>>>>> (line 1664)
>>>>>
>>>>> where the earliest (last in list) call is rooted in the send
>>>>> function, not the send2 function.  Is that expected?
>>>>>
>>>>> Here's Firebug's display of the Function closure's variables and
>>>>> values where the breakpoint hit:
>>>>>
>>>>> batch Object { async={...},  charsProcessed={...},  handlers={...},
>>>>> more...}
>>>>>    async  true
>>>>>    charsProcessed 0
>>>>>    handlers [Object { callbackScope=Window,
>>>>> exceptionScope=Window,
>>>>> callback=function(),  more...}]
>>>>>    isPoll false
>>>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>>>    paramCount 169
>>>>>    preHooks null
>>>>>    postHooks []
>>>>>    timeout 0
>>>>>    errorHandler null
>>>>>    globalErrorHandler Object {
>>>>> compassErrorHandler=compassErrorHandler(),
>>>>> showDetails=showDetails(),
>>>>>  showErrorsDialog=showErrorsDialog()}
>>>>>    warningHandler function(warnString, exObj)
>>>>>    textHtmlHandler null
>>>>>    globalTextHtmlHandler null
>>>>>    headers Object {}
>>>>>    attributes Object {}
>>>>>    path "/UrsRegistrationWizard/dwr"
>>>>>    completed false
>>>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>>>> send=function(),  more...}
>>>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>>>> withCredentials=false,  more...}
>>>>>    mode "/call/plaincall/"
>>>>> arguments Object { type="object"}
>>>>> repliesReceived 0
>>>>> i 1
>>>>>
>>>>> That stateChange function should only get called when the browser
>>>>> has detected a change in the XmlHttpRequest  -  right?  If my
>>>>> interface method hasn't yet explicitly returned or thrown an
>>>>> exception, then how can the stateChange callback get triggered
>>>>> prematurely?  I'm trying to find a clue in by examining the fields
>>>>> at the breakpoint and parent execution chain, but I don't know
>>>>> what I'm missing.
>>>>>
>>>>> Thanks again,
>>>>> Gregor Okorn,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>> Sent: Friday, September 25, 2015 9:11 AM
>>>>> To: [hidden email]
>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>
>>>>> Let me rephrase that, each time a call is initiated
>>>>> (YourDWRInterface.method()) send is called.  The first time send
>>>>> is called per page DWR makes an additional call to the server to
>>>>> retrieve the dwr session id.  All subsequent calls delegate to
>>>>> send2.  It is normal to see stateChange called several times.  If
>>>>> you place a breakpoint lower down in stateChange you will see we
>>>>> break out of it under certain status conditions.  Per your
>>>>> original email it is likely that the first time stateChange is
>>>>> called the status is 0, and we are breaking out of it.  If you
>>>>> want to debug the incomplete reply error, I would start at the source of it:
>>>>>
>>>>> Line 2438:
>>>>> } else if (repliesReceived < batch.map.callCount) {
>>>>>      dwr.engine._handleError(batch, {
>>>>> name:"dwr.engine.incompleteReply",
>>>>> message:"Incomplete reply from server" }); }
>>>>>
>>>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>>>
>>>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>>>> point
>>>>>> does DWR make that call to your DwrServlet server?   I search
>>>>>> through
>>>>>> the engine.js and see four different places where there is a
>>>>>> dwr.engine.transport.send function being called, and three places
>>>>>> where a dwr.engine.transport.send2 function is being called.
>>>>>> You're
>>>>>> saying that this function is called 1 time before my first call?
>>>>>> What does "my first call" refer to?  The call to my java method
>>>>>> through the interface javascript object?   Is that what you mean?
>>>>>>
>>>>>> Unfortunately the application is not available publicly; that
>>>>>> would be great if I could have you take a live look at it.  If
>>>>>> there's any particular information that I could share, I'd be
>>>>>> happy to try through here.
>>>>>>
>>>>>> Thanks for your help,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>
>>>>>> DWR makes a 1 time call to the server (engine.js -
>>>>>> dwr.engine.transport.send) before you first call.  Is your
>>>>>> application available publicly for us to take a look?
>>>>>>
>>>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>>>> interesting behavior.   I added a breakpoint in the
>>>>>>> xhr:stateChange
>>>>>>> function and see that it is triggered BEFORE my service gets its
>>>>>>> response from our server.  How is that possible?   As I look at
>>>>>>> that
>>>>>>> breakpoint I see from the WebSphere log file that I'm tailing,
>>>>>>> that the response eventually comes back from the server and I
>>>>>>> see that the DWR debug prints (enabled with the "accessLogLevel"
>>>>>>> set to "CALL"
>>>>>>> in
>>>>>>> our web.xml) show that the response is received
>>>>>>>
>>>>>>>
>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-INSERT
>>>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-REPLY
>>>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-START#
>>>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): (function(){
>>>>>>> if(!window.dwr)return;
>>>>>>> var dwr=window.dwr._[0];
>>>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120):
>>>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newO
>>>>>>> bject
>>>>>>> (
>>>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"
>>>>>>> ",err
>>>>>>> o
>>>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inp
>>>>>>> rogre
>>>>>>> s
>>>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchA
>>>>>>> ddInf
>>>>>>> o
>>>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:
>>>>>>> "1",b
>>>>>>> r
>>>>>>> anchName:"URS
>>>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>>>> ...
>>>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): })();
>>>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>> out(-2120569120): //#DWR-END#
>>>>>>>
>>>>>>>
>>>>>>> at this point I'm still looking at the breakpoint that has
>>>>>>> javascript caught in the xhr:stateChange function and see that
>>>>>>> the req.responseText is of course empty (because its stateChange
>>>>>>> was triggered too early) and when I hit Continue the eventual
>>>>>>> error "Incomplete reply from server" is thrown.  But a reply was
>>>>>>> received from the server - out of sync with the stateChange
>>>>>>> being triggered.
>>>>>>>
>>>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>>>> function before my java interface completes and returns with the
>>>>>>> response?
>>>>>>> How can I make further sense of this?
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>>>> To: [hidden email]
>>>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>> portlets on a single portal page?
>>>>>>>
>>>>>>> Mike is right, and I gave you bad advice earlier.  If you put
>>>>>>> your breakpoint in validate you can inspect the batch.map and
>>>>>>> the replies that have been received.
>>>>>>>
>>>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>>>> batch for you.
>>>>>>>> There is no need to debug the Java side; most efficient way to
>>>>>>>> see what is happening is to load your site in a browser with
>>>>>>>> Firebug, Developer Tools or similar, open up engine.js in the
>>>>>>>> script pane, search for the "Incomplete" error message and set
>>>>>>>> a JS breakpoint there.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>>>> where we don't have multiple portlets on a single page (yet)
>>>>>>>> just to make sure I have the syntax of setting it up correctly
>>>>>>>> before I try it in our pre-AMD multi-portlet-per-page portal,
>>>>>>>> and after a few corrections with my dojoConfig and require
>>>>>>>> declaration, it appears to be working.
>>>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> I've seen it succeed with a couple dwr calls, but on one it
>>>>>>>> throws the "Incomplete reply from server". Previously with DWR2
>>>>>>>> it would sometimes throw the "No data received from server"
>>>>>>>> error, but now it's saying that the reply is incomplete? I've
>>>>>>>> added a breakpoint to my java side interface and no exception
>>>>>>>> is thrown from there. I see that the javascript error is
>>>>>>>> happening during the middle of the server side call from my
>>>>>>>> java interface. I see also that the engine.js explains that the
>>>>>>>> "Incomplete reply from server" is thrown when it doesn't
>>>>>>>> receive all the responses that were sent during a batch call -
>>>>>>>> but I don't set up a batch for this dwr call. I've downloaded
>>>>>>>> the DWR3 source code so I can try to debug what is causing
>>>>>>>> this. Where in the source code should I place a breakpoint for
>>>>>>>> this "Incomplete reply from server" javascript response?
>>>>>>>>
>>>>>>>> Thanks for your help.
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> I'm reading that additional link and it is useful. Thanks. I'll
>>>>>>>> be implementing this preferred technique in both the AMD and
>>>>>>>> pre-AMD Dojo implementations we have. Looking forward to it
>>>>>>>> going smoothly and being clean. Will report my results when
>>>>>>>> it's ready. Thanks again.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> I hear that you understood this perfectly. Key is not to
>>>>>>>> pollute the global namespace and instead let the AMD module
>>>>>>>> loader map these "anonymous" modules to each other through
>>>>>>>> local variables (function parameters). Then each DWR instance
>>>>>>>> will work in isolation in the browser and will not interfere
>>>>>>>> with the others.
>>>>>>>>
>>>>>>>> You still need to ensure that script paths published by the
>>>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>>>
>>>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>>>> set things up in Liferay:
>>>>>>>>
>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
>>>>>>>> essio
>>>>>>>> n
>>>>>>>> -
>>>>>>>> addScript-tp6334142p6466106.html [1]
>>>>>>>>
>>>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>>>> implementation looks promising for our project. Our project has
>>>>>>>> three separate parts, each contained in their own virtual
>>>>>>>> portal, and when we recently started the third part I updated
>>>>>>>> from our older Dojo pre-AMD library to the newer Dojo AMD
>>>>>>>> library, and so should be able to apply the DWR AMD solution in
>>>>>>>> our project's third part.
>>>>>>>> The
>>>>>>>> first two parts might still benefit from the pre-AMD Dojo
>>>>>>>> module option for integrating DWR like your link describes.
>>>>>>>> I'll investigate these new options and see if it solves our problem.
>>>>>>>> From
>>>>>>>> what I read from that link so far, I would be able to have each
>>>>>>>> portlet safely include its own proper engine.js along with the
>>>>>>>> interfaces it needs and not have to implement the work-around
>>>>>>>> of extracting out a single engine.js that is shared by multiple
>>>>>>>> portlets. That will be great if that's true and if I can get it
>>>>>>>> to work as intended.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>>>> TO: [hidden email]
>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> While I don't have any portlet example to prove this point,
>>>>>>>> historically portlet problems have usually revolved around
>>>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>>>> ignore the following advice.
>>>>>>>>
>>>>>>>> DWR (2 and 3) supports to have its servlet instantiated
>>>>>>>> multiple times with different configuration and dwr.xml in the
>>>>>>>> same webapp.
>>>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>>>
>>>>>>>> DWR's js-files can then be consumed in a couple of different
>>>>>>>> ways.
>>>>>>>> You can use the standard <script> include but this is limited
>>>>>>>> to connecting to one DWR servlet as it defines objects in the
>>>>>>>> global js namespace that will collide if another engine.js is
>>>>>>>> included this way.
>>>>>>>>
>>>>>>>>
>>>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>>>> similar)
>>>>>>>> there are no global objects defined in JS so you can include
>>>>>>>> any number of DWR servlets' scripts in the same page. You can
>>>>>>>> read up on DWR's AMD integration here:
>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>>>
>>>>>>>> To sum up, I think the problems you are seeing is that your
>>>>>>>> DWR2 workaround is not working in DWR3, but I think you should
>>>>>>>> be able to get things working by using official DWR3
>>>>>>>> functionality and not using hacks or workarounds. But l could
>>>>>>>> certainly be wrong :-)
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Is there anyone out there that has successfully configured
>>>>>>>> their portal (WebSphere, Liferay, etc) to use DWR3 with
>>>>>>>> multiple portlets on a single portal page?? We're using
>>>>>>>> WebSphere and our home page has over seven portlets. Up until
>>>>>>>> now we have been using
>>>>>>>> DWR2.0.5
>>>>>>>> and extracted the served engine.js file to a common location
>>>>>>>> for all portlets to share so that each portlet would not try to
>>>>>>>> include its own engine.js. Including multiple engine.js files
>>>>>>>> won't work.
>>>>>>>> That
>>>>>>>> had been working to the extent that each portlet was able to
>>>>>>>> make DWR calls independent of the other portlets and the calls
>>>>>>>> generally succeeded in completing successfully.
>>>>>>>>
>>>>>>>> We're upgrading to DWR3 and I have been struggling to get the
>>>>>>>> same configuration to work. Do I need to go back to DWR2 or is
>>>>>>>> there any evidence - any example of someone else already
>>>>>>>> successfully using
>>>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>>>
>>>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet,
>>>>>>>> but only DWR2 works with multiple portlets. I've been
>>>>>>>> experimenting and struggling for over two weeks trying to
>>>>>>>> upgrade to DWR3 with one roadblock after another. Is it
>>>>>>>> possible? Is there any example of this scenario out there for
>>>>>>>> me to review? DWR3 in multiple portlets on a single portal
>>>>>>>> page. Each portlet has its own dwr.xml with its own set of
>>>>>>>> interfaces. Each portlet makes service calls using DWR to
>>>>>>>> populate its content and does so without worrying about other
>>>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>>>> this possible?
>>>>>>>> Is there a single example to verify that this scenario can work?
>>>>>>>>
>>>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>>>
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Links:
>>>>>>>> ------
>>>>>>>> [1]
>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
>>>>>>>> essio
>>>>>>>> n
>>>>>>>> -
>>>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
You tell me!  Go up a bit more in stateChange:

               if (batch.isPoll && batch.map.partialResponse ==
dwr.engine._partialResponseYes) {
                 dwr.engine.transport.xhr.processCometResponse(reply,
batch);
               } else {
                 if (reply.search("//#DWR") === -1) {
                   dwr.engine._handleError(batch, {
name:"dwr.engine.invalidReply", message:"Invalid reply from server" });
                 } else {
                   toEval = reply;
                 }
               }

reply is essentially what is coming back from the server
(xhr.responseText).


On 2015-09-25 15:04, Okorn, Gregor C. wrote:

> We do see this same behavior in our portlets too, but applying the
> update to DWR3 is easier and quicker with our non-portlet app so
> that's where I'm starting.
>
> I added a breakpoint at the end of stateChange, at the call to
> dwr.engine._executeScript(toEval) and after testing for about 10
> minutes I've seen twice that it has the "toEval" variable undefined -
> which then led to the  "Incomplete reply from server" error again.
> That's a little bit of progress - I see that when that toEval is
> undefined then I'll get this "Incomplete reply from server".  When I
> try to step into that function with Firebug it's not letting me
> though.  How can that toEval be undefined at that point?
>
> Thanks again for your help,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 16:31 PM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> "I've implemented the update to DWR3 and AMD loading, but this app is
> not a portlet.  This is a standalone web app that I'm testing DWR3
> with AMD on first - before I attempt to update our portlets with it.
> There is just the one engine.js being loaded."
>
> That is truly bizarre that you are seeing the incomplete reply error
> in a stand-alone web-page.  At least in the portal environment it made
> a bit of sense.  In one of my previous emails I gave you enough
> information to track this down.  To re-iterate - at the bottom of
> stateChange we call dwr.engine._executeScript(toEval).  This will
> execute the script being returned from the server which should lead to
> a call of dwr.engine.remote.handleCallback.  The handleCallback call
> is critical because it marks the completion of the batch.  Narrow down
> your break-points to handleCallback and examing the toEval that is
> passed to _executeScript.
>
> On 2015-09-25 14:16, Okorn, Gregor C. wrote:
>> Thanks for the response and questions.  The batch.map shows the method
>> I'm expecting to see.  It doesn't always happen on the same remote
>> call.  It has happened on various calls at random times.  All of our
>> remote calls do have callbacks awaiting a response.  I'm testing this
>> on my local development machine.   I'm currently unable to open the
>> page with Chrome; and with IE I'm unable to get it to stop asking me
>> if I'm wanting to leave the page or stay on the page.  We do have the
>> app configured to prompt the user if he tries to navigate away from
>> the page by closing the browser or hitting the refresh or back button;
>> we're using the browser's built-in mechanism, and when I try to open
>> the page with IE it constantly prompts me for that answer.   So - I've
>> been unable to test this behavior on my local machine with anything
>> other than Firefox.  On our shared development server however, which
>> is still using DWR2, we are still seeing the similar error "No data
>> received from server" with the same amount of randomness from all
>> browsers.
>>
>> I've implemented the update to DWR3 and AMD loading, but this app is
>> not a portlet.  This is a standalone web app that I'm testing DWR3
>> with AMD on first - before I attempt to update our portlets with it.
>> There is just the one engine.js being loaded.
>>
>> I think that answers all your questions.  I hope they are helpful in
>> offering any clue as to what I could try next to debug this.  Thanks
>> again for your help.
>>
>> Gregor Okorn,
>>
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Friday, September 25, 2015 16:01 PM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Incomplete reply from server
>>
>> With the new AMD set-up that Mike recommended you have engine.js
>> defined in each portlet, correct?  Do you still have engine.js fined
>> at the portal level?  If so, make sure you remove it.  Make sure you
>> have a clean set-up with engine.js defined only in the portlets.
>>
>> I would have to dig into this a bit deeper but it is possible that we
>> have a scope issue with XHR (stateChange ), and that it is picking up
>> other portlets.  But before we dig deeper, please answer my other
>> questions as they could also be the cause.
>>
>> On 2015-09-25 13:38, [hidden email] wrote:
>>> If you notice at the bottom of stateChange there is a call to
>>> dwr.engine._executeScript(toEval).  This will call the callback and
>>> complete the batch (among other things).  For some reason your
>>> callback is not executing and the batch is not being completed.  If
>>> you have a callback specified I would check it for errors.
>>>
>>> On 2015-09-25 13:31, [hidden email] wrote:
>>>> Do you always see this for the same remote call and does it happen
>>>> everytime?  Do you have a callback specified?
>>>>
>>>> On 2015-09-25 13:28, [hidden email] wrote:
>>>>> That's helpful.  Per my last email, what is in batch.map?  Is it
>>>>> the method you expected to see?  How often does this happen?  Does
>>>>> it happen in all browsers?  When it happens are you the only one
>>>>> using the portal (on a local machine)?
>>>>>
>>>>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>>>>> Forgot to point out that the final condition before the error was
>>>>>> handled was true because the repliesReceived was 0 and the
>>>>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>>>>> some values that did not let it break out  - but let it go as far
>>>>>> as handling this error.
>>>>>>
>>>>>> Thanks,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>> Sent: Friday, September 25, 2015 14:20 PM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>
>>>>>> Appreciate the clarification.   I do see that the first call made
>>>>>> when
>>>>>> I open the page is the _System.generateId, which doesn't get
>>>>>> called again until I refresh the page.  And I see that it
>>>>>> retrieves the DWRSESSIONID value that is then used in all
>>>>>> subsequent calls.  I also see that the stateChange function
>>>>>> handles multiple status values and can break out without error in
>>>>>> depending on the state.
>>>>>>
>>>>>> I've added a breakpoint where you suggested and am examining the
>>>>>> repliesReceived, batch.map, and other fields but am unsure what to
>>>>>> make of the fact that the stateChange is getting called before my
>>>>>> interface method returns.  This is happening well after the
>>>>>> initial startup phase, long after the generateId call is made and
>>>>>> received.
>>>>>> It happens during any random occurrence of our interface calls.
>>>>>> You mentioned that these subsequent calls are made through the
>>>>>> send2 function but when the breakpoint is hit for this "Incomplete
>>>>>> reply from server" the Firebug stacktrace shows:
>>>>>>
>>>>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>>>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>>>>> type="object"})engine.js (line 1568)
>>>>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>>>>> type="object"})engine.js (line 1796)
>>>>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.
>>>>>> js
>>>>>> (line 1664)
>>>>>>
>>>>>> where the earliest (last in list) call is rooted in the send
>>>>>> function, not the send2 function.  Is that expected?
>>>>>>
>>>>>> Here's Firebug's display of the Function closure's variables and
>>>>>> values where the breakpoint hit:
>>>>>>
>>>>>> batch Object { async={...},  charsProcessed={...},  
>>>>>> handlers={...},
>>>>>> more...}
>>>>>>    async  true
>>>>>>    charsProcessed 0
>>>>>>    handlers [Object { callbackScope=Window,
>>>>>> exceptionScope=Window,
>>>>>> callback=function(),  more...}]
>>>>>>    isPoll false
>>>>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>>>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>>>>    paramCount 169
>>>>>>    preHooks null
>>>>>>    postHooks []
>>>>>>    timeout 0
>>>>>>    errorHandler null
>>>>>>    globalErrorHandler Object {
>>>>>> compassErrorHandler=compassErrorHandler(),
>>>>>> showDetails=showDetails(),
>>>>>>  showErrorsDialog=showErrorsDialog()}
>>>>>>    warningHandler function(warnString, exObj)
>>>>>>    textHtmlHandler null
>>>>>>    globalTextHtmlHandler null
>>>>>>    headers Object {}
>>>>>>    attributes Object {}
>>>>>>    path "/UrsRegistrationWizard/dwr"
>>>>>>    completed false
>>>>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>>>>> send=function(),  more...}
>>>>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>>>>> withCredentials=false,  more...}
>>>>>>    mode "/call/plaincall/"
>>>>>> arguments Object { type="object"}
>>>>>> repliesReceived 0
>>>>>> i 1
>>>>>>
>>>>>> That stateChange function should only get called when the browser
>>>>>> has detected a change in the XmlHttpRequest  -  right?  If my
>>>>>> interface method hasn't yet explicitly returned or thrown an
>>>>>> exception, then how can the stateChange callback get triggered
>>>>>> prematurely?  I'm trying to find a clue in by examining the fields
>>>>>> at the breakpoint and parent execution chain, but I don't know
>>>>>> what I'm missing.
>>>>>>
>>>>>> Thanks again,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Friday, September 25, 2015 9:11 AM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>
>>>>>> Let me rephrase that, each time a call is initiated
>>>>>> (YourDWRInterface.method()) send is called.  The first time send
>>>>>> is called per page DWR makes an additional call to the server to
>>>>>> retrieve the dwr session id.  All subsequent calls delegate to
>>>>>> send2.  It is normal to see stateChange called several times.  If
>>>>>> you place a breakpoint lower down in stateChange you will see we
>>>>>> break out of it under certain status conditions.  Per your
>>>>>> original email it is likely that the first time stateChange is
>>>>>> called the status is 0, and we are breaking out of it.  If you
>>>>>> want to debug the incomplete reply error, I would start at the
>>>>>> source of it:
>>>>>>
>>>>>> Line 2438:
>>>>>> } else if (repliesReceived < batch.map.callCount) {
>>>>>>      dwr.engine._handleError(batch, {
>>>>>> name:"dwr.engine.incompleteReply",
>>>>>> message:"Incomplete reply from server" }); }
>>>>>>
>>>>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>>>>
>>>>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>>>>> point
>>>>>>> does DWR make that call to your DwrServlet server?   I search
>>>>>>> through
>>>>>>> the engine.js and see four different places where there is a
>>>>>>> dwr.engine.transport.send function being called, and three places
>>>>>>> where a dwr.engine.transport.send2 function is being called.
>>>>>>> You're
>>>>>>> saying that this function is called 1 time before my first call?
>>>>>>> What does "my first call" refer to?  The call to my java method
>>>>>>> through the interface javascript object?   Is that what you mean?
>>>>>>>
>>>>>>> Unfortunately the application is not available publicly; that
>>>>>>> would be great if I could have you take a live look at it.  If
>>>>>>> there's any particular information that I could share, I'd be
>>>>>>> happy to try through here.
>>>>>>>
>>>>>>> Thanks for your help,
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>>>>> To: [hidden email]
>>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>>
>>>>>>> DWR makes a 1 time call to the server (engine.js -
>>>>>>> dwr.engine.transport.send) before you first call.  Is your
>>>>>>> application available publicly for us to take a look?
>>>>>>>
>>>>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>>>>> interesting behavior.   I added a breakpoint in the
>>>>>>>> xhr:stateChange
>>>>>>>> function and see that it is triggered BEFORE my service gets its
>>>>>>>> response from our server.  How is that possible?   As I look at
>>>>>>>> that
>>>>>>>> breakpoint I see from the WebSphere log file that I'm tailing,
>>>>>>>> that the response eventually comes back from the server and I
>>>>>>>> see that the DWR debug prints (enabled with the "accessLogLevel"
>>>>>>>> set to "CALL"
>>>>>>>> in
>>>>>>>> our web.xml) show that the response is received
>>>>>>>>
>>>>>>>>
>>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-INSERT
>>>>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-REPLY
>>>>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-START#
>>>>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): (function(){
>>>>>>>> if(!window.dwr)return;
>>>>>>>> var dwr=window.dwr._[0];
>>>>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120):
>>>>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newO
>>>>>>>> bject
>>>>>>>> (
>>>>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"
>>>>>>>> ",err
>>>>>>>> o
>>>>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inp
>>>>>>>> rogre
>>>>>>>> s
>>>>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchA
>>>>>>>> ddInf
>>>>>>>> o
>>>>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:
>>>>>>>> "1",b
>>>>>>>> r
>>>>>>>> anchName:"URS
>>>>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>>>>> ...
>>>>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): })();
>>>>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-END#
>>>>>>>>
>>>>>>>>
>>>>>>>> at this point I'm still looking at the breakpoint that has
>>>>>>>> javascript caught in the xhr:stateChange function and see that
>>>>>>>> the req.responseText is of course empty (because its stateChange
>>>>>>>> was triggered too early) and when I hit Continue the eventual
>>>>>>>> error "Incomplete reply from server" is thrown.  But a reply was
>>>>>>>> received from the server - out of sync with the stateChange
>>>>>>>> being triggered.
>>>>>>>>
>>>>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>>>>> function before my java interface completes and returns with the
>>>>>>>> response?
>>>>>>>> How can I make further sense of this?
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>>>>> To: [hidden email]
>>>>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> Mike is right, and I gave you bad advice earlier.  If you put
>>>>>>>> your breakpoint in validate you can inspect the batch.map and
>>>>>>>> the replies that have been received.
>>>>>>>>
>>>>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>>>>> batch for you.
>>>>>>>>> There is no need to debug the Java side; most efficient way to
>>>>>>>>> see what is happening is to load your site in a browser with
>>>>>>>>> Firebug, Developer Tools or similar, open up engine.js in the
>>>>>>>>> script pane, search for the "Incomplete" error message and set
>>>>>>>>> a JS breakpoint there.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>>
>>>>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>>>>> where we don't have multiple portlets on a single page (yet)
>>>>>>>>> just to make sure I have the syntax of setting it up correctly
>>>>>>>>> before I try it in our pre-AMD multi-portlet-per-page portal,
>>>>>>>>> and after a few corrections with my dojoConfig and require
>>>>>>>>> declaration, it appears to be working.
>>>>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> I've seen it succeed with a couple dwr calls, but on one it
>>>>>>>>> throws the "Incomplete reply from server". Previously with DWR2
>>>>>>>>> it would sometimes throw the "No data received from server"
>>>>>>>>> error, but now it's saying that the reply is incomplete? I've
>>>>>>>>> added a breakpoint to my java side interface and no exception
>>>>>>>>> is thrown from there. I see that the javascript error is
>>>>>>>>> happening during the middle of the server side call from my
>>>>>>>>> java interface. I see also that the engine.js explains that the
>>>>>>>>> "Incomplete reply from server" is thrown when it doesn't
>>>>>>>>> receive all the responses that were sent during a batch call -
>>>>>>>>> but I don't set up a batch for this dwr call. I've downloaded
>>>>>>>>> the DWR3 source code so I can try to debug what is causing
>>>>>>>>> this. Where in the source code should I place a breakpoint for
>>>>>>>>> this "Incomplete reply from server" javascript response?
>>>>>>>>>
>>>>>>>>> Thanks for your help.
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>>>>> TO: [hidden email]
>>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>>> portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> I'm reading that additional link and it is useful. Thanks. I'll
>>>>>>>>> be implementing this preferred technique in both the AMD and
>>>>>>>>> pre-AMD Dojo implementations we have. Looking forward to it
>>>>>>>>> going smoothly and being clean. Will report my results when
>>>>>>>>> it's ready. Thanks again.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>>>>> TO: [hidden email]
>>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>>> portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> I hear that you understood this perfectly. Key is not to
>>>>>>>>> pollute the global namespace and instead let the AMD module
>>>>>>>>> loader map these "anonymous" modules to each other through
>>>>>>>>> local variables (function parameters). Then each DWR instance
>>>>>>>>> will work in isolation in the browser and will not interfere
>>>>>>>>> with the others.
>>>>>>>>>
>>>>>>>>> You still need to ensure that script paths published by the
>>>>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>>>>
>>>>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>>>>> set things up in Liferay:
>>>>>>>>>
>>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
>>>>>>>>> essio
>>>>>>>>> n
>>>>>>>>> -
>>>>>>>>> addScript-tp6334142p6466106.html [1]
>>>>>>>>>
>>>>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> Okorn, Gregor C. wrote:>>>>>>>>>
>>>>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>>>>> implementation looks promising for our project. Our project has
>>>>>>>>> three separate parts, each contained in their own virtual
>>>>>>>>> portal, and when we recently started the third part I updated
>>>>>>>>> from our older Dojo pre-AMD library to the newer Dojo AMD
>>>>>>>>> library, and so should be able to apply the DWR AMD solution in
>>>>>>>>> our project's third part.
>>>>>>>>> The
>>>>>>>>> first two parts might still benefit from the pre-AMD Dojo
>>>>>>>>> module option for integrating DWR like your link describes.
>>>>>>>>> I'll investigate these new options and see if it solves our
>>>>>>>>> problem.
>>>>>>>>> From
>>>>>>>>> what I read from that link so far, I would be able to have each
>>>>>>>>> portlet safely include its own proper engine.js along with the
>>>>>>>>> interfaces it needs and not have to implement the work-around
>>>>>>>>> of extracting out a single engine.js that is shared by multiple
>>>>>>>>> portlets. That will be great if that's true and if I can get it
>>>>>>>>> to work as intended.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>>>>> TO: [hidden email]
>>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>>> portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> While I don't have any portlet example to prove this point,
>>>>>>>>> historically portlet problems have usually revolved around
>>>>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>>>>> ignore the following advice.
>>>>>>>>>
>>>>>>>>> DWR (2 and 3) supports to have its servlet instantiated
>>>>>>>>> multiple times with different configuration and dwr.xml in the
>>>>>>>>> same webapp.
>>>>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>>>>
>>>>>>>>> DWR's js-files can then be consumed in a couple of different
>>>>>>>>> ways.
>>>>>>>>> You can use the standard <script> include but this is limited
>>>>>>>>> to connecting to one DWR servlet as it defines objects in the
>>>>>>>>> global js namespace that will collide if another engine.js is
>>>>>>>>> included this way.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>>>>> similar)
>>>>>>>>> there are no global objects defined in JS so you can include
>>>>>>>>> any number of DWR servlets' scripts in the same page. You can
>>>>>>>>> read up on DWR's AMD integration here:
>>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>>>>
>>>>>>>>> To sum up, I think the problems you are seeing is that your
>>>>>>>>> DWR2 workaround is not working in DWR3, but I think you should
>>>>>>>>> be able to get things working by using official DWR3
>>>>>>>>> functionality and not using hacks or workarounds. But l could
>>>>>>>>> certainly be wrong :-)
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Is there anyone out there that has successfully configured
>>>>>>>>> their portal (WebSphere, Liferay, etc) to use DWR3 with
>>>>>>>>> multiple portlets on a single portal page?? We're using
>>>>>>>>> WebSphere and our home page has over seven portlets. Up until
>>>>>>>>> now we have been using
>>>>>>>>> DWR2.0.5
>>>>>>>>> and extracted the served engine.js file to a common location
>>>>>>>>> for all portlets to share so that each portlet would not try to
>>>>>>>>> include its own engine.js. Including multiple engine.js files
>>>>>>>>> won't work.
>>>>>>>>> That
>>>>>>>>> had been working to the extent that each portlet was able to
>>>>>>>>> make DWR calls independent of the other portlets and the calls
>>>>>>>>> generally succeeded in completing successfully.
>>>>>>>>>
>>>>>>>>> We're upgrading to DWR3 and I have been struggling to get the
>>>>>>>>> same configuration to work. Do I need to go back to DWR2 or is
>>>>>>>>> there any evidence - any example of someone else already
>>>>>>>>> successfully using
>>>>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet,
>>>>>>>>> but only DWR2 works with multiple portlets. I've been
>>>>>>>>> experimenting and struggling for over two weeks trying to
>>>>>>>>> upgrade to DWR3 with one roadblock after another. Is it
>>>>>>>>> possible? Is there any example of this scenario out there for
>>>>>>>>> me to review? DWR3 in multiple portlets on a single portal
>>>>>>>>> page. Each portlet has its own dwr.xml with its own set of
>>>>>>>>> interfaces. Each portlet makes service calls using DWR to
>>>>>>>>> populate its content and does so without worrying about other
>>>>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>>>>> this possible?
>>>>>>>>> Is there a single example to verify that this scenario can
>>>>>>>>> work?
>>>>>>>>>
>>>>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Links:
>>>>>>>>> ------
>>>>>>>>> [1]
>>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
>>>>>>>>> essio
>>>>>>>>> n
>>>>>>>>> -
>>>>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok
I found that the toEval is undefined because it never gets set.  The status gets set from the req.status value which is 0, and that happens because the req.readyState is 4.   Since the status is 0, the condition is never met that would set the toEval to the reply value.  The dwr.engine._executeScript(toEval);  gets called with an undefined toEval variable.   Is that the intended behavior?  Is that a valid situation to be in?

Thanks for your help,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Friday, September 25, 2015 17:11 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

You tell me!  Go up a bit more in stateChange:

               if (batch.isPoll && batch.map.partialResponse ==
dwr.engine._partialResponseYes) {
                 dwr.engine.transport.xhr.processCometResponse(reply,
batch);
               } else {
                 if (reply.search("//#DWR") === -1) {
                   dwr.engine._handleError(batch, { name:"dwr.engine.invalidReply", message:"Invalid reply from server" });
                 } else {
                   toEval = reply;
                 }
               }

reply is essentially what is coming back from the server (xhr.responseText).


On 2015-09-25 15:04, Okorn, Gregor C. wrote:

> We do see this same behavior in our portlets too, but applying the
> update to DWR3 is easier and quicker with our non-portlet app so
> that's where I'm starting.
>
> I added a breakpoint at the end of stateChange, at the call to
> dwr.engine._executeScript(toEval) and after testing for about 10
> minutes I've seen twice that it has the "toEval" variable undefined -
> which then led to the  "Incomplete reply from server" error again.
> That's a little bit of progress - I see that when that toEval is
> undefined then I'll get this "Incomplete reply from server".  When I
> try to step into that function with Firebug it's not letting me
> though.  How can that toEval be undefined at that point?
>
> Thanks again for your help,
> Gregor Okorn,
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Friday, September 25, 2015 16:31 PM
> To: [hidden email]
> Subject: [dwr-users] Re: Incomplete reply from server
>
> "I've implemented the update to DWR3 and AMD loading, but this app is
> not a portlet.  This is a standalone web app that I'm testing DWR3
> with AMD on first - before I attempt to update our portlets with it.
> There is just the one engine.js being loaded."
>
> That is truly bizarre that you are seeing the incomplete reply error
> in a stand-alone web-page.  At least in the portal environment it made
> a bit of sense.  In one of my previous emails I gave you enough
> information to track this down.  To re-iterate - at the bottom of
> stateChange we call dwr.engine._executeScript(toEval).  This will
> execute the script being returned from the server which should lead to
> a call of dwr.engine.remote.handleCallback.  The handleCallback call
> is critical because it marks the completion of the batch.  Narrow down
> your break-points to handleCallback and examing the toEval that is
> passed to _executeScript.
>
> On 2015-09-25 14:16, Okorn, Gregor C. wrote:
>> Thanks for the response and questions.  The batch.map shows the method
>> I'm expecting to see.  It doesn't always happen on the same remote
>> call.  It has happened on various calls at random times.  All of our
>> remote calls do have callbacks awaiting a response.  I'm testing this
>> on my local development machine.   I'm currently unable to open the
>> page with Chrome; and with IE I'm unable to get it to stop asking me
>> if I'm wanting to leave the page or stay on the page.  We do have the
>> app configured to prompt the user if he tries to navigate away from
>> the page by closing the browser or hitting the refresh or back button;
>> we're using the browser's built-in mechanism, and when I try to open
>> the page with IE it constantly prompts me for that answer.   So - I've
>> been unable to test this behavior on my local machine with anything
>> other than Firefox.  On our shared development server however, which
>> is still using DWR2, we are still seeing the similar error "No data
>> received from server" with the same amount of randomness from all
>> browsers.
>>
>> I've implemented the update to DWR3 and AMD loading, but this app is
>> not a portlet.  This is a standalone web app that I'm testing DWR3
>> with AMD on first - before I attempt to update our portlets with it.
>> There is just the one engine.js being loaded.
>>
>> I think that answers all your questions.  I hope they are helpful in
>> offering any clue as to what I could try next to debug this.  Thanks
>> again for your help.
>>
>> Gregor Okorn,
>>
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> Sent: Friday, September 25, 2015 16:01 PM
>> To: [hidden email]
>> Subject: [dwr-users] Re: Incomplete reply from server
>>
>> With the new AMD set-up that Mike recommended you have engine.js
>> defined in each portlet, correct?  Do you still have engine.js fined
>> at the portal level?  If so, make sure you remove it.  Make sure you
>> have a clean set-up with engine.js defined only in the portlets.
>>
>> I would have to dig into this a bit deeper but it is possible that we
>> have a scope issue with XHR (stateChange ), and that it is picking up
>> other portlets.  But before we dig deeper, please answer my other
>> questions as they could also be the cause.
>>
>> On 2015-09-25 13:38, [hidden email] wrote:
>>> If you notice at the bottom of stateChange there is a call to
>>> dwr.engine._executeScript(toEval).  This will call the callback and
>>> complete the batch (among other things).  For some reason your
>>> callback is not executing and the batch is not being completed.  If
>>> you have a callback specified I would check it for errors.
>>>
>>> On 2015-09-25 13:31, [hidden email] wrote:
>>>> Do you always see this for the same remote call and does it happen
>>>> everytime?  Do you have a callback specified?
>>>>
>>>> On 2015-09-25 13:28, [hidden email] wrote:
>>>>> That's helpful.  Per my last email, what is in batch.map?  Is it
>>>>> the method you expected to see?  How often does this happen?  Does
>>>>> it happen in all browsers?  When it happens are you the only one
>>>>> using the portal (on a local machine)?
>>>>>
>>>>> On 2015-09-25 12:57, Okorn, Gregor C. wrote:
>>>>>> Forgot to point out that the final condition before the error was
>>>>>> handled was true because the repliesReceived was 0 and the
>>>>>> batch.map.callCount was 1.  In this situation the stateChange saw
>>>>>> some values that did not let it break out  - but let it go as far
>>>>>> as handling this error.
>>>>>>
>>>>>> Thanks,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>> Sent: Friday, September 25, 2015 14:20 PM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>
>>>>>> Appreciate the clarification.   I do see that the first call made
>>>>>> when
>>>>>> I open the page is the _System.generateId, which doesn't get
>>>>>> called again until I refresh the page.  And I see that it
>>>>>> retrieves the DWRSESSIONID value that is then used in all
>>>>>> subsequent calls.  I also see that the stateChange function
>>>>>> handles multiple status values and can break out without error in
>>>>>> depending on the state.
>>>>>>
>>>>>> I've added a breakpoint where you suggested and am examining the
>>>>>> repliesReceived, batch.map, and other fields but am unsure what to
>>>>>> make of the fact that the stateChange is getting called before my
>>>>>> interface method returns.  This is happening well after the
>>>>>> initial startup phase, long after the generateId call is made and
>>>>>> received.
>>>>>> It happens during any random occurrence of our interface calls.
>>>>>> You mentioned that these subsequent calls are made through the
>>>>>> send2 function but when the breakpoint is hit for this "Incomplete
>>>>>> reply from server" the Firebug stacktrace shows:
>>>>>>
>>>>>> dwr.engine.batch.validate(batch=Object { type="object"})engine.js
>>>>>> (line 2445) dwr.engine.transport.complete(batch=Object {
>>>>>> type="object"})engine.js (line 1568)
>>>>>> dwr.engine.transport.xhr.stateChange(batch=Object {
>>>>>> type="object"})engine.js (line 1796)
>>>>>> dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.
>>>>>> js
>>>>>> (line 1664)
>>>>>>
>>>>>> where the earliest (last in list) call is rooted in the send
>>>>>> function, not the send2 function.  Is that expected?
>>>>>>
>>>>>> Here's Firebug's display of the Function closure's variables and
>>>>>> values where the breakpoint hit:
>>>>>>
>>>>>> batch Object { async={...},  charsProcessed={...},  
>>>>>> handlers={...},
>>>>>> more...}
>>>>>>    async  true
>>>>>>    charsProcessed 0
>>>>>>    handlers [Object { callbackScope=Window,
>>>>>> exceptionScope=Window,
>>>>>> callback=function(),  more...}]
>>>>>>    isPoll false
>>>>>>    map Object { callCount=1,  nextReverseAjaxIndex=0,
>>>>>> c0-scriptName="UrsRegWizardDataHandler",  more...}
>>>>>>    paramCount 169
>>>>>>    preHooks null
>>>>>>    postHooks []
>>>>>>    timeout 0
>>>>>>    errorHandler null
>>>>>>    globalErrorHandler Object {
>>>>>> compassErrorHandler=compassErrorHandler(),
>>>>>> showDetails=showDetails(),
>>>>>>  showErrorsDialog=showErrorsDialog()}
>>>>>>    warningHandler function(warnString, exObj)
>>>>>>    textHtmlHandler null
>>>>>>    globalTextHtmlHandler null
>>>>>>    headers Object {}
>>>>>>    attributes Object {}
>>>>>>    path "/UrsRegistrationWizard/dwr"
>>>>>>    completed false
>>>>>>    transport Object { httpMethod="POST",  XMLHTTP=[6],
>>>>>> send=function(),  more...}
>>>>>>    req XMLHttpRequest { readyState=4,  timeout=0,
>>>>>> withCredentials=false,  more...}
>>>>>>    mode "/call/plaincall/"
>>>>>> arguments Object { type="object"}
>>>>>> repliesReceived 0
>>>>>> i 1
>>>>>>
>>>>>> That stateChange function should only get called when the browser
>>>>>> has detected a change in the XmlHttpRequest  -  right?  If my
>>>>>> interface method hasn't yet explicitly returned or thrown an
>>>>>> exception, then how can the stateChange callback get triggered
>>>>>> prematurely?  I'm trying to find a clue in by examining the fields
>>>>>> at the breakpoint and parent execution chain, but I don't know
>>>>>> what I'm missing.
>>>>>>
>>>>>> Thanks again,
>>>>>> Gregor Okorn,
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>> Sent: Friday, September 25, 2015 9:11 AM
>>>>>> To: [hidden email]
>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>
>>>>>> Let me rephrase that, each time a call is initiated
>>>>>> (YourDWRInterface.method()) send is called.  The first time send
>>>>>> is called per page DWR makes an additional call to the server to
>>>>>> retrieve the dwr session id.  All subsequent calls delegate to
>>>>>> send2.  It is normal to see stateChange called several times.  If
>>>>>> you place a breakpoint lower down in stateChange you will see we
>>>>>> break out of it under certain status conditions.  Per your
>>>>>> original email it is likely that the first time stateChange is
>>>>>> called the status is 0, and we are breaking out of it.  If you
>>>>>> want to debug the incomplete reply error, I would start at the
>>>>>> source of it:
>>>>>>
>>>>>> Line 2438:
>>>>>> } else if (repliesReceived < batch.map.callCount) {
>>>>>>      dwr.engine._handleError(batch, {
>>>>>> name:"dwr.engine.incompleteReply",
>>>>>> message:"Incomplete reply from server" }); }
>>>>>>
>>>>>> Inspect repliesReceived, batch.map etc. in the debugger.
>>>>>>
>>>>>> On 2015-09-25 06:23, Okorn, Gregor C. wrote:
>>>>>>> Thanks for the response.   I'm not sure what you mean.  At what
>>>>>>> point
>>>>>>> does DWR make that call to your DwrServlet server?   I search
>>>>>>> through
>>>>>>> the engine.js and see four different places where there is a
>>>>>>> dwr.engine.transport.send function being called, and three places
>>>>>>> where a dwr.engine.transport.send2 function is being called.
>>>>>>> You're
>>>>>>> saying that this function is called 1 time before my first call?
>>>>>>> What does "my first call" refer to?  The call to my java method
>>>>>>> through the interface javascript object?   Is that what you mean?
>>>>>>>
>>>>>>> Unfortunately the application is not available publicly; that
>>>>>>> would be great if I could have you take a live look at it.  If
>>>>>>> there's any particular information that I could share, I'd be
>>>>>>> happy to try through here.
>>>>>>>
>>>>>>> Thanks for your help,
>>>>>>> Gregor Okorn,
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>>> Sent: Friday, September 25, 2015 8:01 AM
>>>>>>> To: [hidden email]
>>>>>>> Subject: [dwr-users] Re: Incomplete reply from server
>>>>>>>
>>>>>>> DWR makes a 1 time call to the server (engine.js -
>>>>>>> dwr.engine.transport.send) before you first call.  Is your
>>>>>>> application available publicly for us to take a look?
>>>>>>>
>>>>>>> On 2015-09-24 10:47, Okorn, Gregor C. wrote:
>>>>>>>> Thanks.  I've put some breakpoints in engine.js and found some
>>>>>>>> interesting behavior.   I added a breakpoint in the
>>>>>>>> xhr:stateChange
>>>>>>>> function and see that it is triggered BEFORE my service gets its
>>>>>>>> response from our server.  How is that possible?   As I look at
>>>>>>>> that
>>>>>>>> breakpoint I see from the WebSphere log file that I'm tailing,
>>>>>>>> that the response eventually comes back from the server and I
>>>>>>>> see that the DWR debug prints (enabled with the "accessLogLevel"
>>>>>>>> set to "CALL"
>>>>>>>> in
>>>>>>>> our web.xml) show that the response is received
>>>>>>>>
>>>>>>>>
>>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): throw 'allowScriptTagRemoting is false.';
>>>>>>>> [9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-INSERT
>>>>>>>> [9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-REPLY
>>>>>>>> [9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-START#
>>>>>>>> [9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): (function(){
>>>>>>>> if(!window.dwr)return;
>>>>>>>> var dwr=window.dwr._[0];
>>>>>>>> [9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120):
>>>>>>>> dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newO
>>>>>>>> bject
>>>>>>>> (
>>>>>>>> "URSRegistration",{applicantId:"",applicationId:"",displayHelp:"
>>>>>>>> ",err
>>>>>>>> o
>>>>>>>> rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inp
>>>>>>>> rogre
>>>>>>>> s
>>>>>>>> s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchA
>>>>>>>> ddInf
>>>>>>>> o
>>>>>>>> :"",branchCode:"B001",branchDescription:"",branchInstanceNumber:
>>>>>>>> "1",b
>>>>>>>> r
>>>>>>>> anchName:"URS
>>>>>>>> Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
>>>>>>>> ...
>>>>>>>> companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
>>>>>>>> [9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): })();
>>>>>>>> [9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
>>>>>>>> org.directwebremoting.util.DebuggingPrintWriter printBuffer
>>>>>>>> out(-2120569120): //#DWR-END#
>>>>>>>>
>>>>>>>>
>>>>>>>> at this point I'm still looking at the breakpoint that has
>>>>>>>> javascript caught in the xhr:stateChange function and see that
>>>>>>>> the req.responseText is of course empty (because its stateChange
>>>>>>>> was triggered too early) and when I hit Continue the eventual
>>>>>>>> error "Incomplete reply from server" is thrown.  But a reply was
>>>>>>>> received from the server - out of sync with the stateChange
>>>>>>>> being triggered.
>>>>>>>>
>>>>>>>> Is there some timeout that is triggering the xhr:stateChange
>>>>>>>> function before my java interface completes and returns with the
>>>>>>>> response?
>>>>>>>> How can I make further sense of this?
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Gregor Okorn,
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [hidden email] [mailto:[hidden email]]
>>>>>>>> Sent: Wednesday, September 23, 2015 14:40 PM
>>>>>>>> To: [hidden email]
>>>>>>>> Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>> portlets on a single portal page?
>>>>>>>>
>>>>>>>> Mike is right, and I gave you bad advice earlier.  If you put
>>>>>>>> your breakpoint in validate you can inspect the batch.map and
>>>>>>>> the replies that have been received.
>>>>>>>>
>>>>>>>> On 2015-09-23 12:10, Mike Wilson wrote:
>>>>>>>>> Technically there is always a batch as DWR creates an implicit
>>>>>>>>> batch for you.
>>>>>>>>> There is no need to debug the Java side; most efficient way to
>>>>>>>>> see what is happening is to load your site in a browser with
>>>>>>>>> Firebug, Developer Tools or similar, open up engine.js in the
>>>>>>>>> script pane, search for the "Incomplete" error message and set
>>>>>>>>> a JS breakpoint there.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>>
>>>>>>>>> I started out using this new technique in our Dojo AMD portal
>>>>>>>>> where we don't have multiple portlets on a single page (yet)
>>>>>>>>> just to make sure I have the syntax of setting it up correctly
>>>>>>>>> before I try it in our pre-AMD multi-portlet-per-page portal,
>>>>>>>>> and after a few corrections with my dojoConfig and require
>>>>>>>>> declaration, it appears to be working.
>>>>>>>>> I'm now using AMD to include the engine.js and my interface.
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> I've seen it succeed with a couple dwr calls, but on one it
>>>>>>>>> throws the "Incomplete reply from server". Previously with DWR2
>>>>>>>>> it would sometimes throw the "No data received from server"
>>>>>>>>> error, but now it's saying that the reply is incomplete? I've
>>>>>>>>> added a breakpoint to my java side interface and no exception
>>>>>>>>> is thrown from there. I see that the javascript error is
>>>>>>>>> happening during the middle of the server side call from my
>>>>>>>>> java interface. I see also that the engine.js explains that the
>>>>>>>>> "Incomplete reply from server" is thrown when it doesn't
>>>>>>>>> receive all the responses that were sent during a batch call -
>>>>>>>>> but I don't set up a batch for this dwr call. I've downloaded
>>>>>>>>> the DWR3 source code so I can try to debug what is causing
>>>>>>>>> this. Where in the source code should I place a breakpoint for
>>>>>>>>> this "Incomplete reply from server" javascript response?
>>>>>>>>>
>>>>>>>>> Thanks for your help.
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>> FROM: Okorn, Gregor C. [mailto:[hidden email]]
>>>>>>>>> SENT: Monday, September 21, 2015 14:11 PM
>>>>>>>>> TO: [hidden email]
>>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>>> portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> I'm reading that additional link and it is useful. Thanks. I'll
>>>>>>>>> be implementing this preferred technique in both the AMD and
>>>>>>>>> pre-AMD Dojo implementations we have. Looking forward to it
>>>>>>>>> going smoothly and being clean. Will report my results when
>>>>>>>>> it's ready. Thanks again.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>>> SENT: Monday, September 21, 2015 13:50 PM
>>>>>>>>> TO: [hidden email]
>>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>>> portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> I hear that you understood this perfectly. Key is not to
>>>>>>>>> pollute the global namespace and instead let the AMD module
>>>>>>>>> loader map these "anonymous" modules to each other through
>>>>>>>>> local variables (function parameters). Then each DWR instance
>>>>>>>>> will work in isolation in the browser and will not interfere
>>>>>>>>> with the others.
>>>>>>>>>
>>>>>>>>> You still need to ensure that script paths published by the
>>>>>>>>> different DWR servlets map to the URL space in a managable way
>>>>>>>>> (maybe your portlet container rewrites paths for all local
>>>>>>>>> servlets?) and that the AMD loader knows about these paths.
>>>>>>>>>
>>>>>>>>> Here's a link to discussion where another DWR user successfully
>>>>>>>>> set things up in Liferay:
>>>>>>>>>
>>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
>>>>>>>>> essio
>>>>>>>>> n
>>>>>>>>> -
>>>>>>>>> addScript-tp6334142p6466106.html [1]
>>>>>>>>>
>>>>>>>>> Reading backwards from the linked post may provide useful info.
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>>
>>>>>>>>> Wow - great information. Thank you. Your link to your AMD
>>>>>>>>> implementation looks promising for our project. Our project has
>>>>>>>>> three separate parts, each contained in their own virtual
>>>>>>>>> portal, and when we recently started the third part I updated
>>>>>>>>> from our older Dojo pre-AMD library to the newer Dojo AMD
>>>>>>>>> library, and so should be able to apply the DWR AMD solution in
>>>>>>>>> our project's third part.
>>>>>>>>> The
>>>>>>>>> first two parts might still benefit from the pre-AMD Dojo
>>>>>>>>> module option for integrating DWR like your link describes.
>>>>>>>>> I'll investigate these new options and see if it solves our
>>>>>>>>> problem.
>>>>>>>>> From
>>>>>>>>> what I read from that link so far, I would be able to have each
>>>>>>>>> portlet safely include its own proper engine.js along with the
>>>>>>>>> interfaces it needs and not have to implement the work-around
>>>>>>>>> of extracting out a single engine.js that is shared by multiple
>>>>>>>>> portlets. That will be great if that's true and if I can get it
>>>>>>>>> to work as intended.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>> FROM: Mike Wilson [mailto:[hidden email]]
>>>>>>>>> SENT: Monday, September 21, 2015 11:39 AM
>>>>>>>>> TO: [hidden email]
>>>>>>>>> SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
>>>>>>>>> portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> While I don't have any portlet example to prove this point,
>>>>>>>>> historically portlet problems have usually revolved around
>>>>>>>>> JavaScript collisions. Ie, the different engine.js inclusions
>>>>>>>>> overwriting each other. If this is not what you are seeing then
>>>>>>>>> ignore the following advice.
>>>>>>>>>
>>>>>>>>> DWR (2 and 3) supports to have its servlet instantiated
>>>>>>>>> multiple times with different configuration and dwr.xml in the
>>>>>>>>> same webapp.
>>>>>>>>> This is analogous to each portlet having its own DWR servlet.
>>>>>>>>>
>>>>>>>>> DWR's js-files can then be consumed in a couple of different
>>>>>>>>> ways.
>>>>>>>>> You can use the standard <script> include but this is limited
>>>>>>>>> to connecting to one DWR servlet as it defines objects in the
>>>>>>>>> global js namespace that will collide if another engine.js is
>>>>>>>>> included this way.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you instead use the AMD script mechanism (requirejs and
>>>>>>>>> similar)
>>>>>>>>> there are no global objects defined in JS so you can include
>>>>>>>>> any number of DWR servlets' scripts in the same page. You can
>>>>>>>>> read up on DWR's AMD integration here:
>>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515 [2]
>>>>>>>>>
>>>>>>>>> To sum up, I think the problems you are seeing is that your
>>>>>>>>> DWR2 workaround is not working in DWR3, but I think you should
>>>>>>>>> be able to get things working by using official DWR3
>>>>>>>>> functionality and not using hacks or workarounds. But l could
>>>>>>>>> certainly be wrong :-)
>>>>>>>>>
>>>>>>>>> Best regards
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> Okorn, Gregor C. wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Is there anyone out there that has successfully configured
>>>>>>>>> their portal (WebSphere, Liferay, etc) to use DWR3 with
>>>>>>>>> multiple portlets on a single portal page?? We're using
>>>>>>>>> WebSphere and our home page has over seven portlets. Up until
>>>>>>>>> now we have been using
>>>>>>>>> DWR2.0.5
>>>>>>>>> and extracted the served engine.js file to a common location
>>>>>>>>> for all portlets to share so that each portlet would not try to
>>>>>>>>> include its own engine.js. Including multiple engine.js files
>>>>>>>>> won't work.
>>>>>>>>> That
>>>>>>>>> had been working to the extent that each portlet was able to
>>>>>>>>> make DWR calls independent of the other portlets and the calls
>>>>>>>>> generally succeeded in completing successfully.
>>>>>>>>>
>>>>>>>>> We're upgrading to DWR3 and I have been struggling to get the
>>>>>>>>> same configuration to work. Do I need to go back to DWR2 or is
>>>>>>>>> there any evidence - any example of someone else already
>>>>>>>>> successfully using
>>>>>>>>> DWR3 in multiple portlets on a single portal page?
>>>>>>>>>
>>>>>>>>> I get the feeling that DWR3 is simply not able to handle this
>>>>>>>>> scenario. Both DWR3 and DWR2 work great with a single portlet,
>>>>>>>>> but only DWR2 works with multiple portlets. I've been
>>>>>>>>> experimenting and struggling for over two weeks trying to
>>>>>>>>> upgrade to DWR3 with one roadblock after another. Is it
>>>>>>>>> possible? Is there any example of this scenario out there for
>>>>>>>>> me to review? DWR3 in multiple portlets on a single portal
>>>>>>>>> page. Each portlet has its own dwr.xml with its own set of
>>>>>>>>> interfaces. Each portlet makes service calls using DWR to
>>>>>>>>> populate its content and does so without worrying about other
>>>>>>>>> portlets possibly making calls at the same time at startup. Is
>>>>>>>>> this possible?
>>>>>>>>> Is there a single example to verify that this scenario can
>>>>>>>>> work?
>>>>>>>>>
>>>>>>>>> Will greatly appreciate any pointer to that elusive example.
>>>>>>>>>
>>>>>>>>> Gregor Okorn,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Links:
>>>>>>>>> ------
>>>>>>>>> [1]
>>>>>>>>> http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
>>>>>>>>> essio
>>>>>>>>> n
>>>>>>>>> -
>>>>>>>>> addScript-tp6334142p6466106.html [2]
>>>>>>>>> https://directwebremoting.atlassian.net/browse/DWR-515
Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

david@butterdev.com
No.  Here is an explanation of when you will encounter this:
http://stackoverflow.com/questions/3070966/xhr-readystate-4-but-status-0-in-google-chrome-browser

What is batch.path and what is the url in the browser window? 

In send2 we do a check for cross-domain:
if (batch.path.indexOf(<a class="moz-txt-link-rfc2396E" href="http://">"http://") === 0 || batch.path.indexOf("https://") === 0) {
  var dwrShortPath = batch.path.split("/", 3).join("/");
  var hrefShortPath = window.location.href.split("/", 3).join("/");
  isCrossDomain = (dwrShortPath != hrefShortPath);
}

What is dwrShortPath and hrefShortPath?
On 09/25/2015 09:01 PM, Okorn, Gregor C. wrote:
I found that the toEval is undefined because it never gets set.  The status gets set from the req.status value which is 0, and that happens because the req.readyState is 4.   Since the status is 0, the condition is never met that would set the toEval to the reply value.  The dwr.engine._executeScript(toEval);  gets called with an undefined toEval variable.   Is that the intended behavior?  Is that a valid situation to be in?

Thanks for your help,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 17:11 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

You tell me!  Go up a bit more in stateChange:

               if (batch.isPoll && batch.map.partialResponse ==
dwr.engine._partialResponseYes) {
                 dwr.engine.transport.xhr.processCometResponse(reply,
batch);
               } else {
                 if (reply.search("//#DWR") === -1) {
                   dwr.engine._handleError(batch, { name:"dwr.engine.invalidReply", message:"Invalid reply from server" });
                 } else {
                   toEval = reply;
                 }
               }

reply is essentially what is coming back from the server (xhr.responseText).


On 2015-09-25 15:04, Okorn, Gregor C. wrote:
We do see this same behavior in our portlets too, but applying the
update to DWR3 is easier and quicker with our non-portlet app so
that's where I'm starting.

I added a breakpoint at the end of stateChange, at the call to
dwr.engine._executeScript(toEval) and after testing for about 10
minutes I've seen twice that it has the "toEval" variable undefined -
which then led to the  "Incomplete reply from server" error again.
That's a little bit of progress - I see that when that toEval is
undefined then I'll get this "Incomplete reply from server".  When I
try to step into that function with Firebug it's not letting me
though.  How can that toEval be undefined at that point?

Thanks again for your help,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 16:31 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

"I've implemented the update to DWR3 and AMD loading, but this app is
not a portlet.  This is a standalone web app that I'm testing DWR3
with AMD on first - before I attempt to update our portlets with it.
There is just the one engine.js being loaded."

That is truly bizarre that you are seeing the incomplete reply error
in a stand-alone web-page.  At least in the portal environment it made
a bit of sense.  In one of my previous emails I gave you enough
information to track this down.  To re-iterate - at the bottom of
stateChange we call dwr.engine._executeScript(toEval).  This will
execute the script being returned from the server which should lead to
a call of dwr.engine.remote.handleCallback.  The handleCallback call
is critical because it marks the completion of the batch.  Narrow down
your break-points to handleCallback and examing the toEval that is
passed to _executeScript.

On 2015-09-25 14:16, Okorn, Gregor C. wrote:
Thanks for the response and questions.  The batch.map shows the method
I'm expecting to see.  It doesn't always happen on the same remote
call.  It has happened on various calls at random times.  All of our
remote calls do have callbacks awaiting a response.  I'm testing this
on my local development machine.   I'm currently unable to open the
page with Chrome; and with IE I'm unable to get it to stop asking me
if I'm wanting to leave the page or stay on the page.  We do have the
app configured to prompt the user if he tries to navigate away from
the page by closing the browser or hitting the refresh or back button;
we're using the browser's built-in mechanism, and when I try to open
the page with IE it constantly prompts me for that answer.   So - I've
been unable to test this behavior on my local machine with anything
other than Firefox.  On our shared development server however, which
is still using DWR2, we are still seeing the similar error "No data
received from server" with the same amount of randomness from all
browsers.

I've implemented the update to DWR3 and AMD loading, but this app is
not a portlet.  This is a standalone web app that I'm testing DWR3
with AMD on first - before I attempt to update our portlets with it.
There is just the one engine.js being loaded.

I think that answers all your questions.  I hope they are helpful in
offering any clue as to what I could try next to debug this.  Thanks
again for your help.

Gregor Okorn,


-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 16:01 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

With the new AMD set-up that Mike recommended you have engine.js
defined in each portlet, correct?  Do you still have engine.js fined
at the portal level?  If so, make sure you remove it.  Make sure you
have a clean set-up with engine.js defined only in the portlets.

I would have to dig into this a bit deeper but it is possible that we
have a scope issue with XHR (stateChange ), and that it is picking up
other portlets.  But before we dig deeper, please answer my other
questions as they could also be the cause.

On 2015-09-25 13:38, [hidden email] wrote:
If you notice at the bottom of stateChange there is a call to
dwr.engine._executeScript(toEval).  This will call the callback and
complete the batch (among other things).  For some reason your
callback is not executing and the batch is not being completed.  If
you have a callback specified I would check it for errors.

On 2015-09-25 13:31, [hidden email] wrote:
Do you always see this for the same remote call and does it happen
everytime?  Do you have a callback specified?

On 2015-09-25 13:28, [hidden email] wrote:
That's helpful.  Per my last email, what is in batch.map?  Is it
the method you expected to see?  How often does this happen?  Does
it happen in all browsers?  When it happens are you the only one
using the portal (on a local machine)?

On 2015-09-25 12:57, Okorn, Gregor C. wrote:
Forgot to point out that the final condition before the error was
handled was true because the repliesReceived was 0 and the
batch.map.callCount was 1.  In this situation the stateChange saw
some values that did not let it break out  - but let it go as far
as handling this error.

Thanks,
Gregor Okorn,


-----Original Message-----
From: Okorn, Gregor C. [[hidden email]]
Sent: Friday, September 25, 2015 14:20 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

Appreciate the clarification.   I do see that the first call made
when
I open the page is the _System.generateId, which doesn't get
called again until I refresh the page.  And I see that it
retrieves the DWRSESSIONID value that is then used in all
subsequent calls.  I also see that the stateChange function
handles multiple status values and can break out without error in
depending on the state.

I've added a breakpoint where you suggested and am examining the
repliesReceived, batch.map, and other fields but am unsure what to
make of the fact that the stateChange is getting called before my
interface method returns.  This is happening well after the
initial startup phase, long after the generateId call is made and
received.
It happens during any random occurrence of our interface calls.
You mentioned that these subsequent calls are made through the
send2 function but when the breakpoint is hit for this "Incomplete
reply from server" the Firebug stacktrace shows:

dwr.engine.batch.validate(batch=Object { type="object"})engine.js
(line 2445) dwr.engine.transport.complete(batch=Object {
type="object"})engine.js (line 1568)
dwr.engine.transport.xhr.stateChange(batch=Object {
type="object"})engine.js (line 1796)
dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.
js
(line 1664)

where the earliest (last in list) call is rooted in the send
function, not the send2 function.  Is that expected?

Here's Firebug's display of the Function closure's variables and
values where the breakpoint hit:

batch	Object { async={...},  charsProcessed={...},
handlers={...},
more...}
   async  true
   charsProcessed	0
   handlers 		[Object { callbackScope=Window,
exceptionScope=Window,
callback=function(),  more...}]
   isPoll 			false
   map			Object { callCount=1,  nextReverseAjaxIndex=0,
c0-scriptName="UrsRegWizardDataHandler",  more...}
   paramCount		 169
   preHooks		null
   postHooks		[]
   timeout		0
   errorHandler		null
   globalErrorHandler	Object {
compassErrorHandler=compassErrorHandler(),
showDetails=showDetails(),
 showErrorsDialog=showErrorsDialog()}
   warningHandler	function(warnString, exObj)
   textHtmlHandler	null
   globalTextHtmlHandler	null
   headers		Object {}
   attributes		Object {}
   path			"/UrsRegistrationWizard/dwr"
   completed		false
   transport		Object { httpMethod="POST",  XMLHTTP=[6],
send=function(),  more...}
   req			XMLHttpRequest { readyState=4,  timeout=0,
withCredentials=false,  more...}
   mode			"/call/plaincall/"
arguments	Object { type="object"}
repliesReceived	0
i		1

That stateChange function should only get called when the browser
has detected a change in the XmlHttpRequest  -  right?  If my
interface method hasn't yet explicitly returned or thrown an
exception, then how can the stateChange callback get triggered
prematurely?  I'm trying to find a clue in by examining the fields
at the breakpoint and parent execution chain, but I don't know
what I'm missing.

Thanks again,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 9:11 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

Let me rephrase that, each time a call is initiated
(YourDWRInterface.method()) send is called.  The first time send
is called per page DWR makes an additional call to the server to
retrieve the dwr session id.  All subsequent calls delegate to
send2.  It is normal to see stateChange called several times.  If
you place a breakpoint lower down in stateChange you will see we
break out of it under certain status conditions.  Per your
original email it is likely that the first time stateChange is
called the status is 0, and we are breaking out of it.  If you
want to debug the incomplete reply error, I would start at the
source of it:

Line 2438:
} else if (repliesReceived < batch.map.callCount) {
     dwr.engine._handleError(batch, {
name:"dwr.engine.incompleteReply",
message:"Incomplete reply from server" }); }

Inspect repliesReceived, batch.map etc. in the debugger.

On 2015-09-25 06:23, Okorn, Gregor C. wrote:
Thanks for the response.   I'm not sure what you mean.  At what
point
does DWR make that call to your DwrServlet server?   I search
through
the engine.js and see four different places where there is a
dwr.engine.transport.send function being called, and three places
where a dwr.engine.transport.send2 function is being called.
You're
saying that this function is called 1 time before my first call?
What does "my first call" refer to?  The call to my java method
through the interface javascript object?   Is that what you mean?

Unfortunately the application is not available publicly; that
would be great if I could have you take a live look at it.  If
there's any particular information that I could share, I'd be
happy to try through here.

Thanks for your help,
Gregor Okorn,


-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 8:01 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

DWR makes a 1 time call to the server (engine.js -
dwr.engine.transport.send) before you first call.  Is your
application available publicly for us to take a look?

On 2015-09-24 10:47, Okorn, Gregor C. wrote:
Thanks.  I've put some breakpoints in engine.js and found some
interesting behavior.   I added a breakpoint in the
xhr:stateChange
function and see that it is triggered BEFORE my service gets its
response from our server.  How is that possible?   As I look at
that
breakpoint I see from the WebSphere log file that I'm tailing,
that the response eventually comes back from the server and I
see that the DWR debug prints (enabled with the "accessLogLevel"
set to "CALL"
in
our web.xml) show that the response is received


[9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): throw 'allowScriptTagRemoting is false.';
[9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-INSERT
[9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-REPLY
[9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-START#
[9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): (function(){
if(!window.dwr)return;
var dwr=window.dwr._[0];
[9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120):
dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newO
bject
(
"URSRegistration",{applicantId:"",applicationId:"",displayHelp:"
",err
o
rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inp
rogre
s
s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchA
ddInf
o
:"",branchCode:"B001",branchDescription:"",branchInstanceNumber:
"1",b
r
anchName:"URS
Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
...
companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
[9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): })();
[9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-END#


at this point I'm still looking at the breakpoint that has
javascript caught in the xhr:stateChange function and see that
the req.responseText is of course empty (because its stateChange
was triggered too early) and when I hit Continue the eventual
error "Incomplete reply from server" is thrown.  But a reply was
received from the server - out of sync with the stateChange
being triggered.

Is there some timeout that is triggering the xhr:stateChange
function before my java interface completes and returns with the
response?
How can I make further sense of this?


Thanks,
Gregor Okorn,

-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Wednesday, September 23, 2015 14:40 PM
To: [hidden email]
Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?

Mike is right, and I gave you bad advice earlier.  If you put
your breakpoint in validate you can inspect the batch.map and
the replies that have been received.

On 2015-09-23 12:10, Mike Wilson wrote:
Technically there is always a batch as DWR creates an implicit
batch for you.
There is no need to debug the Java side; most efficient way to
see what is happening is to load your site in a browser with
Firebug, Developer Tools or similar, open up engine.js in the
script pane, search for the "Incomplete" error message and set
a JS breakpoint there.

Best regards
Mike

Okorn, Gregor C. wrote:

I started out using this new technique in our Dojo AMD portal
where we don't have multiple portlets on a single page (yet)
just to make sure I have the syntax of setting it up correctly
before I try it in our pre-AMD multi-portlet-per-page portal,
and after a few corrections with my dojoConfig and require
declaration, it appears to be working.
I'm now using AMD to include the engine.js and my interface.
Thanks.

I've seen it succeed with a couple dwr calls, but on one it
throws the "Incomplete reply from server". Previously with DWR2
it would sometimes throw the "No data received from server"
error, but now it's saying that the reply is incomplete? I've
added a breakpoint to my java side interface and no exception
is thrown from there. I see that the javascript error is
happening during the middle of the server side call from my
java interface. I see also that the engine.js explains that the
"Incomplete reply from server" is thrown when it doesn't
receive all the responses that were sent during a batch call -
but I don't set up a batch for this dwr call. I've downloaded
the DWR3 source code so I can try to debug what is causing
this. Where in the source code should I place a breakpoint for
this "Incomplete reply from server" javascript response?

Thanks for your help.

Gregor Okorn,

FROM: Okorn, Gregor C. [[hidden email]]
SENT: Monday, September 21, 2015 14:11 PM
TO: [hidden email]
SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?

I'm reading that additional link and it is useful. Thanks. I'll
be implementing this preferred technique in both the AMD and
pre-AMD Dojo implementations we have. Looking forward to it
going smoothly and being clean. Will report my results when
it's ready. Thanks again.

Regards,

Gregor Okorn,

FROM: Mike Wilson [[hidden email]]
SENT: Monday, September 21, 2015 13:50 PM
TO: [hidden email]
SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?

I hear that you understood this perfectly. Key is not to
pollute the global namespace and instead let the AMD module
loader map these "anonymous" modules to each other through
local variables (function parameters). Then each DWR instance
will work in isolation in the browser and will not interfere
with the others.

You still need to ensure that script paths published by the
different DWR servlets map to the URL space in a managable way
(maybe your portlet container rewrites paths for all local
servlets?) and that the AMD loader knows about these paths.

Here's a link to discussion where another DWR user successfully
set things up in Liferay:

http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
essio
n
-
addScript-tp6334142p6466106.html [1]

Reading backwards from the linked post may provide useful info.

Best regards

Mike

Okorn, Gregor C. wrote:

Wow - great information. Thank you. Your link to your AMD
implementation looks promising for our project. Our project has
three separate parts, each contained in their own virtual
portal, and when we recently started the third part I updated
from our older Dojo pre-AMD library to the newer Dojo AMD
library, and so should be able to apply the DWR AMD solution in
our project's third part.
The
first two parts might still benefit from the pre-AMD Dojo
module option for integrating DWR like your link describes.
I'll investigate these new options and see if it solves our
problem.
From
what I read from that link so far, I would be able to have each
portlet safely include its own proper engine.js along with the
interfaces it needs and not have to implement the work-around
of extracting out a single engine.js that is shared by multiple
portlets. That will be great if that's true and if I can get it
to work as intended.

Thanks!

Gregor Okorn,

FROM: Mike Wilson [[hidden email]]
SENT: Monday, September 21, 2015 11:39 AM
TO: [hidden email]
SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?

While I don't have any portlet example to prove this point,
historically portlet problems have usually revolved around
JavaScript collisions. Ie, the different engine.js inclusions
overwriting each other. If this is not what you are seeing then
ignore the following advice.

DWR (2 and 3) supports to have its servlet instantiated
multiple times with different configuration and dwr.xml in the
same webapp.
This is analogous to each portlet having its own DWR servlet.

DWR's js-files can then be consumed in a couple of different
ways.
You can use the standard <script> include but this is limited
to connecting to one DWR servlet as it defines objects in the
global js namespace that will collide if another engine.js is
included this way.


If you instead use the AMD script mechanism (requirejs and
similar)
there are no global objects defined in JS so you can include
any number of DWR servlets' scripts in the same page. You can
read up on DWR's AMD integration here:
https://directwebremoting.atlassian.net/browse/DWR-515 [2]

To sum up, I think the problems you are seeing is that your
DWR2 workaround is not working in DWR3, but I think you should
be able to get things working by using official DWR3
functionality and not using hacks or workarounds. But l could
certainly be wrong :-)

Best regards

Mike

Okorn, Gregor C. wrote:

Hello,

Is there anyone out there that has successfully configured
their portal (WebSphere, Liferay, etc) to use DWR3 with
multiple portlets on a single portal page?? We're using
WebSphere and our home page has over seven portlets. Up until
now we have been using
DWR2.0.5
and extracted the served engine.js file to a common location
for all portlets to share so that each portlet would not try to
include its own engine.js. Including multiple engine.js files
won't work.
That
had been working to the extent that each portlet was able to
make DWR calls independent of the other portlets and the calls
generally succeeded in completing successfully.

We're upgrading to DWR3 and I have been struggling to get the
same configuration to work. Do I need to go back to DWR2 or is
there any evidence - any example of someone else already
successfully using
DWR3 in multiple portlets on a single portal page?

I get the feeling that DWR3 is simply not able to handle this
scenario. Both DWR3 and DWR2 work great with a single portlet,
but only DWR2 works with multiple portlets. I've been
experimenting and struggling for over two weeks trying to
upgrade to DWR3 with one roadblock after another. Is it
possible? Is there any example of this scenario out there for
me to review? DWR3 in multiple portlets on a single portal
page. Each portlet has its own dwr.xml with its own set of
interfaces. Each portlet makes service calls using DWR to
populate its content and does so without worrying about other
portlets possibly making calls at the same time at startup. Is
this possible?
Is there a single example to verify that this scenario can
work?

Will greatly appreciate any pointer to that elusive example.

Gregor Okorn,



Links:
------
[1]
http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
essio
n
-
addScript-tp6334142p6466106.html [2]
https://directwebremoting.atlassian.net/browse/DWR-515

    

Reply | Threaded
Open this post in threaded view
|

Re: Incomplete reply from server

gregorcok

Thanks for the pointer to that stackoverflow link; I’m taking a look at it now.  

 

I’ve set a breakpoint in the send2 function and see that the batch.path is always “/UrsRegistrationWizard/dwr” and never anything else for this app.   The URL for this page is always “https://localhost:10060/UrsRegistrationWizard/”.   Does that offer any hint as to the behavior I’m seeing?

 

Thanks again,

Gregor Okorn,

 

 

From: David Marginian [mailto:[hidden email]]
Sent: Saturday, September 26, 2015 8:28 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server

 

No.  Here is an explanation of when you will encounter this:
http://stackoverflow.com/questions/3070966/xhr-readystate-4-but-status-0-in-google-chrome-browser

What is batch.path and what is the url in the browser window? 

In send2 we do a check for cross-domain:

if (batch.path.indexOf(<a href="http://">"http://") === 0 || batch.path.indexOf("https://") === 0) {
  var dwrShortPath = batch.path.split("/", 3).join("/");
  var hrefShortPath = window.location.href.split("/", 3).join("/");
  isCrossDomain = (dwrShortPath != hrefShortPath);
}
 
What is dwrShortPath and hrefShortPath?

On 09/25/2015 09:01 PM, Okorn, Gregor C. wrote:

I found that the toEval is undefined because it never gets set.  The status gets set from the req.status value which is 0, and that happens because the req.readyState is 4.   Since the status is 0, the condition is never met that would set the toEval to the reply value.  The dwr.engine._executeScript(toEval);  gets called with an undefined toEval variable.   Is that the intended behavior?  Is that a valid situation to be in?
 
Thanks for your help,
Gregor Okorn, 
 
 
-----Original Message-----
From: [hidden email] [[hidden email]] 
Sent: Friday, September 25, 2015 17:11 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server
 
You tell me!  Go up a bit more in stateChange:
 
               if (batch.isPoll && batch.map.partialResponse ==
dwr.engine._partialResponseYes) {
                 dwr.engine.transport.xhr.processCometResponse(reply,
batch);
               } else {
                 if (reply.search("//#DWR") === -1) {
                   dwr.engine._handleError(batch, { name:"dwr.engine.invalidReply", message:"Invalid reply from server" });
                 } else {
                   toEval = reply;
                 }
               }
 
reply is essentially what is coming back from the server (xhr.responseText).
 
 
On 2015-09-25 15:04, Okorn, Gregor C. wrote:
We do see this same behavior in our portlets too, but applying the
update to DWR3 is easier and quicker with our non-portlet app so
that's where I'm starting.
 
I added a breakpoint at the end of stateChange, at the call to
dwr.engine._executeScript(toEval) and after testing for about 10
minutes I've seen twice that it has the "toEval" variable undefined -
which then led to the  "Incomplete reply from server" error again.
That's a little bit of progress - I see that when that toEval is
undefined then I'll get this "Incomplete reply from server".  When I
try to step into that function with Firebug it's not letting me
though.  How can that toEval be undefined at that point?
 
Thanks again for your help,
Gregor Okorn,
 
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 16:31 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server
 
"I've implemented the update to DWR3 and AMD loading, but this app is
not a portlet.  This is a standalone web app that I'm testing DWR3
with AMD on first - before I attempt to update our portlets with it.
There is just the one engine.js being loaded."
 
That is truly bizarre that you are seeing the incomplete reply error
in a stand-alone web-page.  At least in the portal environment it made
a bit of sense.  In one of my previous emails I gave you enough
information to track this down.  To re-iterate - at the bottom of
stateChange we call dwr.engine._executeScript(toEval).  This will
execute the script being returned from the server which should lead to
a call of dwr.engine.remote.handleCallback.  The handleCallback call
is critical because it marks the completion of the batch.  Narrow down
your break-points to handleCallback and examing the toEval that is
passed to _executeScript.
 
On 2015-09-25 14:16, Okorn, Gregor C. wrote:
Thanks for the response and questions.  The batch.map shows the method
I'm expecting to see.  It doesn't always happen on the same remote
call.  It has happened on various calls at random times.  All of our
remote calls do have callbacks awaiting a response.  I'm testing this
on my local development machine.   I'm currently unable to open the
page with Chrome; and with IE I'm unable to get it to stop asking me
if I'm wanting to leave the page or stay on the page.  We do have the
app configured to prompt the user if he tries to navigate away from
the page by closing the browser or hitting the refresh or back button;
we're using the browser's built-in mechanism, and when I try to open
the page with IE it constantly prompts me for that answer.   So - I've
been unable to test this behavior on my local machine with anything
other than Firefox.  On our shared development server however, which
is still using DWR2, we are still seeing the similar error "No data
received from server" with the same amount of randomness from all
browsers.
 
I've implemented the update to DWR3 and AMD loading, but this app is
not a portlet.  This is a standalone web app that I'm testing DWR3
with AMD on first - before I attempt to update our portlets with it.
There is just the one engine.js being loaded.
 
I think that answers all your questions.  I hope they are helpful in
offering any clue as to what I could try next to debug this.  Thanks
again for your help.
 
Gregor Okorn,
 
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 16:01 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server
 
With the new AMD set-up that Mike recommended you have engine.js
defined in each portlet, correct?  Do you still have engine.js fined
at the portal level?  If so, make sure you remove it.  Make sure you
have a clean set-up with engine.js defined only in the portlets.
 
I would have to dig into this a bit deeper but it is possible that we
have a scope issue with XHR (stateChange ), and that it is picking up
other portlets.  But before we dig deeper, please answer my other
questions as they could also be the cause.
 
On 2015-09-25 13:38, [hidden email] wrote:
If you notice at the bottom of stateChange there is a call to
dwr.engine._executeScript(toEval).  This will call the callback and
complete the batch (among other things).  For some reason your
callback is not executing and the batch is not being completed.  If
you have a callback specified I would check it for errors.
 
On 2015-09-25 13:31, [hidden email] wrote:
Do you always see this for the same remote call and does it happen
everytime?  Do you have a callback specified?
 
On 2015-09-25 13:28, [hidden email] wrote:
That's helpful.  Per my last email, what is in batch.map?  Is it
the method you expected to see?  How often does this happen?  Does
it happen in all browsers?  When it happens are you the only one
using the portal (on a local machine)?
 
On 2015-09-25 12:57, Okorn, Gregor C. wrote:
Forgot to point out that the final condition before the error was
handled was true because the repliesReceived was 0 and the
batch.map.callCount was 1.  In this situation the stateChange saw
some values that did not let it break out  - but let it go as far
as handling this error.
 
Thanks,
Gregor Okorn,
 
 
-----Original Message-----
From: Okorn, Gregor C. [[hidden email]]
Sent: Friday, September 25, 2015 14:20 PM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server
 
Appreciate the clarification.   I do see that the first call made
when
I open the page is the _System.generateId, which doesn't get
called again until I refresh the page.  And I see that it
retrieves the DWRSESSIONID value that is then used in all
subsequent calls.  I also see that the stateChange function
handles multiple status values and can break out without error in 
depending on the state.
 
I've added a breakpoint where you suggested and am examining the
repliesReceived, batch.map, and other fields but am unsure what to
make of the fact that the stateChange is getting called before my
interface method returns.  This is happening well after the
initial startup phase, long after the generateId call is made and 
received.
It happens during any random occurrence of our interface calls.
You mentioned that these subsequent calls are made through the
send2 function but when the breakpoint is hit for this "Incomplete
reply from server" the Firebug stacktrace shows:
 
dwr.engine.batch.validate(batch=Object { type="object"})engine.js
(line 2445) dwr.engine.transport.complete(batch=Object {
type="object"})engine.js (line 1568)
dwr.engine.transport.xhr.stateChange(batch=Object {
type="object"})engine.js (line 1796)
dwr.engine.transport.xhr.send/batch.req.onreadystatechange()engine.
js
(line 1664)
 
where the earliest (last in list) call is rooted in the send
function, not the send2 function.  Is that expected?
 
Here's Firebug's display of the Function closure's variables and
values where the breakpoint hit:
 
batch   Object { async={...},  charsProcessed={...},  
handlers={...},
more...}
   async  true
   charsProcessed   0
   handlers       [Object { callbackScope=Window,
exceptionScope=Window,
callback=function(),  more...}]
   isPoll          false
   map       Object { callCount=1,  nextReverseAjaxIndex=0,
c0-scriptName="UrsRegWizardDataHandler",  more...}
   paramCount       169
   preHooks      null
   postHooks      []
   timeout      0
   errorHandler      null
   globalErrorHandler   Object {
compassErrorHandler=compassErrorHandler(),
showDetails=showDetails(),
 showErrorsDialog=showErrorsDialog()}
   warningHandler   function(warnString, exObj)
   textHtmlHandler   null
   globalTextHtmlHandler   null
   headers      Object {}
   attributes      Object {}
   path         "/UrsRegistrationWizard/dwr"
   completed      false
   transport      Object { httpMethod="POST",  XMLHTTP=[6],
send=function(),  more...}
   req       XMLHttpRequest { readyState=4,  timeout=0,
withCredentials=false,  more...}
   mode         "/call/plaincall/"
arguments   Object { type="object"}
repliesReceived   0
i     1
 
That stateChange function should only get called when the browser
has detected a change in the XmlHttpRequest  -  right?  If my
interface method hasn't yet explicitly returned or thrown an
exception, then how can the stateChange callback get triggered
prematurely?  I'm trying to find a clue in by examining the fields
at the breakpoint and parent execution chain, but I don't know
what I'm missing.
 
Thanks again,
Gregor Okorn,
 
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 9:11 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server
 
Let me rephrase that, each time a call is initiated
(YourDWRInterface.method()) send is called.  The first time send
is called per page DWR makes an additional call to the server to
retrieve the dwr session id.  All subsequent calls delegate to
send2.  It is normal to see stateChange called several times.  If
you place a breakpoint lower down in stateChange you will see we
break out of it under certain status conditions.  Per your
original email it is likely that the first time stateChange is
called the status is 0, and we are breaking out of it.  If you
want to debug the incomplete reply error, I would start at the 
source of it:
 
Line 2438:
} else if (repliesReceived < batch.map.callCount) {
     dwr.engine._handleError(batch, {
name:"dwr.engine.incompleteReply",
message:"Incomplete reply from server" }); }
 
Inspect repliesReceived, batch.map etc. in the debugger.
 
On 2015-09-25 06:23, Okorn, Gregor C. wrote:
Thanks for the response.   I'm not sure what you mean.  At what
point
does DWR make that call to your DwrServlet server?   I search
through
the engine.js and see four different places where there is a
dwr.engine.transport.send function being called, and three places
where a dwr.engine.transport.send2 function is being called.
You're
saying that this function is called 1 time before my first call?
What does "my first call" refer to?  The call to my java method
through the interface javascript object?   Is that what you mean?
 
Unfortunately the application is not available publicly; that
would be great if I could have you take a live look at it.  If
there's any particular information that I could share, I'd be
happy to try through here.
 
Thanks for your help,
Gregor Okorn,
 
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Friday, September 25, 2015 8:01 AM
To: [hidden email]
Subject: [dwr-users] Re: Incomplete reply from server
 
DWR makes a 1 time call to the server (engine.js -
dwr.engine.transport.send) before you first call.  Is your
application available publicly for us to take a look?
 
On 2015-09-24 10:47, Okorn, Gregor C. wrote:
Thanks.  I've put some breakpoints in engine.js and found some
interesting behavior.   I added a breakpoint in the
xhr:stateChange
function and see that it is triggered BEFORE my service gets its
response from our server.  How is that possible?   As I look at
that
breakpoint I see from the WebSphere log file that I'm tailing,
that the response eventually comes back from the server and I
see that the DWR debug prints (enabled with the "accessLogLevel"
set to "CALL"
in
our web.xml) show that the response is received
 
 
[9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): throw 'allowScriptTagRemoting is false.';
[9/24/15 12:35:49:398 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-INSERT
[9/24/15 12:35:49:399 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-REPLY
[9/24/15 12:35:49:416 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-START#
[9/24/15 12:35:49:417 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): (function(){
if(!window.dwr)return;
var dwr=window.dwr._[0];
[9/24/15 12:35:49:421 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120):
dwr.engine.remote.handleCallback("16","0",dwr.engine.remote.newO
bject
(
"URSRegistration",{applicantId:"",applicationId:"",displayHelp:"
",err
o
rMessages:[],filingTypeId:"1",isError:"",registrationStatus:"Inp
rogre
s
s",ursBranches:[dwr.engine.remote.newObject("URSBranch",{branchA
ddInf
o
:"",branchCode:"B001",branchDescription:"",branchInstanceNumber:
"1",b
r
anchName:"URS
Welcome",branchStatus:"Completed",displayOrder:"1",helpSummary:"",prevBranchInstNumber:"
...
companyLegalName:"",notifications:[],operationAuthorityRegStatus:"",operationClassification:"",regProcessSteps:[],safetyRegistrationStatus:"",usdotNbr:"",usdotNbrRegStatus:"",usdotNbrStatus:""})}));
[9/24/15 12:35:49:422 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): })();
[9/24/15 12:35:49:476 EDT] 00000078 accessLog     I
org.directwebremoting.util.DebuggingPrintWriter printBuffer
out(-2120569120): //#DWR-END#
 
 
at this point I'm still looking at the breakpoint that has
javascript caught in the xhr:stateChange function and see that
the req.responseText is of course empty (because its stateChange
was triggered too early) and when I hit Continue the eventual
error "Incomplete reply from server" is thrown.  But a reply was
received from the server - out of sync with the stateChange
being triggered.
 
Is there some timeout that is triggering the xhr:stateChange
function before my java interface completes and returns with the
response?
How can I make further sense of this?
 
 
Thanks,
Gregor Okorn,
 
-----Original Message-----
From: [hidden email] [[hidden email]]
Sent: Wednesday, September 23, 2015 14:40 PM
To: [hidden email]
Subject: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?
 
Mike is right, and I gave you bad advice earlier.  If you put
your breakpoint in validate you can inspect the batch.map and
the replies that have been received.
 
On 2015-09-23 12:10, Mike Wilson wrote:
Technically there is always a batch as DWR creates an implicit
batch for you.
There is no need to debug the Java side; most efficient way to
see what is happening is to load your site in a browser with
Firebug, Developer Tools or similar, open up engine.js in the
script pane, search for the "Incomplete" error message and set
a JS breakpoint there.
 
Best regards
Mike
 
Okorn, Gregor C. wrote:
 
I started out using this new technique in our Dojo AMD portal
where we don't have multiple portlets on a single page (yet)
just to make sure I have the syntax of setting it up correctly
before I try it in our pre-AMD multi-portlet-per-page portal,
and after a few corrections with my dojoConfig and require
declaration, it appears to be working.
I'm now using AMD to include the engine.js and my interface.
Thanks.
 
I've seen it succeed with a couple dwr calls, but on one it
throws the "Incomplete reply from server". Previously with DWR2
it would sometimes throw the "No data received from server"
error, but now it's saying that the reply is incomplete? I've
added a breakpoint to my java side interface and no exception
is thrown from there. I see that the javascript error is
happening during the middle of the server side call from my
java interface. I see also that the engine.js explains that the
"Incomplete reply from server" is thrown when it doesn't
receive all the responses that were sent during a batch call -
but I don't set up a batch for this dwr call. I've downloaded
the DWR3 source code so I can try to debug what is causing
this. Where in the source code should I place a breakpoint for
this "Incomplete reply from server" javascript response?
 
Thanks for your help.
 
Gregor Okorn,
 
FROM: Okorn, Gregor C. [[hidden email]]
SENT: Monday, September 21, 2015 14:11 PM
TO: [hidden email]
SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?
 
I'm reading that additional link and it is useful. Thanks. I'll
be implementing this preferred technique in both the AMD and
pre-AMD Dojo implementations we have. Looking forward to it
going smoothly and being clean. Will report my results when
it's ready. Thanks again.
 
Regards,
 
Gregor Okorn,
 
FROM: Mike Wilson [[hidden email]]
SENT: Monday, September 21, 2015 13:50 PM
TO: [hidden email]
SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?
 
I hear that you understood this perfectly. Key is not to
pollute the global namespace and instead let the AMD module
loader map these "anonymous" modules to each other through
local variables (function parameters). Then each DWR instance
will work in isolation in the browser and will not interfere
with the others.
 
You still need to ensure that script paths published by the
different DWR servlets map to the URL space in a managable way
(maybe your portlet container rewrites paths for all local
servlets?) and that the AMD loader knows about these paths.
 
Here's a link to discussion where another DWR user successfully
set things up in Liferay:
 
http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
essio
n
-
addScript-tp6334142p6466106.html [1]
 
Reading backwards from the linked post may provide useful info.
 
Best regards
 
Mike
 
Okorn, Gregor C. wrote:
 
Wow - great information. Thank you. Your link to your AMD
implementation looks promising for our project. Our project has
three separate parts, each contained in their own virtual
portal, and when we recently started the third part I updated
from our older Dojo pre-AMD library to the newer Dojo AMD
library, and so should be able to apply the DWR AMD solution in
our project's third part.
The
first two parts might still benefit from the pre-AMD Dojo
module option for integrating DWR like your link describes.
I'll investigate these new options and see if it solves our 
problem.
From
what I read from that link so far, I would be able to have each
portlet safely include its own proper engine.js along with the
interfaces it needs and not have to implement the work-around
of extracting out a single engine.js that is shared by multiple
portlets. That will be great if that's true and if I can get it
to work as intended.
 
Thanks!
 
Gregor Okorn,
 
FROM: Mike Wilson [[hidden email]]
SENT: Monday, September 21, 2015 11:39 AM
TO: [hidden email]
SUBJECT: [dwr-users] Re: Anyone have DWR3 working on multiple
portlets on a single portal page?
 
While I don't have any portlet example to prove this point,
historically portlet problems have usually revolved around
JavaScript collisions. Ie, the different engine.js inclusions
overwriting each other. If this is not what you are seeing then
ignore the following advice.
 
DWR (2 and 3) supports to have its servlet instantiated
multiple times with different configuration and dwr.xml in the
same webapp.
This is analogous to each portlet having its own DWR servlet.
 
DWR's js-files can then be consumed in a couple of different
ways.
You can use the standard <script> include but this is limited
to connecting to one DWR servlet as it defines objects in the
global js namespace that will collide if another engine.js is
included this way.
 
 
If you instead use the AMD script mechanism (requirejs and
similar)
there are no global objects defined in JS so you can include
any number of DWR servlets' scripts in the same page. You can
read up on DWR's AMD integration here:
https://directwebremoting.atlassian.net/browse/DWR-515 [2]
 
To sum up, I think the problems you are seeing is that your
DWR2 workaround is not working in DWR3, but I think you should
be able to get things working by using official DWR3
functionality and not using hacks or workarounds. But l could
certainly be wrong :-)
 
Best regards
 
Mike
 
Okorn, Gregor C. wrote:
 
Hello,
 
Is there anyone out there that has successfully configured
their portal (WebSphere, Liferay, etc) to use DWR3 with
multiple portlets on a single portal page?? We're using
WebSphere and our home page has over seven portlets. Up until
now we have been using
DWR2.0.5
and extracted the served engine.js file to a common location
for all portlets to share so that each portlet would not try to
include its own engine.js. Including multiple engine.js files
won't work.
That
had been working to the extent that each portlet was able to
make DWR calls independent of the other portlets and the calls
generally succeeded in completing successfully.
 
We're upgrading to DWR3 and I have been struggling to get the
same configuration to work. Do I need to go back to DWR2 or is
there any evidence - any example of someone else already
successfully using
DWR3 in multiple portlets on a single portal page?
 
I get the feeling that DWR3 is simply not able to handle this
scenario. Both DWR3 and DWR2 work great with a single portlet,
but only DWR2 works with multiple portlets. I've been
experimenting and struggling for over two weeks trying to
upgrade to DWR3 with one roadblock after another. Is it
possible? Is there any example of this scenario out there for
me to review? DWR3 in multiple portlets on a single portal
page. Each portlet has its own dwr.xml with its own set of
interfaces. Each portlet makes service calls using DWR to
populate its content and does so without worrying about other
portlets possibly making calls at the same time at startup. Is
this possible?
Is there a single example to verify that this scenario can 
work?
 
Will greatly appreciate any pointer to that elusive example.
 
Gregor Okorn,
 
 
 
Links:
------
[1]
http://dwr.2114559.n2.nabble.com/About-the-delay-on-the-ScriptS
essio
n
-
addScript-tp6334142p6466106.html [2]
https://directwebremoting.atlassian.net/browse/DWR-515
 

 

12