[Isomorphic]

Assuming all of your code represents valid usage (a big assumption), you should not need to change any framework code when you upgrade. There were no intentional changes to the library which would have required changes to your code.

Now please re-read our previous statement:

It's not clear whether there is actually a difference in framework behavior, or whether you inadvertently changed something else in your environment while updating SmartGWT, or whether you have a longstanding usage error. You should troubleshoot the issue, and let us know if you isolate something that appears to be a framework issue. If you do follow up with us, remember to post all required diagnostics.

[wing.t.lee]

2. This stack trace appears to show your own code crashing, specifically, code in a fetchData() callback method. It looks like you may have been assuming that a call to getAttributeAsBoolean() would always return non-null.

It's not clear whether there is actually a difference in framework behavior, or whether you inadvertently changed something else in your environment while updating SmartGWT, or whether you have a longstanding usage error. You should troubleshoot the issue, and let us know if you isolate something that appears to be a framework issue. If you do follow up with us, remember to post all required diagnostics.

Everything is same except the jar library that is bundled in SmartGWT zip from smartclient.com, so it should be caused by the new code between BUILD 2014-03-04 and 2015-02-21.
We don't expect to have change on existing application code that is worked on BUILD 2014-03-04 but not work after upgraded to BUILD 2015-02-21.
Otherwise, please advice what's the code change required if for this upgrade.


So what is code change in this two builds? Also what's the recommended code impact analysis for smartgwt application?

[Isomorphic]

1. No. As previously discussed, this is not possible and would also be useless even if it were possible.

2. This stack trace appears to show your own code crashing, specifically, code in a fetchData() callback method. It looks like you may have been assuming that a call to getAttributeAsBoolean() would always return non-null.

It's not clear whether there is actually a difference in framework behavior, or whether you inadvertently changed something else in your environment while updating SmartGWT, or whether you have a longstanding usage error. You should troubleshoot the issue, and let us know if you isolate something that appears to be a framework issue. If you do follow up with us, remember to post all required diagnostics.

[wing.t.lee]

We've made a couple of minor framework changes:
- we are now re-using IDs for automatically created components. In other words once an automatically generated Tab with ID "isc_Tab_5" (for example) is destroyed, the ID will be re-used and applied to a new tab. This will prevent us from creating thousands of null slots in the case where you saw this.
- we also are deleting the variable names from destroyed widgets rather than simply setting them to null, where this is possible (this is not supported in all browsers - for example Internet Explorer 8 throws an error if you attempt this).

In our testing this gets rid of the problem you're describing in the Add / Remove tabs sample. We are no longer seeing a small slow memory leak in this sample.
You can pick up the next nightly build to test this (dated Feb 14 or above).

This may resolve the issues you're seeing in your application as well, but if, in a real world usage, you're seeing significant memory leakage, it still seems quite likely that some more significant objects are being retained in memory than just the ID strings.
We'd recommend you re test with the new SmartClient / SmartGWT libraries tomorrow regardless. If the problem persists, this may still be an application level issue (not allowing some local references to created objects to go out of scope), or possibly a framework issue, but to comment further we'll need more information.

One aside - if you haven't already, we'd recommend you do perform a real-world test with firebug not running to see if the memory is growing incrementally without ever being reclaimed in a "real world setup".
To exit firebug, you need to close firebug, then close, then reopen firefox -- firebug is not fully closed unless you restart the browser)

Regards
Isomorphic Software

Hello Isomorphic, based on the fixed for about, I have download the SmartGWT Power Edition BUILD 2015-02-21 (latest version) and apply onto my existing application which is well tested and work normally under SmartClient Version: v9.1p_2014-03-04/PowerEdition Deployment (built 2014-03-04) (exception have memory leakage issue).

However I find the exception as attached image. I want to ask


1. can you provide a version of fixing on object leakage based on SmartGWT Power Edition BUILD 2014-03-04?
2. please advice any code change required if we upgrade the SmartGWT framework for same version 4.1p Power Edition but only from 2014-03-04 to 2015-02-21 (which is the latest and including the fix).

[Isomorphic]

We have explained this before, but to cover it again: browsers have various strategies for when exactly they will reclaim memory. In some cases, they will reclaim memory of certain kinds only if the operating system refuses to allocate more memory; the browser will not necessarily attempt to release memory even if performance is somewhat degraded.

So again: memory exhaustion proves a memory leak, nothing else does.

As far as your reported testing times of "three hours later" - are you actually torturing human beings by making them repeatedly press buttons in a sample application thousand of times? Please do not do this. Simply create a loop that repeatedly performs the same action that the button click performs.

As far as reporting any results you may have, report the number of trials, not the time taken to do them. Whether you have automated the repetition of the trials or not, a very high number of repetitions would indicate an extremely slow leak that will never affect real end users, and problems that are merely theoretical and do not affect end users do not qualify as bugs.

Finally, we have repeatedly pointed out:

1. you need to point out what version you are testing, every time. If you are still testing the online Showcase, since the online Showcase has not been updated with the fix for the very slow leak you previously reported, all such efforts are useless.

2. you must not have Firebug active while doing leak tests. You need to in fact disable the Firebug extension and then restart the browser before beginning any leak testing. If you have not been disabling Firebug before doing testing, all of your results are useless; if you have been disabling Firebug before doing testing, you need to explicitly say so.

In sum, we are trying to fix whatever problem is actually affecting your end users. By repeatedly ignoring our advice and focusing on problems that would never affect your end users, you are slowing down the troubleshooting process to the maximum extent (and quite possibly torturing your testing team at the same time :)

[wing.t.lee]

As mentioned we have test the form submit until a very high memory usage already (from 200M at initial, to 1G after 3 hours usage)

And the response time and memory usage is as following

Initial (just open the SmartGWT Showcase Featured Complete Application)
- Response Time: 1.8 seconds for 6 form submissions
- Task Manager: 175M
- about memory: 27.66M (for ShowCase usage)

one hour later
- Response Time: 3.2 seconds for 6 form submission
- Worst case: response time 1-1.2 seconds for one submit, possibly GC in Firefox
- Task Manager: 550M

two hour later
- Response Time: 3.5 seconds for 6 form submission
- Worst case: response time 1.5-1.8 seconds for one submit, possibly GC in Firefox
- Task Manager: 785M

three hour later
- Response Time: 4.2 seconds for 6 form submission
- Worst case: response time 3 seconds for one submit, possibly GC in Firefox
- Task Manager: over 1G
- about memory: 504.64M (for ShowCase usage)

From result, we get the following finding:
"the response time is continuously degrade (from 1.8s to 4.2s) and main usage of memory for firefox is in SmartGWT ShowCase grow continuously grow (from 175M to 1G for Task Manager and 27.66M to 504.64M for about:memory)"

Can you help to check the SmartGWT framework for the memory leakage?

[wing.t.lee]

Once again, memory increases are not evidence of a leak; only memory exhaustion shows a leak.

Please make a note of this as we have also repeated this several times.

There is nothing to investigate or fix here, so we are still waiting for you to take the steps described in our previous post.

1. You should use standard debugging techniques, which are generally the same in any programming language and environment, to find leaks. If you need training in order to do this, or you would like Isomorphic to perform the debugging on your behalf, both are available as commercial services from Isomorphic. However, because you have not identified a bug in SmartGWT, or even shown that there is likely to be one, this is not a service that will be performed by Support; you must purchase it separately

It's not related to debugging techniques issue but we concerning on why there is memory un-released after we submit form in SmartGWT ShowCase, so I will try to prove this in SmartGWT Showcase by loop the action until the memory exhaustion. Will update you the result. If no memory leakage issue, I think that it would release and cannot reach the memory exhaustion.
(FYI that we already experience on memory exhaustion case for the open/close Tab case... but you just treat this as invalid. but if really no memory leakage, why I feel slow perform and memory growth,...)

(If we prove that the case is SmartGWT framework memory leakage issue, it should not be a commercial service, we also suggest isomorphics can perform such test to make sure no memory issue...)

[Isomorphic]

Once again, memory increases are not evidence of a leak; only memory exhaustion shows a leak.

Please make a note of this as we have also repeated this several times.

There is nothing to investigate or fix here, so we are still waiting for you to take the steps described in our previous post.

[wing.t.lee]

10,000 repeats of creating and destroying a set of widgets is unlikely to occur in a real application except over a timeframe of multiple weeks of continuous usage. Even if we could reproduce a slowdown, this would not qualify as a bug, so we will not be attempting to reproduce the slowdown; however, as we have previously noted, the slowdown is likely to be caused by Firebug being active rather than any actual problem with SmartGWT.

We have review the test case as mentioned about and we have choose a more realistic case in SmartGWT ShowCase

My case in my application
our data input operator will update the order (transaction) that have over 300 fields on the screen (including text field, combobox) and the entity is 3 levels. And they need to complete the 80-100 records within 1 hour for every 9AM to 10AM. And it including search data to ListGrid and double click to show 300+ fields entity, and click update to send back the data to server side.


We find the similar example in SmartGWT ShowCase
URL: http://www.smartclient.com/smartgwt/showcase/?sc_selenium=true#featured_complete_app

Test Case: loop 100 times and repeatly update records on the Description Field with new value (only 8 fields in the Form of ShowCase).

Before 100 submit, we find task manager usage 209M and About:Memory usage 26.75MB (after open the SmartGWT ShowCase Featured Complete App and Searched "Category" = "Office Paper Products")
(see attached images: about_memory_init.jpg, task_manager_init_jpg)

After 100 Submit, we find task manager usage grow to 237M and About:Memory grow to 46.62MB (even after click "GC" button for many time in about memory) (see attached images: about_memory_after_execution.jpg, task_manager_after_execution_jpg, screen_after_execution.jpg)

Since there is only 8 fields on the sample app from SmartGWT ShowCase Screen, but for My App that it including over 300 fields data, so the memory leakage is very serious (and after 15-20 submit the memory grow over 300M and response time is significantly impacted to over 10s).

Luckily it would not be too significant performance degrade if we test ShowCase, but if we apply the same coding on a case of a form that have 300 fields and 3 levels entity, it would cause big impact.
It would be more efficent if we check this issue based on SmartGWT ShowCase code as we can reproduce case of memory not release, as well you have much experience on the code detail of SmartGWT ShowCase...
So can your check why SmartGWT ShowCase will have significant grow on memory (by 20M for my test)? How can I fix this in SmartGWT ShowCase?

[Isomorphic]

10,000 repeats of creating and destroying a set of widgets is unlikely to occur in a real application except over a timeframe of multiple weeks of continuous usage. Even if we could reproduce a slowdown, this would not qualify as a bug, so we will not be attempting to reproduce the slowdown; however, as we have previously noted, the slowdown is likely to be caused by Firebug being active rather than any actual problem with SmartGWT.

1. You should use standard debugging techniques, which are generally the same in any programming language and environment, to find leaks. If you need training in order to do this, or you would like Isomorphic to perform the debugging on your behalf, both are available as commercial services from Isomorphic. However, because you have not identified a bug in SmartGWT, or even shown that there is likely to be one, this is not a service that will be performed by Support; you must purchase it separately

2. We have already explained in this thread that the basic advice for avoiding memory leaks is in the QuickStart Guide, and we have explained in more detail in this thread. Nothing further is needed here.

3. There is no list of patches available to review, but there is no point in reviewing one either. We do not provide patches as separate downloads because we cannot test all possible combinations of patches, so you need to download the latest build in order to get the patch that avoids extra nulls in global scope. Once again, the patch resolves an extremely slow, very minor memory leak that would not have any effect on real world usage by end users, so you don't actually need it anyway.

We have covered all of the above points multiple times with you - if you need further help on this point here are your two options:

1. submit a standalone, ready-to-run test case that shows a memory leak that would actually affect typical end users, and is clearly a framework bug

OR

2. purchase Consulting services from Isomorphic, so we can review your application code and identify the source of the leak (which may be a bug in your code)

[wing.t.lee]

Yes, the change was applied to 4.1. Yes, it would affect all objects that have automatically assigned global IDs.

As we keep repeating over and over again: if you are experiencing significant memory leakage, these ID/null pairs you are seeing in global scope are not the problem.

It would take something like weeks of continuous usage of an application without ever reloading the page before this very very slow leak would ever add up to a significant amount of memory.

So if you are seeing a significant memory leak in your application, something that is actually affecting your end users, you should investigate that leak and stop worrying about these ID/null pairs.

Per testing the latest SmartGWT Public ShowCase again and I find that the object leakage is not found

Same step that I test the following link and add a new Tab and Close the new Tab, and I repeatly perform this action for 4 hrs and more than 10000 times on same session.

http://www.smartclient.com/smartgwt/...abs_add_remove

I still find memory leakage and slow response of this action

- Response from extreme fast (less than 0.3s) to slow > 1.2s after 4 hrs repeat work. Experience Slow Response after 4 hrs
- Task Manager FireFox from ~200M to 580M
- about:memory for that URL from <100M to >250M


Question 1:
So if for SmartGWT ShowCase case, how can I check the memory hold up by which object and any program fix need?

Question 2:
Is there any wiki or FAQ explicit list out how to code the SmartGWT application in order to prevent client side memory and object leakage?

Question 3:
As mentioned before, my application is developed and tested on v9.1p_2014-03-04/PowerEdition Deployment (built 2014-03-04) version. You fix is on built 2015-02-14. Can you advice where can I find the list of bugfix or minor enhancement between the two builds 2014-03-04 to 2015-02-14?

[Isomorphic]

Yes, the change was applied to 4.1. Yes, it would affect all objects that have automatically assigned global IDs.

As we keep repeating over and over again: if you are experiencing significant memory leakage, these ID/null pairs you are seeing in global scope are not the problem.

It would take something like weeks of continuous usage of an application without ever reloading the page before this very very slow leak would ever add up to a significant amount of memory.

So if you are seeing a significant memory leak in your application, something that is actually affecting your end users, you should investigate that leak and stop worrying about these ID/null pairs.

[wing.t.lee]

Thx Isomorphic admin

- I'm using SmartGWT SmartClient Version: v9.1p_2014-03-04/PowerEdition Deployment (built 2014-03-04) version, I want to double confrim your fix is on 4.1p Power Edition?

- other than isc_Tab_XXX, I can see other such object with null value after destroy such as isc_ComboBoxItem, isc_DateItem, isc_DoubleItem, isc_HeaderControl, isc_ListGrid, isc_ResultSet, isc_SectionHeader, isc_SectionStack, isc_StaticTextItem, isc_TextAreaItem, isc_TextItem, isc_VLayout. Is the new fix also effective for those component....

- As my application is already in Production and on version "v9.1p_2014-03-04/PowerEdition Deployment (built 2014-03-04)", I want to know can I have some quick fix by removing those isc_ objects based on the old version? (we don't need to perform the regression test in short time due to SmartGWT version upgrade... So if we can remove in destroy method as a quick fix, do you have sample code? do we need some native method?

[Isomorphic]

We've made a couple of minor framework changes:
- we are now re-using IDs for automatically created components. In other words once an automatically generated Tab with ID "isc_Tab_5" (for example) is destroyed, the ID will be re-used and applied to a new tab. This will prevent us from creating thousands of null slots in the case where you saw this.
- we also are deleting the variable names from destroyed widgets rather than simply setting them to null, where this is possible (this is not supported in all browsers - for example Internet Explorer 8 throws an error if you attempt this).

In our testing this gets rid of the problem you're describing in the Add / Remove tabs sample. We are no longer seeing a small slow memory leak in this sample.
You can pick up the next nightly build to test this (dated Feb 14 or above).

This may resolve the issues you're seeing in your application as well, but if, in a real world usage, you're seeing significant memory leakage, it still seems quite likely that some more significant objects are being retained in memory than just the ID strings.
We'd recommend you re test with the new SmartClient / SmartGWT libraries tomorrow regardless. If the problem persists, this may still be an application level issue (not allowing some local references to created objects to go out of scope), or possibly a framework issue, but to comment further we'll need more information.

One aside - if you haven't already, we'd recommend you do perform a real-world test with firebug not running to see if the memory is growing incrementally without ever being reclaimed in a "real world setup".
To exit firebug, you need to close firebug, then close, then reopen firefox -- firebug is not fully closed unless you restart the browser)

Regards
Isomorphic Software

[Isomorphic]

This is assigned to a developer for investigation. We'll update when we have more information for you.

Regards
Isomorphic Software