Hi John, Not aware of any location for the last 100 filters or the max filter count other than the good old filter log. As far as some general information about how high you are reaching - again the log file is the only source I know. If you log to a form you may be able to report on it. A good log file analyzer is probably handy too. I suppose the big issue is that the filter logs can get very big very fast and to get a decent period of time in a busy system you are going to get an unmanageable file. The advantage of the log file though is that it will tell you quite a bit about why you have so many filters in the transaction. Recent versions of the log have the filter sequence number clearly displayed for reference.
I have seen OOB workflow maybe associated with SLM events, from memory, loop forever. I also believe there are some tools (DMT perhaps) that may set the filter limit extremely high, maybe because it wants to loop a lot within a single transaction. The two issues together are a fatal combination and after the server crashes it doesn't seem to recover properly, often throwing malloc errors periodically and not allowing big transactions to finish. A clean restart fixes the issue, that is until the loop happens again. The above I've seen on ARS 7.5 patch 7 or thereabouts running ITSM 7.6. Rod Always a good idea to keep the filter limits low enough that they are breached before the server crashes. Rod On 14 March 2014 00:09, John Sundberg <[email protected]> wrote: > ** > Good one. > > BTW - is there a location somewhere that tells you what your max filters > hit were? > > Or -- when you hit 500,000? And maybe a list of the last 100 filters that > executed. > > (Both those would be very helpful in troubleshooting / avoiding the issue) > > Minimally - they should probably become RFEs ... would be pretty easy to > implement -- value == high. > > > > -John > > > > > > On Thu, Mar 13, 2014 at 2:20 AM, Rod Harris <[email protected]> wrote: > >> ** >> Hi, >> >> Check to make sure that the server has a reasonable value for the maximum >> number of filters in an operation (in AR System Admin-Advanced tab). No >> more than about 500,000 is preferred. Sometimes the server can get into an >> endless loop and you want the maximum filters error thrown before the >> server itself crashes. The maximum filter stack should also be reasonable. >> >> Rod >> >> >> On 13 March 2014 15:07, shashidhar M S <[email protected]> wrote: >> >>> Hello Experts, >>> >>> We are getting the Malloc failed on server error in our production >>> environment daily. Below is the log trace. I am confused as what might be >>> causing this issue. Please can someone help me out on this? >>> >>> hu Mar 13 01:52:02 2014 390620 : AR System server terminated when a >>> signal/exception was received by the server (ARNOTE 20) >>> Thu Mar 13 01:52:02 2014 >>> Timestamp: 1394689922.4490 >>> Thread Id: 29048 >>> Version: 7.5.00 Patch 007 201009161400 Sep 16 2010 16:20:23 >>> ServerName: arsprod >>> Database: SQL -- Oracle >>> Hardware: Intel Pentium >>> OS: Windows Server 2003 >>> RPC Id: 1186482 >>> RPC Call: 121 (XMLGE) >>> RPC Queue: 390620 >>> Client: User BMCCTRLM from Webservice (protocol 14) at IP address >>> 10.218.105.64 >>> Logging On: Thread >>> Code: c0000005 >>> Operation: write >>> Access Addr: 0x230 >>> Stack Begin: >>> Addr: 0083B692 >>> Addr: 00515F1F >>> Addr: 00523F7B >>> Addr: 53214782 >>> Stack End >>> >>> Thu Mar 13 01:52:02 2014 390620 : AR System server terminated when a >>> signal/exception was received by the server (ARNOTE 20) >>> Thu Mar 13 01:52:02 2014 0xc0000005 >>> Thu Mar 13 01:52:02 2014 390620 : AR System server terminated -- fatal >>> error encountered (ARNOTE 21) >>> Thu Mar 13 01:55:10 2014 390620 : AR System server terminated when a >>> signal/exception was received by the server (ARNOTE 20) >>> Thu Mar 13 01:55:10 2014 >>> Timestamp: 1394690110.8880 >>> Thread Id: 61196 >>> Version: 7.5.00 Patch 007 201009161400 Sep 16 2010 16:20:23 >>> ServerName: arsprod >>> Database: SQL -- Oracle >>> Hardware: Intel Pentium >>> OS: Windows Server 2003 >>> RPC Id: 1202227 >>> RPC Call: 121 (XMLGE) >>> RPC Queue: 390620 >>> Client: User POMEROY from Webservice (protocol 14) at IP address >>> 10.218.88.229 >>> Logging On: Thread >>> Code: c0000005 >>> Operation: write >>> Access Addr: 0x230 >>> Stack Begin: >>> Addr: 0083B692 >>> Addr: 00515F1F >>> Addr: 00523F7B >>> Addr: 5321483E >>> Stack End >>> >>> Thu Mar 13 01:55:10 2014 390620 : AR System server terminated when a >>> signal/exception was received by the server (ARNOTE 20) >>> Thu Mar 13 01:55:10 2014 0xc0000005 >>> Thu Mar 13 01:55:10 2014 390620 : AR System server terminated -- fatal >>> error encountered (ARNOTE 21) >>> Thu Mar 13 01:57:05 2014 390620 : AR System server terminated when a >>> signal/exception was received by the server (ARNOTE 20) >>> Thu Mar 13 01:57:05 2014 >>> Timestamp: 1394690225.2890 >>> Thread Id: 24020 >>> Version: 7.5.00 Patch 007 201009161400 Sep 16 2010 16:20:23 >>> ServerName: arsprod >>> Database: SQL -- Oracle >>> Hardware: Intel Pentium >>> OS: Windows Server 2003 >>> RPC Id: 1213519 >>> RPC Call: 121 (XMLGE) >>> RPC Queue: 390620 >>> Client: User BMCCTRLM from Webservice (protocol 14) at IP address >>> 10.218.105.64 >>> Logging On: Thread >>> Code: c0000005 >>> Operation: write >>> Access Addr: 0x230 >>> Stack Begin: >>> Addr: 0083B692 >>> Addr: 00515F1F >>> Addr: 00523F7B >>> Addr: 532148B1 >>> Stack End >>> >>> Thu Mar 13 01:57:05 2014 390620 : AR System server terminated when a >>> signal/exception was received by the server (ARNOTE 20) >>> Thu Mar 13 01:57:05 2014 0xc0000005 >>> Thu Mar 13 01:57:05 2014 390620 : AR System server terminated -- fatal >>> error encountered (ARNOTE 21) >>> Thu Mar 13 01:57:34 2014 : Action Request System(R) Server Version >>> 7.5.00 Patch 007 201009161400 >>> (c) Copyright 1991-2009 BMC Software, Inc. >>> >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> "Where the Answers Are, and have been for 20 years" >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > > -- > > *John Sundberg* > Kinetic Data, Inc. > "Your Business. Your Process." > > 651-556-0930 I [email protected] > www.kineticdata.com I community.kineticdata.com > > > _ARSlist: "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"
