gmane.comp.java.dwr.user

[dwr-users] Re: Dwr error on WAS 8.5

David Marginian — 2013-05-17T02:13:42

1) If you change the class you have exposed to not implement an 
interface, does the problem go away?

2) Would you be willing to download the DWR source, place a few 
breakpoints in the code 
(org.directwebremoting.impl.DefaultCreatorManager addCreator), and 
investigate this a bit?

On 05/16/2013 05:50 AM, T THRADINGHAM wrote:

[dwr-users] Dwr error on WAS 8.5

T THRADINGHAM — 2013-05-16T11:50:27

Hi guys,
I wonder if you can help me as I'm experiencing a strange issue with DWR, Spring and Websphere.
 
My setup currently is Websphere 7, Spring 2.5, Dwr 2. We are moving to Websphere 8.5. This causes us the dreaded crossDomainSessionSecurity issue - currently remedied by changing the dwr configuration setting to false as per the current guidelines - and everything is working as expected. 
At some stage we will probably upgrade to Dwr 3 and as we are undergoing a WAS change at the moment I decided to test this out. So I have downloaded Dwr 3 and included the jar in one of my applications. We have a number of apps using Dwr so we have no plan for major changes, but simple configuration changes are ok.
 
So, my setup now is Websphere 8.5, Dwr 3, Spring 2.5. 
When trying to access my app I am getting the following error thrown in the WAs logs -
 
[16/05/13 10:37:03:478 BST] 00000092 startup I org.directwebremoting.impl.StartupUtil logStartup Starting: DwrController v3.0.0-RC2-final-312 on IBM WebSphere A

[dwr-users] Re:

David Marginian — 2013-05-14T23:09:35

The NPE is being thrown on this line:
return 
LocalUtil.classForName(moduleConfig.findFormBeanConfig(formBean).getType());

It looks like the formBean can't be found (best guess).

If you had everything working I would suggest back-tracking your steps.

On 05/14/2013 04:08 PM, Fordemo Only wrote:

[dwr-users]

Fordemo Only — 2013-05-14T22:08:33

Hello
I re-deployed an app with changes, none of which I believed 
affected dwr and I am getting the error below.  Works perfectly in the 
previous environment.  Using 2.0.10, same error when deployed to Tomcat 
6.0.29 and Tomcat 6.0.37.  DWR is in \WEB-INF\lib I am nonplused.  I 
have nothing else to try.  tia.

error snipped
0    
[http-8080-1] ERROR org.directwebremoting.impl.DefaultCreatorManager  
error - Error loading class for creator 'StrutsCreator[pojo00]'.
java.lang.NullPointerException
    at org.directwebremoting.struts.StrutsCreator.getType(StrutsCreator.java:121)
    at org.directwebremoting.impl.DefaultCreatorManager.addCreator(DefaultCreatorManager.java:118)
    at
 org.directwebremoting.impl.DefaultCreatorManager.addCreator(DefaultCreatorManager.java:100)
    at org.directwebremoting.impl.DwrXmlConfigurator.loadCreate(DwrXmlConfigurator.java:274)
    at org.directwebremoting.impl.DwrXmlConfigurator.loadAllows(DwrXmlConfigurator.java:224)
    at org.directwebremotin

[dwr-users] Re: How disable escaped single quotes in JSON/JSONP response with dwr-3.0.0.rc2 and jsonpEnabled

David Marginian — 2013-05-08T23:36:28

I realize I mistakenly responded to Josh directly.  If anyone else is 
interested in this we have created an issue for it - 
http://directwebremoting.org/jira/browse/DWR-602.  Please follow the 
comments there, this issue was just resolved and the fix will be 
available in RC3 or bamboo builds 514 and up.

On 05/07/2013 10:40 AM, Josh Sents wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mike Wilson — 2013-05-08T14:15:30

Ok, thanks for testing, Mark. I still find it strange that IE is leaking
with the script tag approach. I'll keep an eye out for this in our work on
http://bugs.directwebremoting.org/jira/browse/DWR-576.
 
Best regards
Mike
 
Mark Priest wrote:

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< at >public.gmane.org> wrote:



Thanks for testing. Both JS functions trigger closures internally in IE so
it might be those that IE have

[dwr-users] Re: Incomplete reply from server in Chrome - when using location.href or window.parent.location

Mike Wilson — 2013-05-08T14:17:24

Does the last solution seem to work well, Aneesh?
Best regards
Mike 

Aneesh Vijendran wrote:

[dwr-users] How disable escaped single quotes in JSON/JSONP response with dwr-3.0.0.rc2 and jsonpEnabled

Josh Sents — 2013-05-07T16:40:33

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

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-06T18:15:30

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< at >public.gmane.org> wrote:

[dwr-users] Test

David Marginian — 2013-05-06T11:59:08

This is a test message.

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mike Wilson — 2013-05-05T10:50:55

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 globa

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-04T14:07:51

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< at >public.gmane.org> wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

David Marginian — 2013-05-03T15:18:49

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< at >public.gmane.org> wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mike Wilson — 2013-05-03T15:15:56

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

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-03T00:43:41

Yes, I do have time right now.  I will look into the jquery approach.

On May 2, 2013, at 7:58 PM, David Marginian <david-H55tQ8LTKd1xxXtqJ93Y6g< at >public.gmane.org> wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

David Marginian — 2013-05-02T23:58:57

Thanks Mark.  I took a look at JQuery's code and I noticed they use 
execScript instead of eval for IE clients.  This may be something to 
look into.  Do you have some time to experiment with this?

On 05/02/2013 05:41 PM, Mark Priest wrote:

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-02T23:41:50

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

[dwr-users] Re: SVN Tag or revision for 2.0.10

David Marginian — 2013-05-02T21:46:51

Mark, generally I tag each release. But it appears I have failed to do 
that for the 2.x branch since 2.0.8.  There are very few changes in 
2.0.9 and 2.0.10.  And there are probably even fewer changes from 2.0.10 
to trunk.  Let me take a look and see where we are and I may be able to 
push out a 2.0.11 and tag it (I have been planning on doing this soon 
anyway).

On 05/02/2013 03:13 PM, Mark Priest wrote:

[dwr-users] SVN Tag or revision for 2.0.10

Mark Priest — 2013-05-02T21:13:14

Hi,

Is there an svn tag or revision number that corresponds to the 2.0.10
stable release?

Thanks,
Mark

[dwr-users] Re: Memory Leak in Clock Demo DWR 2.0.5 and IE 9

Mark Priest — 2013-05-02T19:29:07

Mike,

I think we have identified where the leak is coming from in IE9.  It
appears that the eval() function leaks memory in IE9.  See
http://support.microsoft.com/kb/2572253 from Microsoft.  We put together a
simple test that demonstrates that eval() leaks and it is attached to this
email.  You can run the test by clicking on the startLeak() link.

I am thinking about reworking DWR so that it does not use eval() in
engine.js.  I would do this by sending over a JSON structure rather than
executable JS and then parsing that structure within engine.js.  I would
extract the function to be called and the args, etc from there.  Not sure
what else to do to stop the leaking in IE.  There does not seem to be a
leak in other browsers.

Thanks,
Mark


On Thu, Mar 28, 2013 at 6:36 PM, Mark Priest <mark.priest-bdq14YP6qtRg9hUCZPvPmw< at >public.gmane.org>wrote:

[dwr-users] Re: Incomplete reply from server in Chrome - when using location.href or window.parent.location

Mike Wilson — 2013-04-19T19:07:59

Great if you want to test it further! If it seems to work well
then that will be the version I check in.

The reason for the problems you've been having is that the 
browser is slow due to many things to do. My thinking is 
that the chained timeouts solution will mirror this and 
thereby "detect" that the browser is going slowly, and give
some more time to wait for the Unload event.

Thanks for your help!
Mike

Aneesh Vijendran wrote: