Diameter Stack: Minimize Configuration Lookup

[brainslog]

For instance, on each message send, the following is performed:

long timeOut = container.getConfiguration().getLongValue(MessageTimeOut.ordinal(), (Long) MessageTimeOut.defValue());

Behaviors like this should be replaced by storing the configuration value in a local variable.

[chathsuom]

Hi, Just to get more understanding. Is the requirement is like below, define, protected long defaultMessageTimeOut = container.getConfiguration().getLongValue(MessageTimeOut.ordinal(), (Long) MessageTimeOut.defValue());

and then use in a method

Or,

protected static final Configuration configuration = Configuration.getInstance();

and get the values in methods as and when required?

Sorry if this is an obvious case, i am a new bee. Tks,

[brainslog]

The idea would be to reduce the actual configuration values lookup, this was an old issue so the whole context behind it and how I thought it could work isn't fresh in my mind. I recall this came up as result of some profiling where these calls had some impact.

There's a concern where these configuration values are modifiable at runtime, so "caching" them might not be always possible, or has to be done with some sort of measure for retrieving the actual value.

[chathsuom]

Hi, As per my understanding it requires a change in configuration loading methods/class's. I found a way for jboss configurations to auto load, but jdiameter uses an its own configuration loading class.(if i am correct) Can I have some more guideline for this to proceed?

[brainslog]

Hi @chathsuom. Yes, jDiameter uses it's own configuration loading mechanism, independent from jboss.

For this to work we will need to specify a configuration change listener (see https://github.com/RestComm/jdiameter/blob/6e911bf9fe3b7d3e7c9e88ef1b50f88265027c82/core/jdiameter/impl/src/main/java/org/jdiameter/server/impl/helpers/EmptyConfiguration.java#L244) for the specific values which we want to cache and that are possible to be changed, so we can update those cached values.

Not all configuration lookup needs to be cached, the particular one mentioned in this issue is one that occurs at every message send and (probably) has an impact in performance.

A good first step is to identify the places where it's possibly a good idea to cache the config values. After that implement the caching mechanism along with a listener to update the cached value.