Asked  7 Months ago    Answers:  5   Viewed   37 times

I got a problem I am submitting a simple form that has a small data and when I checked in the console tab the URL of ajax seems to be working but after the ajax was processed it will alert an error and it is redirected to my homepage and from the console tab I have this weird error:

Uncaught exception: out of memory

In my ajax I have this simple code only:

$("#add-comment").on('click', function() {

    var id = $('input[name='review_id']').val();
    var customer_id = $('input[name='customer_id']').val();
    var $comment = $('textarea[name='user_comment']').val();

    var sample = "test";

    $.ajax({
        url: 'index.php?route=product/product/writeSubComment',
        type: 'post',
        dataType: 'json',
        data: { text: sample },
        beforeSend: function() {

        },
        success: function(data) {
            console.log(data.test);
        },
        error: function() {
            alert('ERROR!!!');
        }
    });

});

In my PHP controller I have this function

public function writeSubComment() {

    $json = array();

    $json['test'] = $this->request->post['text'];

    $this->response->addHeader('Content-Type: application/json');
    $this->response->setOutput(json_encode($json));

}

 Answers

59

From your description of being redirected to your homepage, but having no code in your ajax response sections to do this, I suspect that the element #add-comment is a submit button in your form.

If this is the case, then your form may be submitting at the same time the ajax code is running when you click the #add-comment submit button. This would explain the out of memory error as the ajax javascript is being expunged while the page redirects.

You would need to prevent your form from submitting, and let the success() or failure sections handle the next step (i.e. refreshing the page, updating the comments box). One way to do this would be to change

$("#add-comment").on('click', function() {
     ... 

to

$('#add-comment').on('click', function(event){ 
    event.preventDefault();
    ...

or change the submit button from

<button type="submit" ...>Add comment</button>

to

<button type="button" ...>Add comment</button>

or change the form tag like this

<form onsubmit="return false;">

This is my best guess from the information I have available.

Wednesday, March 31, 2021
 
axiomer
answered 7 Months ago
80

dataType - delete this one.

Add console.log and open console in Your browser

success: function (data) {
   console.log( data );

show Your console, and then You will see why. Maybe an unwanted char or php error

Second thing - there should be if stament like this (I supposed)

if (data == "1") // it is returning string, not integer.

You can also try to use switch case in success.

Wednesday, March 31, 2021
 
CodeCaster
answered 7 Months ago
38

Try this out.

function loadlink(){
    $('#links').load('test.php',function () {
         $(this).unwrap();
    });
}

loadlink(); // This will run on page load
setInterval(function(){
    loadlink() // this will run after every 5 seconds
}, 5000);

Hope this helps.

Thursday, June 3, 2021
 
Asher
answered 5 Months ago
19

Well it turned out to be a rather specific issue. The memory allocated to other processes was in fact memory leaking from my app. It occurred when I flattened a node with many children, but didn't nil an NSDictionary that contained references to all the pre-flattened nodes. For some reason, this mem leak didn't show up when profiling.

I also found a very good blog post: http://battleofbrothers.com/sirryan/memory-usage-in-sprite-kit on reducing your app's memory footprint. Worth a read if you're trying to optimise.

Monday, August 16, 2021
 
James King
answered 2 Months ago
46
           fs.WriteByte(fileSize[i]);
           prog.Report(i);

You created a fire-hose problem. After deadlocks and threading races, probably the 3rd most likely problem caused by threads. And just as hard to diagnose.

Easiest to see by using the debugger's Debug + Windows + Threads window and look at thread that is executing CreateRandomFile(). With some luck, you'll see it is completed and has written all 99MB bytes. But the progress reported on the console is far behind this, having only reported 125KB bytes written, give or take.

Core issue is the way Progress<>.Report() works. It uses SynchronizationContext.Post() to invoke the ProgressChanged event handler. In a console mode app that will call ThreadPool.QueueUserWorkItem(). That's quite fast, your CreateRandomFile() method won't be bogged down much by it.

But the event handler itself is quite a lot slower, console output is not very fast. So in effect, you are adding threadpool work requests at an enormous rate, 99 million of them in a handful of seconds. No way for the threadpool scheduler to keep up, you'll have roughly 4 of them executing at the same time. All competing to write to the console as well, only one of them can acquire the underlying lock.

So it is the threadpool scheduler that causes OOM, forced to store so many work requests.

And sure, when you call Report() less frequently then the fire-hose problem is a lot less worse. Not actually that simple to ensure it never causes a problem, although directly calling Console.Write() is an obvious fix. Ultimately simple, create a usable UI that is useful to a human. Nobody likes a crazily scrolling window or a blur of text. Reporting progress no more frequently than 20 times per second is plenty good enough for the user's eyes, the console has no trouble keeping up with that.

Sunday, August 29, 2021
 
Mark Ransom
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :