I have been using DWR-native remote inside our web application.  It works awesome! Now I am creating an API for an external client within the same application.  The client has required that I return valid JSON response.   I have enabled JSON/JSONP and I get the response back from the server with the expected data.     The problem is that the JSON does not pass JSON validation.  Here is a sample site that validates a JSON string http://jsonlint.com/ .  I think the only issue is that the String fields have single quotes escaped. 

Is there a way to disable escaping for the JSON/JSONP remote responses only and leave the escaping enabled DWR-native remote?

Thanks

Josh

Mike,

I didn't see any improvement in the leak with your script tag approach.  It was still leaking about 6.4 mb/hr.   using your script tag approach.  The memory is reclaimed when I refresh the browser.

It's worth mentioning that this leak isn't likely to be a problem for a lot of people.  In our case, customers want our app to run for a week at a time or longer without refreshing the page so any leak starts to be a problem.  I think this is probably a rare requirement, however.  Also, if we could use Chrome or Firefox I don't think we would see any leak.

On Sun, May 5, 2013 at 6:50 AM, Mike Wilson <mikewse-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:

Thanks for testing. Both JS functions trigger closures internally in IE so it might be those that IE have a hard time cleaning up. They don't have a great track record in that department

 

It might be worth trying something that doesn't trigger any closures at all. I'm successfully running the following in my local env:

 

dwr.engine._eval = function(script) {

    if (script == null) return null;

    if (script == "") { dwr.engine._debug("Warning: blank script", true); return null; }

    var elem = document.createElement("script");

    elem.text = script;

    var head = document.getElementsByTagName("head")[0];

    head.appendChild(elem);

    head.removeChild(elem);

};

 

I haven't had time to test a lot of browsers yet, or do any long running resource tests. It would be great if you could try to see what (if any) difference it makes for you?

 

Best regards

Mike

 

Mark Priest wrote:

Mike/David,

Unfortunately, I didn't see any improvement using execScript.  That function is used to do an eval in the global scope and is intended to be used to load long-lived scripts dynamically.

My coworker tried the approach of doing the eval in an iframe as suggested in the Microsoft knowledge base article I referenced.  This was their suggestion for use with IE 7.   The leak was reduced to 40% of the leak we see using eval in the parent.   However,  the memory does not get reclaimed in that case until you close the browser.   When doing the eval without the iframe the memory is reclaimed when the page is refreshed or when you browse to a new page.

We are still planning to go down the road of removing eval altogether and sending JSON back to the browser rather than executable JavaScript.

-Mark

On May 3, 2013, at 11:18 AM, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g@public.gmane.org> wrote:

Just an FYI guys, I tried replacing our _eval last night with a version that uses the execScript and all our tests pass, etc.  So if it fixes the memory leak it will be a good fix to get in.

On Fri, May 3, 2013 at 9:15 AM, Mike Wilson <mikewse-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:

Great find, thanks Mark!

BTW, in my tests I got much lower memory increase than 8MB/hr so it seems it can vary depending on some environmental factor.

Looking forward to your execScript tests! Another alternative could be to add an inline <script> tag containing the script through the DOM.

 

Best regards

Mike

 

Mark Priest wrote:

A simpler way to demonstrate that the leak disappears when removing eval() is to run the clock demo but edit the engine.js like so:

dwr.engine._eval = function(script) {

  if (script == null) return null;

  if (script == "") { dwr.engine._debug("Warning: blank script", true); return null; }

  // dwr.engine._debug("Exec: [" + script + "]", true);

  

  //return eval(script);

  // hard-code the response so we don't call eval

  var batchNum = dwr.engine._nextBatchId - 1;

  dwr.util.setValue("clockDisplay", "" + batchNum);

  dwr.engine._remoteHandleCallback("" + batchNum,'0',0);

};

If you do that then you can test by doing this:

1. Hit the clock demo page and start the clock 

2. Close the browser 

3. Hit the clock demo page again and see the batch ids being printed

That is necessary because I changed _eval() to just print the batch id every time rather than eval the expression (and print the server date/time) and the first time that gets messed up by the call to start the clock.  After the first few minutes the memory usage stabilizes and it leaks very little - maybe 37 kb/hr compared to 8 mb/hr in the unedited demo.

Hi all,

Hello dwr community,

dwr 3.0 rc3 snapshots used to be published on sonatype oss snapshots repository, but that directory is empty - see https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr-core/3.0.0-rc3-SNAPSHOT/

What happened with these files? From dwr sources I see it still uses sonatype parent 6 (see http://svn.directwebremoting.org/dwr/trunk/pom.xml ) so distribution management is inherited and snapshots should be released at sonatype oss snapshots repo.

Thinking out loud - maybe there is some cleanup job and there have been no (successful) dwr 3.0 RC3 snapshot builds for some time.
E.g. there are snapshots of dwr 2.0.9, with date from 2012 (see https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/2.0.9-SNAPSHOT/ )

Kind regards,
Stevo.