QT with AMQP-CPP library

[SGaist]

Hi,

That's where your issue lies. You don't delete the previous socket notifier before creating a new one. So you have now three active notifiers.

[maragr]

@SGaist So how do I catch any errors and delete the socket notifiers that are not required?

[SGaist]

You should keep track of the file descriptors and if already in use, don't create a new QSocketNotifier for it.

[maragr]

@SGaist Not sure if that is the case. Because the QSocketNotifier: Invalid socket 36 and type 'Read', disabling... shows that the invalid socket is disabled. So it might not be firing the activated signal. I printed out the file descriptor when onSocketActivated gets triggered and all of them are called by the same fd. (in this case fd=40). What am I missing?

Same behavior is observed even when I keep track of all file descriptors and only create new ones when they are not in use. The only difference with this addition is that now the error QSocketNotifier: Invalid socket 36 and type 'Read', disabling... only appears once.

[JonB]

@maragr
Hi. Don't know if I can help butting in. Seems I don't understand what you are asking as well as the others do. Which issue are you trying to address now?

• Multiple calls to onSocketActivated() when no data?
• Message Invalid socket ...?
• Keeping track of which file descriptor numbers you have placed notifiers on?
• Something else?

[maragr]

@JonB i am only trying to address why the onSocketActivated function is being called multiple times even when there is no data?

(The comments above indicated that it might be an issue with creating many socket notifiers per file descriptor. But resolving this by tracking file descriptors and socket notifiers does not solve the above issue. Hope this helps!)

[JonB]

@maragr
OK, now I know where we are :)

The QSocketNotifier uses Linux select() call on the file descriptor. I really think you should assume if it says there is a Read data available when it's called there is. Assuming we are indeed not talking about multi-notifiers per descriptor, then I would question how you get your assertion/evidence that no data is there.

[maragr]

@JonB Hmm that is a good question. My assertion was based on the fact that onSocketActivated was called 6 times before the consume.onReceived function was triggered from the AMQP-CPP library, thus reading the available message. But now, I think there might be something with this function _conn->process(fd, AMQP::readable); (called within the onSocketActivated slot) from AMQP-CPP library that does not register the read call right away once activated signal is received.

Is this a correct assumption that QSocketNotifier will keep triggering the activated signal until the data is read from the socket?

[JonB]

@maragr
I was about to say "no", I thought it would only raise the signal whenever new data arrived, even if old data was left there presently unread. I believe that is what Qt's normal socket readyRead() behaves:

This signal is emitted once every time new data is available for reading from the device. It will only be emitted again once new data is available, such as when a new payload of network data has arrived on your network socket, or when a new block of data has been appended to your device

However, I am not sure that will be case for QSocketNotifier using select() (or maybe poll()) call. That returns whenever any data is available on a file descriptor (so that a read() will complete), I don't think it would know that new data has arrived rather than old data is already lying there.

Unless one or both of these reads the data into a buffer when it first arrives, so that the descriptor is clear for future reads.

Truth is I don't know, you would have to test.

[maragr]

@JonB QSocketNotifier fires until there is data to read on the socket. Marking this as solved.