Locking up when inactive?

[Tarby777]

Hi all,

I have Webspeed running in a v11.6 PASOE instance, and I'm finding that it periodically locks up. OE Explorer shows it as running, and tcman doesn't report anything wrong, but it gets into a state where nothing seems to be getting through and the only solution is to stop and restart the instance. I call up a Webspeed URL in a browser, and all I get is a blank screen. Chrome dev tools show that the call to the server returned a 200, but there was nothing in the response.

As far as I can tell, the problems start after a long period of inactivity. For example: it was fine when I left it at end of play yesterday but when I come to run something in it for the first time this morning, it doesn't want to know. I'm the only person using this instance. I have several Webspeed instances in PASOE on this particular Windows server and this one - which I created recently - seems to be the only one that behaves like this, so I'm wondering if there is perhaps something like a Tomcat setting that I might need to change from its default value.

There's nothing in the Windows event logs, and not much in the Progress logs. I ran my test at 08:58. I have the following in [instance].agent.log (the last entry is written when I close the browser tab):

[23/11/24@08:17:00.396+1100] P-002032 T-000516 1 AS-Listener MSAS Spawning New Worker Thread. Number: 5
[23/11/24@08:18:14.673+1100] P-002032 T-010044 1 AS-Aux MSAS Worker Thread exiting. Number: 5, Status: 0
[23/11/24@08:47:00.575+1100] P-002032 T-000516 1 AS-Listener MSAS Spawning New Worker Thread. Number: 5
[23/11/24@08:48:14.731+1100] P-002032 T-006268 1 AS-Aux MSAS Worker Thread exiting. Number: 5, Status: 0
[23/11/24@08:58:35.038+1100] P-002032 T-000516 1 AS-Listener MSAS Spawning New Worker Thread. Number: 5
[23/11/24@08:58:53.958+1100] P-002032 T-009924 1 AS-13 -- (Procedure: 'CRM/crm.p' Line:873) Error reading socket, ret=10054, errno=2. (778)
[23/11/24@08:58:53.958+1100] P-002032 T-009924 1 AS-13 -- (Procedure: 'CRM/crm.p' Line:873) ** Incomplete write when writing to the server. (735)
[23/11/24@09:00:14.769+1100] P-002032 T-009924 1 AS-Aux MSAS Worker Thread exiting. Number: 4, Status: 0

I have the following in [instance].yyyy-mm-dd.log:

08:18:14.671/56528034 [9Ql0cwOPRiqUlfF70lLWKw-Monitor] WARN  c.p.appserv.IdleResourceWatchdog - shutdown 1 idle connections for agent pool J3x2SYS4Rf28x4S20rsjXQ
08:48:14.729/58328092 [9Ql0cwOPRiqUlfF70lLWKw-Monitor] WARN  c.p.appserv.IdleResourceWatchdog - shutdown 1 idle connections for agent pool J3x2SYS4Rf28x4S20rsjXQ
09:00:14.767/59048130 [9Ql0cwOPRiqUlfF70lLWKw-Monitor] WARN  c.p.appserv.IdleResourceWatchdog - shutdown 1 idle connections for agent pool J3x2SYS4Rf28x4S20rsjXQ

I have compared the various properties files in the instance folder to another instance that is working OK, and there are no obvious differences that I could see. Any ideas what to try next? I'm going to see if there is anything in the Tomcat logs...

TIA
Tarby

 

[Stefan]

Looks like the connection between PASOE and your database was lost / snipped? What does your database log show?

 

[Rob Fitzpatrick]

Looks like the connection between PASOE and your database was lost / snipped? What does your database log show?

Agreed, that 778/735 happens when there is a network disruption and the client disconnects from the database.

 

[Tarby777]

The WebSpeed session starts without a database connection, then it connects by using a PF whose name is supplied in the FormData in the post. It does some stuff then it disconnects via some logic in a 'Finally' block. So... it should always start without a database and give up its connection when it completes. That's why it seems odd to me that I should see a message that hints at an existing connection being lost. Ah well, onward and upward. I'll try some tweaks today...

 

[Stefan]

From the notes section of the disconnect statement manual:

• By default, the AVM disconnects all databases at the end of a session. The DISCONNECT statement, which explicitly disconnects a database, does not execute until all active procedures that reference the database end or stop.

 

[Tarby777]

From the notes section of the disconnect statement manual:

That should be fine, unless I'm falling foul of something that has happened in another session. In the code that I'm checking, the PF for the database is supplied in the form data on the HTTPS post. The top-level program disconnects any databases apart from the one it needs, connects it, runs a program and disconnects the database afterwards, then it terminates.