I am getting an IMM sync problem when testing with different controller versions. When second controller is part of IMM loading it works, when it syncs it does not work:
May 16 12:01:01 SC-2 local0.notice osafimmnd[427]: Started May 16 12:01:01 SC-2 local0.notice osafimmnd[427]: NO SERVER STATE: IMM_SERVER_ANONYMOUS --> IMM_SERVER_CLUSTER_WAITING May 16 12:01:01 SC-2 local0.notice osafimmnd[427]: NO SERVER STATE: IMM_SERVER_CLUSTER_WAITING --> IMM_SERVER_LOADING_PENDING May 16 12:01:01 SC-2 local0.notice osafimmnd[427]: NO SERVER STATE: IMM_SERVER_LOADING_PENDING --> IMM_SERVER_SYNC_PENDING May 16 12:01:01 SC-2 local0.notice osafimmnd[427]: NO NODE STATE-> IMM_NODE_ISOLATED May 16 12:01:02 SC-2 local0.notice osafimmd[389]: NO SBY: Ruling epoch noted as:4 May 16 12:01:02 SC-2 local0.notice osafimmd[389]: NO IMMND coord at 2010f May 16 12:01:02 SC-2 local0.notice osafimmnd[427]: NO NODE STATE-> IMM_NODE_W_AVAILABLE May 16 12:01:02 SC-2 local0.notice osafimmnd[427]: NO SERVER STATE: IMM_SERVER_SYNC_PENDING --> IMM_SERVER_SYNC_CLIENT May 16 12:01:03 SC-2 local0.notice osafimmd[389]: NO SBY: New Epoch for IMMND process at node 2010f old epoch: 3 new epoch:4 May 16 12:01:03 SC-2 local0.notice osafimmd[389]: NO IMMND coord at 2010f May 16 12:01:03 SC-2 local0.err osafimmnd[427]: ER Can not sync Ccb that is active May 16 12:01:03 SC-2 local0.err opensafd[337]: ER Could Not RESPAWN IMMND and trace: May 16 12:01:20.395920 osafimmnd [455:ImmModel.cc:15360] >> finalizeSync May 16 12:01:20.396115 osafimmnd [455:ImmModel.cc:15643] IN finalizeSync message contains 0 admin-owners May 16 12:01:20.396218 osafimmnd [455:ImmModel.cc:15748] T5 Immnd sync client synced implementer id:6 name:>>safSmfService<< size:13 May 16 12:01:20.396522 osafimmnd [455:ImmModel.cc:15748] T5 Immnd sync client synced implementer id:5 name:>>safCheckPointService<< size:20 May 16 12:01:20.396615 osafimmnd [455:ImmModel.cc:15748] T5 Immnd sync client synced implementer id:0 name:>>@safAmfService2020f<< size:19 May 16 12:01:20.396706 osafimmnd [455:ImmModel.cc:15748] T5 Immnd sync client synced implementer id:3 name:>>safAmfService<< size:13 May 16 12:01:20.396798 osafimmnd [455:ImmModel.cc:15748] T5 Immnd sync client synced implementer id:2 name:>>safClmService<< size:13 May 16 12:01:20.396887 osafimmnd [455:ImmModel.cc:15748] T5 Immnd sync client synced implementer id:1 name:>>safLogService<< size:13 May 16 12:01:20.397029 osafimmnd [455:ImmModel.cc:15752] IN finalizeSync message contains 6 implementers May 16 12:01:20.397293 osafimmnd [455:ImmModel.cc:15828] IN Synced 58 classes May 16 12:01:20.397404 osafimmnd [455:ImmModel.cc:15859] T5 CCB 1 state OTHER May 16 12:01:20.397838 osafimmnd [455:ImmModel.cc:15861] ER Can not sync Ccb that is active May 16 12:01:20.397938 osafimmnd [455:ImmModel.cc:16173] << finalizeSync May 16 12:01:20.406856 osafimmnd [455:immnd_evt.c:8607] ER Unexpected local error 21 in finalizeSync for sync client - aborting On 16 May 2014 10:20, A V Mahesh <mahesh.va...@oracle.com> wrote: > Hi, > > >> So is this an ack for the complete series? > Yes. > > -AVM > > On 5/16/2014 12:51 PM, Hans Feldt wrote: >> >> Hi, >> >> This is a series of 4 patches. It is all or nothing. I sent out v2 for >> patch 1 after Surya’s comments. >> >> So is this an ack for the complete series? >> >> Thanks, >> >> Hans >> >> *From:*A V Mahesh [mailto:mahesh.va...@oracle.com] >> *Sent:* den 16 maj 2014 03:51 >> *To:* Hans Feldt; Hans Feldt >> *Cc:* opensaf-devel@lists.sourceforge.net; Suryanarayana Garlapati >> *Subject:* Re: [devel] [PATCH 3 of 4] mds: use TIPC >> segmentation/reassembly [#654] >> *Importance:* High >> >> Hi Hans , >> >> *ACK from me for your published patch , please go-ahead and push the >> patch as it is.* >> >> I discussion/syncdup with Surya, following are the summary points : >> >> By *default *MDS does FULL encode/decode between different nodes >> (inter-node communication), also the behavior is same when the MDS >> messaging happens between 32-bit and 64-bit processes. your published >> Patch: #654 is not impacting any of these default functionality**. >> >> Even though MDS is providing a compile time flag called "mds_arch", >> when this flag is set explicitly to the same value on different nodes, >> then only MDS messaging across nodes will happen with FLAT >> encode/decode routines, but most of the OpenSAF services (mds >> application) are still doing FULL encode/decode even when the MDS is >> triggered FLAT encode/decode callbacks ( Middle ware applications are >> not using advantage of "mds_arch" ). >> >> Till now none of the OpenSAF user are using the 'mds_arch' field and >> all are going with the MDS default settings. So they are NO impacts >> of deprecating "mds_arch" and considering that for versions. >> >> -AVM >> >> On 5/7/2014 12:20 PM, SuryaNarayana Garlapati wrote: >> >> OK, >> Here goes the solution. >> There is a 8 bit field in each message that is being exchanged >> between the services (which contains the message priority, mds >> prot_ver(mds protocol and mds version)) when message send is >> attempted. 6 bits are allocated for the mds prot_ver, present >> value for this field is 0xA8. This field can be used for >> versioning(and intended for this type of changes in MDS). This >> version can be dynamically learnt for a destination, when the >> first message is received from that destination and is stored in >> the Subscription result table. MDS prot_ver value will be changed >> in this release. So we can identify the old and new ones. If the >> destination is an old one, we will send with the old logic and if >> its a new one we will send with the bigger message. >> >> There is other solution, but this includes quite code changes. For >> example, In each node bind a new type say X and in each process >> subscribe for this X. When we get up this means, it indicates a >> new node and messaging is with bigger size else the normal one. >> Only a single extra bind is done for a node. >> >> There is one more solution, but it breaks the inservice >> upgradabilty, where in which the vdest id range is decreased. >> >> >> Regards >> Surya >> >> On Wednesday 07 May 2014 08:44 AM, A V Mahesh wrote: >> >> Surya, >> >> Thank for reiterating arch_word of the MDS feature ,we all in sync. >> >> On 5/6/2014 3:55 PM, SuryaNarayana Garlapati wrote: >> >> MDS version unless we get alternate bits/variables used for >> MDS version. >> >> [Surya] Thats the reason i am asking for some time. >> >> >> [AVM] If we get some alternate bits/variables used for MDS version >> this will the best Option >> and we can retain arch_word MDS feature. >> >> >> On 5/6/2014 3:55 PM, SuryaNarayana Garlapati wrote: >> >> >> 6) This current patch Honors the default Opensaf >> configuration ` mds_arch=0` behavior ( point 1 & 2 ) and it >> removed >> hidden `same arc message optimization` feature related >> code and used those 3bits/variable for the purpose of MDS >> version. >> >> [Surya] Current patch has still problems. I am repeating the same, >> but for your convenience, they are listed below. >> 1. Its taking out MDS optimization feature for the performance >> enhancement of the messaging. >> >> >> [AVM] we all in sync on this , now we are at the point whether we >> should expose this or not to OpenSAF users? >> >> >> 2. 64 bit and 32 bit combination will not work on the local node >> as it is doing flat encode which is wrong. >> >> >> [AVM] The current patch do ENC_TYPE_FULL for mixed 32/64 bit >> clients on the same Node. >> >> -AVM >> >> >> On 5/6/2014 3:55 PM, SuryaNarayana Garlapati wrote: >> >> Before going ahead, Following is the explanation for the arch_word >> of the MDS. >> >> Arch word(4bits) is combination of architecture and bit size of >> the machine. 3 bits are allocated >> for architecture and 1 bit is allocated for bit size. >> architecture of value 0 means unspecified. >> >> Message encoding is done as follows: >> 1. If the source and destination of the message is same process, >> then copy callback is called. >> 2. If source and destination arch_word are same, >> then encode flat is called. >> >> But there are some exceptions here, >> >> Say there are two nodes, A(Intel) and B(Powerpc) communicating >> with each other and are 64 bit each and >> opensaf code was compiled without giving any mds_arch input. In >> this case mds_arch is set to default 0. >> So as per the rule, encode flat callback should be called. But in >> this case if the flat encode is called, then >> the communication between A and B will not work as one is little >> endian and other is big endian. >> For handling this type of situations where the mds_arch is >> unspecified, mds checks for the mds_arch >> and if it is set to 0, MDS will call the encode full such that the >> communication will work between the nodes >> as the message is fully encoded. >> >> Encode flat will also be called if the source and destination are >> on the same node and arch_word is same. >> >> 3. If source and destination arch_word are different, then encode >> full is called. In this case the source and destination >> can be on the same or different node. >> >> On Tuesday 06 May 2014 09:05 AM, A V Mahesh wrote: >> >> Hi All, >> >> I re-verified the behavior of OpenSAF >> MDS_ENC_TYPE_FULL/MDS_ENC_TYPE_FLAT messaging >> and its optimization , following is my observation and option: >> >> 1) In the default OpenSAF configuration (` mds_arch=0` ) , >> messaging across the node is ENC_TYPE_FULL and >> messaging with-in the node is ENC_TYPE_FLAT . >> >> [Surya] See the explanation in point 2 and point 3. >> >> >> 2) Even though Opensaf is configured with default `mds_arch=0`, >> if their is difference of 32--bit application communicating to >> 64-bit middle-ware >> ( mixed 32/64 bit clients on the same Node), messaging >> with-in the node is also ENC_TYPE_FULL. >> >> [Surya] See the explanation in point 3. >> >> >> 3) when OpenSAF is configured with `mds_arch=1... to 7` >> messaging across & with-in the node is ENC_TYPE_FLAT , >> hear we have advantage of message optimization , only when >> explicitly enabling this configuration . >> >> [Surya] See the exception explanation in point 2. MDS was always >> designed to have this optimization a long time. It was just the >> build system was not using it. >> >> >> 4) Unfortunate the same arc message optimization feature got >> broken in few services such as RDE & PLM >> doesn't support ENC_TYPE_FLAT , we need fix these issue along >> with in-service upgrade to make it work properly . >> >> [Surya] Optimization feature is triggered by MDS. RDE & PLM are >> missing the implementation for this callbacks. >> >> >> 5) One more important note is that the `same arc message >> optimization` feature was not exposed to OpenSAF user till now. >> >> [Surya] It was always present in the confiure. Its just that, it >> was not used any time and default option was choosed for the >> mds_arch. >> >> >> 6) This current patch Honors the default Opensaf configuration >> ` mds_arch=0` behavior ( point 1 & 2 ) and it removed >> hidden `same arc message optimization` feature related >> code and used those 3bits/variable for the purpose of MDS version. >> >> [Surya] Current patch has still problems. I am repeating the same, >> but for your convenience, they are listed below. >> 1. Its taking out MDS optimization feature for the performance >> enhancement of the messaging. >> 2. 64 bit and 32 bit combination will not work on the local node >> as it is doing flat encode which is wrong. >> >> >> >> So I agree with Hans and let us not regressed for Un exposed >> feature , >> >> [Surya] Feature is present, the only thing is it was not used. >> >> and we will use the ARCHTYPE 3 bits for >> MDS version unless we get alternate bits/variables used for MDS >> version. >> >> [Surya] Thats the reason i am asking for some time. >> >> I also NOT much in favor of little bit expensive >> `new Node install & subscribe its Mds version` (My previously >> published approach) >> >> So following are current options : >> >> - Use ARCHTYPE 3 bits for MDS version and discard un exposed >> feature ( `mds_arch` config option) >> >> - Find out alter native bits for MDS version fix all the >> ENC_TYPE_FLAT issue with in-service upgrade >> and expose `same arc message optimization` feature to OpenSAF >> users. >> >> - Use `new Node install & subscribe` option for Mds version (My >> previously published approach) and fix >> all the ENC_TYPE_FLAT issue with in-service upgrade and >> expose `same arc message optimization` >> feature to OpenSAF users. >> >> >> -AVM >> >> On 5/1/2014 2:45 PM, SuryaNarayana Garlapati wrote: >> >> >> On Thursday 01 May 2014 02:30 PM, Hans Feldt wrote: >> >> Let's be clear that MDS a pure internal opensaf service since >> quite a long time. There are no "applications" to consider at all. >> This means the only thing to care about is in-service performance >> and making sure characteristics are improved, not regressed. >> >> [Surya] I am saying in the context of internal messaging between >> the services which use MDS. Yes, thats what even i am trying to. >> >> >> I am not sure we have to maintain some legacy requirement of mixed >> 32/64 bit clients on the same system. I don't see why we should. >> >> [Surya] This is not limited to even 32/64 bit. Its how the >> encoding is handled for the destinations. >> >> >> Thanks, >> Hans >> >> >> -----Original Message----- >> From: SuryaNarayana Garlapati >> [mailto:suryanarayana.garlap...@oracle.com] >> Sent: den 1 maj 2014 10:54 >> To: A V Mahesh >> Cc: opensaf-devel@lists.sourceforge.net >> <mailto:opensaf-devel@lists.sourceforge.net> >> Subject: Re: [devel] [PATCH 3 of 4] mds: use TIPC >> segmentation/reassembly [#654] >> >> >> On Thursday 01 May 2014 01:04 PM, A V Mahesh wrote: >> >> On 5/1/2014 10:16 AM, SuryaNarayana Garlapati wrote: >> >> The archtype is not a legacy one, it was introduced to have the >> optimization for the message encoding by the applications. >> >> Passing compile flags `mds_arch=1` `mds_arch=2` (mds_arch, [The >> arch-type input to MDS - valid values 1-7]) , is not a standard >> Open-Source ( enterprise things for legacy product ) option for >> compilations. >> >> [Surya] Wrong, if you see any standard linux configure options for >> any >> linux application code distributions, they do provide the options for >> supporting the options to provide such powerpc, intel, 32/64bit >> etc. So >> similar is the configure options for opensaf as well. For example you >> can see the configure options for the net-snmp as well. >> >> Open source user not need to Understand/get-Educate about this >> internal options , >> >> [Surya] This is not a internal option, configure option which is >> exposed >> to user as well. >> >> we are ok loose advantage of flat encode optimization , >> from now we want to send full_encode to different node. >> >> [Surya] This is not only done for optimization, this internally >> effects >> the message performance between the opensaf services which do huge >> messaging. >> I am on way of thinking the solution for this. Lets wait. >> >> >> We are also raising enhancement ticket for code clean. >> >> -AVM >> >> >> On 5/1/2014 10:16 AM, SuryaNarayana Garlapati wrote: >> >> On Thursday 01 May 2014 09:56 AM, A V Mahesh wrote: >> >> Hi Surya, >> >> On 5/1/2014 7:28 AM, Suryanarayana Garlapati wrote: >> >> Nack. >> MDS ARCHWORD is used for deciding the factor whether the message >> which is being sent to the destination should be encoded >> full/flat/copied. This >> bits were introduced to do a optimization in the way the callbacks >> encode full/flat are called. For example, if there are two >> processes(can be present in the same node or different node) and >> there architecture and bit size is same, so in this case, the >> encode flat can be called (or simply a flat copy of the message can >> be done in the UB). If these bits were not used, earlier the >> messages was being full encoded when the messages were sent to >> another node. At the same time, the arch field is given in the >> configure such that this can be used for different architectures >> such as the powerpc, etc. >> >> [AVM] >> “ARCHTYPE” is getting only used while cross-compiling, and to >> distinguish architecture flavors: x86, >> PowerPC, m68k ,ect . >> In the code "arch_word" is used while encoding whether to do >> MDS_ENC_TYPE_FLAT/MDS_ENC_TYPE_FULL. >> >> Keeping “ARCHTYPE” doesn't have any significance in current >> Open-sourced Opnesaf code , >> >> [Surya] This is provided to accommodate different architectures and >> is a build option which optimizes the applications way of message >> encoding(full/flat) and corresponding decode(full/flat). >> So that means, you want to remove this support and introduce the over >> head again. One more thing, with the new changes if you have two >> nodes one with powerpc and intel, both will not be able to >> communicate >> each other as both will result in flat encode/flat decode(as the >> value is one with the latest changes). >> >> why because In the current MDS messaging we do full encoded when >> the messages were sent to another process/node, irrelevant of >> “ARCHTYPE” >> >> [Surya] Wrong, the decision is done always on the archword only. >> >> I already verified cross 32/64 middle-ware & application >> combination , all the fowls are working fine . >> >> [Surya] As you said this might work, but you are loosing the >> optimization and would always result in full encode/full decode of >> application messages which is an overhead. >> >> I am thinking of a solution for this and will get back to you. >> >> [AVM] we already have an alternative option of new node do install >> & subscribe its Node Mds version, to handle in-service Upgrade , >> but we used legacy “ARCHTYPE” 3 bits for Mds version >> which is optimized solution then install & subscribe. >> >> [Surya] Thats what we had discussed before as well. The archtype is >> not a legacy one, it was introduced to have the optimization for the >> message encoding by the applications. >> >> -AVM >> >> >> Regards >> Surya >> >> >> ----- Original Message ----- >> From: osafde...@gmail.com <mailto:osafde...@gmail.com> >> To: mahesh.va...@oracle.com <mailto:mahesh.va...@oracle.com> >> Cc: opensaf-devel@lists.sourceforge.net >> <mailto:opensaf-devel@lists.sourceforge.net> >> Sent: Tuesday, April 29, 2014 10:58:53 AM GMT +05:30 Chennai, >> Kolkata, Mumbai, New Delhi >> Subject: [devel] [PATCH 3 of 4] mds: use TIPC >> segmentation/reassembly [#654] >> >> configure.ac | 21 --------------------- >> osaf/libs/core/mds/Makefile.am | 1 - >> osaf/libs/core/mds/include/mds_dt2c.h | 17 ++++++++--------- >> osaf/libs/core/mds/mds_c_sndrcv.c | 14 +++++--------- >> osaf/libs/core/mds/mds_dt_tipc.c | 11 ++++++++++- >> osaf/libs/core/mds/mds_log.c | 4 ++-- >> 6 files changed, 25 insertions(+), 43 deletions(-) >> >> >> TIPC supports sending message with a maximum length of 66000 bytes. >> MDS supports >> sending even bigger messages, upto ~46Mb. MDS has used an internal >> fragmentation >> of just 1400 bytes (MDTM_NORMAL_MSG_FRAG_SIZE) despite that the >> receive buffer >> is 8000 bytes (MDS_DIRECT_BUF_MAXSIZE) >> >> This patch changes MDS to use TIPC segmentation/reassembly. This >> gives benefits >> such as secure transmission (TIPC does retransmission). TIPC send >> congestion is >> reduced since TIPC counts messages not bytes. Less processing done >> in user >> space in the sending opensaf or client process. >> >> Since the receive buffer of older MDS cores is limited to 8000 >> bytes we have be >> sure not to send larger messages than that to older cores. >> Otherwise we have >> problems with in-service upgradeability. >> >> Each MDS TIPC port is bound to a functional address - a port name. >> The port name >> consists of 32 bit type and 32 bit instance. The 4 msb of the >> instance word >> contains the so called "archword" field. The msb indicates if this >> MDS core is >> 32 or 64 bit. The remaining 3 bits is now used as a version field. >> Version 0 is >> used by older versions of MDS, version 1 is now used to indicate >> the capability >> for longer fragmentation. >> >> This information is part of the published port name thus a >> subscriber will >> get them using the TIPC discovery service. These bits are ignored >> by old MDS >> cores, so it can receive messages from a new MDS core. When sending >> a message >> this bit is used to understand if the peer uses TIPC >> segmentation/reassembly >> (or not) and adapt the limit accordingly. >> >> The possibility to set mds_arch using configure has been removed. >> >> The change is in-service compliant and can be upgraded into a system. >> >> diff --git a/configure.ac b/configure.ac >> --- a/configure.ac >> +++ b/configure.ac >> @@ -470,27 +470,6 @@ if test "$enable_java" = no; then >> fi >> ############################################# >> -# MDS ARCH TYPE: MDS advises message encode/decode >> -# optimization to its clients if the sender and receiver >> -# are of "compatible-type". For this optimization to work, >> -# the sender's platform and receiver's platform should be >> -# similar (for e.g. both PowerPC) and use an libncs_core built >> -# with the same value for "mds_arch". An "mds_arch" value of 0 >> -# is the default value and stands for a platform which is NOT >> -# compatible with any platform. >> -############################################# >> - >> -AC_ARG_VAR([mds_arch], [The arch-type input to MDS - valid values >> 1-7]) >> - >> -if test "$mds_arch" = ""; then >> - mdsarchtype=0 >> -else >> - mdsarchtype=$mds_arch >> -fi >> - >> -AC_SUBST([MDS_WORD_ARCH_FLAGS], [" -DMDS_ARCH_TYPE=$mdsarchtype"]) >> - >> -############################################# >> # Checks for libraries. >> ############################################# >> PKG_CHECK_MODULES([XML2], [libxml-2.0]) >> diff --git a/osaf/libs/core/mds/Makefile.am >> b/osaf/libs/core/mds/Makefile.am >> --- a/osaf/libs/core/mds/Makefile.am >> +++ b/osaf/libs/core/mds/Makefile.am >> @@ -23,7 +23,6 @@ SUBDIRS = include >> noinst_LTLIBRARIES = libmds.la >> libmds_la_CPPFLAGS = \ >> - @MDS_WORD_ARCH_FLAGS@ \ >> $(AM_CPPFLAGS) >> libmds_la_LDFLAGS = -static >> diff --git a/osaf/libs/core/mds/include/mds_dt2c.h >> b/osaf/libs/core/mds/include/mds_dt2c.h >> --- a/osaf/libs/core/mds/include/mds_dt2c.h >> +++ b/osaf/libs/core/mds/include/mds_dt2c.h >> @@ -33,17 +33,16 @@ >> typedef uint8_t MDS_SVC_ARCHWORD_TYPE; /*MDS app-svc arch >> and word_size combination */ >> -/* MDS_WORD_SIZE_TYPE and MDS_ARCH_TYPE are compile-time >> macros */ >> - >> -#ifndef MDS_ARCH_TYPE >> -#define MDS_ARCH_TYPE 0 /* Stands for unspecified >> architecture type */ >> -#elif (MDS_ARCH_TYPE > 7) >> -#error MDS_ARCH_TYPE should be in the range 0 to 7. >> -#endif >> - >> #define MDS_WORD_SIZE_TYPE ((sizeof(long)/4) - 1) /* 0 for >> 32-bit, 1 for 64-bit */ >> -#define MDS_SELF_ARCHWORD ((MDS_SVC_ARCHWORD_TYPE) >> ((MDS_WORD_SIZE_TYPE<<3) | MDS_ARCH_TYPE)) >> +/* >> + * 4 bit ARCHWORD usage: >> + * Bit 3 is wordsize >> + * Bit 2:0 is a version field indicating capabilities. >> + * Version 0 uses 1400 bytes fragmentation. >> + * Version 1 uses TIPC max msg (66000 bytes) fragmentation. >> + */ >> +#define MDS_SELF_ARCHWORD ((MDS_SVC_ARCHWORD_TYPE) >> ((MDS_WORD_SIZE_TYPE<<3) | 1)) >> typedef enum { >> MDS_VIEW_NORMAL, >> diff --git a/osaf/libs/core/mds/mds_c_sndrcv.c >> b/osaf/libs/core/mds/mds_c_sndrcv.c >> --- a/osaf/libs/core/mds/mds_c_sndrcv.c >> +++ b/osaf/libs/core/mds/mds_c_sndrcv.c >> @@ -1483,10 +1483,10 @@ static uint32_t mcm_msg_encode_full_or_f >> msg_send.dest_pwe_id = >> m_MDS_GET_PWE_ID_FROM_SVC_HDL(svc_cb->svc_hdl); >> msg_send.dest_vdest_id = dest_vdest_id; >> msg_send.src_svc_sub_part_ver = svc_cb->svc_sub_part_ver; >> + msg_send.msg_arch_word = to_msg->rem_svc_arch_word; >> if (msg_send.msg.encoding == MDS_ENC_TYPE_FULL) { >> if (NULL == bcast_ptr) { >> - msg_send.msg_fmt_ver = >> cbinfo.info.enc.o_msg_fmt_ver; /* archword will be filled in >> next label */ >> - msg_send.msg_arch_word = to_msg->rem_svc_arch_word; >> + msg_send.msg_fmt_ver = cbinfo.info.enc.o_msg_fmt_ver; >> } >> } else { >> if (NULL == bcast_ptr) { >> @@ -6502,14 +6502,10 @@ static uint32_t mcm_query_for_node_dest_ >> if (m_MDS_GET_ADEST == adest) { >> *to = DESTINATION_SAME_PROCESS; >> } else if (MDS_SELF_ARCHWORD == arch_word) { >> - if ((0 == (MDS_SELF_ARCHWORD & 0x7) && (0 == (arch_word & >> 0x7)))) { >> - if (m_MDS_GET_NODE_ID_FROM_ADEST(m_MDS_GET_ADEST) == >> m_MDS_GET_NODE_ID_FROM_ADEST(adest)) { >> - *to = DESTINATION_ON_NODE; /* This hash define >> may give a wrong impression, but actually it means to do flat_enc */ >> - } else { >> - *to = DESTINATION_OFF_NODE; >> - } >> + if (m_MDS_GET_NODE_ID_FROM_ADEST(m_MDS_GET_ADEST) == >> m_MDS_GET_NODE_ID_FROM_ADEST(adest)) { >> + *to = DESTINATION_ON_NODE; /* This hash define may >> give a wrong impression, but actually it means to do flat_enc */ >> } else { >> - *to = DESTINATION_ON_NODE; >> + *to = DESTINATION_OFF_NODE; >> } >> } else { >> *to = DESTINATION_OFF_NODE; >> diff --git a/osaf/libs/core/mds/mds_dt_tipc.c >> b/osaf/libs/core/mds/mds_dt_tipc.c >> --- a/osaf/libs/core/mds/mds_dt_tipc.c >> +++ b/osaf/libs/core/mds/mds_dt_tipc.c >> @@ -2035,7 +2035,16 @@ uint32_t mds_mdtm_send_tipc(MDTM_SEND_RE >> m_MDS_LOG_INFO("MDTM: User Sending Data lenght=%d >> Fr_svc=%d to_svc=%d\n", len, >> req->src_svc_id, req->dest_svc_id); >> - int frag_size = MDTM_NORMAL_MSG_FRAG_SIZE; >> + // determine fragment limit using a bit in >> destination archword >> + int frag_size; >> + int version = req->msg_arch_word & 0x7; >> + if (version > 0) { >> + // normal mode, use TIPC fragmentation >> + frag_size = TIPC_MAX_USER_MSG_SIZE; >> + } else { >> + // old mode, completely skip TIPC fragmentation >> + frag_size = MDTM_NORMAL_MSG_FRAG_SIZE; >> + } >> if (len > frag_size) { >> /* Packet needs to be fragmented and send */ >> diff --git a/osaf/libs/core/mds/mds_log.c >> b/osaf/libs/core/mds/mds_log.c >> --- a/osaf/libs/core/mds/mds_log.c >> +++ b/osaf/libs/core/mds/mds_log.c >> @@ -64,8 +64,8 @@ uint32_t mds_log_init(char *log_file_nam >> if ((fh = fopen(lf, "a+")) != NULL) { >> fclose(fh); >> - log_mds_notify("BEGIN MDS LOGGING| >> PID=%d|ARCH=%d|64bit=%ld\n", >> - process_id, MDS_ARCH_TYPE, >> (long)MDS_WORD_SIZE_TYPE); >> + log_mds_notify("BEGIN MDS LOGGING| >> PID=%d|ARCHW=%x|64bit=%ld\n", >> + process_id, MDS_SELF_ARCHWORD, >> (long)MDS_WORD_SIZE_TYPE); >> } >> return NCSCC_RC_SUCCESS; >> >> >> ------------------------------------------------------------------------------ >> >> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For >> FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform >> available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Opensaf-devel mailing list >> Opensaf-devel@lists.sourceforge.net >> <mailto:Opensaf-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >> >> >> >> ------------------------------------------------------------------------------ >> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For >> FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform >> available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Opensaf-devel mailing list >> Opensaf-devel@lists.sourceforge.net >> <mailto:Opensaf-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >> > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. > Get unparalleled scalability from the best Selenium testing platform available > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Opensaf-devel mailing list > Opensaf-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensaf-devel ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
