Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Don't understand why OI is crashing
My question here relates to this btree.extract discussion
I thought initially it may be a btree.extract limitation but it's not specifically.
The error is occurring with calls initiated via http.
Further testing of the btree.extract with less parameters shows the issues occur once the criteria reaches the 11th customer.
Less than that and the results return as expected. Change the 11th customer and it still crashes so it's not the specific data.
If I make the exact same btree.extract call as the screenshot but run from tcl everything works correctly and the data is returned.
When I say run from tcl, I wrote a small routine with the same btree.extract call hardcoded. Does nothing else.
This leads me to think (perhaps incorrectly) that it has something to do with the user profile and I'm moving out of my depth here.
Web server is IIS. I'm guessing that IIS executes as the "System" user? Could there perhaps be an issue with clientsetup needing to be run for the "System" user or does it not matter who you're logged in as when running the clientsetup?
I thought initially it may be a btree.extract limitation but it's not specifically.
The error is occurring with calls initiated via http.
Further testing of the btree.extract with less parameters shows the issues occur once the criteria reaches the 11th customer.
Less than that and the results return as expected. Change the 11th customer and it still crashes so it's not the specific data.
If I make the exact same btree.extract call as the screenshot but run from tcl everything works correctly and the data is returned.
When I say run from tcl, I wrote a small routine with the same btree.extract call hardcoded. Does nothing else.
This leads me to think (perhaps incorrectly) that it has something to do with the user profile and I'm moving out of my depth here.
Web server is IIS. I'm guessing that IIS executes as the "System" user? Could there perhaps be an issue with clientsetup needing to be run for the "System" user or does it not matter who you're logged in as when running the clientsetup?
Comments
Therefore, I believe your focus should be on the OEngineServer service. You can view the Properties for this service and check the Log On tab to see how it interacts with the computer. The default will be Local System Account. I have not had any experience in changing how this works, but you might try to configure for a different user account and see what happens.
My highly speculative guess is that once your Btree.Extract string gets to a certain level of complexity, the system needs to rely upon temporary disk storage. If that is unavailable to your account, then this might result in the crashing you are experiencing. You might also check the Database Manager to see where the Sort Path is directed. That might help explain things.
CUSTOMER²EBL²EBL-PERM²EBL-KNOWLES15²EBL-KNOWLES17²EBL-KNOWLES19²EBL-KNOWLES23²EBL-KNOWLES²EBL-BOLIVAR²EBL-DRYS2²EBL-DRYS3²EBL-FERGUSSON3A²EBL-FERGUSSON3B²EBL-HARROWHOUSE ROSTER_DATE²17903~17912If not then would this structure help avoid your limit?
Cheers, M@
Don, I will work through your suggestions today and see where it gets me.
Matt, there is a reason but at the moment I can't remember what it was. I suspect that it had to do with the fact that the routine that actually builds the criteria is a generic routine that builds the criteria from an array of any number of index fields and values.
I admit it's something I've had mentally slated to revisit and see if I can rework but I feel like I tried that approach in the first instance and couldn't come up with a consistent pattern to make it work. Also may have just been this was easier in the limited timeframe.
As for the second part of the question, I'm not yet convinced it's a "limit" problem but something more sinister that just presents itself more noticeably in these conditions. As I need this working yesterday I'm just throwing out information as I gather it in a hope it will expedite the troubleshooting process.
Thanks for your suggestion though. It's good to know that that syntax should work. I thought it should but hadn't had a need to use it that way previously and the doco was less than convincing.
Got the same windows crash error. This time I looked at the more detail section.
It says this
which from what I can gather is telling me much the same as the debugger messages, in that OI is trying to access memory that is no longer available ala "Labeled common has not been defined", "Labeled common created smaller than declaration", "Labeled common name string format error"; all messages I've received at some point in this blowing up.
Anybody have a different interpretation of that or a suggestion for what may cause it?
Had nothing to specifically to do with HTTP or btree.extract.
Sorry to report that the culprit was srp_stopwatch and my creative use of meaningful stopwatch names. It's almost as if I had the opposite of Matts issue so it's very possible it has already been addressed and I simply haven't updated.
In benchmarking the code, there was one part where I was recording the timings of the actual select and used a variation of the select statement itself as the stopwatch name. It wasn't until some six weeks or so after the benchmarking had been implemented that somebody managed to create a select/btree filter that made the stopwatch name too long. I don't know how long is too long, just that it hits a point where OI gets unhappy and points the finger at common variables, I assume the next time it tries to use some. The crashes occurred in different OI routines and srp_stopwatch and with different errors but always pointed the finger in some way at common variables.
At a later date I will update srp_stopwatch and retest and perhaps the horse has already bolted but in the meantime, if you're using srp_stopwatch (and I still recommend that people do) I'd suggest to avoid using a novel for the stopwatch name.
Great job on finding that culprit though! :)
StopWatchName = "SRP_Stopwatch_":Name Common //StopWatchName// StartTime@, EndTime@I don't think there is any mystery as to why OI choked on your...ahem...creative choice of stopwatch names. You are on your own with this problem. :)
I had a two digit year in one date and a four digit year in the other