This article explains how timeouts are handled in a logic and in libraries which call each other and how they are handled in general.

...

:

• The timeout of the library element applies to the time spent since the beginning of the current logic element’s execution and not the time spent in each call to the library element

  • You can see an example below

  The timeouts of elements executed element timeout is always honored.

• Library elements timeouts are ignored. What matters is the time the logic element is executed, including library calls.

• Elements timeouts are always capped by the maximum timeout configured at the cluster level.

  • This setting defaults to 900s (15mn15 min).

  • It can be increased by Pricefx Support via the setting formulaEngine.script.maxTimeoutInSec

  Before 10

  • .

  2

  • The timeout of elements is set when the logic is pushed/saved to the partition: if you increased the maximum timeout in your cluster, do not forget to resave your logic!

• Special cases:

  • Since 10.0

  • : PA Data Loads, PA Distributed Calculation, DMModel Calculations and Model Calculations completely ignore the timeouts in their logics but not in their libraries.

  • Since 10.2

  • The timeout of elements reflect the current setting of the cluster, including max timeout, even if the logic has not been resaved

  • The timeout of the library elements is the maximum between the current logic element’s timeout and the library element’s timeout

  • In particular : PA Data Loads, PA Distributed Calculation, DMModel Calculations and Model Calculations completely ignore the timeouts in their logics and in the libraries they use

Example Using a Library

In this example, running libs.MyLib.ElementA.getAverageMargin() for a large set of SKUs will time out after 2 seconds. The reason is that even though each time the getProductMargin method is called, it takes less than 2 seconds each time, the cumulative total time spent inside that method (because of its reference in the loop) will be more than 2 seconds.

MyLib.ElementA (timeout 300 seconds):

Number getAverageMargin(List<String> skus){
  List<Number> margins = []
  for (sku in skus) {
    margins.add(libs.MyLib.ElementB.getProductMargin(sku))
  }
  return margins.sum() / margins.size()
}

MyLib.ElementB (timeout 2 seconds):

Number getProductMargin(String sku) {
  def costPrice = api.find("PX30")... // get cost from some data source
  def sellPrice = api.find("PLI")... // get sellprice from another data source
  return sellPrice - costPrice
}

Explanation and Technical Background

Timeouts are essentially safety catches against a bad logic (such as accidental infinite loops). JVM does not have a setting like "run this thread, but only for x seconds". So we inject (at compile time) some code that throws an exception if the system time has elapsed the start time + timeout. Now the different logic elements are essentially Groovy script classes. There is no easy sharing of a script-global "start time" variable in all thinkable cases. So we resort to using a start time variable per element (normal or lib element) which is initialized at the class instantiation. It is a private script class member variable which is set to the system time in the constructor of the script class. The engine "resets" that start time for lib elements by re-instantiating the lib elements before executing every normal logic element. Normal elements are only instantiated once (hence the topic of "timer starts running when the element is executed first time" when you call previous elements further down).

...

• • .

  • Before 10.2: Elements timeout is set when the logic is pushed/saved to the partition. So if you increase the maximum timeout in your cluster, you need to resave your logic.

  • If an element just calls a library and the library has a higher timeout than the element, then the library element timeout is honored.