Transient SharedObject acquire()/release() Bug

[rfkrocktk]

I think I may have found a bug in the functionality of SharedObjects and I'm just about to start investigating it at the source. For the current app that I'm working on, I need to basically hold my transient SharedObjects in memory for the life of the application. Thus, when I'm creating the SharedObjects when the app starts, I call this code:

sharedObject.acquire();

... with no corresponding call to release(). The thought is that it'll be held indefinitely. The problem is that after one person connects/disconnects from the SharedObject, it's gc'ed. Is this intentional functionality? I'm going to start digging away and see what I can find. 

Thanks, 

 - TK

--
... and they stirred up the Nazarites who had completed their days and they cried aloud to Heaven, saying, "What shall we do with these? Where shall we take them?"

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

[Jens Stündel-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I can confirm this bug. After the last client disconnects from a remote shared object it is destroyed, no matter if it’s acquired or not. My simple workaround is to add an event listener to the shared object which does nothing. Thus it never gets destroyed. But it would be nice, if the acquire functionality could be fixed.

 

Jens

 

 

Von: red5-bounces@... [mailto:red5-bounces@...] Im Auftrag von Tyler Kocheran
Gesendet: Freitag, 6. November 2009 00:28
An: red5@...
Betreff: [Red5] Transient SharedObject acquire()/release() Bug

 

I think I may have found a bug in the functionality of SharedObjects and I'm just about to start investigating it at the source. For the current app that I'm working on, I need to basically hold my transient SharedObjects in memory for the life of the application. Thus, when I'm creating the SharedObjects when the app starts, I call this code:

 

sharedObject.acquire();

 

... with no corresponding call to release(). The thought is that it'll be held indefinitely. The problem is that after one person connects/disconnects from the SharedObject, it's gc'ed. Is this intentional functionality? I'm going to start digging away and see what I can find. 

 

Thanks, 

 - TK

--
... and they stirred up the Nazarites who had completed their days and they cried aloud to Heaven, saying, "What shall we do with these? Where shall we take them?"

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

[Paulo henrique França Silva]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Helo guys,
You don't manipulate SharedObject objects directly. When you create a shared object with createSharedObject(), though it implements the interface ISharedObject, the class that impements ISharedObject isn't SharedObject. Who implements this interface is the SharedObjectScope. So, when you create a SharedObject, what you created is actually a SharedObjectScope.
SharedObjectScope extends from BasicScope which in turn have a protected property called keepOnDisconnect. This property must receive true to his SharedObject do not been destroyed.
unfortunately there is no way to access this variable, so you have to change it to public. Then just do ((BasicScope) yourSoObject). KeepOnDisconnect = true;

Att Paulo Henrique

---

From: newsletter@...
To: red5@...
Date: Fri, 6 Nov 2009 10:09:34 +0100
Subject: Re: [Red5] Transient SharedObject acquire()/release() Bug

I can confirm this bug. After the last client disconnects from a remote shared object it is destroyed, no matter if it’s acquired or not. My simple workaround is to add an event listener to the shared object which does nothing. Thus it never gets destroyed. But it would be nice, if the acquire functionality could be fixed.

 

Jens

 

 

Von: red5-bounces@... [mailto:red5-bounces@...] Im Auftrag von Tyler Kocheran
Gesendet: Freitag, 6. November 2009 00:28
An: red5@...
Betreff: [Red5] Transient SharedObject acquire()/release() Bug

 

I think I may have found a bug in the functionality of SharedObjects and I'm just about to start investigating it at the source. For the current app that I'm working on, I need to basically hold my transient SharedObjects in memory for the life of the application. Thus, when I'm creating the SharedObjects when the app starts, I call this code:

 

sharedObject.acquire();

 

... with no corresponding call to release(). The thought is that it'll be held indefinitely. The problem is that after one person connects/disconnects from the SharedObject, it's gc'ed. Is this intentional functionality? I'm going to start digging away and see what I can find. 

 

Thanks, 

 - TK

--
... and they stirred up the Nazarites who had completed their days and they cried aloud to Heaven, saying, "What shall we do with these? Where shall we take them?"

---

Chegou o Windows 7: Incrivelmente simples! Clique e conheça.
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

[Hugo Flambó]

Check this out:

http://www.zehnet.de/2008/04/11/red5-remote-sharedobject-experience-tips/

BR

Hugo

2009/11/6 Paulo henrique França Silva <phmasters@...>:

> Helo guys,
> You don't manipulate SharedObject objects directly. When you create a shared
> object with createSharedObject(), though it implements the interface
> ISharedObject, the class that impements ISharedObject isn't SharedObject.
> Who implements this interface is the SharedObjectScope. So, when you create
> a SharedObject, what you created is actually a SharedObjectScope.
> SharedObjectScope extends from BasicScope which in turn have a protected
> property called keepOnDisconnect. This property must receive true to his
> SharedObject do not been destroyed.
> unfortunately there is no way to access this variable, so you have to change
> it to public. Then just do ((BasicScope) yourSoObject). KeepOnDisconnect =
> true;
>
> Att Paulo Henrique
> ________________________________
> From: newsletter@...
> To: red5@...
> Date: Fri, 6 Nov 2009 10:09:34 +0100
> Subject: Re: [Red5] Transient SharedObject acquire()/release() Bug
>
> I can confirm this bug. After the last client disconnects from a remote
> shared object it is destroyed, no matter if it’s acquired or not. My simple
> workaround is to add an event listener to the shared object which does
> nothing. Thus it never gets destroyed. But it would be nice, if the acquire
> functionality could be fixed.
>
>
>
> Jens
>
>
>
>
>
> Von: red5-bounces@... [mailto:red5-bounces@...] Im Auftrag
> von Tyler Kocheran
> Gesendet: Freitag, 6. November 2009 00:28
> An: red5@...
> Betreff: [Red5] Transient SharedObject acquire()/release() Bug
>
>
>
> I think I may have found a bug in the functionality of SharedObjects and I'm
> just about to start investigating it at the source. For the current app that
> I'm working on, I need to basically hold my transient SharedObjects in
> memory for the life of the application. Thus, when I'm creating the
> SharedObjects when the app starts, I call this code:
>
>
>
> sharedObject.acquire();
>
>
>
> ... with no corresponding call to release(). The thought is that it'll be
> held indefinitely. The problem is that after one person connects/disconnects
> from the SharedObject, it's gc'ed. Is this intentional functionality? I'm
> going to start digging away and see what I can find.
>
>
>
> Thanks,
>
>  - TK
>
> --
> ... and they stirred up the Nazarites who had completed their days and they
> cried aloud to Heaven, saying, "What shall we do with these? Where shall we
> take them?"
>
> ________________________________
> Chegou o Windows 7: Incrivelmente simples! Clique e conheça.
> _______________________________________________
> Red5 mailing list
> Red5@...
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>

_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org