-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XSOR: Incomplete state transition in case of conflicting states #1290
Comments
If there is a conflict xyna-factory/components/xnwh/xcs/xsor/src/com/gip/xyna/xsor/XynaScalableObjectRepositoryImpl.java Line 1316 in 971b722
which is not handled in search xyna-factory/components/xnwh/xcs/xsor/src/com/gip/xyna/xsor/XynaScalableObjectRepositoryImpl.java Line 1236 in 971b722
As the state has been changed to 'E' it should be added to the grabbed elements xyna-factory/components/xnwh/xcs/xsor/src/com/gip/xyna/xsor/XynaScalableObjectRepositoryImpl.java Line 1298 in 971b722
as e.g. in the case of PENDING_ACTIONS_LOCAL_CHANGES and the payload needs to be released again.
case CONFLICTING_REQUEST_FROM_OTHER_NODE:
// state is 'E' but the grab failed due to inconsitency.
transactionContext.grabbed(internalId, searchRequest.getTablename());
releaseAndUnlockFromTransaction(internalId, payload, correspondingMemory, strictlyCoherent,
transactionContext);
throw new CollisionWithRemoteRequestException(); |
The xyna-factory/components/xnwh/xcs/xsor/src/com/gip/xyna/xsor/interconnect/InterconnectServer.java Lines 196 to 210 in 971b722
xyna-factory/components/xnwh/xcs/xsor/src/com/gip/xyna/xsor/interconnect/InterconnectServer.java Lines 347 to 354 in 971b722
So the server will accept connections from clients while being paused and keep the messages from the client until accept is called again. xyna-factory/components/xnwh/xcs/xsor/src/com/gip/xyna/xsor/interconnect/InterconnectServer.java Lines 76 to 86 in 971b722
Server closes its connection to the client:
Client immediately opens a new connection and (tries) to send updates
After synchronization the server accepts the connection and handles the (old) messages.
|
Node 1: CONNECTED
Node 2: DISCONNECTED but reachable (NAd died on Node 1)
Update on Node 1
Restart of Node 1
Start NAd
Node 1 is updated with all data from Node 2 (SYNC_M => SYNC_S)
Node 2 gets (old) updated state from Node 1 which is still in its incomming queue somehow
Update on Node 1: => Conflict as the states are different
Node 1 stays in state 'M'
The state should not stay in 'M' but return to 'S' and the data should be considered as invalid (for updates).
The text was updated successfully, but these errors were encountered: