Listener Vs Poll

3 posts / 0 new
Last post
Offline
Last seen: 8 years 3 weeks ago
Joined: 10/21/2012
Posts: 18
Listener Vs Poll

In order to test and try out different DDS configurations and QoS settings, I have a small suite of 3 test applications.

The first is a publisher that writes new data every 0.5 seconds.

The second is a subscriber that polls for new data every 1.0 seconds.

The third is a subscriber that uses a listener on the datareader. However, the on_data_available callback contains a sleep(1.0). This means that the callback can only be called once every second.

All readers and writers have the same Qos: RELIABLE_RELIABILITY_QOS, TRANSIENT_LOCAL_DURABILITY_QOS, and KEEP_ALL_HISTORY_QOS.

Both the callback function and the poll routine retrieve data samples using my_reader->take(...).

I would have thought that the two subscribers would behave very similarly. But they do not.

The take function in the polling routine will return 2 data samples each time it is called.

The take function in the listener callback function only ever returns 1 sample and, of course, gets further and further behind as time goes on. If the publisher is killed, this subscriber will continue to happily take samples 1 per second until it has caught up.

Could somebody explain what is happening here please? Why does the listener callback only get 1 sample each time it is called, not 2 like the polling version?

Thanks

Organization:
Gerardo Pardo's picture
Offline
Last seen: 3 weeks 10 hours ago
Joined: 06/02/2010
Posts: 602

Hi,

The first application that polls each second gets 2 samples per poll. No surprises there.

The second application that has a listener is immediately notified as soon as each sample arrives. As these samples are send immediately whenever they are published you always get one sample (each 0.5 seconds) no surprises there either.

The third application is something a DDS application should never do. A DDS application should never sleep of invoke any blocking operations inside a DDS Listener because doing this blocks a infrastructure thread that needs to do other things. In this case you are blocking the very same thread that is processign data on the socket. So what is happening is that as the middleware reads data from the socket, it seems the message, it calls you, you block, and you fall further and further behind.   This explains why you are gettign only one message at a time and falling behind. But as I said this is a bad use of listeners and you will see many other problems as the thread used to call the listener is needed to process data on other Topics, respond to heartbeats, etc. 

Gerardo

Offline
Last seen: 8 years 3 weeks ago
Joined: 10/21/2012
Posts: 18

Thanks Gerardo,

I understand that what I'm doing is bad form. I'm just trying to explore the differences between the different methods of obtaining new data. It seems that there are more differences than I was expecting. There are a few other differences I was not expecting, but it is starting to become clear now. The infrastructure thread responsible for the callback is managing things quite differently to how I was expecting.

Dallas