- **summary**: imm: Implicit class/object-applier checked by OiImplementeSet is
incorrect --> imm: Implicit class/object-applier checked by OiImplementeSet is
not globally consistent
- **Comment**:
The actual local check done for the locall attaching applier is correct. The
problem is that the same check may fail at other nodes (where the applier is
not currently attaching) resulting in the
applier attach being handled as rejected at some other node. This will not
impact the correct
behavior of the applier mechanism where it attached. That logic is purely node
local.
A detrimental effect that can happen is that a future sync may detect an
inconstency on
applier-id for a given applier name and escalate this to a restart of the node
director(s) that detects this inconsistency. That is a serious side effect so
the problem needs to be fixed.
One quick solution would be to disarm the check, or at least reduce its
severity to a warning.
That would of course not remove the inconsistency.
Worst case scenario resulting from he inconsistency on applier
existence/identity is that two appliers could be allowed to attach under the
same applier name, at two or more different nodes.
That in itself would not be a problem for the applier mechanism. A problem
would only ocur
if a third party tries to communicate with the supposed unique named applier
using a direct
admin-operation with the applier-name as the target. Such an admin-operation
would end up
arbitrarily reaching one of the appliers under that name.
---
** [tickets:#1504] imm: Implicit class/object-applier checked by
OiImplementeSet is not globally consistent**
**Status:** assigned
**Milestone:** 4.5.2
**Created:** Mon Sep 28, 2015 04:15 AM UTC by Hung Nguyen
**Last Updated:** Mon Sep 28, 2015 10:58 AM UTC
**Owner:** Hung Nguyen
Set an applier to a class. Then exit immapplier to detach the applier.
~~~~
root@SC1:~# immapplier -a @whatever Test
~~~~
Let another node join the cluster.
Create a CCB which is active on an object of 'Test' class. Don't commit the CCB.
~~~~
root@SC1:~# immcfg
> immcfg -c Test test=1
>
~~~~
Try to set applier again.
~~~~
root@SC1:/srv/shared# immapplier -a @whatever Test
Implementer: @whatever
ImmVersion: A 2 16
error - saImmOiImplementerSet FAILED: SA_AIS_ERR_TRY_AGAIN (6)
~~~~
SC-1
~~~~
osafimmnd [419:immsv_evt.c:5414] T8 Received: IMMND_EVT_D2ND_IMPLSET_RSP (60)
from 0
osafimmnd [419:immnd_evt.c:9527] T2 originated here?:1 nodeId:2010f conn: 225
osafimmnd [419:ImmModel.cc:12967] >> implementerSet
osafimmnd [419:ImmModel.cc:13008] T7 Re-using implementer for @whatever
osafimmnd [419:ImmModel.cc:13040] TR TRY_AGAIN: ccb 2 is active on object
'test=1' bound to class applier '@whatever'. Can not re-attach applier
osafimmnd [419:ImmModel.cc:13156] << implementerSet
~~~~
PL-3
~~~~
osafimmnd [392:immsv_evt.c:5414] T8 Received: IMMND_EVT_D2ND_IMPLSET_RSP (60)
from 0
osafimmnd [392:immnd_evt.c:9527] T2 originated here?:0 nodeId:2010f conn: 225
osafimmnd [392:ImmModel.cc:12967] >> implementerSet
osafimmnd [392:ImmModel.cc:13008] T7 Re-using implementer for @whatever
osafimmnd [392:ImmModel.cc:13087] NO Implementer (applier) connected: 5
(@whatever) <0, 2010f>
osafimmnd [392:ImmModel.cc:13156] << implementerSet
~~~~
IMMND on SC-1 rejected the implSet request but IMMND on PL-3 accepted it.
The applier was not synced to PL-3 (mAppliers.empty() returned true) so the
implSet request passed the ccb check.
if( ! obj->mClassInfo->mAppliers.empty()) {
ImplementerSet::iterator ii =
obj->mClassInfo->mAppliers.begin();
for(; ii != obj->mClassInfo->mAppliers.end(); ++ii) {
if((*ii) == info) {
TRACE("TRY_AGAIN: ccb %u is active on object '%s' "
"bound to class applier '%s'. Can not re-attach
applier",
ccb->mId, omit->first.c_str(), implName.c_str());
err = SA_AIS_ERR_TRY_AGAIN;
goto done;
}
}
}
Now commit the CCB and try to set the applier again.
SC-1
~~~~
osafimmnd [419:immsv_evt.c:5414] T8 Received: IMMND_EVT_D2ND_IMPLSET_RSP (60)
from 0
osafimmnd [419:immnd_evt.c:9527] T2 originated here?:1 nodeId:2010f conn: 226
osafimmnd [419:ImmModel.cc:12967] >> implementerSet
osafimmnd [419:ImmModel.cc:13008] T7 Re-using implementer for @whatever
osafimmnd [419:ImmModel.cc:13087] NO Implementer (applier) connected: 6
(@whatever) <226, 2010f>
osafimmnd [419:ImmModel.cc:13156] << implementerSet
~~~~
PL-3
~~~~
osafimmnd [392:immsv_evt.c:5414] T8 Received: IMMND_EVT_D2ND_IMPLSET_RSP (60)
from 0
osafimmnd [392:immnd_evt.c:9527] T2 originated here?:0 nodeId:2010f conn: 226
osafimmnd [392:ImmModel.cc:12967] >> implementerSet
osafimmnd [392:ImmModel.cc:13003] T7 ERR_EXIST: Registered implementer already
exists: @whatever
osafimmnd [392:ImmModel.cc:13005] << implementerSet
~~~~
The applier had diferent ids on SC-1 and PL-3. When a new node joins the
cluster, IMMND on PL-3 will crash when verifying the implementers.
~~~~
PL3 osafimmnd[392]: ER Sync-verify: Established node has different
Implementer-id: 5 for name: @whatever, sync says 6.
~~~~
---
Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
