I was wrong. We did more testing last night and found that the same behavior was happening with the persistent objects too. What threw us off was that we could see the values of the persistent objects after reconnecting so we thought it was working. In fact, we could no longer modify the values of those objects after all connections had been dropped and then reconnected with one.
It only appears to affect items that are created or manipulated by the Java application. Items created by or modified only by the Flash clients appear to work properly. We're not done testing, so my observations could still be wrong - but I think I'm closer to a conclusion now. Bill Tom Krcha wrote: > So you just need to set SO to persistent and it works fine and don't stop? > > Tom > > 2007/5/6, Interalab <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: > > Never mind. I set the SO to persistent and it works fine. > > Interalab wrote: > > I am having the same problem. Did you ever resolve this? > > > > David Schulberg wrote: > > > >> Hi All, > >> > >> Have a strange problem where client can connect to transient shared > >> object that fires up when server starts but if the client > disconnects > >> and tries to connect back to the shared object it cannot do so. > Whilst > >> a client is connected to the shared object other clients can > >> successfully connect and disconnect as much as they like but as > soon > >> as there are no more clients are connected to the shared object > it is > >> no longer possible for a new client to make a connection to the > SO. In > >> apparent contradiction the Red5 log shows that the shared > object is > >> still alive as the server side event listener keeps triggering > as new > >> updates are made to the SO on the server side. > >> > >> Flash client connects as follows along the same lines as the > >> SimpleChat example > >> > >> nc = new NetConnection(); > >> > >> // connect to the local Red5 server > >> > >> nc.connect("rtmp://localhost/demo"); > >> > >> var so:SharedObject = SharedObject.getRemote("statusSO", > nc.uri, false); > >> > >> // setup the onSync events. > >> > >> so.onSync = Delegate.create(this, handleData); > >> > >> // connect to the SO using the netConnection reference > >> > >> so.connect(nc); > >> > >> On the server side this code (as per Joseph Wamicha's Red5 java > >> example) is called in appStart method > >> > >> private void initTSOwithListener() > >> > >> { > >> > >> log.debug("initTSOwithListener initialized"); > >> > >> //set to false to indicate that this is a non-persistent Shared > Object > >> > >> this.createSharedObject(this.appScope, "statusSO", false); > >> > >> //get the TSO just created... > >> > >> ISharedObject TSO = this.getSharedObject(this.appScope , > "statusSO", > >> false); > >> > >> //add a listener to the TSO... > >> > >> TSO.addSharedObjectListener(new SOEventListener()); > >> > >> //register a handler for the TSO... > >> > >> //TSO.registerServiceHandler("TSOHandler", new SOHandler()); > >> > >> //set the initial attribute value of the TSO > >> > >> TSO.setAttribute("status", "status TSO started!"); > >> > >> } > >> > >> onSharedObjectUpdate method in SOEventListener continues to trigger > >> when my separate server thread is doing > >> > >> TSO.setAttribute("status", read); > >> > >> Which brings me to another question – how should/can I access the > >> shared object I have defined in my Application class which extends > >> ApplicationAdapter when starting a new thread? > >> > >> What I am doing is > >> > >> class NewThread extends Thread { > >> > >> static Application refSO; > >> > >> static ISharedObject TSO; > >> > >> //Thread constructor > >> > >> NewThread(….., Application ref, IScope scope) { > >> > >> refSO = ref; > >> > >> TSO = refSO.getSharedObject(scope, "statusSO", false); > >> > >> } > >> > >> Regards, > >> > >> David Schulberg > >> > >> email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > >> > >> > ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Red5 mailing list > >> [email protected] <mailto:[email protected]> > >> http://osflash.org/mailman/listinfo/red5_osflash.org > >> > >> > > > > _______________________________________________ > > Red5 mailing list > > [email protected] <mailto:[email protected]> > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > _______________________________________________ > Red5 mailing list > [email protected] <mailto:[email protected]> > http://osflash.org/mailman/listinfo/red5_osflash.org > > > ------------------------------------------------------------------------ > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
