Hi zoran, comments inline.
On 2016/09/06 06:14 PM, Zoran Milinkovic wrote: > Hi Neelakanta, > > I would go with the point one and count only active CCBs. > That will protect IMM to be CCB non-operational for minutes. > If number of non-active (aborted, committed, ..) grows a lot, than we can > reduce the time in garbage collector, as Anders Bjornerstedt proposed. I will agree, with the above approach. > Anders Bjornerstedt pointed that IMM is not high-performance database, but I > would anyway go with a redesign of CCB part, and switch std::vector structure > with a faster solution in the next OpenSAF release. > > Why maxCcbs cannot be infinite ? Why not consider maxCcbs 0 as infinite value > ? > That will keep IMM backwards compatible. with the point one the backward compatibility issues will not come. > With infinite value, I mean that we don't check number of CCBs. The Limit has to be finite, if we keep "0" then the user can not create first ccb at the time of loading as the check will fail. At the start of the cluster user has to assign a finite value based on his assumption, it is always good to have a finite value from IMM perspective. The limit can not be infinite, as the approach one is considered then 10000 active ccbs will be very high for any cluster. The 10000 limit has been there from long time for macccbs in IMM, but it is checked at sync time only. Thanks, Neel. > > BR, > Zoran > > > -----Original Message----- > From: Neelakanta Reddy [mailto:[email protected]] > Sent: den 6 september 2016 13:21 > To: [email protected]; [email protected]; Zoran Milinkovic; > Hung Duc Nguyen; Anders Widell; Mathivanan Naickan Palanivelu > ([email protected]); [email protected] > Subject: Re: [devel] Immnd: maximum Ccbs limit 10000 has been reached very > quickly > > adding devel list > > On 2016/09/06 04:30 PM, Neelakanta Reddy wrote: >> Hi All, >> >> The MAX_CCBs limit is presently 10000. The Max ccbs are the ccbs >> present in IMM database. >> Which includes active, committed, aborted and initialized. The >> committed and aborted ccbs will be cleared from IMM database after 5 >> minutes. Note that the MAX_CCBs is dynamically configurable. >> >> If an application is fast enough like creating objects using immcfg in >> a for loop, will reach the 10000 mark within seconds. >> If an user wants to create fast ccbs for testing/any other operations >> then maxccbs can be increase dynamically before starting the test. >> immcfg -a maxCcbs = 50000 opensafImm=opensafImm,safApp=safImmService >> >> In the older release this has been allowed because the checking is not >> there and the check is present only at sync time. >> The value of maxccbs cannot be neither "0" nor "infinite(max value)". >> It should be finite. >> >> The following are the discussion points: >> The maxccbs can has two options (in the case of ccb burst): >> a) consider only active ccbs (then the IMM database can grow >> because the ccbs can stay for 5 miniutes before clearing from the IMM >> database) >> b) consider all ccbs that are present in IMM ( then the ccbs will >> reach the limit quickly) this limits the user to think of creating ccb >> bursts or increase dynamically the maxccbs value. >> >> Thanks, >> Neel. >> >> >> >> On 2016/09/06 03:15 PM, [email protected] wrote: >>> Ok, but then that should not impact response time for ccbs that are >>> allowed to start. >>> >>> Yes that throttling needs to be removed. >>> >>> It can be re-introduced if corrected to only considering active ccbs >>> and garbage collecting aborted ccbs faster than today. >>> >>> The basic data-structure could also be changed from vector to >>> something more efficient, although the reason for this "need" I feel >>> has more to do with inappropriate test cases and/or faulty imm >>> applications expecting the IMM to support high transaction throughput. >>> >>> I mean operators or campaigns are unlikely to push in thousands of >>> CCBs in a session. >>> They could be doing so accidentally if executing a poorly designed >>> script or campaign. >>> >>> If what should be *one* or a few logical atomic changes is >>> implemented by many small ccbs/transactions then that subverts the >>> entire transaction concept. The operator or campaign designer then >>> simly does not understand what transactions (ccbs) are there for. >>> >>> This is unfortunately not a rare problem. >>> >>> If one or more of these transactions fail in what should have been a >>> sequence of ad-hoc transactions optimistically inserted. >>> Then the system ends up in a persistent inconsistent state. >>> Transactions/are avery useful tool for achieving change with >>> maintained consistency, but only if the user understands how they >>> work and why they work. >>> >>> /AndersBj >>> >>> >>> /AndersBj >>> >>>> ----Ursprungligt meddelande---- >>>> Från : [email protected] >>>> Datum : 2016-09-06 - 11:17 (CEST) >>>> Till : [email protected], [email protected], >>>> [email protected], [email protected], >>>> [email protected], [email protected] >>>> Ämne : Re: [devel] Immnd: maximum Ccbs limit 10000 has been reached >>>> very quickly >>>> >>>> Yes, the "throttling" is in IMM: I am referring to the new limit >>>> that IMM will handle at most 10000 transactions per every five >>>> minute period. >>>> Since IMM can actually handle around 1000 transactions per second in >>>> my setup, I run into this limit already after ten seconds, and then >>>> my test program gets ERR_NO_RESOURCES for the next four minutes and >>>> 50 seconds until IMM wakes up again. >>>> >>>> / Anders Widel >>>> >>>> On 09/06/2016 11:08 AM, [email protected] wrote: >>>>> I guess there is also a degradation in response time, particularly >>>>> for large CCBs. >>>>> That could impact the patience of operators and increase the >>>>> completion time of upgrade campaigns, which typically execute a >>>>> handful of somtimes large (in number f objects) CCBs. >>>>> >>>>> I guess this throttling also applies to MDS over TIPC transport ? >>>>> >>>>> /AndersBj >>>>> >>>>> >>>>>> ----Ursprungligt meddelande---- >>>>>> Från : [email protected] >>>>>> Datum : 2016-09-06 - 10:53 (CEST) >>>>>> Till : [email protected], >>>>>> [email protected], [email protected], >>>>>> [email protected], [email protected], >>>>>> [email protected] >>>>>> Ämne : Re: [devel] Immnd: maximum Ccbs limit 10000 has been >>>>>> reached very quickly >>>>>> >>>>>> Just for "fun", I wrote a performance test program that does >>>>>> exactly this. Here is the result I got (single-node system using >>>>>> TCP transport, no PBE, totally 18000 transactions): >>>>>> >>>>>> OpenSAF 5.0: 971.5 transactions per second >>>>>> >>>>>> OpenSAF 5.1.FC: 29.5 transactions per second >>>>>> >>>>>> That is what I would call a performance regression! Note that due >>>>>> to the throttling we have introduced in OpenSAF 5.1.FC, the >>>>>> theoretical maximum is 33.3 transactions per second. No matter how >>>>>> much we optimize the code or how powerful the node is, we can >>>>>> never go beyond this limit. I knew already before I ran the test >>>>>> that the result would be close to this number... >>>>>> >>>>>> / Anders Widell >>>>>> >>>>>> On 09/05/2016 04:50 PM, [email protected] wrote: >>>>>>> Again, that's a test of a performance metric (throughput) that I >>>>>>> claim is not relevant for the IMM service. >>>>>>> Response time per transaction does have some relevance though. >>>>>>> >>>>>>> The IMM is not intended to be a high throughput database. >>>>>>> The throughput depends very much on the configuration >>>>>>> PBE/not-PBE/2-PBE. >>>>>>> >>>>>>> During sync there is zero throughput, which is why the docs say >>>>>>> that a sync should never take longer than 60 seconds, which is >>>>>>> what defines a limit on IMM database size. >>>>>>> >>>>>>> (not to mention headless where there is zero throughput >>>>>>> indefinitely and there is no service availability guarantee >>>>>>> indefinitely == disabled SA). >>>>>>> >>>>>>> The typical use case is either one or a very few operators >>>>>>> executing single commands. >>>>>>> Or an upgrade campaign that is more or less complex in steps. >>>>>>> >>>>>>> Neither has any realtime requirements. >>>>>>> >>>>>>> They may have some implicit application specific upper time >>>>>>> requirements expressed as timeouts. >>>>>>> >>>>>>> If single operator commanded CCB takes minutes to commit, then >>>>>>> there is likely a problem, because the operator may have >>>>>>> difficulty in performing a task at the human level. But CCB >>>>>>> commit involves callbacks to applications (implementers). There >>>>>>> is a timeout for that calback, but it is configurable... >>>>>>> >>>>>>> /AndersBj >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> ----Ursprungligt meddelande---- >>>>>>>> Från : [email protected] Datum : 2016-09-05 - 15:49 >>>>>>>> (CEST) Till : [email protected], >>>>>>>> [email protected], [email protected], >>>>>>>> [email protected], [email protected], >>>>>>>> [email protected] >>>>>>>> Ämne : Re: [devel] Immnd: maximum Ccbs limit 10000 has been >>>>>>>> reached very quickly >>>>>>>> >>>>>>>> How about this use case: a performance test program that >>>>>>>> measures the number of CCBs per second that IMM can execute? >>>>>>>> >>>>>>>> / Anders Widell >>>>>>>> >>>>>>>> On 09/05/2016 03:17 PM, [email protected] wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Neither of those examples (1) A shell script calling immcfg >>>>>>>>> command from a loop; (2) A buggy application; are real use cases. >>>>>>>>> For (2) it is obvious. >>>>>>>>> >>>>>>>>> For (1), it is at best a very sloppy implementation of some use >>>>>>>>> case. >>>>>>>>> The intention of that shell script is to accomplish what >>>>>>>>> amounts to one configuration change, but it is doing so using >>>>>>>>> thousands of separate ccbs! >>>>>>>>> Say that the script itself crashes after it has completed some >>>>>>>>> immcfg commands but not all the intended ones. >>>>>>>>> What does the user do then ? >>>>>>>>> So (1) would be either just a very sloppy (and error prone) >>>>>>>>> implementation or possibly a test case of some kind, but a test >>>>>>>>> that is not a valid functional/reliability test. Possibly a >>>>>>>>> performance test of a metric where the imm is not intended to >>>>>>>>> have high performance (high transaction throughput). >>>>>>>>> >>>>>>>>> /AndersBj >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> ----Ursprungligt meddelande---- Från : >>>>>>>>>> [email protected] Datum : 2016-09-05 - 14:00 (CEST) >>>>>>>>>> Till : [email protected], >>>>>>>>>> [email protected], [email protected], >>>>>>>>>> [email protected], >>>>>>>>>> [email protected] >>>>>>>>>> Ämne : Re: [devel] Immnd: maximum Ccbs limit 10000 has been >>>>>>>>>> reached very quickly >>>>>>>>>> >>>>>>>>>> I already mentioned one use case: a shell script calling the >>>>>>>>>> immcfg command from a loop. There is also another important >>>>>>>>>> use case: >>>>>>>>>> a buggy >>>>>>>>>> application. Imagine that an application by mistake creates a >>>>>>>>>> huge amount of CCBs. Since this new limit is global, the buggy >>>>>>>>>> application will now affect all other applications in the >>>>>>>>>> whole cluster. A variant of this use-case is an attacker >>>>>>>>>> carrying out a denial-of-service attack on the system by >>>>>>>>>> somehow (e.g. via NBI) creating many CCBs. >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> >>>>>>>>>> Anders Widell >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/05/2016 12:56 PM, Zoran Milinkovic wrote: >>>>>>>>>>> Hi Hung, >>>>>>>>>>> >>>>>>>>>>> Agree with you and Anders Widell for the first item. >>>>>>>>>>> >>>>>>>>>>> For the second item, as I mentioned earlier, IMM is not >>>>>>>>>>> developed to handle a huge amount of CCBs. If we need to >>>>>>>>>>> support that, then we need to rewrite CCB part, and replace >>>>>>>>>>> std::vector with some other structure, possibly with >>>>>>>>>>> std::map. Then the performance degradation will be minimal. >>>>>>>>>>> >>>>>>>>>>> And when this is changed, probably CCB limitation would me >>>>>>>>>>> more related to memory usage instead of IMM performance. Then >>>>>>>>>>> we can consider all CCB. >>>>>>>>>>> >>>>>>>>>>> To repeat myself again, I don’t see a valid case where I’m >>>>>>>>>>> not able to open/use a CCB for minutes because some other >>>>>>>>>>> application intensively used CCBs and managed to close 10000 >>>>>>>>>>> handles within a minute. >>>>>>>>>>> >>>>>>>>>>> BR, >>>>>>>>>>> >>>>>>>>>>> Zoran >>>>>>>>>>> >>>>>>>>>>> *From:*Hung Nguyen [mailto:[email protected]] >>>>>>>>>>> *Sent:* den 5 september 2016 12:29 >>>>>>>>>>> *To:* Anders Widell; Zoran Milinkovic; A V Mahesh; Neelakanta >>>>>>>>>>> Reddy; [email protected] >>>>>>>>>>> *Subject:* Re: [devel] Immnd: maximum Ccbs limit 10000 has >>>>>>>>>>> been reached very quickly >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> I agree with Anders that we should let users enable the >>>>>>>>>>> limit instead of enabling it automatically. >>>>>>>>>>> Maybe we can set default value of those attributes to 0 and >>>>>>>>>>> IMM will interpret 0 as unlimited. >>>>>>>>>>> It's going to be a defect ticket for #195. >>>>>>>>>>> About the second problem (i.e. the meaning of maxCcbs >>>>>>>>>>> limit), I think the limit should be applied on all CCBs as we >>>>>>>>>>> store them in the same list. >>>>>>>>>>> This limit is for pure performance purpose. >>>>>>>>>>> It should be well documented though. >>>>>>>>>>> The easiest way for users to check how much resource left is >>>>>>>>>>> to use 'immadm -O displayverbose'. >>>>>>>>>>> BR, >>>>>>>>>>> Hung Nguyen - DEK Technologies >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> ------------------- >>>>>>>>>>> >>>>>>>>>>> From: Anders [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> Sent: Friday, September 02, 2016 9:53PM >>>>>>>>>>> To: Zoran Milinkovic, Mahesh Valla, Neelakanta Reddy, >>>>>>>>>>> Opensaf-devel >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>,[email protected] >>>>>>>>>>> m >>>>>>>>>>> <mailto:[email protected]>,[email protected] >>>>>>>>>>> <mailto:[email protected]>,[email protected] >>>>>>>>>>> ceforge.net >>>>>>>>>>> >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> Cc: >>>>>>>>>>> Subject: Re: [devel] Immnd: maximum Ccbs limit 10000 >>>>>>>>>>> has been reached very quickly >>>>>>>>>>> We have to consider the backwards compatibility >>>>>>>>>>> aspect here. The general principle is that if an application >>>>>>>>>>> works fine with one version of OpenSAF, then it should work >>>>>>>>>>> fine also with a newer version of OpenSAF. >>>>>>>>>>> Mahesh has evidently an example application (a test program) >>>>>>>>>>> that starts to fail after upgrading from OpenSAF 5.0 to >>>>>>>>>>> OpenSAF 5.1.FC. >>>>>>>>>>> If it is a >>>>>>>>>>> pathological example program then you can argue that it is >>>>>>>>>>> not relevant, but I don't think it is the case here. You >>>>>>>>>>> could imagine a real-life case where someone has written a >>>>>>>>>>> shell script that runs the immcfg command in a loop 10000 >>>>>>>>>>> times. >>>>>>>>>>> The safest approach to introduce a new limit where we >>>>>>>>>>> previously didn't have any limit, is to set the default value >>>>>>>>>>> of the new limit to infinite (unlimited), and let the user >>>>>>>>>>> take an active decision to configure a lower value of the >>>>>>>>>>> limit. This way, applications will not get unpleasant >>>>>>>>>>> surprises after upgrading OpenSAF. >>>>>>>>>>> regards, >>>>>>>>>>> Anders Widell >>>>>>>>>>> On 09/02/2016 10:56 AM, Zoran Milinkovic wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Mahesh, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ticket #195 introduced this limitation. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After all, I'm not sure who is right... Neelakanta or >>>>>>>>>>> me :) >>>>>>>>>>> >>>>>>>>>>> Earlier, we didn't have any limitation, and >>>>>>>>>>> limitation is introduced to have some reasonable amount of >>>>>>>>>>> CCB handles in IMM. >>>>>>>>>>> >>>>>>>>>>> IMM keeps non-used and active CCB handles in the same >>>>>>>>>>> place. If the amount of CCB handles grows a lot, then we will >>>>>>>>>>> see a degradation of IMM performance. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >From earlier discussion with Anders, it's not meant >>>>>>>>>>> from the beginning that CCB will be used so often. This might >>>>>>>>>>> be very specific case. That's also the reason why CCB handles >>>>>>>>>>> are handled in a way that is not good for huge amount of CCB >>>>>>>>>>> handles. >>>>>>>>>>> >>>>>>>>>>> >From this point of view, Neelakanta is correct. >>>>>>>>>>> >>>>>>>>>>> >From my point of view, we should only consider CCBs >>>>>>>>>>> that can be used. I don't see acceptable that CCB operations >>>>>>>>>>> cannot be done for minutes if we have a huge amount of closed >>>>>>>>>>> CCBs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We can improve CCB handling in the next OpenSAF >>>>>>>>>>> release. Now it's too late. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> For this particular problem, I would go with checking >>>>>>>>>>> only CCBs that can be used (CCB that have SA_AIS_OK on mVeto >>>>>>>>>>> variable, or calling ->isOk() method on CcbInfo struct). This >>>>>>>>>>> solution may have impact on IMM performance. >>>>>>>>>>> >>>>>>>>>>> Or we can revert the ticket and implement it in the >>>>>>>>>>> next release with better performance. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I would also like to hear Neelakanta's and Hung's >>>>>>>>>>> proposals. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Zoran >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> >>>>>>>>>>> From: A V Mahesh [mailto:[email protected]] >>>>>>>>>>> >>>>>>>>>>> Sent: den 2 september 2016 05:56 >>>>>>>>>>> >>>>>>>>>>> To: Zoran Milinkovic; Neelakanta >>>>>>>>>>> Reddy;[email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> Subject: Re: [devel] Immnd: maximum Ccbs limit 10000 >>>>>>>>>>> has been reached very quickly >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Zoran, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for the update , >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> you are right ERR_NO_RESOURCES only justifiable if >>>>>>>>>>> 10000 IMM application concurrently holding 10000 CCB`s ( >>>>>>>>>>> active CCB), in current case agent is already finalized. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> By the way by roll backing which change set I can >>>>>>>>>>> continue my testing ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -AVM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/1/2016 5:52 PM, Zoran Milinkovic wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Neelakanta, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is definitely a bug. >>>>>>>>>>> >>>>>>>>>>> When CCB is finalized, it's still shown as an >>>>>>>>>>> active CCB. >>>>>>>>>>> >>>>>>>>>>> If you check number of CCBs with resource display >>>>>>>>>>> functionality, you will see that number of CCBs is not >>>>>>>>>>> decreasing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> BR, >>>>>>>>>>> >>>>>>>>>>> Zoran >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> >>>>>>>>>>> From: Neelakanta Reddy >>>>>>>>>>> [mailto:[email protected]] >>>>>>>>>>> >>>>>>>>>>> Sent: den 1 september 2016 11:09 >>>>>>>>>>> >>>>>>>>>>> To:[email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> Subject: Re: [devel] Immnd: maximum Ccbs limit >>>>>>>>>>> 10000 has been reached >>>>>>>>>>> >>>>>>>>>>> very quickly >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think this is not yet documented and will be >>>>>>>>>>> documented. >>>>>>>>>>> >>>>>>>>>>> Try to increase the ccb limits and check. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /Neel. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/09/01 02:01 PM, Chani Srivastava wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> With current 5.1 OpenSAF changeset 7997 the >>>>>>>>>>> issue is reproducible >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ============================================== >>>>>>>>>>> >>>>>>>>>>> Sep 1 12:16:52 OSAF-SC1 osafimmnd[27298]: NO >>>>>>>>>>> Ccb 10002 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Sep 1 12:16:52 OSAF-SC1 osafimmnd[27298]: NO >>>>>>>>>>> Ccb 10003 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Sep 1 12:16:52 OSAF-SC1 osafimmnd[27298]: NO >>>>>>>>>>> Ccb 10004 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Sep 1 12:16:52 OSAF-SC1 osafimmnd[27298]: NO >>>>>>>>>>> Ccb 10005 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Sep 1 12:16:52 OSAF-SC1 osafimmnd[27298]: NO >>>>>>>>>>> ERR_NO_RESOURCES: >>>>>>>>>>> >>>>>>>>>>> maximum Ccbs limit 10000 has been reached for >>>>>>>>>>> the cluster >>>>>>>>>>> >>>>>>>>>>> =============================================== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This looks like a candidate for ticket. Let >>>>>>>>>>> me know i'll raise it in >>>>>>>>>>> >>>>>>>>>>> community. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Chani >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/1/2016 1:49 PM, Neelakanta Reddy wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> can you verify the same with 5.1. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /Neel. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/09/01 12:58 PM, Chani Srivastava >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I verified this is a break in >>>>>>>>>>> functionality. In OpenSAF 5.0 I tried >>>>>>>>>>> >>>>>>>>>>> creating 15000 objects per CCB and it >>>>>>>>>>> worked fine. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ===================================== >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:21:17 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 237 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:21:17 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 238 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:21:17 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 239 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:21:17 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 240 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:23:05 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 15230 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:23:05 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 15231 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:23:05 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 15232 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:23:05 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 15233 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:23:05 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 15234 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:23:05 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 15235 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> Nov 26 15:23:05 SCALE_SLOT-91 >>>>>>>>>>> osafimmnd[24451]: NO Ccb 15236 >>>>>>>>>>> >>>>>>>>>>> COMMITTED >>>>>>>>>>> >>>>>>>>>>> (chaniTestClass) >>>>>>>>>>> >>>>>>>>>>> ====================================== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The ticket #195 only makes the MAX >>>>>>>>>>> parameters configurable. >>>>>>>>>>> >>>>>>>>>>> If accepted, I'll raise the ticket in >>>>>>>>>>> sourceforge. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Chani >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/1/2016 10:59 AM, A V Mahesh wrote: >>>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I was running `immcfg` in a loop >>>>>>>>>>> to create some object , once it >>>>>>>>>>> >>>>>>>>>>> reaches 10001objects creation >>>>>>>>>>> Immnd is returning `ERR_NO_RESOURCES: >>>>>>>>>>> >>>>>>>>>>> maximum Ccbs limit 10000 has been >>>>>>>>>>> reached for the cluster` error >>>>>>>>>>> >>>>>>>>>>> which is unexpected , once >>>>>>>>>>> `immcfg` reruns , it is expected that >>>>>>>>>>> >>>>>>>>>>> the `maximum Ccbs` will >>>>>>>>>>> decremented ( this was previous behavior) >>>>>>>>>>> >>>>>>>>>>> , >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> can you please check. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ============================================================= >>>>>>>>>>> ===== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> = >>>>>>>>>>> ====================================== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> for (( i = 1 ; i <=300000; i++)) >>>>>>>>>>> >>>>>>>>>>> immcfg -c PinvId -a >>>>>>>>>>> pinvPhoneNumber=+46768 pinvRdn=$i >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sep 1 10:43:33 SC-1 >>>>>>>>>>> osafimmnd[4466]: NO Ccb 9996 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (immcfg_SC-1_2334) >>>>>>>>>>> >>>>>>>>>>> Sep 1 10:43:33 SC-1 >>>>>>>>>>> osafimmnd[4466]: NO Ccb 9997 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (immcfg_SC-1_2337) >>>>>>>>>>> >>>>>>>>>>> Sep 1 10:43:33 SC-1 >>>>>>>>>>> osafimmnd[4466]: NO Ccb 9998 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (immcfg_SC-1_2340) >>>>>>>>>>> >>>>>>>>>>> Sep 1 10:43:33 SC-1 >>>>>>>>>>> osafimmnd[4466]: NO Ccb 9999 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (immcfg_SC-1_2343) >>>>>>>>>>> >>>>>>>>>>> Sep 1 10:43:33 SC-1 >>>>>>>>>>> osafimmnd[4466]: NO Ccb 10000 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (immcfg_SC-1_2346) >>>>>>>>>>> >>>>>>>>>>> Sep 1 10:43:33 SC-1 >>>>>>>>>>> osafimmnd[4466]: NO Ccb 10001 COMMITTED >>>>>>>>>>> >>>>>>>>>>> (immcfg_SC-1_2349) >>>>>>>>>>> >>>>>>>>>>> Sep 1 10:43:33 SC-1 >>>>>>>>>>> osafimmnd[4466]: NO ERR_NO_RESOURCES: maximum >>>>>>>>>>> >>>>>>>>>>> Ccbs limit 10000 has been reached >>>>>>>>>>> for the cluster Sep 1 10:43:33 >>>>>>>>>>> >>>>>>>>>>> SC-1 osafimmnd[4466]: NO >>>>>>>>>>> ERR_NO_RESOURCES: maximum Ccbs limit >>>>>>>>>>> >>>>>>>>>>> 10000 has been reached for the >>>>>>>>>>> cluster Sep 1 10:43:33 SC-1 >>>>>>>>>>> >>>>>>>>>>> osafimmnd[4466]: NO >>>>>>>>>>> ERR_NO_RESOURCES: maximum Ccbs limit 10000 has >>>>>>>>>>> >>>>>>>>>>> been reached for the cluster >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ============================================================= >>>>>>>>>>> ===== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> = >>>>>>>>>>> ====================================== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -AVM >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> ----------- >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> ------ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> ---------- >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> ------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> --------- >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> -------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> -------- >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------- >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -------- >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> ----------------- >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------- >>>>>>>>>>> ----------------- >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>> >>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>> ---------------- >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>> >>>>>> ------------------------------------------------------------------ >>>>>> ------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Opensaf-devel mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>> >>>> >>>> -------------------------------------------------------------------- >>>> ---------- >>>> >>>> _______________________________________________ >>>> Opensaf-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>> ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
