mmap: changing environment

[markus2330]

As follow-up to #1433, I assume that the mmap plugin is also affected. E.g. suppose $HOME changes and the new config file is also older then the mmap cache file. Then the cache file would be taken although it is actually out-of-date.

I do not expect that we can easily fix that but it would be good if you can describe the requirements we have that such problems do not occur.

[mpranj]

You‘re right, currently the cache only checks the ENV in the plugins kdbOpen. It can easily be checked dynamically, but this invokes the resolver and I suspect it has quite some performance impact.

Edit: On a side note: the config is checked for the exact timestamp (nanosec granularity), but the problem still exists and is true for the default resolver too.

[markus2330]

A workaround for exactly this bug would be that we also store the resolved file names within the mmap cache. But in general it would not help, we would somehow need to capture all variables that might have influence (or avoid the use of any environment variable inside of our plugins, which might be the more elegant solution anyway).

[mpranj]

I did not think about this scenario, but actually we store the resolved filename within the mmap cache. If the path changes it would produce a cache miss.

Still, if $HOME changes while a KDB handle is open, it would not relocate the cache to the new home.

[markus2330]

I did not think about this scenario, but actually we store the resolved filename within the mmap cache. If the path changes it would produce a cache miss.

Perfect! This is the most important case anyway. Afaik we currently do not have environment variables except for the resolvers. (Not all of the environment variables actually have an impact on the file name, though. E.g. curlresolver uses HTTP_PROXY.)

Still, if $HOME changes while a KDB handle is open, it would not relocate the cache to the new home.

Ok but this is an old bug (#1433). So I will close this bug as mmap seems to not make the situation worse.