>1 subscriber to topic on machine B, all in same process
Currently, all subscribers will receive the TCP transmission and each overwrite the cache with the same (identical) received message that was serialized, sent, received, deserialized and copied multiple times needlessly. Fixing this would involve giving MessageCache a socket/server that it could synchronize with other MessageCaches running
on other machines/processes. This greatly complicates and fundamentally changes the backend message passing design, and may actually degrade performance for SHM and local caching significantly.
WORKAROUND/DESIGN TIP:
This performance issue can be worked around by creating a re-publisher that receives TCP messages once, then re-publishes them into local process/cache such that other subscribers in this process have direct cache access to the
message that was serialized only once from the source process.
This bug was mostly addressed (for multiple topics in the same unit) by v3.1.2 with message caching. This issue might be fully-addressed by adding CollectionStream republishers as discussed in #11
Given the following scenario:
topic
on machineA
topic
on machineB
, all in same processCurrently, all subscribers will receive the TCP transmission and each overwrite the cache with the same (identical) received message that was serialized, sent, received, deserialized and copied multiple times needlessly. Fixing this would involve giving MessageCache a socket/server that it could synchronize with other MessageCaches running on other machines/processes. This greatly complicates and fundamentally changes the backend message passing design, and may actually degrade performance for SHM and local caching significantly.
WORKAROUND/DESIGN TIP: This performance issue can be worked around by creating a re-publisher that receives TCP messages once, then re-publishes them into local process/cache such that other subscribers in this process have direct cache access to the message that was serialized only once from the source process.