Interactive UI Elements are not destroyed implicitly by the framework

[Former Member]

Hello Friends

My team has figured out that the interactive UI elements in Web dynpro are not getting destroyed by the framework or JVM so they are getting piled up and are becoming a serious performance issue , I wanted everyone's opinion on that and some way to destroy those elements explicitly

IF some solution is given which does not require much of hard coding then it would be better

Thanks a lot

[Former Member]

Please have a look at the thread given below

[sanyev]

Hi Smriti,

Are you using the recommended JDK version for your version of the server? The version of JDK used will have an impact on garbage collection of UI elements. There are other ways in which UI elements still have reference to active applications.

Check in your webdynpro application that you are not passing any UI Elements or the View itself to other java classes or applications for processing. If you are passing the view or UI elements to other application which might still be active on the server, those applications could still have reference the UI elements and hence not garbage collcted.

Make sure that you are not storing any UI elements or the View itself in any public variables.

Webdynpro applications can me made suspendable. That means if the applications finishes its job it will go to suspend more than exit. A suspendable webdynpro application will hold on to its UI resources. See this document. [https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/102ed591-62a6-2910-94ac-e6038ef7b76e]. make sure you webdynpro applications are not made suspendable.

Sanyev

[Former Member]

Hi ,

Thanks a lot for replying back but I do not think that our application has been put in suspended state as nothing like this has been configured explicitily for the application And also neither the view or the element is passed to some other java class or application. But still the elements are not being destroyed ,the jdk version is 1.5 as suggested ,

[sanyev]

Hi Smriti,

From your wdDoExit() method get hold of your top view container and then call container.destroyAllChildren(); on the container. All the UI elements will be destroyed.

You will not be having access to the view container from wdDoExit() so you will have to store the view container at a publicly accessible place like the controller context.

Regards,

Sanyev

[Former Member]

Hi ,

Thanks a lot for the reply , I too have found out just this way to destroy the elements explicitly, but i was jst wondering that this will add up to the coding part of the WebDynpro which our team wants to minimize, So is there not a solution that may not require this much of hard coding ?

[sanyev]

Hi Smriti,

Memory problems usually require extensive code analysis for identification of the problem. So if you can achieve results with simple code change then that is better. I am not aware of any tool which can solve webdynpro memory issues. There are some profiling tools which can help analyze problems like jprofiler.

Regards,

Sanyev

[p_2_5_6_9_6_0]

Hi,

I am not sure of the Web Dynpro UI Elements are preserved in memory even after the view is terminated.

Eitherways - in order to eliminate the elements - they are actually instances of the Web Dynpro Framework classes (i.e. objects) - you need to set each of the elements to "null" in the wddoexit() method of your view, or controller (as your design permits).

However, to get access to the elements at runtime - you need access to the view that is currently on the screen - this can (as far as i know) be done only in the modifyview() method.

The "view" parameter of this method is the reference to the current view displayed on the screen.

You can use a combination of calls from a custom method that you've written to call modify and exit methods and write code to eliminate the unwanted instances of elements using view.getElement(elementID) and type casting it to a desired type or supertype.

However, I do suggest that you determine that the problem is being caused by the ui element instances and not by an overloaded server.

p256960.

[Former Member]

Actually we found out that , that as other java object Interactive UI elements are not garbage collected by JVM

So they are left in the memory and eat up the resources

[p_2_5_6_9_6_0]

Hi,

The i guess you need to mark UI Elements as null using modify() and exit() methods.

And then call the gc() of the System class. That will invoke the garbage collector - but not mandatorily.

It may happen that the garbage collector will not be invoked as that is the behavious of the JRE itself.

p256960.

[Former Member]

Hi ,

If i destroy those elements though view.getElement.destroy wont those be out of memory or will I have to call the gc explicitly

[p_2_5_6_9_6_0]

Hi,

Setting UI elements to null will not destroy the instances - it will only mark them as ready for garbage collection.

Calling gc() may or may not invoke the Garbage Collector since JRE calls it at specified intervals.

Hope that helps.

p256960.

[Former Member]

And what if i destroy UI elements by .destroy() instead of setting them null , will the instances not be destroyed after tat also

[p_2_5_6_9_6_0]

Hi,

Yes. that will work as well. No need to set to null.

p256960.