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
Discovered this in my application— didn't matter whether I made the initial unlockAndPublish call from the realtime or non-realtime thread, it still would only go through sometimes. Obviously once everything's properly initialized then the most recent message is properly persisted and it doesn't matter, but it would be nice to reliably see that initial latched message.
I think this could be handled in client code by checking is_running(), except that that method is private; the ideal solution would be for unlockAndPublish itself to make a check somehow, and if the publish loop is not up or not yet waiting on the condition, set a flag so that it knows there's an initial message to be published (or even just introduce a separate method which can be used to seed the publisher from non-realtime with an initial message).
The text was updated successfully, but these errors were encountered:
Discovered this in my application— didn't matter whether I made the initial
unlockAndPublish
call from the realtime or non-realtime thread, it still would only go through sometimes. Obviously once everything's properly initialized then the most recent message is properly persisted and it doesn't matter, but it would be nice to reliably see that initial latched message.I think this could be handled in client code by checking
is_running()
, except that that method is private; the ideal solution would be forunlockAndPublish
itself to make a check somehow, and if the publish loop is not up or not yet waiting on the condition, set a flag so that it knows there's an initial message to be published (or even just introduce a separate method which can be used to seed the publisher from non-realtime with an initial message).The text was updated successfully, but these errors were encountered: