| Item |
Section |
Comment |
Response |
| RC-1 |
4.1.2 |
Please describe the algorithm used by the ReplicaSelector and explain how it achieves consistency. What happens if an instance goes down after the ReplicaSelector in another instance has indicated the first instance as the one to replicate to? And what happens when/if that instance comes back? |
Lets say that the replica selector picks inst2 as the replica (because at that time it thinks that inst2 is alive). The save method will attempt to save to inst2 only. If inst2 is down then save will fail. This is how we did it in sailfin days. When inst2 comes back then the next save will pick inst2 as the replica. Note that the replica selector relies on GMS for determining whether an instance is 'alive' or 'dead'. |
|
| RC-2 |
4.1.2 |
For completeness, this section should list the supported attribute types (String, long, what else?) |
Addressed in the doc |
|
| RC-3 |
4.1.4 |
In a cluster, when a new instance is added, how can it call BackingStoreFactory.createBackingStore before any operations in the other instances happen, given that those instances may have been up and running for some time? |
Agreed. Removed this from the doc. Lets say that instances inst1 and inst2 are alive and have replicated some data. Now when instance inst3 comes up, the implementation must ensure that no data is replicated to inst3 until it is in some 'operational' state. |
|
| RC-4 |
4.5 |
Looking at the BackingStore API, it's not clear how instances of a value type V will be created. For example, if a container calls save(k, v, true), meaning the key/value pair is new, where does v come from? And how does V_Sub come into the picture in this case? |
The third param in save(k, v, true) is actually a hint to the store that the k and V are persisted for the first time. This allows, say,a database based store to perform 'insert' sql operation as opposed to 'update' operation. I will update the javadoc with this. Removing the V_Sub from the javadoc |
|
| RC-5 |
4.1.2-4.5 |
What are the constraints on the key type for a BackingStore? And for a ReplicaSelector? If e.g. the key has to be serializable, this should be indicated in the BackingStore type signature, e.g. class BackingStore<K extends Serializable, V>. More generally, I wonder if we shouldn't clean up the BackingStore interface. |
Agreed. modified the signature of the class to say K extends Serializable and V extends Serializable. |
|
| AK-1 |
4.13 |
When is GMS broadcast used in 3.1 in-memory replication ? |
In V2.x we used broadcast in two cases. (a) when store.remove is called to remove any stale data and (b) when a request is directed to a new instance after a failure and if the data for key K was not found in that instance. In V3, we may do this only for remove calls |
|
| shannon-01 |
4.10.2 |
I don't understand what's in shoal-replication.jar vs. shoal-replication-adapter.jar? Why are both needed? |
Agreed. We need only one jar. This jar will live in shoal project but will have dependency on ha-api which is in glassfish repository |
|
| shannon-02 |
4.12.2 |
Note that there is no DTD for domain.xml anymore. |
|
| shannon-03 |
4.12.3 |
I'd like to see a more complete spec for how all the HA-related elements from a v2 domain.xml will be handled by 3.1. What will be mapped to what? What will be ignored? Note that items you intend to ignore still have to be accepted. |
The current plan is to retain the same V2 availability-service element. the <availability-service> element contains a few HADB related attributes, which will not be used by V3. The plan is to mark those attributes with @Deprecated |
|
