This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hello there, We've been experiencing the "pq_del_oldest: conflict" message problem and reading the web page you have describing it got me thinking that there must be a better solution for the slow or flaky network connection element. The net result of the slow downstream feed is that the incoming data is delayed (possibly lost) due to the inablity of ldm to make space in the product queue by deleting the oldest data. It seems to me that the downstream side of things should basically be told to disconnect and reconnect at the latest (newest) end of your product queue. Better the for a customer of your ldm to lose data than for you to, certainly for us anyway. I started looking at the code and realised that this might not be easy to do. After all how do you know which connection has obtained the resource lock? Then I thought that maybe you don't have to know. If you signal the "pq_del_oldest: conflict" to the process group , i.e. Let everyone know you've seen EAGAIN, then in handling the signal the process checks the following: 1. Does it have a lock? If not continue 2. If so is the lock on the oldest queue member? If not continue 3. If it is the oldest, free the resource, reset the pq cursor and disconnect from the peer. I was thinking about trying to implement this but I don't have anytime available, certainly not in the near future, so I was wondering if you've been considering this? Paul. -- Paul Hamer phone: 303.497.6342