QUdpSocket High rate message reading

everybody!

I have a strange issue in working with QUdpSocket and readyRead signal, I can say it's not working as I think,

I create a QUdpSocket and bind it to some port , connect the readyRead signal to my slot and I read all the pending datagram as below

if(!udp_listener)
{
      udp_listener = new QUdpSocket(this);
      connect(udp_listener, SiGNAL(readyRead()), this, SLOT(readBuffers(), Qt::QueuedConnection);
      // the rate of receiving data is 10 msec if i dont put Qt::QueuedConnection, it didn't receive any more signal after first received. why ???
      // change the rate of data to 1 sec and this code work well without Qt::QueuedConnection !!! 
}

udp_lister.bind(Any, 5555);

and my readBuffers code

void readBuffers() {
    QString buffer;
    while(udp_listener->hasPendingDatagrams()) {
           QByteArray received;
           received.resize(udp_listener->pendingDatagramSize());
           udp_listener->readDatagram(received, received.size(), 0,0);
           buffer.append(received);
           // Do some job in 1 msec on buffer and take data from buffer
           if(/* some works done */) buffer.clear(); // almost every time my buffer got cleared 
    }
}

I thought my problems solved with using of Qt::QueuedConnection but today I add another widget to my project and updated it every 100 msec. I don't know how but my slot didn't signal anymore after 2 seconds.

If I change my timer interval or sending data rate to 1 sec, everything is fine.

all of my classes and my widgets live in main program's thread and I don't use another thread, but it seems I should!

so why signals dropped by Qt eventloop?

I check my socket state and it didn't change after Bound.

Thanks in advance

Qt::QueuedConnection tells the signal to be added to the queue, not waiting for it to be treated before continuing.
If the work you do on the received data takes some time, maybe the sending rate is too much higher than the reading rate, resulting in a big signal queue so the qt system blocks the signal?

Don't have the time to test it, but what you say about changing data rate timer makes me think it could be something like that.

Maybe try to measure the time you need to process your data and try some different sending timer lengths to test if you can verify this idea.