Announcement

Collapse
No announcement yet.
X
Collapse
  • Page of 1
  • Filter
  • Time
Clear All
new posts
Previous template Next
    #1

    Memory leaking with DMI call

    Greetings,

    I'm using 7.0rc2. In the <body> tag of my page I'm doing a javascript call to a function that does a DMI call to a java class. For some reason it's leaking memory. When I load the page the memory usage climbs, quite a bit in fact. Each load uses more memory. When I'm not doing the call, the leak doesn't exist. I don't see any way to destroy the object, so I'm wondering what is the appropriate method do use here? Am I doing something improperly?

    This is for controlling login. I know ISC has some login management features, but they won't work for us because of some 3rd party garbage we use for managing session/login.

    Code:
    <body onLoad=verifySession()>
    Code:
    function verifySession() {
	try {
		isc.DMI.call('VerifySessions', 'VerifySessionCtrl', 'checkSessions', null, 'verifySessionCallback(rpcResponse)');
	}catch (err) {
		isc.warn("An exception occurred. " +
				" Error name: " + err.name + ". Error message: " + err.message);
	}
	
}

function verifySessionCallback(rpcResponse) {
	if (rpcResponse.data == false) {
		//alert(' loginlink: <%=__loginLink%>');
		document.location.href = "<%=__loginLink%>";
	}
}
    Thanks!
    Tags: None
    #2
    Sorry, that's not the offending code. The code causing the leak is just under the <body> tag. Any ideas?

    Code:
    <script>
	window.onbeforeunload = function() { 
		setISCObjectState(<%=UserInterface.GLOBAL_NAV_PANEL_CI%>);
		setISCObjectState(<%=UserInterface.GLOBAL_NAV_PANEL_IA%>);
	setISCObjectState(<%=UserInterface.GLOBAL_NAV_PANEL_BASICS%>); 
		}
</script>
    Code:
    <%-- Saves the state of the left nav TreeGrid or segment pulldown --%>
function setISCObjectState(panel_id) {

	var doRPCCall = false;
	var data;
	<%-- This does a database update call, use wisely --%> 
	switch(panel_id)
	{
	case <%=UserInterface.GLOBAL_NAV_PANEL_BASICS %>:
		data = {panel_id:panel_id, userId:userId, viewState:BasicsTreeGrid.getViewState()};
		doRPCCall = true;
	  	break;
	case <%=UserInterface.GLOBAL_NAV_PANEL_CI %>:
		doRPCCall = true;
		data = {panel_id:panel_id, userId:userId, viewState:CITreeGrid.getViewState()};
		break;
	case <%=UserInterface.GLOBAL_NAV_PANEL_IA %>:
		doRPCCall = true;
		data = {panel_id:panel_id, userId:userId, viewState:NewsTreeGrid.getViewState()};
		break;
	case <%=UserInterface.GLOBAL_NAV_PANEL_NEWS %>:
		doRPCCall = true;
		data = {panel_id:panel_id, userId:userId, viewState:IATreeGrid.getViewState()};
		break;
	case <%=UserInterface.GLOBAL_SEGMENT_PULLDOWN %>:
		try {
			if (IndustrySegmentPulldown) {
				doRPCCall = true;
				data = {panel_id:panel_id, userId:userId, viewState:<%=UserInterface.GLOBAL_SEGMENT_ID%>.getValue()};
			}
		}catch (err){
		}
		break;
		
	}
	if (doRPCCall) {
		try {
		    isc.RPCManager.sendRequest({
				containsCredentials: false,
				actionURL:"/iap/ng/jsp/navDataManager.jsp?cmd=setView",
				useSimpleHttp: false,
				timeoutErrorMessage:"Operation timed out. Please close this window and try again.",
				prompt:"Saving...",
				showPrompt: true,
			    willHandleError:false,
			    data : {
			       viewData: data
			    }
		    });
		}catch (err) {
			isc.warn("An exception occurred. " +
					" Error name: " + err.name + ". Error message: " + err.message);
		}
	}
	
}

    Comment

      #3
      You never mentioned what browser..

      The problem is likely the browser native API onbeforeunload. Doing anything other than returning a prompt message (asking the user not to leave the screen) has very unspecified consequences. Probably the browser has a bug where it's leaking memory because you're initiating a server call that the browser abandons. Best to find another time to save this state off.

      Comment

        #4
        Sorry, my mistake. It's IE 8. If I comment out the RPC call, and leave the rest in, the leak goes away. But your point is well taken. I'll try using another method to save state and see if that solves the problem.

        Thanks.

        Comment

          #5
          Removing the call from unload and putting it somewhere else stopped the leak. So that was indeed the problem.

          Thanks.

          Comment

          Previous template Next
          Working...
          X