Looks like some ASI objects are not released. Running the\nfollowing test in instruments revealed that no ASIFormDataRequest\nobjects are ever deallocated:
\n\nvar count = 0;\nfunction runXHR(){\n var xhr = Titanium.Network.createHTTPClient();\n\n xhr.onload = function()\n {\n count++;\n Ti.API.log('available memory:' + Titanium.Platform.availableMemory + ' cnt: ' + count);\n };\n // open the client\n xhr.open('GET','http://www.developedit.com/test.json');\n\n // send the data\n xhr.send();\n}\n\nrunXHR();\n\nsetInterval(function()\n{\n runXHR();\n},1000);\n(from [6e72cfc6d42fc819ccb2632b7ea90f777c3c6307])\n[#2299 state:open] Fixes to set appropriate\nvalues. Resetting bug to open because this actually has to do with\nindefinite proxy retention; see bug for details. \nhttps://github.com/appcelerator/titanium_mobile/commit/6e72cfc6d42f...
Very bad news; this is an endemic problem throughout Titanium,\nthe dreaded \"proxy retention issue.\" This is because we retain\nproxies as part of contexts, and then NEVER release them until the\ncontext is closed. This is especially bad for HTTP requests, as we\nreturn response information in the proxy - that means that over\ntime huge amounts of cruft may accumulate, even with just a few\n(expensive) HTTP requests.
\nMarking this bug CRITICAL even though it may\nnot be completed before 1.5.0.
(from [93f5ab4b4fb667df89641cf97b7495321ee5b02b])\n[#2299] Minor fix to handle some crashers.\n\nhttps://github.com/appcelerator/titanium_mobile/commit/93f5ab4b4fb6...
(from [c499a6e69be9895cce1cf02741b90f679ea34c87])\n[#2299 state:fixed-in-qa] Closer conformance to\nXHR and plugging of memory leak. \nhttps://github.com/appcelerator/titanium_mobile/commit/c499a6e69be9...
How did that last commit just get discovered? It was made before\nthe first one, and... well, who cares. Reopening the bug.
Bumping this down the road, with a note. It's two-pronged: Proxy\nretention issues (how we handle memory warnings is not smart right\nnow, because it LEADS to memory warnings) and problems in Kroll\ninvolving certain objects which should be autoreleased (but never\nare, because they're retained at very bad points in their\nlifecycle).
\nUnfortunately at this time there's no good way to handle\nclearing out stale client responses, simply because there's no good\nway to tell when they're \"stale.\"
\nThis bug should be a high priority target for a\n1.5.1 release due to its critical nature.
Sound objects don't get released until they're explicitly\n.release()d - could a similar approach be taken with ASI, at least\nas a stop gap?
Possibly. Let me know if doing \"this.release()\" inside of your\nonload callbacks helps alleviate memory problems. This will not\nrelease the ASI request, but rather the ASI response (you will have\nto release your XHR objects separately).
\nThere may be a stopgap measure put in place to handle ASI\nresponse memory management, but it will not take care of ASI\nrequest retention.
(from [eb3656b0297a2a28a4b394cd505311415bac7d14])\n[#2299 state:fixed-in-qa] - Don't retain HTTP\nresponses as if they're normal proxies - Cleanup to not use\n'connected' to detect an error vs. success when sending responses;\nwas leading to a race condition that would cause reused HTTP\nclients to stall - Fix for bad juju of separate alloc and init\ncalls in TiModule \nhttps://github.com/appcelerator/titanium_mobile/commit/eb3656b0297a...
Bug #2616 deals with the memory management issues\ndescribed earlier in this bug ticket.
\nBug #2617 deals with XHR compliance in general.
closing this record while noting the 2 open issues Stephen\nlists.
should actually close it maybe