Out of band calls in Netscape

[M B HONG 20]

Hi all -

I have a page using asynchronous out of band calls to a Web Service
located on a server that is on the network. The web service is located
on the machine where the pages are being served. It works the way I
want it to, but there are 2 problems I see.
1) There appears to be a memory leak, with every subsequent call it
seems, the memory that netscp.exe takes up keeps climbing.
2) Every time a call to the web service is made, the dropdown lists on
the page (and on the entire browser, including File, Edit, etc, get
killed, meaning if a user is looking at the contents of a dropdownlist,
upon the web service call, it effectively de-selects the dropdownlist.
I'm guessing that the browser's lists get killed when a SOAP response
is received... Thanks in advance for any help you can offer.

 

[Martin Honnen]

M B HONG 20 wrote:

1) There appears to be a memory leak, with every subsequent call it
seems, the memory that netscp.exe takes up keeps climbing.

Are you still working with Netscape 7.0 or is that memory leak also
occuring with 7.2?
It is very difficult to suggest what do against a leak without seeing
your code as usually the leak is a bug that needs to be fixed in the
browser code so all script solutions to the problem are usually then
workarounds rewriting the existing code so that it still works but
hopefully does no longer leak.

2) Every time a call to the web service is made, the dropdown lists on
the page (and on the entire browser, including File, Edit, etc, get
killed, meaning if a user is looking at the contents of a dropdownlist,
upon the web service call, it effectively de-selects the dropdownlist.

That sounds a bit odd, do you have a URL where that can be visited?
Again the question which version(s) of Netscape is that happening with?

 

[M B HONG 20]

Martin - thanks for replying

I am working with Netscape 7.0. I tested the page with Firefox 1.0.3,
and the memory leak appears to be at a much slower rate, and the leak
stops eventually. However, I need to get this working for Netscape
7.0. Here is my code, maybe there is an obvious problem i am not
seeing.

function refresh(callback)
{
var refreshCall = new SOAPCall();
refreshcall.transportURI = "...";
refreshcall.actionURI = "...";
refreshcall.encode (...);
refreshcall.asyncInvoke(
function (response, soapCall, error)
{
var r = hanldeSOAPResponse( response, soapCall,
error);
callback(r);
}
);
}

function handleSOAPResponse (response, soapCall, error)
{
if(error != 0)
{
alert("service failure");
return false;
}
else
{
var fault = response.fault;
if (fault != null)
{
alert (response.fault);
return false;
}
else
{
return response;
}
}
}

function ParseResult(result)
{
var responseValues = result.getParameters(false, {});
var firstValue = responseValues[0].value;
document.Form1.elements["TextBox2"].value = firstValue;
}

window.setInterval('refresh(ParseResult);', 250);





In testing with FireFox 1.0.3 and Netscape 7.0, the memory is much
better handled in FireFox, but the dropdown problem occurs in both
browsers. I don't have a domain or anything you can visit, but
basically if I have a Netscape window with the above script in it open,
and if i open another browser window and open lets say, eBay, the
dropdownlists in that new eBay page will disappear every 250 ms or
whatever interval I have defined for the SOAP call. It is a strange
problem and I'm surprised no one has ever seen it before... anyways
thanks in advance for your help.

p.s. The dropdownlist problem also occurs when the Web Service is on my
localmachine.

 

[Martin Honnen]

M B HONG 20 wrote:

function refresh(callback)
{
var refreshCall = new SOAPCall();
refreshcall.transportURI = "...";
refreshcall.actionURI = "...";
refreshcall.encode (...);

At least that snippet looks as if you create a new SOAPCall object for
each request although you do not need to as you do not seem to have
different transportURI/actionURI/encode arguments. So to try to avoid a
leak you could create only one SOAPCall object and reuse it. As said
that is a suggestion to reorder the code to try to avoid the leak, I
cannot guarantee that it improves anything.