[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 9:11 am, Scott Blum sco...@google.com wrote: Is this in dev mode or prod mode? Do the tests succeed if you run them individually? This is in dev mode. If I disable all of the tests and run them individually they all pass. I've never tried running tests in prod mode but I think I know how and I can give that a try. The next thing to try as well would be to chain all the test methods together. So instead of having test01...testN, I can have the end of test00 start test01 and the end of test01 start test02, etc. Of course that's problematic if a test fails, the next one won't run. And if the delayTestFinish isn't working, the whole thing might just stop before it gets all the way through. But something to try. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
Thanks for the help Scott. The problem is not with the delayTestFinish. Apparently our tests are throwing uncaught exceptions which causes the test to finish. The exception does appear in our logs, but it's one of these: Caused by: com.google.gwt.core.client.JavaScriptException: (Error): Unspecified error. number: -2147467259 description: Unspecified error. at com.google.gwt.dev.shell.BrowserChannelServer.invokeJavascript(BrowserChannelServer.java: 237) Which are not terribly useful (if you have any useful suggestions on dealing with these, I'm all ears) so I moved on to the next exception which was an NPE in our code. That NPE is caused by the tests running on top of each other. So I guess this was my fault for not paying closer attention to the first exception. There is perhaps one possible recommendation that could come out of this and maybe that is that when a test begins (or finishes) it cancels all outstanding timers, commands and pending async callbacks (perhaps optionally). The confusion occurred here because even though the previous test threw an uncaught exception and finished allowing the next test to begin, the outstanding commands started by the previous test were still allowed to run and when they did, they messed up the shared state used by the next test. Of course now I have to go figure out what's causing this uncaught exception to be thrown :-(. And I'm also still confused why the tests pass when run one at a time. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 12:12 pm, John Tamplin j...@google.com wrote: If your test code ultimately involves callbacks from the browser event loop from your own code, you need to wrap all such calls in $entry, which hooks up the uncaught exception handler and the Scheduler hooks. All of the GWT widgets/etc that do this already take care of it, but if you write your own you have to handle it. Look at JsopRequest for an example, but basically if you set a callback foo.callback = function()... then that should instead be foo.callback=$entry(function()...). -- John A. Tamplin Software Engineer (GWT), Google I'm not sure I entirely understand. Are you suggesting that I need to convert all of my DeferredCommand calls to ones that use some new native method implementation so I can wrap my callbacks in $entry? I'm not sure what that accomplishes since DeferredCommand already does that. When it starts a timer, the timer code wraps the callback in $entry. It also seems like a heavy burden to impose on the test developers when GWT is already maintaining a list of callbacks. If there was a DeferredCommand.cancelAll, I could call that manually myself although I'm suggesting that perhaps the GWT test case should do that for us. That would also catch any DeferredCommands that may have been executed in the production code. I'm not sure how to cancel outstanding RPC calls if that's even possible. Also, I see the calls to $entry in GWT source but I don't really have any idea what it does other than hook at the uncaught exception handler as you just noted. And BTW, my apologies for starting this thread so early. I generally try to avoid getting help for things I should have been able to figure out on my own :-( -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 12:51 pm, John Tamplin j...@google.com wrote: If you are only using GWT-supplied APIs, I am not sure how you aren't getting the uncaught exception handler called on those calls. Can you create a small repro case that illustrates the problem? John A. Tamplin Software Engineer (GWT), Google I think you are misunderstanding. The uncaught exception handle *is* getting called. The uncaught exception handler that is setup by the gwttestcase is catching the exception and calling finishTest. The problem is that there are outstanding commands that continue to get executed even though that particular test case just failed and is done. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
On Oct 1, 12:32 pm, Scott Blum sco...@google.com wrote: It sounds like the problem really boils down to less-than-useful stack traces when a native exception is thrown in Dev mode. Ironically, if you ran this in Prod mode, you'd probably get a better stack trace, because we emulate the stack over there. We could probably implement the same sort of stack trace emulation feature in Dev mode + some other stack cleanup to make the exception traceback much nicer. Well, I'd say there are two problems (well three if you include the fact that this exception wasn't being thrown on 2.0.4). The first is that the stack trace is not very friendly. The second is this problem of allowing outstanding commands to keep executing even after a test has finished. Fixing the original exception would make the second problem go away but I would have been able to focus in on the first exception more quickly if it hadn't been for the secondary exceptions that occurred as a result of the first. Definitely providing more information in the stack trace would be great. For example, with a debugger, I can see that the call that was invoked (that threw the exception) is @com.google.gwt.dom.client.DOMImplTrident::dispatchEvent(Lcom/google/ gwt/dom/client/Element;Lcom/google/gwt/dom/client/NativeEvent;). That tells me a little more than I knew before although I don't know yet if that's useful. It's only telling me that something somewhere inside dispatchEvent threw an exception and a ReturnMessage.isException = true was returned. It would be nice to have a stack trace for the code that created this ReturnMessage in response to an exception. This may be a slight tangent, but I know that we often get these types of exceptions in production (so not dev mode here) that are caught by our uncaught exception handler and some of them don't even include a line number or file name. When your logs say an error occurred and the entire message is literally Unspecified error, there's just no way to debug it. I thought I had heard you guys had some way of creating a stack trace of the native javascript exception and then some means of de-obfuscating it. Did I imagine that? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
And one further minor suggestion: for all the places where you have a comment like // implemented in the translatable version of this class, may I suggest adding some additional information on where the source might be located (such as Scott's instructions above). If I had had those, I probably would have figured out the uncaught exception on my own and never started this thread. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] delayTestFinish allowing the next test to begin before the previous one finishes (2.1.0.m3)?
We are trying to upgrade from 2.0.4 to 2.1.0.m3 because of some bugs
in 2.0.4 but in doing so our GWT test cases have begun failing and I
have determined it's because the next test is beginning before the
previous one is complete and they are messing each other up. I know
that delayTestFinish is meant to allow for tests to make use of async
calls and it's been working for us but now it's not.
We have a number of tests that roughly look like this:
public void test03 {
delayTestFinish(12);
rpcService.someServerCall(new AsyncCallback() {
public void onSuccess() {
// Do some stuff
DeferredCommand.addCommand(new Command() {
public void execute() {
// More stuff
finishTest();
}
}
}
}
}
public void test04 {
delayTestFinish(12);
...
}
Our code actually uses DeferredCommands in a long chain of calls but
in short, test04 begins executing before we call finishTest() in the
previous test and I don't think that's supposed to happen.
I could further debug this if someone could explain to me what
implemented in the translatable version of this class means and how
I would debug this translatable version. Any advice on how to
proceed?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Why is getOffsetWidth/getOffsetHeight returning 0 even after onLoad is called for LayoutPanel children?
I posted this over on the normal group but hopefully I can get some
useful responses here. I am attempting to use the new GWT
LayoutPanels and unfortunately they are causing me some grief. We are
using the layout panels (RootLayoutPanel, DockLayoutPanel,
LayoutPanel, etc) to arrange the overall layout of the panel. Then,
the children of one of these panels needs to know how big it is so
that it can size one of its children properly to cause a scroll bar to
appear. As far as I can tell, the only way to do this is by calling
getOffsetWidth and getOffsetHeight. I know that these methods will
return 0 if the widget is not attached but I am finding that in even
putting the calls in onLoad, these methods are still returning 0.
Clearly I don't understand when GWT and/or the browser figures out
what the sizes of these layout panels are.
Below is a simplification of my problem. The widget added to the
RootLayoutPanel cannot determine its size when it is attached to the
DOM. I made sure the widget had something in it and to prove that it
ends up with a size, I added the call to the deferred command to
display the size again.
If you simply replace RootLayoutPanel with RootPanel then it will
output the full window width. What am I doing wrong here?
final FlowPanel testWidget = new FlowPanel() {
protected void onLoad() {
int width = getOffsetWidth();
Window.alert(width= + width); // Outputs 0
}
};
testWidget.add(new Label(Something));
RootLayoutPanel.get().add(testWidget);
Window.alert(width= + width); // Outputs 0
DeferredCommand.add(new Command() {
public void execute() {
int width = testWidget.getElement().getOffsetWidth();
Window.alert(width= + width); // Outputs non-zero
}
}
The value of 0 comes from FF 3.6. IE6 has almost the same problem
except that in the cases where FF returns 0, IE6 is returning 60
(presumably the default size of the label). In both cases, it returns
the full Window width in the DeferredCommand.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Why is getOffsetWidth/getOffsetHeight returning 0 even after onLoad is called for LayoutPanel children?
On Sep 27, 10:29 am, Joel Webber j...@google.com wrote: getOffsetWidth/Height() always read the current state of the widget's backing element, which won't be updated until the layout panels are done laying themselves out. All the layout panels have the potential to be animated, and defer actually laying things out until the end of the current event (in this case, the current event is likely the module startup). This is pretty important for optimization, because layout can be expensive, and you don't want to do any layout work until the app's done fiddling with its structure. That's why you're seeing the correct value in a DeferredCommand -- it's guaranteed to run after the current event. If you really need to force layout earlier, you can call LayoutPanel.forceLayout(). But be careful with this, because you can end up forcing more layouts than you mean to (in the example you show, it would be fine, but if you were to take a similar structure and nest it within another that *also* called forceLayout(), you would end up doing extra work). Hope that helps, joel. Yes Joel, that does help. You're definitely right in that we need to be careful about executing relayouts in the GWT panels or by the browser. The reason the DeferredCommand is not optimal is because it allows the browser to display the UI before all of it has been properly sized (the bits that need to call getOffset*) which results in the browser jumping. The user sees un-initialized panels briefly and then it redraws correctly which can be unpleasant. I think we want to avoid that. I just tried a quick experiment to try your suggestion but the next question is on which component to call forceLayout. In my simple example, just calling RootLayoutPanel.get().forceLayout() inside the onLoad method works but if that FlowPanel is buried somewhere deep in the app, what then? Do I rely on the very top component (onModuleLoad) to call forceLayout/onResize. Does my onLoad call forceLayout on the entire RootLayoutPanel regardless of how deep it is or just its parent? What should happen if the FlowPanel in question is lazily created and added to the DOM later (in which case it's onLoad method is the one place that knows for sure it's been attached). Unless there is some discussion I have missed, I think that perhaps this is worth starting a Best Practices thread. I have some ideas on how to use onLoad and onResize and avoid some of the performance issues and now forceLayout needs to be included in the mix but I won't pretend to have the right or best answer. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: Why is getOffsetWidth/getOffsetHeight returning 0 even after onLoad is called for LayoutPanel children?
On Sep 21, 10:28 pm, Didier DURAND durand.did...@gmail.com wrote: Did you check if you have the issue on all browsers: I have it on Webkit based browsers (Safari + Chrome) but not on IE and FF. I was remiss in leaving that info out. I am having this problem on both IE 6 and FF 3.6. Although IE 6 doesn't return 0 for the first call but rather 60 which is the width of the label. It does return the full window width in the second call like FF. So you're saying that you see different behavior than I am on IE and FF? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Why is getOffsetWidth/getOffsetHeight returning 0 even after onLoad is called for LayoutPanel children?
I am attempting to use the new GWT LayoutPanels and unfortunately they
are causing me some grief. We are using the layout panels
(RootLayoutPanel, DockLayoutPanel, LayoutPanel, etc) to arrange the
overall layout of the panel. Then, the children of one of these
panels needs to know how big it is so that it can size one of its
children properly to cause a scroll bar to appear. Generally you do
this by calling getOffsetWidth and getOffsetHeight. I know that these
methods will return 0 if the widget is not attached but I am finding
that in even putting the calls in onLoad, these methods are still
returning 0. Clearly I don't understand when GWT and/or the browser
figures out what the sizes of these layout panels are.
Below is a simplification of my problem. The widget added to the
RootLayoutPanel cannot determine its size when it is attached to the
DOM. I made sure the widget had something in it and to prove that it
ends up with a size, I added the call to the deferred command to
display the size again.
If you simply replace RootLayoutPanel with RootPanel then it will
output a size. What am I doing wrong here?
final FlowPanel testWidget = new FlowPanel() {
protected void onLoad() {
int width = getOffsetWidth();
System.out.println(width= + width); // Outputs 0
}
};
testWidget.add(new Label(Something));
RootLayoutPanel.get().add(testWidget);
DeferredCommand.add(new Command() {
public void execute() {
int width = testWidget.getElement().getOffsetWidth();
System.out.println(width= + width); // Outputs a non-zero
value
}
});
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Why is getOffsetWidth/getOffsetHeight returning 0 even after onLoad is called for LayoutPanel children?
On Sep 21, 5:21 pm, Gal Dolber gal.dol...@gmail.com wrote:
try with onAttach()
The method onLoad is called by onAttach so overiding onAttach won't
change anything not to mention the fact that the doc for onAttach says
It is strongly recommended that you override {...@link #onLoad()} or
{...@link #doAttachChildren()} instead of this method.
On Sep 21, 5:35 pm, Thomas Broyer t.bro...@gmail.com wrote:
How about implementing RequiresResize and doing the job in onResize()?
That doesn't help because onResize isn't called automatically when the
widgets are initially constructed, only when a browser initiates a
resize event. However I have tried exactly what you suggest by
putting the code I am having trouble with in a RequiresResize.onResize
method and am calling that method in onLoad (so the sizing happens on
both resize and when the widget is initially created). The method
getOffsetWidth still returns 0. I also tried manually calling
onResize on the RootLayoutPanel at the end of my onModuleLoad with the
same result. Only a DeferredCommand seems to result in getOffsetWidth
not returning 0.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Should onbeforeunload work in GWT JSNI?
In GWT, use Window.addWindowClosingHandler and setMessage on the Window.ClosingEvent. Well, how about that? That works. Thank you very much! I'm still a little curious though why the JSNI version doesn't work. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Should onbeforeunload work in GWT JSNI?
I have a need to implement a Are you sure you want to leave?
functionality that can prevent the user from leaving the page (the
same thing Gmail does) when there is unsaved data. All the
documentation I've read says that you can do this by returning a
string from the window.onbeforeunload method. This works if I embed
raw javascript in my html page, but it doesn't seem to work when I
make a native GWT method to do that same thing.
This works:
script type=text/javascript
window.onbeforeunload = function () {
return Hello (in the browser);
};
/script
This doesn't:
private native String addOnBeforeUnloadHandler() /*-{
$wnd.onbeforeunload = function () {
return Hello (in GWT);
};
}-*/;
Any idea why (and I added an alert in that method to verify that it is
being called to add the onbeforeunload)?
If I have to, I can embed the raw script in the HTML and add a hook
into my GWT code, but that's not as pretty.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Why do we define AsyncCallbacks inline?
BTW, the terminology you are looking for is that the inline inner class as you put is called an anonymous inner class while the inner class that is defined on its own (not at the point of a method call) but still inside the outer class is usually just called an inner class but named inner class would also work too. Both of these have been available as in Java from the very beginning. As for why, it is just a matter of taste. It's sometimes a bit more concise to just define an anonymous inner class inline, particularly if the inner class code needs access to variables defined in the calling method. With an anonymous inner class you just have to define the variables or parameters as final and they can be access in the code of the inner class. With a named inner class you have to define extra member variable on the inner class to hold those variables and probably a constructor that accepts them. If you find that it results in a ton of code inside the inner class that all indented, you could just move all that code into a method on the outer class. The code in the inner class can access methods and methods of the outer class. You can even reference methods and methods of the outer class that have the same name as something in the inner class by using the syntax: MyOuter.this.outerMethodCall(). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: ImageBundle using AlphaImageLoader don't allow events to fire properly
I went ahead and filed http://code.google.com/p/google-web-toolkit/issues/detail?id=3951 in case anyone else comes across this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
ImageBundle using AlphaImageLoader don't allow events to fire properly
On IE6, we've run into a problem that we don't know how to work
around. If you create an ImageBundle and use it for buttons in your
application, you will run into problems where clicking on the image
does not fire all the events that it's supposed to. In particular,
the blur event does not get fired.
I have distilled the problem to some basic HTML which will show you
the problem:
The code below is essentially what you get when using an ImageBundle.
If you put focus on the input field and then click the image, the text
box does not lose focus and the blur event does not get fired. If you
click anywhere but the image, the blur event will get fired. If you
use a .gif instead of a .png and the AlphaImageLoader, clicking the
image will cause the blur event to fire. Note that the problem is not
that clicking the image fires no events. If you add an onClick
handler below, it will fire. It just won't fire the blur event. This
is particularly troublesome if your code relies on the blur event to
update your model before handling the click event on the button. In
this case, the click event fires but the blur does not and your click
handler gets a model that's not updated yet (of course we could design
our click handlers to force an update but that's easier said than done
in our application).
Does anyone know of any tricks to work around this? I know there are
some position tricks people use to make links clickable inside such an
area, but here all we have is an img that does have any nested
elements. Is there a way to have the ImageBundle compiler create
a .gif instead of a .png (assuming all the images were .gifs in the
first place)?
html
script type=text/javascript
function onBlur() {
window.alert(Blurred!);
}
/script
body
input type=text onblur=onBlur();/
DIV
clipper
IMG style=FILTER:
progid:DXImageTransform.Microsoft.AlphaImageLoader(src='http://
blueprint.lombardi.com/skins/Default/images/popup/talk_right.png');
height=200 width=200 src=http://blueprint.lombardi.com/
com.lombardi.online.gwt.pages.process.ProcessPage/clear.cache.gif/
/clipper
/DIV
/body
/html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Memory leak in onWindowClosed with RPC call
I'm sorry I didn't mention what browser I was using. IE6 is such a pain point for us, I tend to forget everything else. The problem I am having is running IE6 *not* in hosted mode. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Memory leak in onWindowClosed with RPC call
I just tried another test. I moved the original RPC call from the onWindowClosed method and put it into the onModuleLoad method and inserted a 3 second delay on the server. If I refresh the page only after waiting a few seconds, there is no memory leak, but if I refresh the page immediately after it loads, the memory leak returns. It would appear that the leak isn't specific to an RPC call started during the window closing event but rather to the window closing while there is an outstanding RPC request started any time. If that is the case, then we may have a bigger problem because our application uses two second polling for updates and it's probably not unlikely for a user to leave a page while one of those is outstanding. Can we stop the window closing event until the RPC call returns? If we can, I have a feeling we can only abort it and not actually resume the event and either navigate to the other page or close the browser when the call does return. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Memory leak in onWindowClosed with RPC call
I've tried adding the HTTPRequestImplCleaner.java class to my project that attached to that issue but none of the methods on it seem to be getting called. I did verify that's it's getting instantiated but I suspect that this is based off of old code and no longer works against the current http request implementation (we're using GWT 1.6 now). However, taking a hint here, I have tried something that does appear to give us a workaround. If I have my RPC method return the Request and then immediately call cancel on the request, the request is still sent to the server, but the memory leak disappears. We should be able to do that for our oustanding poll requests as well - keep track of them and cancel them in onWindowClosed. This definitely seems like something that GWT could handle for us and auto-cancel requests when then window is closed. Perhaps that's what the patch in the 1304 issue was meant to do. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Memory leak in onWindowClosed with RPC call
I take back part of what I said above. Calling cancel immediately after the send does prevent the call from getting to the server. It looks like I'll have to stick with my Image hack. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Memory leak in onWindowClosed with RPC call
Well, I did try using a RequestBuilder as I mentioned above and it had the same problem. I also made sure that my callback was not an inner class of the class making the request in case it was capturing the outer class and holding on to it until the response returned. I did find a solution that works but is a bit of a hack. I add an image to the application who's URL points to the servlet I added. That does appear to fire off the call to the server on both navigating away from the page as well as closing the window. It looks something like this: RootPanel.get().add(new Image(url to servlet)); --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Memory leak in onWindowClosed with RPC call
GWT does a great job of letting us avoid the memory leak pitfalls that
often occur in poor browser, but I think I may have found a case that
GWT does not handle and I'm not sure why.
We have an application where we mark a particular page as visited by a
user when they open the page and when they leave the page. To do the
mark when they leave the page, we have added an onWindowClosed
listener that gets called and which makes an RPC call to the server.
I have discovered that this RPC call is causing a cross-page memory
leak. That is if you simply repeatedly hit refresh in the browser
(calling onWindowClosed each time) we are leaking 5 megabytes of
memory on each click. If I comment out the RPC call, the leak goes
away.
The method looks like this:
public void onWindowClosed() {
UserPreferencesServiceAsync serviceAsync =
(UserPreferencesServiceAsync)GWT.create(UserPreferencesService.class);
((ServiceDefTarget)serviceAsync).setServiceEntryPoint(/scr/
UserPreferencesService);
UserPreferencesService.App.getInstance().markProcessViewed(new
AsyncCallbackAdapterVoid());
super.onWindowClosed();
}
The GWT.create itself is not the culprit since I can leave that bit in
and just remove the RPC call and there is no leak. I'm guessing some
part of GWT or the browser has to hold on memory in order to handle
the response from the server which could return after the page is
gone. I will point out that we don't care about the response from the
server.
Does anyone have any ideas as to what would cause this or how to fix
it? I haven't tried it yet, but I'm going to try using a
RequestBuilder and just executing an old-fashioned Servlet call
instead of an RPC call.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Return type of AsyncCallback methods
You can also have your async method return RequestBuilder which will
not dispatch the RPC call, but rather returns the RequestBuilder
already set up and ready to go. You can then make changes to it
before making the call such as setting a timeout. Then you dispatch
the RPC call which will return you the Request object you ask for
above.
RequestBuilder builder = service.myMethod(new AsyncCallback
() {...});
builder.setTimeoutMillis(REQUEST_TIMEOUT);
Request request = builder.send();
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
I don't expect this to necessarily be done any time soon, but is there anything I need to do to make sure that it doesn't get lost? Should I file a feature request? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] HashMap Optimization: return null for put and remove
I have an idea of an optimization of usages of HashMap. I have recently switched from using the FastStringMap to using a normal HashMap since the performance difference isn't as significant as it once was. However, there is one point where I was able to still make the FastStringMap faster. I overrode the put and remove methods and had them return null instead of performing a get to fetch the current value for the keys. In the vast majority of cases, the client never uses the values returned from put or remove which just wastes the gets to look them up. I tried a test that does 100,000 puts and gets and I have found that my version which returns null in the put is almost twice as fast as the version which does not. If the compiler can devirtualize a variable to a java.util.HashMap and it sees that the return value is not used, could the compilter substitute a different method call to a different version of put and remove that just return null (or perhaps nothing)? If you want to see the details of my tests, you can read the blog post I recently put up regarding our usage of FastStringMap: http://development.lombardi.com/?p=797 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
Re: gwt rpc vs json
I will probably write up a summary of my experience with this, but my application just switched from using JSON to RPC as the payload for the initial data set embedded in the original HTML sent from the server on the first request. We've also been slowly converting our JSON HTTP requests to RPC calls. Using RPC is vastly easier since you have an entire Serialization layer you can throw away. However, it does have drawbacks. If you have massive amounts of data, contrary to what gregor said above, the RPC calls will be significantly slower on the client. With JSON, the client does an eval on the data and its ready to go. That is very fast. With RPC, the GWT RPC deserialization code has the parse the data, walk over it, and construct the relevant objects. There is no way that will ever be as fast as eval. That said, the difference is insignificant for most of our RPC calls and for the larger ones (where the amount of data makes for a slow client anyway) we decided that the drop in performance was more than worth the simplicity in our code. There is one upside to this - there's a project in the works that will modify the RPC payload format so that it uses directly eval-able Javascript code so that deserialization mechanism doesn't have to actively parse the payload but can just eval the results into existence. That would immediately speed all RPC calls up for everyone. It also has the added benefit of automatically ensuring that your data model matches on the client and server. We've been in the situation where our data model was different on both side with JSON essentially translating between the two. This has made it difficult to write code that can run on either the server or the client and use the same model. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR:JS collections
I realize I may be jumping in late to this discussion, but Bruce just introduced me to this fine contributors group. At a talk during the Google I/O conference, I mentioned the benefit of using the GWT FastStringMap implementation over the HashMap implementation and I decided to re-run my analysis for 1.5 to see if the 1.5 compiler was smart enough to pick a faster implementation and unfortunately that does not appear to be the case. I hope I'm not hijacking Emily's thread, but I just thought some of you would find my (basic) data interesting for HashMap vs. FastStringMap. I posted my results up on my company development blog if you don't mind me not copy-and-pasting it all here: http://development.lombardi.com/?p=95 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
Upgrade performance from 1.4 to 1.5
We on the team for Lombardi's Blueprint application have just begun the upgrade from GWT 1.4 to 1.5 and we've gathered some performance numbers that some of you might find interesting. We only tested for IE6 since that's our slowest platform, but it looks like the upgrade gets us around a 10% boost with very little work and to the congratulations of the GWT compiler team. Blueprint is a fairly complicated application that is very performance demanding on Javascript and IE6 in particular which is why we've been paying attention to the improvements made in 1.5. For those interested, I've written up a few more details about the upgrade on our blog that you can find here: http://development.lombardi.com/?p=50. If anyone else has any performance data for the upgrade, I'm sure we'd all welcome seeing it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
