Nice...good catch. I'd never seen evidence of ARS level locking before...interesting.
It was simple enough refactor to avoid this and get it working as needed. Without boring you with details, I'd originally coded it that way to avoid an extra round trip from client to server. But it's not really important in this situation. Thanks for the help. On Wed, Mar 15, 2017 at 10:51 AM, LJ LongWing <[email protected]> wrote: > ** > Ok, I see your issue. > > You are working with a 'Physician, operate on thyself' type of issue. > > So, you finish doing phase 1 operations on form MD_KronosTest, > request MDKT-0000000001....you then start phase 2 which includes the > run-processes... > > you run process is then coming in and trying to do a set on the same form, > same record.... > > Because your original operation is currently locking that record, the > second operation cannot modify it until phase 3 is completed, and the > record is released....so, because operation 2 is sitting inside of > operation 1, operation 1 won't be able to complete BEFORE operation 2 > finishes...and operation 2 can't complete till operation 1 finishes....thus > deadlock.... > > simply....you can't have the doctor operate on himself.... > > On Wed, Mar 15, 2017 at 12:01 PM, Charlie Lotridge <[email protected]> > wrote: > >> ** >> LJ, >> >> Thanks for the suggestion. >> >> Unfortunately filterAPI isn't really an option. I have a large >> infrastructure (C++ & C# libraries) that I build on that allow me to >> rapidly develop API programs, but don't lend themselves to being used for >> filterAPI. I'd have to get the .NET runtime to work in the plugin framework >> and haven't taken (don't have) the time to figure that out, especially for >> this short project. Also, (getting way off topic) my typical API paradigm >> doesn't require synchronous access...this is a very unusual use case for >> me...which further decreases the motivation to do that research. >> >> Not sure if I can better describe the deadlock beyond the filter log >> description I gave, but I'll try... >> >> The $PROCESS$ times out and causes the ARS transaction to error. Here's >> the relevant filter log section with the $PROCESS$ Set Fields, and the >> subsequent failure message, highlighted: >> >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > /* Wed Mar 15 2017 >> 08:40:53.3190 */ End of filter processing (phase 1) -- Operation - SET >> on MD_KronosTest - MDKT-0000000001 >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > 1: Process >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > >> Application-Release-Pending >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > 2: Set Fields >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > >> c:\bin\KronosPost.exe >> -X=localhost -U=ARSystem -P=xxxxx --arRPC=390680 MDKT-0000000001 >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > Exit code: >> 0 Value: >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > Filter/escalation >> 'set field' process timed out before completion >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > **** Error while performing >> filter action: Error 39 >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > **** Filter >> "MDKT:GUIDEHandleEvents200Post:IfServicePushToUpdateEntry&Setup&RunKronosPost`!": >> No enabled error handler >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > /* Wed Mar 15 2017 >> 08:40:58.3540 */ Call Guide "MDKT:F:HandleEvents:GENERATED" (return) >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > **** Error while performing >> filter action: Error 39 >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > **** Filter >> "MDKT:050OnSubmitModifyService:IfEventCallHandleEvents:GENERATED": No >> enabled error handler >> <FLTR> <TID: 0000001804> <RPC ID: 0000031115> <Queue: Fast > <Client-RPC: >> 390620 > <USER: Admin > <Overlay-Group: 1 > /* Wed Mar 15 2017 >> 08:40:58.3540 */ End of filter processing (phase 1) -- Operation - >> SERVICE on MD_KronosTest - MDKT-0000000001 >> >> Once the transaction completes, I then see workflow associated with the >> API program operation, indicating it DID get started (this logging >> immediately follows the above): >> >> <FLTR> <TID: 0000003856> <RPC ID: 0000031120> <Queue: Prv:390680> >> <Client-RPC: 390680 > <USER: ARSystem > <Overlay-Group: 1 > /* Wed Mar 15 >> 2017 08:40:58.3550 */ Start filter processing (phase 1) -- Operation - >> GET on MD_KronosTest - MDKT-0000000001 >> <FLTR> <TID: 0000003856> <RPC ID: 0000031120> <Queue: Prv:390680> >> <Client-RPC: 390680 > <USER: ARSystem > <Overlay-Group: 1 > /* Wed Mar 15 >> 2017 08:40:58.3550 */ <Filter Level:0 Number Of Filters:0> Checking >> "MDKT:500OnGetEntry:CallOnGetEntry:GENERATED" (500) >> <FLTR> <TID: 0000003856> <RPC ID: 0000031120> <Queue: Prv:390680> >> <Client-RPC: 390680 > <USER: ARSystem > <Overlay-Group: 1 > --> Passed >> -- perform actions >> <FLTR> <TID: 0000003856> <RPC ID: 0000031120> <Queue: Prv:390680> >> <Client-RPC: 390680 > <USER: ARSystem > <Overlay-Group: 1 > 0: Call >> Guide "MDKT:F:OnGetEntry:GENERATED" >> <FLTR> <TID: 0000003856> <RPC ID: 0000031120> <Queue: Prv:390680> >> <Client-RPC: 390680 > <USER: ARSystem > <Overlay-Group: 1 > /* Wed Mar 15 >> 2017 08:40:58.3570 */ <Filter Level:0 Number Of Filters:1> Checking >> "MDKT:GUIDEOnGetEntry010CallGetEntryDescription:GENERATED" (0) >> <FLTR> <TID: 0000003856> <RPC ID: 0000031120> <Queue: Prv:390680> >> <Client-RPC: 390680 > <USER: ARSystem > <Overlay-Group: 1 > --> Passed >> -- perform actions >> <FLTR> <TID: 0000003856> <RPC ID: 0000031120> <Queue: Prv:390680> >> <Client-RPC: 390680 > <USER: ARSystem > <Overlay-Group: 1 > 0: Call >> Guide "MDKT:F:GetEntryDescription:GENERATED" >> ... >> >> Until the timeout on the $PROCESS$ occurs, both the ARS thread and my API >> process are stuck (deadlocked). >> >> When run standalone, the program completes in less than 1 second. Still, >> just to test, I did try setting the "Process Timeout" to 25 seconds. >> >> Regardless, the documentation, and my vague recollection from the last >> time I tried this, suggest that it can be made to work and my question is: >> why isn't it working? >> >> I *am* running this in a SERVICE operation...maybe Remedy doesn't like >> that for some reason? I will try refactoring to run it in a SET operation >> instead to test. >> >> Thanks, >> Charlie >> >> >> On Wed, Mar 15, 2017 at 9:22 AM, LJ LongWing <[email protected]> >> wrote: >> >>> ** >>> Charlie, >>> Being you are writing it.....have you considered making it a filterAPI >>> Plugin instead of a command line?....this has many advantages over a >>> run-process....anyway >>> >>> You say it's a deadlock....can you identify what you mean by that? >>> >>> On Wed, Mar 15, 2017 at 11:11 AM, Charlie Lotridge <[email protected]> >>> wrote: >>> >>>> ** >>>> Hi, >>>> >>>> I'm trying to run an API program I wrote in a filter Set Fields using >>>> $PROCESS$, but it's deadlocking and I can't see why. >>>> >>>> The first thing I tried, described in the documentation here >>>> <https://docs.bmc.com/docs/display/public/ars81/Executing+C+API+programs+in+workflow>, >>>> is to increase the Max Thread counts of the relevant queues but no joy. I >>>> even tried directing the API to use a private queue (RPC 390680), but still >>>> it deadlocks. >>>> >>>> I can see the deadlocking occur in a filter log: I first see my >>>> workflow (running in a fast queue) perform the $PROCESS$. It hangs for the >>>> configured 5 second timeout, then issues its error and completes its >>>> transaction. But it DID spin up my program, which (after my initial >>>> transaction fails and completes) then makes its connection (to private >>>> queue 390680) and correctly does its thing. >>>> >>>> I haven't bothered to instrument the API program to test this, but I'm >>>> quite sure that it's hanging at the point that it tries to make the ARS >>>> connection. >>>> >>>> FYI I need to use $PROCESS$ because I need the results of the API to be >>>> available to subsequent filter workflow. Run Process, which will run the >>>> API asynchronously, is not suitable. >>>> >>>> Also FYI, it's a fully licensed development system with absolutely >>>> nothing else going on (no other person or processes are using it). >>>> >>>> I've done this kind of thing before, but it's been a long time and my >>>> best recollection is that increasing the thread count solved the problem. >>>> >>>> Any suggestions? >>>> >>>> Thanks, >>>> Charlie >>>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
