[Red5] 0.7 SharedObjects... once and for all...

Fri Aug 22 10:32:37 PDT 2008

Well, now I have the splendid problem of SharedObjects not dispatching
update events again. Again, is 0.7.1 going to address this, team?

2008/8/22 Tyler Kocheran <rfkrocktk at gmail.com>

> Jeez, it seems that SharedObjects are really screwed up in Red5. I guess
> I'm glad to find out that I'm not insane and this isn't only happening to
> me, but I'm bummed that there are all of these problems. Do we know in the
> source what's causing this and is 0.7.1 going to fix these issues?  Trevor,
> I'll give it a try and close my SO when all users have disconnected from it.
> Is there a better way to do it rather than just keep a "room" property on
> each client to see what room they're on?
>
>  - TK
>
> 2008/8/22 j d <rr404 at hotmail.fr>
>
> Amazingly dirty.. it's weird that the so (even persistent) crashes like
>> this....
>>
>> Does anyone know it having a service hadler would help the stability ?
>>
>> i've seen quite a few pieces of code with service handlers suposidly
>> stable with SO...
>> just a very wild guess.
>>
>> An other problem i have is with multiple SO on server taken at anytime by
>> clients on their connection.
>>
>> is there conflict or collision probability ?
>>
>> thanks
>>
>>
>>
>>
>> ------------------------------
>>
>> Date: Fri, 22 Aug 2008 14:35:03 +0100
>> From: worldofpaper at googlemail.com
>>
>> To: red5 at osflash.org
>> Subject: Re: [Red5] 0.7 SharedObjects... once and for all...
>>
>>
>>  I've seen this too - if you're controlling your SO on the server then
>> monitor the number of clients who are connected to it - if the last user
>> disconnects call so.close() on it - then recreate it when a new user
>> connects - this is the workaround i've used.
>>
>> T
>>
>> On Fri, Aug 22, 2008 at 7:36 AM, j d <rr404 at hotmail.fr> wrote:
>>
>> At last, someone that seems to have the same problem as me...
>>
>> Does this happen if at one point (except at start) the shared object has
>> no one listening to him anymore ??
>>
>> When it works fine if you keep one guy connected to the SO and play the
>> connect disconnect with other clients does it work fine ? (it should) .
>>
>> I have not solved the problem yet.
>>
>> i noticed however that on the same connection (when it bugs) if you try to
>> reconnect the SO (so.connect(uri...)) you will get the so on your client,
>> BUT !! it seems that it is not actively listening the so for some strange
>> reasons.
>>
>> SOLUTION ..?
>>
>> I tweak for now (i hate it, it's dirty)  i have a client that always stay
>> connected to the SO, for it to keep working fine and registering listeners
>> properly.
>>
>> I hope we find a solution by sunday ...
>>
>>
>>
>>
>> ------------------------------
>>
>> Date: Thu, 21 Aug 2008 17:30:06 -0700
>> From: rfkrocktk at gmail.com
>> To: red5 at osflash.org
>> Subject: Re: [Red5] 0.7 SharedObjects... once and for all...
>>
>>
>>
>> Now I'm getting even WEIRDER SharedObject problems with 0.7. I have a
>> client connecting to a lobby SharedObject that has an object representing
>> each user. This SO is controlled entirely by the server. I'll call a
>> function on the client side to create a new room in the lobby (a new entry)
>> and then close my SharedObject and NetConnection. When I reconnect in the
>> same SWF, it shows the entry as remaining, when I connect with any other SWF
>> file, it does not appear. Is Red5 cacheing SharedObjects or something?
>>
>>  - TK
>>
>> On Fri, Aug 8, 2008 at 1:03 AM, Trevor Burton <
>> worldofpaper at googlemail.com> wrote:
>>
>>  I experienced CASE 3 myself - a workaround that worked in my case was to
>> check on the server-side when someone disconnected whether anyone was still
>> connected to the SO and, if not, call so.close() - then, when the next
>> person connects all is well and sync events fire, etc. etc.
>>
>> this may not work if you're only working client-side
>>
>> T
>>
>>   On Fri, Aug 8, 2008 at 8:57 AM, Anze Cesar <anze.cesar at gmail.com>wrote:
>>
>>   Hi,
>>
>> I'm running Revision: 2887 and am still having major SharedObject issues.
>>
>> What I need is a SO that holds an array of available streams and is
>> updated by red5 on streams changes. It should be read-only for the clients.
>>
>> To outline them: if I create the shared object in my app start method and
>> it's persistent, almost allways red5 will lock up my app. Clients that try
>> to connect to that SO would be successfully connected, but disconnected some
>> 30 seconds later.
>>
>> If the SO is not persistent, it just goes away once all clients disconnect
>> from it. Which would be correct if I wouldn't have a local reference to the
>> SO (I think).
>> I hold a reference to it in my App adapter, as well as have a listener
>> associated with it. The same thing happens even if the SO is persistent. In
>> my listener I just have debug statements, and they get logged until the last
>> client disconnects from the so. When the next client connects, my listener
>> no longer produces any debug noise and the client just gets an empty SO.
>>
>> The way I solved it for now is have a sort of lazy SO creation.
>> On stream publih/stream close I do:
>>
>> ISharedObject streamsSO = getSharedObject(scope, "streams", true);
>> ...
>> streamsSO.setAttribute("list", str);
>>
>> and on the Flex side when successfully connected I do:
>> streamsSO = SharedObject.getRemote("streams",
>> connection.getConnection().uri, true);
>>
>> which as far as I've been able to test works just fine.
>>
>>
>>
>> On Fri, Jul 4, 2008 at 11:28 AM, clemos <cl3mos at gmail.com> wrote:
>>
>> Hi all
>>
>> On Thu, Jul 3, 2008 at 8:56 PM, rfkrocktk <rfkrocktk at gmail.com> wrote:
>>
>> > Case 3:
>> > Persistent SharedObject created on server-side, updated from
>> server-side.
>> > Here's where the big problems lie. Using a remote method, I can invoke a
>> > server-side change on the persistent SharedObject. The VERY FIRST time I
>> > connect to the persistent SharedObject, I can call the remote method and
>> > receive SyncEvents. My code is this:
>> "Application.pso.setAttribute("math",
>> > Math.random())" in my Red5 remote method. After I close my Flash Player
>> > instance and restart it, I receive NO SyncEvents, but I do receive my
>> > NetConnection.call's callback function telling me that the remote method
>> > worked. I also receive debug output from my server that tells me that
>> the
>> > SharedObject's property has changed according to Red5. (I just trace the
>> > value of the property via
>> > System.out.println(Application.so.getAttribute("math"))) I have also
>> tried
>> > using code such as the acquire/release and beginUpdate/endUpdate
>> functions
>> > with the server, but to no avail.
>>
>> Did you receive other exceptions or debug output ?
>> In my experience, this kind of behaviour (a SharedObject that stops
>> working when all clients have disconnected) is due to the fact (bug or
>> feature, I don't know) that SharedObjects become empty when no client
>> is connected to it, and that calling methods on it at this time will
>> throw an exception after which the SharedObject won't work properly.
>> I've been scratching my head for a while until I read the
>> org.red5.components.ClientManager source, and its "removeClient"
>> method, which shows how to prevent this effect by checking that
>> SharedObject.hasAttributes() before doing anything else on it...
>>
>> I'm not sure if it helps (it may be an over-well-known issue) and my
>> knowledge in Java is rather poor, but it's my 2c
>>
>> +++++++
>> Clément
>>
>>
>>
>>
>> --
>> lp,
>> Anže
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>>
>>
>> --
>> Trevor Burton
>> http://www.paperworld3d.com
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>>
>>
>> --
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> And do this, knowing the time, that now it is high time to awake out of
>> sleep;
>> for now our salvation is nearer than when we first believed.
>>
>> ------------------------------
>> Avec une webcam et Messenger partagez vos émotions en vidéo ! Téléchargez
>> gratuitement ! <http://www.windowslive.fr/messenger/>
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>>
>>
>> --
>> Trevor Burton
>> http://www.paperworld3d.com
>>
>> ------------------------------
>> Consultez vos emails sur votre mobile ! Créez un compte Hotmail, c'est
>> gratuit ! <http://www.messengersurvotremobile.com/?d=hotmail>
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> And do this, knowing the time, that now it is high time to awake out of
> sleep;
> for now our salvation is nearer than when we first believed.
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
And do this, knowing the time, that now it is high time to awake out of
sleep;
for now our salvation is nearer than when we first believed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20080822/35e77cfd/attachment-0001.html 