[Isomorphic]

I think that this thread contains very valueable information regarding "how to use the framework". It would be great if you could include them in some docs (or, if they are already, link them here).

The need to destroy unused components is covered in the QuickStart Guide ("Architecture Tips"). We agree we could add additional detail in the reference area and perhaps interlink things more.

Is there a list of classes I have to take care of?
What about FormItems or ListGridFields (either class variables or local variables) that I create using new, but then don't use in a DynamicForm or ListGrid via setFields. Would they leak memory as well?

This is nonsense usage (since there is no other way to use these objects), but no, those would not leak memory so long as you do not hold references to them.

What do you mean by "keep them around"?

This was re:DataSources. Keeping a DataSource around means just not calling destroy() on it.

From this thread I get that this way I will leak a DS for every window open/close cycle.

No. Using new DataSource() and assigning a DataSource ID without corresponding destroy() calls will leak DataSources if your application creates an unbounded number of DataSources. DataSource.get() will not.

[edulid]

I think that this thread contains very valueable information regarding "how to use the framework". It would be great if you could include them in some docs (or, if they are already, link them here).

This is true.

The questions summarized are:

• Is there a list of classes I have to take care of? Every com.smartgwt.client.*-class instance that is not used with setFields(), addMember(), setItems() etc?
• What about unused FormItems and ListGridFields?
• How to "keep DataSources around"? ("toolbox" class instance?, singleton class?)
• Is there already a documentation on this?
• If not, can you suggest a best practice here?

As I always use DataSource.get("ds.ds.xml") when I need a datasource operation, for example DataSource.get("ds.ds.xml").fetch(criteria); should I better use global variables instead, for example in a singleton class ?

[Blama]

Hi Isomorphic,

I think that this thread contains very valueable information regarding "how to use the framework". It would be great if you could include them in some docs (or, if they are already, link them here).

See docs for destroy() - it will destroy hierarchically contained components, so yes, destroying a Window destroys components contained within it.

This would not destroy a DataSource or ValuesManager, neither of which is a visual component.

Is there a list of classes I have to take care of?
What about FormItems or ListGridFields (either class variables or local variables) that I create using new, but then don't use in a DynamicForm or ListGrid via setFields. Would they leak memory as well?
Those containing classes I talk about as always subclasses of your Window, VLayout, HLayout, ListGrid, DynamicForm, etc.

Generally, most applications do not destroy DataSources because they create a fixed set of DataSources and keep them around for the entire user session. If you have one of the rare applications which generates a potentially unbounded set of new DataSources on the fly during a session, you do need to destroy() the ones you aren't using any more to avoid leaks.

What do you mean by "keep them around"? This sounds to me like global variables. Can you show an example how you do that?
Do you have a "toolbox" class instance that you pass around the whole application? Is it some singleton class?

In my application I have e.g. a Window-subclass. Every time the window is opened with eg:

editItemWindow = new AddEditItem(record.getAttributeAsLong("ITEM_ID"), false, true);
editItemWindow.show();

it does a

final private DataSource someDS = DataSource.get(dsString);

The Window is then closed by a call to destroy() (will change it to markForDestroy()).

From this thread I get that this way I will leak a DS for every window open/close cycle.
I'd really like to know the best practice here.


The questions summarized are:

• Is there a list of classes I have to take care of? Every com.smartgwt.client.*-class instance that is not used with setFields(), addMember(), setItems() etc?
• What about unused FormItems and ListGridFields?
• How to "keep DataSources around"? ("toolbox" class instance?, singleton class?)
• Is there already a documentation on this?
• If not, can you suggest a best practice here?

I think that this information is very valuable for all users following this thread.

Thank you & Best regards,
Blama

[wing.t.lee]

Per troubleshooting vs DevConsole, Tab "Watch"

Questions:

1. try to click the component such as VLayout, Button as well as Label, Right Click --> Destroy, I find the component immediately disable in the UI as well as the Canvas Count decreasing, but I cannot see any droping of memory (even I click the GC button in about:memory. Is it expected?

2. How to know the memory consumption based on particular VLayout and their Members ...? Can we find this in DevConsole?

3. as mentioned in <http://planet.openbravo.com/blog/finding-and-fixing-memory-leaks-in-a-smartclient-based-application/> that object to be associated by addChild(...) should not be auto destroy. However we find for Canvas that it only have addChild, but no addAutoChild or addMember methods, do you know how can object in Canvas can be auto destroy?

[Isomorphic]

Generally, most applications do not destroy DataSources because they create a fixed set of DataSources and keep them around for the entire user session. If you have one of the rare applications which generates a potentially unbounded set of new DataSources on the fly during a session, you do need to destroy() the ones you aren't using any more to avoid leaks.

ResultSets and ResultTrees also need to be destroy()ed, but only manually created ones. The ResultSet and ResultTree instances automatically created by ListGrid/TreeGrid.fetchData() are automatically destroyed with the component, and also automatically destroyed if you call setData() to replace them with your own data set.

[jpappalardo]

I assume the same goes for ResultSets? Thank you for starting this thread, this is good information.

[edulid]

Good to know, I think I have to take a look at my ValuesManagers.
If I create my client-side datasources by DataSource.get("dsName").fetch( ... ) I don't need to destroy them, right?

[Isomorphic]

See docs for destroy() - it will destroy hierarchically contained components, so yes, destroying a Window destroys components contained within it.

This would not destroy a DataSource or ValuesManager, neither of which is a visual component.

[edulid]

and make sure that you destroy() them if you no longer need them.

Is it enough to call markForDestroy() on the Window these components are created in?

[Isomorphic]

@edulid: the Canvas count and Watch Tab features are actually covered in the QuickStart Guide. It's true that the isc.getKeys() trick might deserve more attention.

@wing.t.lee:

2. what the recommended method to destroy DataSource, DynamicForm and/or ValuesManager in order to prevent such leakage?

Call destroy() on them.

1. is there any propor way to identify the memory leakage for DataSource, DynamicForm and ValuesManager?

Unfortunately, this question is tantamount to saying "how do I identify bugs in my code"? You need to look at when and where your code creates these components and make sure that you destroy() them if you no longer need them.

If you need help doing this, consider our hourly services, since it does not appear you have found any framework issue that we can address from a Support perspective.

[wing.t.lee]

First, per check with Canvas count and Watch Tab, we can identify some leakage object suchas list grid and VLayout. But when we try some form submit for updating data to DB, we find leakage of ValuesManager

As show below that the isc_ValuesManager_3, isc_ValuesManager_15 should be the valuesManager that we created in previous form submit.

So I want to ask,
1. is there any propor way to identify the memory leakage for DataSource, DynamicForm and ValuesManager?
2. what the recommended method to destroy DataSource, DynamicForm and/or ValuesManager in order to prevent such leakage?

17:59:36.718:MUP8:WARN:validation:isc_ValuesManager_3:Validation failed with the following errors:
ismShtNm:- Field is required
ismSttsIdr:- Field is required
ismLngNm:- Field is required
ismMnm:- Field is required
issrShtNm:- Field is required
issrLngNm:- Field is required
ismShtDscn:- Field is required
cnMktCod:- Field is required
prcInpCat:- Field is required
prcPrntFmt:- Field is required
qtnBass:- Field is required
17:59:36.770:MUP8:WARN:validation:isc_ValuesManager_15:Validation failed with the following errors:
ismShtNm:- Field is required
ismSttsIdr:- Field is required
ismLngNm:- Field is required
ismMnm:- Field is required
issrShtNm:- Field is required
issrLngNm:- Field is required
ismShtDscn:- Field is required
cnMktCod:- Field is required
prcInpCat:- Field is required
prcPrntFmt:- Field is required
qtnBass:- Field is required

[edulid]

You can use the Developer Console in a couple of ways to find leaks of components:

1. a "Canvas count" is displayed in the Results tab - if this keeps going up, you are leaking components

2. the "Watch Tab" shows all currently existing components. If new components keep appearing here as you repeat the cycle of your code, you are leaking components

In addition, you can use isc.getKeys(window) to see all the global variables in your application - if on repeating runs you see the total number of variables rising here, take a look at the newly appearing entries.

This is very important information. Shouldn't this be in the FAQs?

[Isomorphic]

In GWT JSNI methods, you must use "$wnd" to refer to the "window" object - see the JSNI basics doc. The second line of your JSNI method should read:

	var keys = [b]$wnd[/b].isc.getKeys ( [b]$wnd[/b] );

[wing.t.lee]

Thx for you reply and we working on the Canvas count as you suggested

But as you mentioned in "isc.getKeys(window)"

I try to write a native javascript code fragment

private native String [] getGlobalVariables() /*-{
	var keys = isc.getKeys ( window );
	return keys;
}-*/;
...

String [] keys = getGlobalVariables();
for ( String key : keys  ) {
	SC.logInfo(key);
}

But from DevConsole Console, I find the error

11:23:23.577:KPR6:INFO:Log:Exception caught: (ReferenceError) 
 stack: $getGlobalVariables@http://127.0.0.1:8080/myapp/myweb/922EEAFD4F0951CE307C8B91D9469D8B.cache.html:3913
execute_10@http://127.0.0.1:8080/myapp/myweb/922EEAFD4F0951CE307C8B91D9469D8B.cache.html:7749
registerKey/<@http://127.0.0.1:8080/myapp/myweb/922EEAFD4F0951CE307C8B91D9469D8B.cache.html:24735
apply@http://127.0.0.1:8080/myapp/myweb/922EEAFD4F0951CE307C8B91D9469D8B.cache.html:233
entry0@http://127.0.0.1:8080/myapp/myweb/922EEAFD4F0951CE307C8B91D9469D8B.cache.html:271
entry_0/<@http://127.0.0.1:8080/myapp/myweb/922EEAFD4F0951CE307C8B91D9469D8B.cache.html:256
isc_c_Page_handleKeyPress@http://127.0.0.1:8080/myapp/myweb/sc/modules/ISC_Core.js:1147
isc_c_EventHandler_handleKeyPress@http://127.0.0.1:8080/myapp/myweb/sc/modules/ISC_Core.js:1182
isc_c_EventHandler__handleNativeKeyPress@http://127.0.0.1:8080/myapp/myweb/sc/modules/ISC_Core.js:1177
isc_c_EventHandler_dispatch@http://127.0.0.1:8080/myapp/myweb/sc/modules/ISC_Core.js:1448
anonymous@http://127.0.0.1:8080/myapp/myweb/sc/modules/ISC_Core.js:71

 fileName: http://127.0.0.1:8080/myapp/myweb/922EEAFD4F0951CE307C8B91D9469D8B.cache.html
 lineNumber: 3913
 columnNumber: 0: isc is not defined

Do you know any clue?

[Isomorphic]

Note on the point about testing with other browsers - even though you don't use other browsers normally, the point here is to confirm whether this is an application-level link (some code is holding onto memory that can't be GC'd) or a Firefox-specific browser bug (the browser itself leaks memory even though the application is correctly releasing objects).

Finally, if you have any other extensions installed in your Firefox, please disable them and confirm the leak still occurs.