|
Bug in SharedObjectService.hasSharedObject(IScope, String)
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?"
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
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@...> 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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
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@...> 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
TOn Tue, Nov 10, 2009 at 9:14 AM, xk su <suxuekun@...> 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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
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@...>
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@...> 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
TOn Tue, Nov 10, 2009 at 9:14 AM, xk su <suxuekun@...> 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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
Uh, I hate to break it to you, but JIRA doesn't exist anymore :( And thus, I don't know if this relates to that. However, my patch does fix the issues I'm having! :)
Basically, the usage scenario is this. I have set in place an ISharedObjectSecurityProvider implementation which basically prohibits the creation of SharedObjects by clients. I don't want clients creating SharedObjects, I'll do that on the server so I can at least implement some security and prevent rogue clients from doing wacky stuff. So, I create all of my SharedObjects on application startup, and users connect and disconnect from my index SharedObjects as they please. When I create the transient index SharedObjects, I acquire() them, expecting them to remain in memory so I'll be able to make modifications to them at any point in time without having to "bring them back from the dead." When clients connect and disconnect to/from the SharedObject, no creation is required since the SharedObject is in memory already and won't be closed unless I release() it.
However, this is not the case right now in Red5. Currently, the above usage scenario breaks as soon as all clients disconnect from a SharedObject. Ignoring whether the SharedObject is acquired or not, Red5 closes the SharedObject in the SharedObjectScope.removeEventListener(IEventListener) method when there are no clients connected to the SharedObject any more, thus forcing the SharedObject to have to be recreated whenever all clients disconnect and one tries to reconnect. My fix, posted above, does not kill a SharedObject if it is acquired, regardless of whether there are clients connected to it or not, which would seem to be the desired functionality of acquire(). Otherwise, in the above usage scenario, acquire() seems broken and unable to be used as intended.
On Tue, Nov 10, 2009 at 8:03 AM, julien Devouassoud <julien.dev@...> wrote:
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@...>
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@...> 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
TOn Tue, Nov 10, 2009 at 9:14 AM, xk su <suxuekun@...> 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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
Personally i'm all for it. Apart from the bit where you stop clients creating SOs. It works the way it does right now because that's the way FMS did it (i think) - the dev team were following the original functionality. But as Red5 goes above and beyond all that it would be nice to have an easy way to circumvent something that's really annoying (although not incredibly hard to fix).
+1 for me... T On Wed, Nov 11, 2009 at 1:46 AM, Tyler Kocheran <rfkrocktk@...> wrote:
Uh, I hate to break it to you, but JIRA doesn't exist anymore :(And thus, I don't know if this relates to that. However, my patch does fix the issues I'm having! :)
Basically, the usage scenario is this. I have set in place an ISharedObjectSecurityProvider implementation which basically prohibits the creation of SharedObjects by clients. I don't want clients creating SharedObjects, I'll do that on the server so I can at least implement some security and prevent rogue clients from doing wacky stuff. So, I create all of my SharedObjects on application startup, and users connect and disconnect from my index SharedObjects as they please. When I create the transient index SharedObjects, I acquire() them, expecting them to remain in memory so I'll be able to make modifications to them at any point in time without having to "bring them back from the dead." When clients connect and disconnect to/from the SharedObject, no creation is required since the SharedObject is in memory already and won't be closed unless I release() it.
However, this is not the case right now in Red5. Currently, the above usage scenario breaks as soon as all clients disconnect from a SharedObject. Ignoring whether the SharedObject is acquired or not, Red5 closes the SharedObject in the SharedObjectScope.removeEventListener(IEventListener) method when there are no clients connected to the SharedObject any more, thus forcing the SharedObject to have to be recreated whenever all clients disconnect and one tries to reconnect. My fix, posted above, does not kill a SharedObject if it is acquired, regardless of whether there are clients connected to it or not, which would seem to be the desired functionality of acquire(). Otherwise, in the above usage scenario, acquire() seems broken and unable to be used as intended.
On Tue, Nov 10, 2009 at 8:03 AM, julien Devouassoud <julien.dev@...> wrote:
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@...>
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@...> 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
TOn Tue, Nov 10, 2009 at 9:14 AM, xk su <suxuekun@...> 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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
Hmm ok, i'm not sure that the problem i Had, anyway i looked into the 0.9 source code to try to remember what i did to fix my problem which was. When the server creates a persistant SO and at one point all users disconnect from it : the SO stays but the scope disapears => the clients can't ever receive the Updates from this SO.
I found that : in server/BasicScope.java, we have the boolean keepOnDisconnect that is set to false and never set to true by the code. Maybe it's intended but what i did is : set it to the value of boolean "persistent" in the constructor; which seems logical from the way i understood the persistent aspect.
I have no dev environment at the moment so i can't send a patch but can you look very quickly into it ? tell me if i'm mistaking on the behaviour it should have ? Cheers
2009/11/11 Trevor Burton <worldofpaper@...>
Personally i'm all for it. Apart from the bit where you stop clients creating SOs.
It works the way it does right now because that's the way FMS did it (i think) - the dev team were following the original functionality. But as Red5 goes above and beyond all that it would be nice to have an easy way to circumvent something that's really annoying (although not incredibly hard to fix).
+1 for me...
TOn Wed, Nov 11, 2009 at 1:46 AM, Tyler Kocheran <rfkrocktk@...> wrote:
Uh, I hate to break it to you, but JIRA doesn't exist anymore :(And thus, I don't know if this relates to that. However, my patch does fix the issues I'm having! :)
Basically, the usage scenario is this. I have set in place an ISharedObjectSecurityProvider implementation which basically prohibits the creation of SharedObjects by clients. I don't want clients creating SharedObjects, I'll do that on the server so I can at least implement some security and prevent rogue clients from doing wacky stuff. So, I create all of my SharedObjects on application startup, and users connect and disconnect from my index SharedObjects as they please. When I create the transient index SharedObjects, I acquire() them, expecting them to remain in memory so I'll be able to make modifications to them at any point in time without having to "bring them back from the dead." When clients connect and disconnect to/from the SharedObject, no creation is required since the SharedObject is in memory already and won't be closed unless I release() it.
However, this is not the case right now in Red5. Currently, the above usage scenario breaks as soon as all clients disconnect from a SharedObject. Ignoring whether the SharedObject is acquired or not, Red5 closes the SharedObject in the SharedObjectScope.removeEventListener(IEventListener) method when there are no clients connected to the SharedObject any more, thus forcing the SharedObject to have to be recreated whenever all clients disconnect and one tries to reconnect. My fix, posted above, does not kill a SharedObject if it is acquired, regardless of whether there are clients connected to it or not, which would seem to be the desired functionality of acquire(). Otherwise, in the above usage scenario, acquire() seems broken and unable to be used as intended.
On Tue, Nov 10, 2009 at 8:03 AM, julien Devouassoud <julien.dev@...> wrote:
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@...>
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@...> 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
TOn Tue, Nov 10, 2009 at 9:14 AM, xk su <suxuekun@...> 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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
Yes. I've attached a patch.
Basically, everytime that someone disconnects from a SharedObject, when SharedObjectScope.removeEventListener(IEventListener) is triggered, we set BasicScope.keepOnDisconnect to so.isAcquired(). It works as expected, if the last client disconnects from the SharedObject and it's acquired, it will remain in memory. Otherwise, it'll be wiped out by either the call to super.removeEventListener() or in the "if" statement below it. It makes sense when you look at the code :)
So in layman's terms, if user 1 disconnects from a SharedObject and it's not acquired, it'll be wiped out. However, if user 1 disconnects from a SharedObject that is acquired, it will be kept in memory indefinitely, until it is released. When it is released, it will remain in memory until at least one client connects to it and then disconnects from it. Does that make sense?
-- ... 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
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
@Trevor The part where I'm stopping clients from creating SO's is because of my own security interests. It doesn't really have too much to do with this issue, but it's the environment in which I discovered the bug. If you want to look into SharedObject security, see the ISharedObjectSecurity interface and the MultiThreadedApplicationAdapter.registerSharedObjectSecurity(ISharedObjectSecurity) method. No cause for alarm :)
On Tue, Nov 10, 2009 at 11:26 PM, Trevor Burton <worldofpaper@...> wrote:
Personally i'm all for it. Apart from the bit where you stop clients creating SOs.
It works the way it does right now because that's the way FMS did it (i think) - the dev team were following the original functionality. But as Red5 goes above and beyond all that it would be nice to have an easy way to circumvent something that's really annoying (although not incredibly hard to fix).
+1 for me...
TOn Wed, Nov 11, 2009 at 1:46 AM, Tyler Kocheran <rfkrocktk@...> wrote:
Uh, I hate to break it to you, but JIRA doesn't exist anymore :(And thus, I don't know if this relates to that. However, my patch does fix the issues I'm having! :)
Basically, the usage scenario is this. I have set in place an ISharedObjectSecurityProvider implementation which basically prohibits the creation of SharedObjects by clients. I don't want clients creating SharedObjects, I'll do that on the server so I can at least implement some security and prevent rogue clients from doing wacky stuff. So, I create all of my SharedObjects on application startup, and users connect and disconnect from my index SharedObjects as they please. When I create the transient index SharedObjects, I acquire() them, expecting them to remain in memory so I'll be able to make modifications to them at any point in time without having to "bring them back from the dead." When clients connect and disconnect to/from the SharedObject, no creation is required since the SharedObject is in memory already and won't be closed unless I release() it.
However, this is not the case right now in Red5. Currently, the above usage scenario breaks as soon as all clients disconnect from a SharedObject. Ignoring whether the SharedObject is acquired or not, Red5 closes the SharedObject in the SharedObjectScope.removeEventListener(IEventListener) method when there are no clients connected to the SharedObject any more, thus forcing the SharedObject to have to be recreated whenever all clients disconnect and one tries to reconnect. My fix, posted above, does not kill a SharedObject if it is acquired, regardless of whether there are clients connected to it or not, which would seem to be the desired functionality of acquire(). Otherwise, in the above usage scenario, acquire() seems broken and unable to be used as intended.
On Tue, Nov 10, 2009 at 8:03 AM, julien Devouassoud <julien.dev@...> wrote:
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@...>
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@...> 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
TOn Tue, Nov 10, 2009 at 9:14 AM, xk su <suxuekun@...> 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@...> 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@...> 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@...> 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- Trevor Burton http://www.flashmonkey.orghttp://www.infrared5.com
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
And yeah, it works :) On Wed, Nov 11, 2009 at 9:17 AM, Tyler Kocheran <rfkrocktk@...> wrote:
Yes. I've attached a patch.
Basically, everytime that someone disconnects from a SharedObject, when SharedObjectScope.removeEventListener(IEventListener) is triggered, we set BasicScope.keepOnDisconnect to so.isAcquired(). It works as expected, if the last client disconnects from the SharedObject and it's acquired, it will remain in memory. Otherwise, it'll be wiped out by either the call to super.removeEventListener() or in the "if" statement below it. It makes sense when you look at the code :)
So in layman's terms, if user 1 disconnects from a SharedObject and it's not acquired, it'll be wiped out. However, if user 1 disconnects from a SharedObject that is acquired, it will be kept in memory indefinitely, until it is released. When it is released, it will remain in memory until at least one client connects to it and then disconnects from it. Does that make sense?
On Wed, Nov 11, 2009 at 8:35 AM, Mondain <mondain@...> wrote:
Should aquire() set the keepOnDisconnect? Does the keepOnDisconnect work as you intend it too?
Paul
-- ... 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
Is this the bug that they were trying to link to:
BTW, I heard that Trevor is going to look into this tomorrow.. he's our SO expert
Paul On Wed, Nov 11, 2009 at 9:22 AM, Tyler Kocheran <rfkrocktk@...> wrote:
And yeah, it works :)On Wed, Nov 11, 2009 at 9:17 AM, Tyler Kocheran <rfkrocktk@...> wrote:
Yes. I've attached a patch.
Basically, everytime that someone disconnects from a SharedObject, when SharedObjectScope.removeEventListener(IEventListener) is triggered, we set BasicScope.keepOnDisconnect to so.isAcquired(). It works as expected, if the last client disconnects from the SharedObject and it's acquired, it will remain in memory. Otherwise, it'll be wiped out by either the call to super.removeEventListener() or in the "if" statement below it. It makes sense when you look at the code :)
So in layman's terms, if user 1 disconnects from a SharedObject and it's not acquired, it'll be wiped out. However, if user 1 disconnects from a SharedObject that is acquired, it will be kept in memory indefinitely, until it is released. When it is released, it will remain in memory until at least one client connects to it and then disconnects from it. Does that make sense?
On Wed, Nov 11, 2009 at 8:35 AM, Mondain <mondain@...> wrote:
Should aquire() set the keepOnDisconnect? Does the keepOnDisconnect work as you intend it too?
Paul
-- ... 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
-- http://gregoire.org/http://code.google.com/p/red5/http://code.google.com/p/blue5/
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
@Paul, ticket 580 relates to an entirely different set of functionality. Ticket 580 refers to the often not used locally and remotely persistent shared object functionality of FMS. Basically the thought is that from the client, you can create SharedObjects that are persistent on both the client and the server so that if the client works on the SharedObject while offline, when he connects to the server, changes are merged successfully and seamlessly. The serverside SharedObject maintains a version number to aid in the syncing. It's a really nifty feature that isn't often discussed. In some cases, locally and remotely persistent SharedObjects can save bandwidth by only sending "diffs" rather than the entire SharedObject and its contents every time a client connects.
On Wed, Nov 11, 2009 at 5:10 PM, Mondain <mondain@...> wrote:
Is this the bug that they were trying to link to:
BTW, I heard that Trevor is going to look into this tomorrow.. he's our SO expert
Paul On Wed, Nov 11, 2009 at 9:22 AM, Tyler Kocheran <rfkrocktk@...> wrote:
And yeah, it works :)On Wed, Nov 11, 2009 at 9:17 AM, Tyler Kocheran <rfkrocktk@...> wrote:
Yes. I've attached a patch.
Basically, everytime that someone disconnects from a SharedObject, when SharedObjectScope.removeEventListener(IEventListener) is triggered, we set BasicScope.keepOnDisconnect to so.isAcquired(). It works as expected, if the last client disconnects from the SharedObject and it's acquired, it will remain in memory. Otherwise, it'll be wiped out by either the call to super.removeEventListener() or in the "if" statement below it. It makes sense when you look at the code :)
So in layman's terms, if user 1 disconnects from a SharedObject and it's not acquired, it'll be wiped out. However, if user 1 disconnects from a SharedObject that is acquired, it will be kept in memory indefinitely, until it is released. When it is released, it will remain in memory until at least one client connects to it and then disconnects from it. Does that make sense?
On Wed, Nov 11, 2009 at 8:35 AM, Mondain <mondain@...> wrote:
Should aquire() set the keepOnDisconnect? Does the keepOnDisconnect work as you intend it too?
Paul
-- ... 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
|
Re: Bug in SharedObjectService.hasSharedObject(IScope, String)
Ok, sorry to have mixed 2 different bugs in there. Yeha my problem was that the sharedObject persistency worked but not its attached scope. Anyway case close if you fixed it.
2009/11/12 Tyler Kocheran <rfkrocktk@...>
@Paul, ticket 580 relates to an entirely different set of functionality. Ticket 580 refers to the often not used locally and remotely persistent shared object functionality of FMS. Basically the thought is that from the client, you can create SharedObjects that are persistent on both the client and the server so that if the client works on the SharedObject while offline, when he connects to the server, changes are merged successfully and seamlessly. The serverside SharedObject maintains a version number to aid in the syncing. It's a really nifty feature that isn't often discussed. In some cases, locally and remotely persistent SharedObjects can save bandwidth by only sending "diffs" rather than the entire SharedObject and its contents every time a client connects.
On Wed, Nov 11, 2009 at 5:10 PM, Mondain <mondain@...> wrote:
Is this the bug that they were trying to link to:
BTW, I heard that Trevor is going to look into this tomorrow.. he's our SO expert
Paul On Wed, Nov 11, 2009 at 9:22 AM, Tyler Kocheran <rfkrocktk@...> wrote:
And yeah, it works :)On Wed, Nov 11, 2009 at 9:17 AM, Tyler Kocheran <rfkrocktk@...> wrote:
Yes. I've attached a patch.
Basically, everytime that someone disconnects from a SharedObject, when SharedObjectScope.removeEventListener(IEventListener) is triggered, we set BasicScope.keepOnDisconnect to so.isAcquired(). It works as expected, if the last client disconnects from the SharedObject and it's acquired, it will remain in memory. Otherwise, it'll be wiped out by either the call to super.removeEventListener() or in the "if" statement below it. It makes sense when you look at the code :)
So in layman's terms, if user 1 disconnects from a SharedObject and it's not acquired, it'll be wiped out. However, if user 1 disconnects from a SharedObject that is acquired, it will be kept in memory indefinitely, until it is released. When it is released, it will remain in memory until at least one client connects to it and then disconnects from it. Does that make sense?
On Wed, Nov 11, 2009 at 8:35 AM, Mondain <mondain@...> wrote:
Should aquire() set the keepOnDisconnect? Does the keepOnDisconnect work as you intend it too?
Paul
-- ... 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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
--
_______________________________________________
Red5 mailing list
Red5@...
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@...
http://osflash.org/mailman/listinfo/red5_osflash.org
_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
|
sharedObjectPatch.patch (1K) 