Process-isolation when testing DDS code

2 posts / 0 new
Log in or register to post comments
Last post
Fri, 11/18/2016 - 14:16
#1
oreccpz
Offline
Last seen: 4 years 4 months ago
Joined: 04/25/2016
Posts: 9
Process-isolation when testing DDS code

I have a use case where it would be really nice to process-isolate my DDS code so I can unit/module test them, possibly in parallel without them interfering with one another.

So far I've come up with using different domains, shmem transport only and randomized topic names.  Are there any other strategies that I could use to get process isolation?  I understand that this is the opposite of what DDS is meant for but from a testing standpoint, it is useful.

Thanks,

Paul

Top
Fri, 11/18/2016 - 18:09
asanchez
asanchez's picture
Offline
Last seen: 4 years 7 months ago
Joined: 11/16/2011
Posts: 50

Hi Paul,


Using domain IDs is the actual mechanism provided by DDS to isolate systems from communicating. Also random topic names looks good to me. I would follow this strategy considering this two suggestions:

  1. I personally prefer to use UPDv4 instead of shared memory. In some cases when you are running many DDS processes in the same machine there could be some shared memory segments that have not been cleaned up properly and might interfere with the unit test, making it fail.
  2. If you are running out of domain Ids, you can either play with the participant ID and initial peers, or with the WireProtocolQosPolicy to limit the number of participants per process and domain ID, so you can get a bigger number of domainIds (in the case of UDPv4, since it is mapped to a port).

Another tool that may be useful in some parts is partitions. The provide isolation at the endpoint (writer or reader ) level, so still participants will exchange discovery information.


- Antonio

Top