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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
