red5-server
red5-server copied to clipboard
Red5
No file system persistence of Scope attributes in r4585
From @GoogleCodeExporter on March 15, 2015 17:0
On red5 buids up to r4283, the AttributeStore of scopes was being persisted to
the file system for Attributes that don't start with "_transient".
Tests with Red5 r4585 that those attributes are no longer persisted as before.
expected behaviour (from former versions) is that (IScope)
scope.setAttribute("SomeKey", somevalue) should be persisted. This is no longer
the case.
version of the product/os
r4585 so far tested on windows 7, will update after tests on *nix based oses.
Original issue reported on code.google.com by [email protected] on 26 May 2013 at 4:05
Copied from original issue: mondain/red5#399
From @GoogleCodeExporter on March 15, 2015 17:0
update: apparently the default persistence store for scopes is no longer set
(getStore() delivers null)
Is that intended behaviour?
Original comment by [email protected] on 26 May 2013 at 5:07
From @GoogleCodeExporter on March 15, 2015 17:0
A code review indicates that the FilePersistenceThread was removed as a class
and from the red5-common.xml.
In order to use file system persistence in releases where that happened up to
the point where the persistence was replaced by a quarz sheduled job, is there
a workaround to programatically activate the persistence by for instance
calling setPersistenceClass on scopes that need to be persisted and what
additional work would have to be done to make sure the system behaves at least
similar as before?
I could review the code from earlier releases to grok that bit of red5 logic,
but hints "from the top of some mind" would be apreciated.
Original comment by [email protected] on 26 May 2013 at 6:05
From @GoogleCodeExporter on March 15, 2015 17:0
Further code review showed that the IPersistable interface was removed from
Scope and it's subclasses, so while sthe scope still works as an
AttributeStore, it can no longer be persisted out of the box. Is that intended
behaviour?
Original comment by [email protected] on 27 May 2013 at 7:05
From @GoogleCodeExporter on March 15, 2015 17:0
Try setting the FilePersistence class with setPersistenceClass; default should
be RAM persistence.
Original comment by mondain on 28 May 2013 at 2:43
- Changed state: Accepted
From @GoogleCodeExporter on March 15, 2015 17:0
I did that in a test, i could set the persistence class alright, but as far as
i understood the data is persisted using the save(IPersistable) method. There
does not seem to be a default worker/thread that manages that (no class was
persisted in the persistence folder structure out of the box) and scopes could
not be passed to the method, since they could not be cast to IPersistable.
Original comment by [email protected] on 28 May 2013 at 4:26
From @GoogleCodeExporter on March 15, 2015 17:0
We are open to suggestions on how to resolve this, but I don't believe
persisting the "scope" itself is an option.
Original comment by mondain on 4 Jul 2013 at 2:08
From @GoogleCodeExporter on March 15, 2015 17:0
To my mind this is mainly a question of documentation and the principle of
least surprises. When i started with Red5, the fact that a lot of Red5
component implemented the IPersistableAttributeStore, due to lack of more in
depth documentation the obvious assumption was that this implementation allows
a simple way to keep states of Red5 in applications.
It would either be possible to just state clearly that this is not intended
(and maybe shared objects should be used for that), or follow that assumption
and guarantee that this remains true.
It is very practical to have a persistable attribute store in Scopes that
guarantee that whenever a scope gets recreated it will keep attributes set to
it (as long as those attributes are not somehow used internally, in which case
this should be either inaccessible for application developers or be well
documented).
Likewise being able to save attributes on clients and connections is very
helpful to access application relevant data on those objects in order to be
able to access this from wherever in the application (for instance getting data
from a connections or it's associated clients attribute store in a security
handler).
According to the principle of least surprise it would be expected that:
* Attributes of a scope get persisted according to it's canonical name,
* Attributes of a client get persisted by it's id
* Attributes of connections are useful but should not allow persistence, since
it's unlikely that it can be guaranteed that a connection should keep state,
the client would be the way to go in those cases.
Generally spoken, it seems the least surprise to me that persisting an
IPersistable recreates an Object with an identical AttributeStore. Every other
field of a given object would be left to the internal logic of Red5.
Documentation should explain that IPersistable persists the AtrributeStore
characteristics of an object, maybe an overrideable method should be documented
that allows processing of initialization logic to be performed on getting such
an IPersistable from the attribute store AFTER it's AttributeStore has been
populated.
my2pesos
Stefan
Original comment by [email protected] on 4 Jul 2013 at 5:09
Please fix this issue as it breaks current implementations. My application relies on scope.setAttribute(String, String) being persisted. Thanks.
