ApigeeX PopulateCache - ExpirySettings -TimeoutInSec or TimeoutInSeconds?

Hello All,

              Am little confused on how to use the PopulateCache's - ExpirySettings .

1) The document says "TimeoutInSec"  is Deprecated.. But when I create a new "PopulateCache" policy in ApigeeX , the  default XML tag for ExpirySettings is "TimeoutInSec".. 

Is this still supported? Also I noticed that "TimeoutInSec" doesn't accept both reference and value in ApigeeX.

2) When we migrate proxies from say OPDK to ApigeeX do we need to update "TimeoutInSec" to "TimeoutInSeconds" . Currently it gets deployed as is but what is the best practice going forward .

Any guidance will be appreciated.

Thanks

 

 

Solved Solved
1 2 613
1 ACCEPTED SOLUTION

Am little confused on how to use the PopulateCache's - ExpirySettings .

Yes, it is confusing. Sorry about that.

TimeoutInSec has been in place for a long time. What we noticed recently was that when there is a fixed value, the referenced value is ignored. Let me explain with an example. Suppose you have this

 

<TimeoutInSec>180</TimeoutInSec>

 

In that case the timeout will always be 180 seconds. Pretty clear. You can also reference a variable, like this:

 

<TimeoutInSec ref='mytimeout'/>

 

And in that case, the timeout will be whatever you had placed in the mytimeout variable. If it holds 600, then you will get a 600-second timeout.

The bug happens when you use both. like this:

 

<TimeoutInSec ref='mytimeout'>180</TimeoutInSec> <!-- DO NOT USE THIS -->

 

The usual behavior in Apigee with this sort of syntax is to use the referenced variable if it exists; if it does not, then fallback to the constant value. But TimeoutInSec does not behave that way. It was always using the fixed, constant value.

So we introduced TimeoutInSeconds, which behaves the desired way. We considered "fixing" TimeoutInSec so that it behaves the way every other config element in Apigee behaves, but realized that some proxies may be silently depending on the "broken" behavior. So we opted to introduce a new element, that exhibits the desired behavior.

I noticed that "TimeoutInSec" doesn't accept both reference and value in ApigeeX.

Yes, the reason is because we introduced new validation in Apigee X to avoid the situation where a person uses both, and expects it to work as "use the variable, or fallback to the constant if the variable doesn't exist." That doesn't work with TimeoutInSec. It works with TimeoutInSeconds. You should use TimeoutInSeconds.

When we migrate proxies from say OPDK to ApigeeX do we need to update "TimeoutInSec" to "TimeoutInSeconds" . Currently it gets deployed as is but what is the best practice going forward .

I advise that you convert to TimeoutInSeconds. TimeoutInSec will continue to "work", as it always has worked, even though it is deprecated. Even so, in my opinion, it has confusing behavior and at this point, it is better to avoid using it.

Also: don't use BOTH in the same policy!

 

View solution in original post

2 REPLIES 2

Am little confused on how to use the PopulateCache's - ExpirySettings .

Yes, it is confusing. Sorry about that.

TimeoutInSec has been in place for a long time. What we noticed recently was that when there is a fixed value, the referenced value is ignored. Let me explain with an example. Suppose you have this

 

<TimeoutInSec>180</TimeoutInSec>

 

In that case the timeout will always be 180 seconds. Pretty clear. You can also reference a variable, like this:

 

<TimeoutInSec ref='mytimeout'/>

 

And in that case, the timeout will be whatever you had placed in the mytimeout variable. If it holds 600, then you will get a 600-second timeout.

The bug happens when you use both. like this:

 

<TimeoutInSec ref='mytimeout'>180</TimeoutInSec> <!-- DO NOT USE THIS -->

 

The usual behavior in Apigee with this sort of syntax is to use the referenced variable if it exists; if it does not, then fallback to the constant value. But TimeoutInSec does not behave that way. It was always using the fixed, constant value.

So we introduced TimeoutInSeconds, which behaves the desired way. We considered "fixing" TimeoutInSec so that it behaves the way every other config element in Apigee behaves, but realized that some proxies may be silently depending on the "broken" behavior. So we opted to introduce a new element, that exhibits the desired behavior.

I noticed that "TimeoutInSec" doesn't accept both reference and value in ApigeeX.

Yes, the reason is because we introduced new validation in Apigee X to avoid the situation where a person uses both, and expects it to work as "use the variable, or fallback to the constant if the variable doesn't exist." That doesn't work with TimeoutInSec. It works with TimeoutInSeconds. You should use TimeoutInSeconds.

When we migrate proxies from say OPDK to ApigeeX do we need to update "TimeoutInSec" to "TimeoutInSeconds" . Currently it gets deployed as is but what is the best practice going forward .

I advise that you convert to TimeoutInSeconds. TimeoutInSec will continue to "work", as it always has worked, even though it is deprecated. Even so, in my opinion, it has confusing behavior and at this point, it is better to avoid using it.

Also: don't use BOTH in the same policy!

 

Thanks @dchiesa1 for the detailed explanation ..

This is very helpful ..

Cheers..