[tickets] [opensaf:tickets] #1190 AMF: saAmfSIPrefActiveAssignments has wrong default, stopping scaling nway active SGs
--- ** [tickets:#1190] AMF: saAmfSIPrefActiveAssignments has wrong default, stopping scaling nway active SGs** **Status:** unassigned **Milestone:** 4.4.2 **Created:** Thu Oct 23, 2014 01:10 PM UTC by Hans Feldt **Last Updated:** Thu Oct 23, 2014 01:10 PM UTC **Owner:** nobody Problem: In naway-active, SUs are not instantiated unless saAmfSIPrefActiveAssignments is configured. saAmfSIPrefActiveAssignments is a configuration attribute only valid for the nway-active redundancy model. According to the spec 3.6.5.3 it should have a default value of the preferred number of assigned service units. and saAmfSGNumPrefAssignedSUs should have a default value of the preferred number of in-service service units and saAmfSGNumPrefInserviceSUs should have a default value of the number of the service units configured for the service group. The value of saAmfSIPrefActiveAssignments is currently set to one when not configured, instead it should be set to saAmfSGNumPrefAssignedSUs --- 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
[tickets] [opensaf:tickets] #1190 AMF: saAmfSIPrefActiveAssignments has wrong default, stopping scaling nway active SGs
the schema seems to be wrong since has a default value of 1, should have no default --- ** [tickets:#1190] AMF: saAmfSIPrefActiveAssignments has wrong default, stopping scaling nway active SGs** **Status:** unassigned **Milestone:** 4.4.2 **Created:** Thu Oct 23, 2014 01:10 PM UTC by Hans Feldt **Last Updated:** Thu Oct 23, 2014 01:10 PM UTC **Owner:** nobody Problem: In naway-active, SUs are not instantiated unless saAmfSIPrefActiveAssignments is configured. saAmfSIPrefActiveAssignments is a configuration attribute only valid for the nway-active redundancy model. According to the spec 3.6.5.3 it should have a default value of the preferred number of assigned service units. and saAmfSGNumPrefAssignedSUs should have a default value of the preferred number of in-service service units and saAmfSGNumPrefInserviceSUs should have a default value of the number of the service units configured for the service group. The value of saAmfSIPrefActiveAssignments is currently set to one when not configured, instead it should be set to saAmfSGNumPrefAssignedSUs --- 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
[tickets] [opensaf:tickets] #1075 2PBE: pbed aborts at sqlite_prepare_ccb
- **status**: accepted -- duplicate - **Comment**: This ticket is a duplicate of ticket #1057 already fixed. The problem is that on timeout waiting for This error message: Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmpbed: ER sqlite_prepare_ccb invoked when no sqlite transaction has been started. can only be explained by the sqlite transaction having been incorrectly aborted by the other thread in the slave. Such a case was fixed in #1057. WE can see that this case occurrs shortly before the error: Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmpbed: NO 2PBE Error (21) in PRTA update (ccbId:100a5) --- ** [tickets:#1075] 2PBE: pbed aborts at sqlite_prepare_ccb** **Status:** duplicate **Milestone:** 4.4.1 **Created:** Mon Sep 15, 2014 06:45 AM UTC by Sirisha Alla **Last Updated:** Thu Oct 23, 2014 09:20 AM UTC **Owner:** Anders Bjornerstedt The issue is seen on SLES X86 running with 2PBE and 50k objects. Opensaf is with changeset 5697 + #946 patch. IMM Applications along with switchovers is in progress Syslog of SC-1: Sep 12 18:01:34 SLES-64BIT-SLOT1 osafamfnd[2526]: NO Assigned 'safSi=SC-2N,safApp=OpenSAF' ACTIVE to 'safSu=SC-1,safSg=2N,safApp=OpenSAF' Sep 12 18:01:34 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer disconnected 431 0, 2020f (@OpenSafImmReplicatorA) Sep 12 18:01:34 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:34 SLES-64BIT-SLOT1 osafimmpbed: IN ccb-prepare received at PBE slave ccbId:100a5/4294967461 numOps:1 Sep 12 18:01:34 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer (applier) connected: 446 (@OpenSafImmReplicatorA) 0, 2020f Sep 12 18:01:34 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer (applier) connected: 447 (@OpenSafImmReplicatorB) 333, 2010f Sep 12 18:01:34 SLES-64BIT-SLOT1 osafntfimcnd[4781]: NO Started Sep 12 18:01:35 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:35 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:36 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:36 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:37 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:37 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:38 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:38 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:39 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a5 Sep 12 18:01:39 SLES-64BIT-SLOT1 osafimmpbed: NO Slave PBE time-out in waiting on porepare for PRTA update ccb:100a5 dn:safNode=PL-3,safCluster=myClmCluster Sep 12 18:01:40 SLES-64BIT-SLOT1 osafimmnd[2452]: WA Timeout on Persistent runtime Object Mutation, waiting on PBE Sep 12 18:01:44 SLES-64BIT-SLOT1 osafimmnd[2452]: WA update of PERSISTENT runtime attributes in object 'safNode=PL-3,safCluster=myClmCluster' REVERTED. PBE rc:20 Sep 12 18:01:45 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer disconnected 422 0, 2020f (safAmfService) Sep 12 18:01:45 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer (applier) connected: 448 (@safAmfService2020f) 0, 2020f Sep 12 18:01:45 SLES-64BIT-SLOT1 osafamfd[2516]: NO Switching StandBy -- Active State Sep 12 18:01:45 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer disconnected 435 12, 2010f (@safAmfService2010f) Sep 12 18:01:45 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer connected: 449 (safAmfService) 12, 2010f Sep 12 18:01:45 SLES-64BIT-SLOT1 osafrded[2423]: NO RDE role set to ACTIVE Sep 12 18:01:45 SLES-64BIT-SLOT1 osafamfd[2516]: NO Controller switch over done Sep 12 18:01:46 SLES-64BIT-SLOT1 osafimmnd[2452]: WA Timeout on Persistent runtime Object Mutation, waiting on PBE Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmpbed: NO 2PBE Error (21) in PRTA update (ccbId:100a5) Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmpbed: IN PBE slave waiting for prepare from primary on PRTA update ccb:100a6 Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmpbed: ER sqlite_prepare_ccb invoked when no sqlite transaction has been started. Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmnd[2452]: ER PBE PRTAttrs Update continuation missing! invoc:165 Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer locally disconnected. Marking it as doomed 437 313, 2010f (@OpenSafImmPBE) Sep 12 18:01:49 SLES-64BIT-SLOT1 osafimmnd[2452]: NO Implementer locally disconnected. Marking it as doomed 438 314, 2010f (OsafImmPbeRt_B) Sep 12 18:01:49 SLES-64BIT-SLOT1
[tickets] [opensaf:tickets] #1189 imm: admin operation returns ERR_NAME_TOO_LONG for a valid extended name in return parameters
- **status**: accepted -- review
- **Comment**:
https://sourceforge.net/p/opensaf/mailman/message/32962560/
---
** [tickets:#1189] imm: admin operation returns ERR_NAME_TOO_LONG for a valid
extended name in return parameters**
**Status:** review
**Milestone:** 4.5.1
**Created:** Thu Oct 23, 2014 12:47 PM UTC by Zoran Milinkovic
**Last Updated:** Thu Oct 23, 2014 12:47 PM UTC
**Owner:** Zoran Milinkovic
If return parameters, from successful admin operation call, contain a valid
extended name, then operation return error is set to SA_AIS_ERR_NAME_TO_LONG.
if((*returnParams)[i]-paramType == SA_IMM_ATTR_SANAMET
osaf_is_extended_name_valid((SaNameT
*)(*returnParams)[i]-paramBuffer)) {
if(*operationReturnValue == SA_AIS_OK) {
*operationReturnValue = SA_AIS_ERR_NAME_TOO_LONG;
}
osaf_extended_name_free((SaNameT *)(*returnParams)[i]-paramBuffer);
osaf_extended_name_clear((SaNameT *)(*returnParams)[i]-paramBuffer);
}
---
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
[tickets] [opensaf:tickets] #1188 IMM: Sync-retry wait time causes problems
To address following the sysnc wait time was changed from 'usleep(15)' to a 'sleep(2)' ( above TIPC link tolerance of 1.5 sec ) while testing TIPC Multicast. When A node sync is in-progress , the sync message are being send in very high number/frequency when Large IMM DB, at that movement , any other node in the cluster restarts ( TIPC Link down) , the send buffer are getting filled up to Max with-in TIPC link tolerance of 1.5 sec time , so sednto() at IMMD is getting blocked and we are hitting `16` FEVS Replies pending. So Just increasing `rmem_max` `wmem_max` of system and increasing SA_AIS_ERR_TRY_AGAINsleep time of saImmOmSearchNext_2() in imm_loader above TIPC link tolerance of 1.5 sec resolved the issue. --- ** [tickets:#1188] IMM: Sync-retry wait time causes problems** **Status:** review **Milestone:** 4.5.1 **Created:** Wed Oct 22, 2014 10:51 AM UTC by Anders Bjornerstedt **Last Updated:** Thu Oct 23, 2014 09:13 AM UTC **Owner:** Anders Bjornerstedt Some changes where made to imm-sync in 4.5 in ticket #851. One change was to alter the wait time from 'usleep(15)' to a 'sleep(2)'. Having sync always wait for two seconds causes a major performance reduction in OpenSAF 4.5 for sync on some configurations. I am not sure why there was a perceived need to increase the wait time to as much as 2 seconds. But a better solution would be a back-off solutuion where the wait time is increased exponentially after each failed retry. --- 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
