You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a problem (device readout), where I can't allow to suspend sender (the device can't wait), and I do not want to allow infinite channel, since listener could never arrive. But on the other hand I want for listener to be able to "catch up" with sender in case it is attached lately or there is a burst of device events. For that it would be helpful to have a FIFO-buffer inside the channel to cache few last values and evict the oldest one, when new value arrives in case the buffer is full.
The text was updated successfully, but these errors were encountered:
Thanks. Noted. It does make total sense with flows, too. When you share flows (see #1716) it would be also helpful to provide fine-grained configuration on how much data is cached for later arriving subscribers. This is somewhat similar to this use-case.
I have a problem (device readout), where I can't allow to suspend sender (the device can't wait), and I do not want to allow infinite channel, since listener could never arrive. But on the other hand I want for listener to be able to "catch up" with sender in case it is attached lately or there is a burst of device events. For that it would be helpful to have a FIFO-buffer inside the channel to cache few last values and evict the oldest one, when new value arrives in case the buffer is full.
The text was updated successfully, but these errors were encountered: