[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-880) Discussion on how to support backward / forward compatible serialization layer

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-880?pag... ] Sanne Grinovero commented on HSEARCH-880: ----------------------------------------- Some first-impact questions: h3. General principles - protocol version Should the protocol version be a global number across serialization providers? Should it be mandatory for each serialization provider? I guess that each provider should be free to handle it as it thinks best. I'd of course support the idea that our reference providers should have versioning, but I wouldn't impose this to other implementors. h3. What is a _serialization provider id_ in practice? I'd say it should be short as it's transmitted, but also if these ids are global (scoped to the SearchFactory) then ids should be able to be assigned dynamically, making me think about a fully qualified class name of an implementor. Proposal: remove it, and consider the serialization provider coupled to the IndexManager (identified by the index name already). As far as dynamic configuration goes, we'll support the option to start/stop new IndexManagers but not to reconfigure an existing one (at least not without stop+start). bq. Do we need a serialization provider id? In other words, do we need to be able to hot-upgrade the SerializationProvider in a cluster? Exactly, I would say no for the reasons I just mentioned. h3. Cluster with one way communication - minor bump case you say it's allowed to fail when a new feature is being used. Is transmitting a new feature not something that we're supposed to bump the mayor version for? Maybe an example could clarify. Is our switch from a Delete+Add LuceneWork into an Update LuceneWork something you would bump the mayor version for? I would rather have expected to have an option on the sender side to send "backwards compatible messages", i.e. convert each Update to the couple of operations. So people could define a version number in their configuration, then update the software but have it still send messages the old way. bq. If message_major or message_minor < node_major or node_minor, we use the older protocol deserializer. In practice, how are "older" implementations loaded by the factory? I won't assume with a classloader really loading the older jar? duplicating the packages into different names for each byte-format change? bq. could there ever be a problem where a new HSearch Engine cannot deal with an old HSearch engine's message? I think we should always be able to compensate, in theory. The problem is how to compensate with our mistakes, i.e. how should the engine deal with the fact that we might not do it in practice: even in the best effort we might miss to test unexpected message combinations. bq. Is the JGroups clustering using multicast to send change messages ie does it know which node it sends the message to to do the handshake? It should be unicast, being a point-to-point communication (for each backend we can't have more than one IndexWriter). bq. What happens if B goes down and back up? Does it have a "new" name that uniquely identify it? What do you mean by _name_ ? JGroups networks are identified mainly by their network address, and a string defined in the configuration named _cluster name_. So if it's the same node coming up again, it will have the same name (assuming I understood your question). It becomes more tricky if a different node takes over the role of Master, and happens to have different protocol versions. We will receive an event when the cluster elements change, and then we should start a new handshake. bq. could it be that Serializer / Deserializer / LuceneWorksBuilder lead to the inability to support a version n-1 (by adding of new methods or stuff like that? Didn't understand this question. you mean we won't be able to support the previous mayor version? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira