No file system persistence of Scope attributes in r4585

[GoogleCodeExporter]

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 S.No...@gmail.com on 26 May 2013 at 4:05

[GoogleCodeExporter]

update: apparently the default persistence store for scopes is no longer set 
(getStore() delivers null)
Is that intended behaviour?

Original comment by S.No...@gmail.com on 26 May 2013 at 5:07

[GoogleCodeExporter]

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 S.No...@gmail.com on 26 May 2013 at 6:05

[GoogleCodeExporter]

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 S.No...@gmail.com on 27 May 2013 at 7:05

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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 S.No...@gmail.com on 28 May 2013 at 4:26

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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 S.No...@gmail.com on 4 Jul 2013 at 5:09