Documentation says: “The minimum non-zero value is 1”
documentation.progress.com/.../index.html
If the -usernotifytime is set to non-zero value then each client locks USR latch once per the -usernotifytime interval or once per 10 seconds if the -usernotifytime is less than 10 seconds. Does it mean that the minimum value of the -usernotifytime is 10 seconds?
I saw the real cases where the -usernotifytime was set to a few minutes (3-10 minutes). Would it be wrong to set the -usernotifytime let’s say to 10 seconds? For comparison: enabling statement cache would create much higher USR latch activity.
Yes, for ABL clients the minimum is effectively 10 seconds. This limit is imposed because the client could be a remote client connected to multiple databases, and the network IO could be significant in extreme cases. There is also some synchronization within the client process. Note that SQL does not have this limit because the SQL server is not a remote connection to the database.
You could set the value to 10 seconds, but this could also increase the network IO in addition to the USR latch contention.
Off-topic note:
V11 introduced the -noneedsattnthread parameter: no needs an attention thread used for -usernotifytime. ABL session will not launch the second thread when it's connected to a database with non-zero value of the -usernotifytime. Othewise session will consist of two threads. We can see them: ps -T p <abl-client-pid>.
PID SPID TTY TIME CMD 21456 21456 pts/0 00:00:00 _progres 21456 21473 pts/0 00:00:00 _progres
gdb -p <abl-client-pid> (gdb) info thread (gdb) thread 1 (gdb) where (gdb) thread 2 (gdb) where
Output for the second thread will contain rnNeedsAttnThread
Yes, for ABL clients the minimum is effectively 10 seconds. This limit is imposed because the client could be a remote client connected to multiple databases, and the network IO could be significant in extreme cases. There is also some synchronization within the client process. Note that SQL does not have this limit because the SQL server is not a remote connection to the database.
You could set the value to 10 seconds, but this could also increase the network IO in addition to the USR latch contention.
Thanks, Kyle!
And yes, the remote ABL clients send to a server and get back one 64-byte message per notification.
By the way, IMPORT statement blocks the client's notifications. Is it expected?
The following code will reproduce the issue again any database started with non-zero -usernotifytime:
output to value("test.input").
output close.
input through value("tail -f test.input").
import unformatted ^.
input close.
message "Done" view-as alert-box.
The session will run an attention thread but it will not lock the USR latch and will block the idxactivate. Program above immitates the import of data from the third-party systems.
READKEY, UPDATE or WAIT-FOR don't have such issue.
I believe that's a bug in the ABL client. The client should allow notifications to be checked whenever the client is in a long wait for external input outside of a transaction, and this should include that usage of the IMPORT statement.
I will open a case.