3.2.5. Partitions
Partitions introduce a logical entity isolation level concept inside the physical isolation induced by a Domain. They represent another level to separate Publishers and Subscribers beyond Domain and Topic. For a Publisher to communicate with a Subscriber, they have to belong at least to one common partition. In this sense, partitions represent a light mechanism to provide data separation among endpoints:
Unlike Domain and Topic, Partitions can be changed dynamically during the life cycle of the endpoint with little cost. Specifically, no new threads are launched, no new memory is allocated, and the change history is not affected. Beware that modifying the Partition membership of endpoints will trigger the announcement of the new QoS configuration, and as a result, new endpoint matching may occur, depending on the new Partition configuration. Changes on the memory allocation and running threads may occur due to the matching of remote endpoints.
Unlike Domain and Topic, an endpoint can belong to several Partitions at the same time. For certain data to be shared over different Topics, there must be a different Publisher for each Topic, each of them sharing its own history of changes. On the other hand, a single Publisher can share the same data over different Partitions using a single topic data change, thus reducing network overload.
The Partition membership of an endpoint can be configured on the PartitionQosPolicy data member of the PublisherQos or SubscriberQos objects. This member holds a list of Partition name strings. If no Partition is defined for an entity, it will be automatically included in the default nameless Partition. Therefore, a Publisher and a Subscriber that specify no Partition will still be able to communicate through the default nameless Partition.
Warning
Partitions are linked to the endpoint and not to the changes. This means that the endpoint history is oblivious to modifications in the Partitions. For example, if a Publisher switches Partitions and afterwards needs to resend some older change again, it will deliver it to the new Partition set, regardless of which Partitions were defined when the change was created. This means that a late joiner Subscriber may receive changes that were created when another set of Partitions was active.
3.2.5.1. Wildcards in Partitions
Partition name entries can have wildcards following the naming conventions defined by the
POSIX fnmatch
API (1003.2-1992 section B.6).
Entries with wildcards can match several names, allowing an endpoint to easily be included in several Partitions.
Two Partition names with wildcards will match if either of them matches the other one according to fnmatch
.
That is, the matching is checked both ways.
For example, consider the following configuration:
A Publisher with Partition
part*
A Subscriber with Partition
partition*
Even though partition*
does not match part*
, these Publisher and Subscriber
will communicate between them because part*
matches partition*
.
Note that a Partition with name *
will match any other partition except the default Partition.
3.2.5.2. Full example
Given a system with the following Partition configuration:
Participant_1 |
Pub_11 |
{“Partition_1”, “Partition_2”} |
Pub_12 |
{“*”} |
|
Participant_2 |
Pub_21 |
{} |
Pub_22 |
{“Partition*”} |
|
Participant_3 |
Subs_31 |
{“Partition_1”} |
Subs_32 |
{“Partition_2”} |
|
Subs_33 |
{“Partition_3”} |
|
Subs_34 |
{} |
The endpoints will finally match the Partitions depicted on the following table.
Note that Pub_12
does not match the default Partition.
Participant_1 |
Participant_2 |
Participant_3 |
||||||
Pub_11 |
Pub_12 |
Pub_21 |
Pub_22 |
Subs_31 |
Subs_32 |
Subs_33 |
Subs_34 |
|
Partition_1 |
✓ |
✓ |
✕ |
✓ |
✓ |
✕ |
✕ |
✕ |
Partition_2 |
✓ |
✓ |
✕ |
✓ |
✕ |
✓ |
✕ |
✕ |
Partition_3 |
✕ |
✓ |
✕ |
✓ |
✕ |
✕ |
✓ |
✕ |
{default} |
✕ |
✕ |
✓ |
✕ |
✕ |
✕ |
✕ |
✓ |
The following table provides the communication matrix for the given example:
Participant_1 |
Participant_2 |
||||
Pub_11 |
Pub_12 |
Pub_21 |
Pub_22 |
||
Participant_3 |
Subs_31 |
✓ |
✓ |
✕ |
✓ |
Subs_32 |
✓ |
✓ |
✕ |
✓ |
|
Subs_33 |
✕ |
✓ |
✕ |
✓ |
|
Subs_34 |
✕ |
✕ |
✓ |
✕ |
The following piece of code shows the set of parameters needed for the use case depicted in this example.
C++ |
PublisherQos pub_11_qos;
pub_11_qos.partition().push_back("Partition_1");
pub_11_qos.partition().push_back("Partition_2");
PublisherQos pub_12_qos;
pub_12_qos.partition().push_back("*");
PublisherQos pub_21_qos;
//No partitions defined for pub_21
PublisherQos pub_22_qos;
pub_22_qos.partition().push_back("Partition*");
SubscriberQos subs_31_qos;
subs_31_qos.partition().push_back("Partition_1");
SubscriberQos subs_32_qos;
subs_32_qos.partition().push_back("Partition_2");
SubscriberQos subs_33_qos;
subs_33_qos.partition().push_back("Partition_3");
SubscriberQos subs_34_qos;
//No partitions defined for subs_34
|
XML |
<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com">
<data_writer profile_name="pub_11">
<qos>
<partition>
<names>
<name>Partition_1</name>
<name>Partition_2</name>
</names>
</partition>
</qos>
</data_writer>
<data_writer profile_name="pub_12">
<qos>
<partition>
<names>
<name>*</name>
</names>
</partition>
</qos>
</data_writer>
<data_writer profile_name="pub_22">
<qos>
<partition>
<names>
<name>Partition*</name>
</names>
</partition>
</qos>
</data_writer>
<data_reader profile_name="subs_31">
<qos>
<partition>
<names>
<name>Partition_1</name>
</names>
</partition>
</qos>
</data_reader>
<data_reader profile_name="subs_32">
<qos>
<partition>
<names>
<name>Partition_2</name>
</names>
</partition>
</qos>
</data_reader>
<data_reader profile_name="subs_33">
<qos>
<partition>
<names>
<name>Partition_3</name>
</names>
</partition>
</qos>
</data_reader>
</profiles>
|