Hi Jason and Victor and others, One thing that I noticed about V8 is that I think the default for the maximum stack of filters is still a very high 10,000. The trouble with having such a high limit is that you can have your system just run out of resources eg. stack space, before that limit is reached. I would have thought a limit to nested filters at around 25 or 50 should be plenty. If you have it set to this limit and you find that a perfectly well behaved process is still hitting the limit I'd be surprised, and you could just up the limit. I suspect in the examples here there is a bug or some bad data that is causing the system to be a lot more recursive than was intended. You would probably see a bit of a spike on resources such as cpu and memory if a process does loop.
In the old days we didn't have a filter stack limit, just a total number of filters. The trouble with that is that with the large number of filters that something like HPD:Help Desk had you could hit pretty high limits in just normal use. Alternatively you could have a tightly recursive set of filters that used up the stack without hitting the filter limit. If you can replicate the problem it would be a good idea to have server logging on to see what is happening. You may not see the log immediately prior to the system crash but you will definitely be able to see a trend before hand. Your log will be pretty full if you are running out of stack. If you have a low filter stack limit then you will see an error thrown and won't have a crash to worry about. Rod On 3 December 2012 15:06, Jason Miller <[email protected]> wrote: > ** Not that I know of. I didn't notice the error right when it happened. > It occurred about 40 minutes after I released the system to users (all two > at that time of morning). I was done with everything on the server and > finishing up some documentation so I don't know what the resources looked > like a that moment. > > Now that I had a change to look again I was wrong about the progression > being the same. It was stack limit -> DB connection error (different than > Victor's DB update timeout) -> AR terminated. > > Wed Nov 28 04:23:19 2012 390635 : Approaching physical stack limit. ( > ARERR 8749) > Wed Nov 28 04:23:19 2012 390635 : Unable to connect to the SQL database. > (ARERR 551) > Wed Nov 28 04:23:19 2012 Stop server > Wed Nov 28 04:23:19 2012: AR System server terminated — fatal error > occurred in ARSERVER (ARNOTE 21) > Wed Nov 28 04:23:20 2012 : Action Request System(R) Server x64 Version > 7.6.04 SP4 201209051922 > (c) Copyright 1991-2011 BMC Software, Inc. > > I don't want to steal the thread about his DMT issue. It seemed odd this > being the first time I have seen the physical stack limit error and Victor > happens to mention days later. > > Jason > > > > On Sun, Dec 2, 2012 at 2:24 PM, Tauf Chowdhury <[email protected]> wrote: > >> ** >> Jason, was there a spike in arserver process memory usage? >> >> Sent from my iPhone >> >> On Dec 2, 2012, at 5:09 PM, Jason Miller <[email protected]> wrote: >> >> ** >> >> I saw the "Approaching physical stack limit" error for the first time >> Tuesday night after upgrading production from 7.5 to 7.6.04 64-bit. It was >> the same progression you observed, DB timeout -> stack limit -> AR >> terminated. I have only seen it once so far. >> >> Jason >> On Dec 2, 2012 1:30 AM, "Victor" <[email protected]> wrote: >> >>> Hi Adhwari, >>> >>> Unfortunately I didn't get past creating the first job. After logging >>> back in >>> I could not find the job created in job console. >>> >>> Thanks for your time. >>> >>> Regards, >>> Victor. >>> >>> On Sunday 02 Dec 2012 08:06:20 Kulkarni, Adhwari wrote: >>> > Hi Victor, >>> > This kind of error is usually observed when you are creating the first >>> job >>> > using the 'job console'. That is the time when the UDM engine builds >>> the >>> > complete dependency data required for UDM to work which takes a lot of >>> > resources. Do you see the same error while creating all the jobs? >>> > Also, can you please check if the job is created by logging back in. >>> > >>> > Regards, >>> > Adhwari >>> > >>> > >>> >>> >>> _______________________________________________________________________________ >>> 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_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _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"
