Indexer Server locking up (OpenInsight 32-bit Specific)
At 22 FEB 2005 04:35:40AM Simon G Wilmot wrote:
We are running an OI32 (ver 4.0.2) dedicated index server on a system using both OI and ARev user interfaces. If a user on an ARev 'front end' does a select on a perticular index that will take a long time, or that user cancels the select but then does nothing on that terminal, the index server sits at the locked index record and is inaccessible until that index is freed. The machine running the index server also then goes up to 100% CPU utilisation. Is there anything that can be set to ignore locked index records or is this a known problem ??
Regards,
Simon
At 22 FEB 2005 05:10AM Simon G Wilmot wrote:
This appears to be due to an ARev error. The issue with a long running selection is acceptable, the other isn't.
If in TCL, Select Table with column=??' and then Escape.
This leaves the !Table, Column*Root record locked. This lock is only cleared on logging out of ARev.
Any thoughts anyone ??
Simon
At 22 FEB 2005 07:56AM support@sprezzatura.com wrote:
Your station locked it, so write a routine that unlocks it.
support@sprezzatura.com
The Sprezzatura Group Web Site
World Leaders in all things RevSoft
At 22 FEB 2005 08:52AM Simon G Wilmot wrote:
Not necessarily my station … if a user runs a select and then cancels it I wouldn't expect ARev to continue to hold the index record locked. We are looking at ways around this, but I would have thought that the index engine shouldn't just halt at this until something comes along and kicks the lock off.
Is this a known ARev bug at all with a patch ??
Simon
At 22 FEB 2005 09:07AM support@sprezzatura.com wrote:
There is no patch that we are aware of.
support@sprezzatura.com
The Sprezzatura Group Web Site
World Leaders in all things RevSoft
At 22 FEB 2005 09:12AM Simon G Wilmot wrote:
Thanks.
Simon
At 22 FEB 2005 11:46AM Warren Auyong wrote:
There was a "bug" in Arev 3.0 (beta at least, it may have been fixed in the release version) that would not unlock these records on index re/builds.
Otherwise this is the first I've heard of this problem.
At 23 FEB 2005 06:50AM Simon G Wilmot wrote:
It definitely happens in Arev 3.1, it wasn't obvious until we put the OI indexer on it.
We've got round it as we have a replacement to the background indexing on normal workstations and that now checks for locks and clears them as necessary.