Automic Workload Automation

 View Only
  • 1.  GET_FILESYSTEM is taking too much time

    Posted Nov 20, 2019 02:51 AM
    Hello Folks, I need some help here!!!

    GET_FILESYSTEM(&HOST,&FILE,PATH_SPACE_USED,Bytes) command -
    - Taking more than 20 mins to respond back in PROD Win box.
    - Taking just seconds to respond back in QA WIN box.

    I spoke to Win Admin team & the PROD box is healthy enough to respond back. So they do not see any reason to have response time of 20 mins.

    Would anyone please explain how GET_FILESYSTEM works ? What parameter from WIN is responsible for this response. Based on that we can check with Win Admin with more details.

    Codes of a FILE-EVENT - EVENT-PROCESS
    ----------------------------------------------
    :SET &HOST = GET_ATT(HOST)
    :SET &FILE = GET_ATT(EVENT_FILE_PATH)

    :PRINT "HOST -&HOST"
    :PRINT "FILE -&FILE"
    :SET &C1 = '0'
    :SET &C2 = '1'
    : SET &C1 = GET_FILESYSTEM(&HOST,&FILE,PATH_SPACE_USED,Bytes)
    : WAIT 30
    : SET &C2 = GET_FILESYSTEM(&HOST,&FILE,PATH_SPACE_USED,Bytes)
    : PRINT '(2) PATH_SPACE_USED Returned - 2ND CHECK OF FILE IS &C2'
    ----------------------------------------------

    REPORT from a QA box
    ----------------------------------------------
    2019-11-20 01:27:02 - U00020408 HOST - < just omitting the server name for this community post >
    2019-11-20 01:27:02 - U00020408 FILE - < just omitting the File Path for this community post >
    2019-11-20 01:27:02 - U00020408 1ST CHECK OF FILE IS 0000000000139256
    2019-11-20 01:27:31 - U00020408 2ND CHECK OF FILE IS 0000000000139256
    ----------------------------------------------

    REPORT from a PROD box
    ----------------------------------------------
    2019-11-20 00:46:36 - U00020408 HOST - < just omitting the server name for this community post >
    2019-11-20 00:46:36 - U00020408 FILE - < just omitting the File Path for this community post >
    2019-11-20 01:06:43 - U00020408 1ST CHECK OF FILE IS 0000000000007341
    2019-11-20 01:16:24 - U00020408 2ND CHECK OF FILE IS 0000000000007341
    ----------------------------------------------

    ------------------------------
    Regards,
    Prosenjit
    ------------------------------


  • 2.  RE: GET_FILESYSTEM is taking too much time

    Posted Nov 21, 2019 02:53 AM
    Hello Prosenjit,

    What is the Agent Window version you are using?
    There is an issue with function get_filesystem and solution is available in 12.3 or 12.2.4.

    Maybe you can check if this is also your case.

    Regards,
    Carlos

    ------------------------------
    Regards,
    Carlos
    ------------------------------



  • 3.  RE: GET_FILESYSTEM is taking too much time

    Posted Nov 21, 2019 05:45 PM
    Its with 12.2.3+build.1558154957665

    Carlos thanks - do you have link to the bug you mention?

    I see this related bug but its not an exact hit - 

    The script command GET_FILESYSTEM() aborted with an error when it had to process directories containing other files
    and directories with an absolute file name longer than the Windows limitation PATH_MAX (260 characters).
    2019-08-16
    A problem has been fixed, where the script command GET_FILESYSTEM() aborted with an error
    when it recursively had to process directories containing other files and directories expanding to
    absolute file names longer than the Windows limitation PATH_MAX (260 characters). While it is
    possible in the Automation Engine to provide file names of only up to 256 characters, such long
    absolute file names especially can occur when a Unix file share is accessed in Windows via
    Samba and is processed recursively. The limit for absolute path lengths processed by
    GET_FILESYSTEM() is 32,767 characters, now.
    Components:
    Agent Windows
    Fixed Versions:
    Automation.Engine 12.1.6
    Automation.Engine 12.2.4
    Automation.Engine 12.3.1
    Automation.Engine 12.4.0


  • 4.  RE: GET_FILESYSTEM is taking too much time

    Posted Nov 22, 2019 02:33 AM
    Hello Tony,

    We raise this issue to Broadcom as we have hit the issue for this function.
    so they tell us the issue is resolve in 12.2.4 version.

    ------------------------------
    Regards,
    Carlos
    ------------------------------



  • 5.  RE: GET_FILESYSTEM is taking too much time

    Posted Nov 25, 2019 11:42 PM
    Hello Carlos, 

    We are using Win Agent version - 12.2.3+build.1558154957665

    Before upgrading to the above version, we were at V10 & GET_FILESYSTEM was working similar to all of the Win boxes. 
    Post migrating to the above version for one particular Server GET_FILESYSTEM is taking too much time.
    For rest of the servers we are using same UC4 Windows Agent but DO NOT observe such.

    As per the GET_FILESYSTEM documentation ( which is NOT changed between V10 & V12 ), we put parameter "Include Sub directories" = "N" then the function started behaving as expected. 

    https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/12.2/AWA%20Guides/help.htm#Script/Reference/GET_FILESYSTEM.htm?Highlight=GET_FILESYSTEM


    Earlier command line     -  : SET &C1 = GET_FILESYSTEM(&HOST,&FILE,PATH_SPACE_USED,Bytes)
    Present command Line  -  : SET &C1 = GET_FILESYSTEM(&HOST,&FILE,PATH_SPACE_USED,Bytes,"N")

    Now we are NOT sure if V10 Windows Agent was working correctly & V12 windows agent introduced bug OR the otherwise. On top of that if this is expected behavior for V12 Windows agents then we have  more than 800 win agents in total, so could have seen another scenario as above explained. But only one particular server is behaving this way so we are not confident on it's root cause. Any comments on this please ?  


    ------------------------------
    Regards,
    Prosenjit
    ------------------------------



  • 6.  RE: GET_FILESYSTEM is taking too much time
    Best Answer

    Posted Nov 29, 2019 02:33 AM
    Hello Prosenjit,

    I would suggest to do a trace on this particular server and send the needed logs to Broadcom support.
    They might discover a new bug on your use case.


    ------------------------------
    Regards,
    Carlos
    ------------------------------