I’m not accessing it from the client at all though. I just want the server side apps to access it. To answer your thoughts on having synchronization and locking in place, that’s the point of only doing updates from the server side, and with that only from one of the apps. The other one only reads, all I want is to be able to get the latest information out of it from another app.
Essentially what I’m looking for is a shared data entity that can stay within Wowza and persist. I don’t want to use a database.
The SO is never duplicated across apps because it is saved in one spot. It’s a persistent SO, not one that lives in memory.
With that, only one of the apps does the writing. The other one just reads. In the end, all I want it to do is update that SO and then let it go so that something else can get that data. The flush method obviously isn’t working as expected, or something else is going wrong.
I still think it’s a bug but if you’re saying it just isn’t possible then I guess I have to think of either a workaround or a completely different method of attaining my goal.
It’s an interesting idea to create even one more app that I can tell what to do and also get information back from. The biggest issue there is that Wowza can’t have app to app connections on the server side… making that route impossible with Wowza. I do know that it’s possible with FMS, but I don’t want to use FMS.
I don’t need syncing up between servers on a shared object even listener level. I just want to access that written file. I thought that if I actively closed the connection on one app then it should write that info to it and let it go so that something else can go get it. Otherwise, what’s the point of being able to put shared objects anywhere? Their saved location should just be hardcoded because other apps can’t access it anyways until that app shuts down.
Thank you for your help though, definitely appreciated.