Forum Discussion

Karl_Billingto2's avatar
Karl_Billingto2
Icon for Nimbostratus rankNimbostratus
Oct 17, 2014

Changing custom APM variable in iRule does not evaluate correctly in APM

Hi,

 

I have the following issue:

 

If I create a custom session variable in an APM policy as follows (using a variable assign object):

 

session.custom.SymantecAPIerror = expr { "false" }

 

I then call an iRule from APM which changes the custom value as follows:

 

ACCESS::session data set session.custom.SymantecAPIerror "true"

 

I can now check the session variables using the APM reporting tool and it shows:

 

Variable ID: session.custom.SymantecAPIerror Variable Value: true

 

So I can see that it has changed from "false" to "true".

 

Now I create a blank object in the APM policy to check the state of session.custom.SymantecAPIerror using the following branch rule:

 

expr { [mcget {session.custom.SymantecAPIerror}] equals "true"}

 

This branch is followed by a message box which will display an error message, but despite the session variable being set to "true", it follows the fallback branch.

 

I have tried this with an integer (0 or 1) to represent true and false, but the same happens. If I delete the iRule variable and set the initial APM variable assign value to "true", it follows the correct branch and displays the error message box, so despite the iRule changing the variable value within the session (as seen from the reporting tool), it still evaluates using the value set in the APM policy.

 

Can anyone help with this?

 

Thanks in advance.

 

2 Replies

  • I've figured out a workaround for this now:

     

    If I don't ever set the variable assignment in the APM policy and only ever set it in the iRule, then it works fine. Can anyone validate whether this is a bug or a strange caveat of the order of operation where the despite the iRule changing the value the APM policy value always wins, even though the session shows that it has changed? I'm running version 11.5.1 Build 3.0.131 Hotfix HF3. It looks like a bug to me, but I am new to iRules, so this could just be the way it works?

     

    Thanks

     

  • Hi Karl,

     

    You are running into an issue where apd will cache the session variable when you first use it. In this case you are setting it to "false" in the VPE. When the iRule then modifies the variable in tmm and you check it again in the access policy, apd will grab the value from cache instead of grabbing the new value from tmm set in the iRule. This is a known issue and is tracked as ID 420284.

     

    Until this behavior can be modified you can set "session.custom.SymantecAPIerror" in the policy to "false" if you need it for a test before you trigger the iRule. If you do this, then in the iRule when you update the variable set it to "session.custom.SymantecAPIerror1" or something different than the original name. You would then test for "session.custom.SymantecAPIerror1" being "true" or "false" later in the VPE and it will pull the variable from tmm instead of looking at its local cache for the information. If you are not using the original setting of the variable for anything before the iRule you could just remove the variable assign from the VPE and the first time the session variable would be used is in the iRule which would then be new to apd when you test it later in the VPE.

     

    I would also suggest opening a support case and asking to be linked to the ID listed above. This puts more visibility on issues and will help prioritize things going forward.

     

    Hopefully this will help you resolve this issue.

     

    Regards,

     

    Seth Cooper