Hi, I am tring to send a large data message (>64k) with shared memory transport in two apps. Each app has one data writer and data reader to communicate with the other app. I tried to use the participant QoS to increase the message_size_max for the SHMEM transport like this:
but I got the following error when I run one of my apps (only one data writer and data reader in this app, the other app with matching data reader and data writer is not running).
...NDDS_Transport_Shmem_attach_writer:incompatible shared memory segment found.
Found segment with max message size 65536. Needed 10485760.
It seems there is still a seting of max message size of 65536 somewhere, but there is no other app is running and I suspect that the other builtin transport udpv4 is still active which has a max message size of 65536. So my questions is what I did with the participant QoS is correct or enough to increase the max message size? why there is still a segment with max message size of 65536 and what is it? Is it from udpv4?
thanks!
When a DDS DomainParticipant creates a shared memory segment, the key that is used is based on the domain and participant ID. 2 participants in the same domain will not try to use the same shared memory segment since they will have different participant IDs.
However, if you kill an application (or the application ungracefully exits, i.e, doesn't explicitly call the API to delete the DomainParticipant), then on certainn OSes...Linux being the primary one...the shared memory segment created by the DomainParticipant is not deleted but left around in the operating system.
When an application is started and creates a DomainParticipant in the same domain as the killed app, it may be assigned the same participant ID as the DomainParticipant that was killed, and thus will use the same key for the shared memory segment that it needs.
That's normally OK, the OS will just give that unused shared memory segment to the new DomainParticipant. However, if the new DomainParticipant changes the configuration of of the shared memory segment, e.g., the maximum message size (which is a DDS property, not a shared memory segment property...but never-the-less...is stored by DDS in the shared memory segment), the existing shared memory segment may not be compatible with the configuration required by the new DomainParticipant.
So, what I suspect in your case is that you've been cntrl-c'ing your DDS apps which will leave shared memory segments around. But since they will be reused when you restart your apps, you haven't seen a problem....until you changed the configuration of the message_size_max. Now there's a problem since there's already a shared memory segment for the key being used by the new participant...and it's got an incompatible message_size_max configuration.
What you have to to is either
1) reboot the OS...which gets rid of all shared memory segments
or
2) delete the shared memory segment in question....
You can use the "ipcrm -m <id>", where <id> is the shared memory segment in question...which you will have to use "ipcs -m" to find. You can remove all shared memory segments that have no attached processes if you can't figure out which one it is.
https://www.geeksforgeeks.org/ipcrm-command-in-linux-with-examples/
A quick google on "shared memory Linux" will provide lots of different useful links about understanding and managing shared memory in Linux. E.g.,
https://linuxopsys.com/topics/check-shared-memory-in-linux
https://datacadamia.com/os/linux/shared_memory
Hi Howard, thanks a lot for your note. Yes, you are right, I had apps with different settings running before. After I reboot the OS, it worked.