What is the minimum non-zero value of the -usernotifytime?

Posted by George Potemkin on 20-Aug-2019 17:54

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.

Posted by Kyle Monico on 22-Aug-2019 12:02

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.

All Replies

Posted by George Potemkin on 21-Aug-2019 15:11

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

Posted by Kyle Monico on 22-Aug-2019 12:02

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.

Posted by George Potemkin on 22-Aug-2019 13:05

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.

Posted by Kyle Monico on 22-Aug-2019 14:58

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.

Posted by George Potemkin on 22-Aug-2019 16:32

I will open a case.

This thread is closed