On Tuesday, January 13, 2004, at 05:09 PM, Jeremy Boynes wrote:
David Jencks wrote:I think there is a problem with the new configuration serialization code. It appears to rely on the ordering from a set iterator.
Configuration constructs it's GBeanInfo in some static code. This GBeanInfo is not serialized with the other contents of a configuration. However the persistent attributes are written out in the order presented by a HashSet iterator on the source machine. When it is read back in, the local machines GBeanInfo is used, in particular the order of persistent attributes is determined by a HashSet iterator on this local machine. There is no reason to suppose the ordering will be the same for 2 different machines.
This is not a problem for subsequent GBeanInfo objects in the configuration, since the ordering of persistent attributes is serialized in the GBeanInfo, which is deserialized on the target machine before reading the attribute values.
However, I think that depending on the ordering being serialized/deserialized is obscure and risky. I would prefer to see the list of persistent attributes become computed on demand or transient, and the persistent attributes stored with their names.
OK. I think this is better than the option below.Alternatively, the GBeanInfo for the Configuration could also be serialized, or the constructed GBeanInfo could put the attributes in a SortedSet.Oops
----------------
Other unimplemented features in the configuration code are
-endpoint patterns are not serialized
Upon a bit more thought, I think the best way is to have attribute value and endpoint pattern objects holding name, value pairs that we serialize. Otherwise we need a count or type code or something.
If you don't beat me to this I'll put this in later tonight, OK?
-stop does not in fact serialize the configuration.I added the comment but was not sure we actually wanted to do this. I am torn between automatically saving the state on stop and having an explicit method on the Configuration that saves the state; the first is easy, the second gives the admins more control.
Any thoughts?
I was just looking at this...
saving state after stopping the gbeans has the advantage that the state is definitely the final state of the gbean. However, it requires a read-only "savedState" attribute in the Configuration mbean, and then you have to read it and save it. On the other hand it assumes that stopping and deregistering a gbean won't change its state. I'm not sure how plausible this is.
saving state before stopping certainly requires less messing with the insides of Configuration but runs the risk of someone changing the state between the time you save the state and shut down the configuration.
I think both is best, so you can have a timed backup service and also get the guaranteed last state when you shut down on purpose. We may need to implement both and find out what works.
-----------
A possibly bigger problem is that I can't find any dependency ordering in this new structure. The gbeans are serialized in a random order, started in a random order, and I don't see the endpoint code doing much to encourage waiting until the other end is started to start. Am I missing something?
Also, I don't see a way to preserve dependencies registered with the dependency service.
I'm looking forward to seeing how the deployment planners work in this new framework.
david
thanks david jencks
