hello uv's gurus,
I'll share a strange behavior we encounter on Uv Windows.
We run some phantoms as
scheduler which performs actions on request.
The phantom check what to do, execute it then wait for the next instruction. It is restarted each 8 hours.
---
Sometimes, we encounter troubles at uniQUERY SELECT level, the select is 'pending', seems 'blocked' ...
After 50 seconds of execution, we check the status via PORT.STATUS PID xxxx LAYER.STACK and we read the phantom is 'selecting' - actual level of execution is 'Query' from uniBASIC EXECUTE CAPTURING
Here is a sample stack
- MI.SCHEDULER is the base program which CALL MI.SCHEDULER.CTR
MI.SCHEDULER.CTR
-- receive the job to do
-- create a level EXECUTE MI.SUB which perform the task
In this sample, we read SB.EXECUTE perform a EXECUTE query SELECT ARTICLES ...
PORT.STATUS PID 21448 LAYER.STACK
Pid.... User name. Who. Port name..... Last command processed
0ř0ř0
21448řsvc_uv_coldstartř -2řSELECT ARTICLES USING DICT D.FPRART WITH ART.CLE # "" AND WITH ART.ESP = "BET" AND WITH ART.VAR = "4G" AND WITH ART.CAT = "1"
Layer type....... Program name.................... Address...
Query
Verb
Command Language
Execute
BASIC run machine SB.EXECUTE 0x000004DA
BASIC run machine SB.SELECT.IDS 0x00001702
BASIC run machine SB.PROCESS 0x00001484
BASIC run machine PR.P.TRE.NOD.IMPORT 0x00001598
BASIC run machine SB.PROCESS 0x00000A84
BASIC run machine PR.WS.TRE.NOD.IMPORT 0x0000046C
BASIC run machine MI.SUB 0x000000E4
Verb
Command Language
Execute
BASIC run machine MI.SCHEDULER.CTR 0x00002618
BASIC run machine MI.SCHEDULER 0x00000856
Verb
Command Language
the list-readu every report a active group lock on ARTICLES by the phantom port itself but no other 'lock' situation....
Active Group Locks: Record Group Group Group
Device.... Inode..... Netnode Userno Lmode G-Address. Locks ...RD ...SH ...EX
3095298892 4836996281 0 -2 25 RD 3D5800 0 1 0 0
ARTICLES is loaded with 3000 of records, correctly sized/hashed/distributed, have no index, all dictionaries are D-type direct attributes (no i-type)
Our solution is to kill to restart the phantom.Executed from a interactive session, the SELECT is realy quick and is never 'pending'
This is a sample, we encounter it on different files, different queries ... it seems linked to the 'phantom' context.
We already identify that phantoms's SELECT goes slower and slower after hours of service, thats why we restart it after 8 hours.
Any idea is welcome :-) !
------------------------------
Manu Fernandes
------------------------------