Hi Danny, I haven't done much investigation. I expect there is a core but it will be relatively useless without source. I haven’t run arserver under any of the tracing utilities. I do run with server tracing on but truth to tell, I haven't inspected them.
As I said, it is on random forms (rather 'arbitrary'),and arbitrary numbers of forms, etc. As I said, sometimes it blows after a few dozen forms. Other times it doesn't blow up at all. Data should not matter. It is doing nothing with data - it is only building the form. I don't test it often 'cause once the forms are created, there is no need to do so again. It's just that I ran it on a customer's dev box this morning and that is where the number 4 came out. Interestingly, the archive form was there on restart (so it may well have been on cleanup; perhaps a double free or free of a null, or some such thing). I could do more investigation but then I'd be working for BMC - and not getting paid, and I am swamped right now. For now, I will simply document the warnings etc. Just that it's quite ugly to have to do that. I did have to once before, on an old release and it took 3 or 4 major releases 'till that problem was fixed. I finally removed that warning and the work-around code :) Thanks Ben -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Danny Kellett Sent: May-22-13 11:33 To: arslist@ARSLIST.ORG Subject: Re: Creating "Archive forms" and ARS stability Hi Ben, Thats interesting. Here are some thoughts: Is there always a crash after 4? Is it the same 4 forms? e.g. If you just created 4 other sample forms and used those do you get the same crash after 4? Do you think its something to do with form number 4? e.g. it didnt like diary fields or something like that? Or maybe it's due to the weight of data on form 4? When it crashes is there a core on the Linux box or is there a stack trace in the arerror.log? Are you seeing the copycache, in the thread logging, complete before you try the next form? You could probably fire up 5 dev studios and get them ready to save and try replicating it to a certain degree. Or actually maybe a quick driver script? Kind regards Danny Single Sign On (SSO) for the BMC Remedy AR System and ITSM http://www.javasystemsolutions.com/jss/ssoplugin > Hi Folks, > > > > Environments: > > 1) ARS / ITSM 7.6.04 p4 Linux Oracle (customer dev machine - ie larger > than the average VM) > > 2) ARS / ITSM 7.6.04 p0 Windows 2003 x64, MS SQL VM > 2 cores (4 cpu to the OS) 8 Gb > > 3) ARS / ITSM 8.0.0 p0 Linux Oracle > VM 2 cores (4 cpu to the OS) 8 Gb > > > > I create archive forms in an automated way one time but for many forms > (over > 100 in a full run). The forms I do this for are all "Regular" forms: > not Joins or other forms types. > > > > In the API it is a simple argument passed to ARSetSchema on the > non-archive schema. > > > > I find each creation takes 5 to 7 minutes, takes a huge amount of > memory on the server - most of which is not released when completed, > and drives the server CPU quite high to calm down again when > completed. > > > > More concern is the fact that ARS crashes occasionally. For example, > once after a customer built 4 forms on his development machine the > server crashed building the 5th. After it restarted (automatically - > the common fix these days for bad code in an application) a rerun of > the job caused no server crashes at all for a subsequent 29ish forms. > (Just running the creation against the Incident forms). > > > > On my VMs this also happens on rareish occasions. If I had to put a > number on it, it would average once per 40ish forms - but this is a > guestimate at best. It is run once and only once per VM instance and > I tend to run it against all requests rather than say just Incident. > Because of snapshots, it is easy enough to rerun this job. > > > > Obviously, causing a crash is never good, and documentation reading > "this process can cause server crashes" is not a good thing J > > > > I also always restart the server process once the forms are built to > clean up the memory - also not a good thing to tell customers: that > after building their archive forms, their server "should" be restarted > to clean up leaked memory J > > > > Of course it is hard to replicate this using Dev Studio as one must > create a single archive form, wait the requisite 5 or so minutes, then > manually create the next one. My process creates one, waits the > requisite time, and then creates the next - right away (after say a > few milliseconds). > > > > I have not tried this yet on 8.1 but intend to do so shortly. > > > > A further irritation is that the BMC documentation indicates that > Merge writes into these forms are permitted. Yet I get the error > saying that writes into these forms is not permitted - with all > variations of the Merge options. I have not tested this on a lot of > releases but it is true in the > 8.0.0 unpatched release. I simply disassociate the archive forms from > their original forms to get around this. > > > > Just curious. Has anyone dealt with this? Or communicated with BMC > on this? I suppose I should raise a BMC ticket but I generally do not > do this unless a customer has asked (and paid) me to do so J > > > > Ben Chernys > Senior Software Architect > logoSthInc-sm > > Canada / Deutschland > Mobile: +49 171 380 2329 GMT + 1 + [ DST ] > Email: <mailto:Ben.Chernys_AT_softwaretoolhouse.com> > Ben.Chernys_AT_softwaretoolhouse.com > Web: <http://www.softwaretoolhouse.com/> > www.softwaretoolhouse.com > > We are a BMC Technology Alliance Partner. > > > Check out Software Tool House's free Diary Editor and out Freebies > > Section for ITSM 7.6.04 and 8.0.0 Fields spreadsheets. > > Meta-Update, our premium ARS Data tool, lets you automate your > imports, migrations, in no time at all, without programming, without > staging forms, without merge workflow. > <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/ > > > > > > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3343 / Virus Database: 3162/6346 - Release Date: 05/21/13 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
smime.p7s
Description: S/MIME cryptographic signature
