[Red5] Bug in SharedObjectService.hasSharedObject(IScope, String)
julien Devouassoud
julien.dev at gmail.com
Tue Nov 10 08:03:22 PST 2009
Hey guys, is it not linked to this :
http://jira.red5.org/browse/APPSERVER-370 ?
Sorry i've been so busy / sick / away this year I forgot to submit the
patch.
but i explained it in the post i think
2009/11/10 Tyler Kocheran <rfkrocktk at gmail.com>
> Wouldn't it make more sense to have acquire() actually acquire it
> indefinitely? For what other reason are people using the acquire() method
> for? If we need to define a new method on ISharedObject like
> get/setKeepInMemory(), should we do that? I really do need this
> functionality so I can make sure everything is all triggered correctly. When
> a SharedObject is "resurrected," it is done so without recreating listeners,
> so that's definitely a problem for me. The same is true for persistent and
> transient SO's. It's unreliable functionality. I'd kind of like a way to
> guarantee that I have a grip on the SharedObject no matter what and that it
> won't be killed.
>
>
> On Tue, Nov 10, 2009 at 3:28 AM, Trevor Burton <
> worldofpaper at googlemail.com> wrote:
>
>> This is from an old email in the list archive
>>
>> SNIP
>>
>> seems not to be bug, joachim wrote
>> http://osflash.org/pipermail/red5_osflash.org/2007-July/013429.html
>>
>> >>the SO is non-persistent (you pass "false" when creating it). Such
>> >>SOs are destroyed when the last client disconnects from them. You
>> >>should create the SO in "appConnect", or better use the method
>> >>"getAttribute(scope, name, false)" every time you access if from
>> >>one of your methods. That way the existing SO is returned or it
>> >>is created if it doesn't exist.
>>
>> /SNIP
>>
>> T
>>
>>
>> On Tue, Nov 10, 2009 at 9:14 AM, xk su <suxuekun at gmail.com> wrote:
>>
>>> I have had this problem.
>>> when appStart I have something like
>>> ISharedObject UserListSO = getSharedObject(Scope ,"UserList", true);
>>> UserListSO.setAttribute(conn.getclient().getId(),someinfo);
>>>
>>> and it work well until the last client disconnected from this
>>> SharedObject. and then UserListSO do not work at server side any longer.
>>>
>>> in fact UserListSO = (something connected to "UserList") and when the
>>> last client disconnected from this SO, RED5 delete this (something) , now
>>> UserListSO = null
>>>
>>> and another client connect to "UserList" RED5 find that we don't have
>>> this "UserList" so RED5 create (something connected to "UserList"),but now
>>> UserListSO = null but not this new created (something connected to
>>> "UserList");
>>>
>>> my English is poor hope you can understand me.
>>>
>>> and I do something like this.
>>>
>>> @Override
>>> public void appDisconnect(IConnection conn){
>>>
>>> if (//something that can check this connection is the last client of
>>> the SO){
>>> ISharedObject UserListSO = getSharedObject(Scope ,"UserList",
>>> true);
>>> }
>>> UserListSO.removeAttribute(conn.getclient().getId);
>>> super.appDisconnect(conn);
>>> }
>>>
>>> and it works when the last client disconnected ,and also work well when
>>> this SO has connection again as UserListSO is re-registered to "UserList".
>>> I mean the server side UserListSO now is still connected to UserList
>>> whether this SO has client side connections.
>>>
>>> but I suppose it's not a good way to do like this.
>>> anyone has some better solution?
>>> On Tue, Nov 10, 2009 at 4:10 PM, Trevor Burton <
>>> worldofpaper at googlemail.com> wrote:
>>>
>>>> I think that, rather than being a bug, this is what Shared Object is
>>>> supposed to do. When the last client disconnects the SO is disposed of...
>>>>
>>>> I seem to remember the workaround was to call So.close() and then
>>>> recreate the SO when a client tries to connect to a disposed SO
>>>>
>>>> but i may be remembering incorrectly
>>>>
>>>> T
>>>>
>>>> On Tue, Nov 10, 2009 at 12:01 AM, Tyler Kocheran <rfkrocktk at gmail.com>wrote:
>>>>
>>>>> Ok, just pinpointed the bug. By modifying
>>>>> org.red5.server.so.SharedObjectScope.removeEventListener() to the following
>>>>> code:
>>>>>
>>>>> @Override public void removeEventListener(IEventListener listener) {
>>>>>
>>>>> so.unregister(listener);
>>>>>
>>>>>
>>>>>
>>>>> this.keepOnDisconnect = so.isAcquired(); // so if the SO is
>>>>>> acquired, it won't be accidentally killed
>>>>>
>>>>>
>>>>>
>>>>> super.removeEventListener(listener);
>>>>>
>>>>>
>>>>>
>>>>> if (!so.isPersistentObject() && (so.getListeners() == null ||
>>>>>> so.getListeners().isEmpty())
>>>>>
>>>>> && !so.isAcquired()) { // again, so it won't be killed on
>>>>>> accident
>>>>>
>>>>> getParent().removeChildScope(this);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> for (ISharedObjectListener soListener : serverListeners) {
>>>>>
>>>>> soListener.onSharedObjectDisconnect(this);
>>>>>
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> Basically, the problem is that the SharedObject (or rather, its
>>>>> IScope) is removed when the last person disconnects from it. However, this
>>>>> isn't good because it doesn't obey SharedObject.isAcquired(). If I acquire()
>>>>> a SharedObject, I'm basically expecting it to remain in memory so I can work
>>>>> with it and count on it not disappearing.
>>>>>
>>>>> I'm surprised this bug hasn't been found by anyone else lately. It
>>>>> would seem to throw a lot of functionality off in SharedObjects. Anybody
>>>>> else experiencing similar problems, or noticed this?
>>>>>
>>>>> On Mon, Nov 9, 2009 at 1:00 PM, Tyler Kocheran <rfkrocktk at gmail.com>wrote:
>>>>>
>>>>>> It appears that there is a bug in
>>>>>> org.red5.server.so.SharedObjectService.hasSharedObject(IScope, String). The
>>>>>> method does not account for situations where the SharedObject has been
>>>>>> persisted to disk. The method simply calls IScope.hasChildScope(), which, in
>>>>>> itself, does not account for the unique situation of SharedObjects.
>>>>>>
>>>>>> There also appears to be a problem with transient SharedObjects as
>>>>>> well in this scenario. If I acquire() a transient SharedObject indefinitely,
>>>>>> when the last user disconnects from it, it unregisters itself and
>>>>>> hasChildScope() of course returns false when trying to access it. I haven't
>>>>>> had time to fix this yet, unfortunately it'll have to wait until after my
>>>>>> current project is launched.
>>>>>>
>>>>>> - 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?"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ... 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 at osflash.org
>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Trevor Burton
>>>> http://www.flashmonkey.org
>>>> http://www.infrared5.com
>>>>
>>>> _______________________________________________
>>>> Red5 mailing list
>>>> Red5 at osflash.org
>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Red5 mailing list
>>> Red5 at osflash.org
>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>
>>>
>>
>>
>> --
>> Trevor Burton
>> http://www.flashmonkey.org
>> http://www.infrared5.com
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>
>
>
> --
> ... 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 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://osflash.org/pipermail/red5_osflash.org/attachments/20091110/fa801866/attachment.html>
More information about the Red5
mailing list