| ||>the submitter node is making polling request to back-end
||>node using acms$get_procedure_info to see whether the application
||>is available or not. At this time the polling request is executed
||>about 45 times per minute.
||>While the back-end node was going down, if new user try to sign-in to
||>back-end node and submit transaction to back-end node, the transaction
||>delay was occurred.
HERE'S MY GUESS:
$get_procedure_info is not designed to be a polling service executing
45 times per min-- this action is basically flooding the BE ACC to
the point that other ACC business (such as login validation) is being
starved out. This would be especially likely if you have more than
one FE, or more than one FE agent process or both. Both $get_proc_info
and $sign_in services use the ACC -- and the BE ACC is involved in
distributed configurations.
Couldn't you use ACMS's builtin primitive failover, (search list
logical names), rather than such strenuous polling, or at least slow
down the polling frequency?
Dave Carew
|
|
To add to Dave's explanation (thanks Dave)...ACC, like most
ACMS processes is AST driven. Messages are received in
EXEC mode and then delivered to the process as a USER-mode
AST. While a process is executing at AST level, it cannot
be interrupted at the same level until the AST is dismissed.
Since the bulk of ACC works occurs at USER-mode AST level,
they just back up waiting for the current AST routine
to complete. There is no threading here, no time-slicing,
nothing. A routine executes to completion, dismisses the
AST and the next one gets delivered. If you bombard the
ACC with requests, then you just have to wait for them to
complete. Since most ACMS processes run at the same priority,
you could change the ACC priority to something a little higher,
so that it could be selected to run more frequently.
Bill
|
| Thank you for your reply,
Dave and Bill.
This customer;Japan Telcom does not use ACMS's primitive failover.
I don't know the reason of not using this, probably poor design ?
Thank you,
Yuichi Ohshima,
System Support Tokyo.
|