Rick,

We've had this happen 3 times now. Once about a week ago, on Saturday, and then just barely before I started righting this (Monday). The response we are getting from WebConnect is {"isCallbackError":true,"message":"Alias is not found."} If I reload the comm servers everything immediately starts working again.

What I can't figure out is why our procs would work for a week and then suddenly say 'alias not found' but as soon as I unload and then reload the comm servers everything immediately starts working again. We have thousands if not 10s of thousands of requests a day hit this site and I know our cursors are around / aliases are correct. Once we get the 'alias is not found' message all of our comm server instances return that error message and nothing processes. Our site is crippled until I reload the comm servers. Any thoughts on something I can check?

Are there cursors that webconnect uses that may be getting closed that get recreated / opened once the comm servers are reloaded?

Thanks,

Scott

Alias not found refers to SELECT (someCursor) and it looks like that's failing.

It sounds like there's some selection that is failing. Either because the cursor is not open (do you have global cursors that maybe get closed when they shouldn't?), or because there is a resource problem opening a cursor (too many cursors open) or out of memory/locked.

Makes sense a restart of servers would fix any of those issues.

You probably need to make sure errors get logged with more information to see if you can pinpoint where the error occurs which hopefully should give you a hint what tables/cursors are affected.

Also make sure you clean up tables like the log and session so they don't get too large and cross the 2 gig limit.

+++ Rick ---

Rick,

I hadn't thought of the resource problem. I put a break point on between my response.write() and response.end() and using 'SET' in the command window to browse open cursors it looks like web connect opens a cursor called 'cgilog'. Are there any other cursors that web connect opens that I should be aware of? What I'm wondering is can I issue a 'Close Tables All' in fox or do I need to loop through and close all cursors except the cgilog?

I realize it's better to close them when I'm done with them but I found a few that are left open and as I'm not entirely sure what method(s) they are being opened in and so this is a quick band-aid to stop us from going down until I can get it resolved properly.

Also, It looks like the wwRequestLog (which gets aliased as 'cgilog' if I'm not mistaken?) is currently around 132MB after about a month of using web connect on our production site. Is there any harm to deleting records in that table after say 3+ days / packing it?

You mentioned "Also make sure you clean up tables like the log and session so they don't get too large and cross the 2 gig limit." Are those the same thing I've been talking about (the wwRequestLog / cgilog) or are those something different? What the aliases for the log and session tables?

Thanks,

Scott

Web Connection uses two tables (may just one if you're not using Sessions).

• CgiLog - the Web Connection Log table
• wwSession - the Web Connection Session State table

Logging can be turned off if you're not using it, and sessions have to be enabled in order to be used (wwProcess::InitSession() typically).

These are two tables with fixed ALIAS names but WWC opens those tables on first use, so they shouldn't cause problems, unless something inside of the application is closing cursors.

Generally you shouldn't do a CLOSE TABLES ALL because it might close something that is expected to be open. Web Connection generally checks for alias's being open and available before accessing or writing data, so this is likely not the problem unless there's a resource issue (too many open cursors or out of memory type errors).

You probably need to instrument your application, capture the error and look and see where the error is occurring and potentially store additional error state in the log.

+++ Rick --