I have an interesting question maybe. I have two apps that need to access one shared object. I’ve changed up the XML files to point to the “content” directory to save the shared object in. The saving of the information works fine, I don’t have any problems getting that information back out within the same app but if I try to get that information from the other app in that shared object then I can’t get it until I unload the app (generally by reloading the server itself).
Is there another way around that?
I’m getting a pointer to the shared object upon each function call and when I save that information in the first app I am sure to flush and close it. I would expect that shared object to get all closed up and let go. It seems like the second app can’t get in to read that latest information. That seems weird since shared objects are “shared”.
Hi
The only way I can think of is to have the applications talk to each other,
As far as I know a “shared object” is shared between an application’s streams and app instances not between 2 or more applications them selves
Jason
Two different applications cannot share the same shared object. The shared object context in Wowza is at the application instance level. I believe it is the same for fms. The fact that you can save then to the same location will not make this work. It is just not possible.
Charlie
Easiest way to share data between applications is WMSProperties
Richard
Graeme,
From what I understand, it is just not doable to access a SO from one application in another.
For persistent data across apps, you can write to a file with java.io.file API or connect to a database.
Richard
Graeme,
I’m not sure what the possibility of that is, but the idea/request will be noted.
Thanks,
Richard
That’s not an option though. The problem seems to be that the data isn’t written to the shared object until the application actually closes down. That doesn’t make sense as the flush() method should flush the data into the shared object. When I try to access the shared object from another app I can’t get the latest data out of it.
This has to be a bug of some sorts. I shouldn’t have to shut down an app to let go of the shared object, especially since I am also explicitly closing it too on the writing side.
I should have mentioned that this is a persistent shared object, so it’s an actual file that gets created in the content directory (I pointed the application.xml file there for shared objects)
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.
Even if I don’t need them to act like shared objects? They’re just tiny databases to me.
If not, is there another option? Can I create and save text files?
It should be noted that the file does show that is has been updated in Finder (my dev is a mac computer). So the file is getting physically updated.
I hope I’m not beating a dead horse but I would just really really like this to work. That’s all 
Thanks for all the responses so far.
Thanks Richard. How would I make that data persistent though? There will be cases when the writer is not running but the reader is.
I’ve just realized you guys save your shared objects as XML files. Very cool idea. The information is in there as soon as I save it. All I need to do is access that file from another app. Is it just that I can’t access one RSO text file from Wowza from two apps? As in, it’s locked in some way?
Thanks Richard. I’ve figured out a way to get the two apps to exist as one for now until I come up with something better. I did try everything but it looks like the I/O thread just doesn’t let go of the file no matter what until the application is unloaded. Even though the information exists in that file I just have no way to get it until that app dies. It would be incredibly handy if there was a method that could be called that would let go of that SO if you “closed” it by calling close() or release(). Maybe a feature for a future version?
Hi Graeme,
The easiest way would probably be to have another application that just contains your shared object. Then your different flash clients can open up a second NetConnection to that app, in order to communicate with each other.
I think the idea of closing a SO file and opening it in another app is an atypical use-case. Since you typically don’t have control over when a shared object will be accessed, if your app had closed the SO, and a new RTMP connection was made that tried to access the SO, it would break, right? Also, the idea of multiple applications sharing a SO file seems desirable, but how would it work? Each application opens up the file for read/write, with the object duplicated across applications? To do that you would need complicated file or record locking/synchronization methods that are operating system dependent. Instead, if you were to implement this, you would probably make one application handle the file I/O, and make a sort of client/server synchronization where the other apps are the clients. Well, this functionality is already implemented in the RTMP shared object technique.
The “shared” in RTMP “shared objects” refers to automatic synchronization of a single object (data structure) instantiation between flash clients, with synchronization handled by the server. It doesn’t refer to synchronization between servers (a.k.a applications).
Hope this helps.