Re: Revprop caching 'n stuff

Hi, Stefan,

Von: Stefan Fuhrmann [mailto:eqfox_at_web.de]
>On 08.03.2012 08:54, Markus Schaber wrote:
> On 08.03.2012 02:13, Bert Huijben wrote:
>>>>> And this shared mem approach will work with both threaded as well
>>>>> as multi-process servers?
>>>>> If so, this sounds like a good plan to me.
>>>> This still assumes that the repository is only used by a single
>>>> machine, while using NFS paths with multiple servers is not uncommon.
>>>> (I heard from a few of those setups on users_at_s.a.o)
>>> That is correct. Those users will not be able to use revprop caching. And this is one of the reasons why it will need to be activated explicitly.
>> Is it possible some mechanism to auto-detect access from a different machine and error out? Or do we risk silent corruption in cases of misconfiguration?

>That is a false dichotomy ;)

> No, IMHO, we don't have a way to detect whether servers on different machines write to the same data.
> Maybe we could write one (e.g. "tagging" an open repository with the server's IP address) but I'm not sure how reliable that would be.

One possible scheme would involve a unique machine token (random GUID or IP-Address or whatever) which is placed both in the shared memory area and a token file in the working copy. Something like the following steps could be done by each process on the first access of a repository:

- Initialize the shared memory area.
  - If you are the first process, generate the unique token and place it in that area.
  - If you are not the first process, read the token from the area.

- Try to get a shared, read-only lock on the token file in the working copy.
  - If the token file does not exist:
    - Create that file with exclusive, read-write access
    - Write your own token there.
    - Degrade your access to shared, read-only.
    - Everything is fine, proceed with normal work.

  - If your shared, read-only lock attempt failed:
    - It seems some other process is just initializing that file.
      - Try again several times, and time out with an error eventually.

  - If your shared, read-only lock attempt is successful:
    - Read the token and compare to your own.
      - If they are equal: Fine.
      - If they are not equal:
        - Try to get an exclusive, read-write lock on the file.
          - If that fails:
            - Error out, a process from a different machine has the repository.
          - If it succeeds:
            - The token file is stale, nobody else is accessing it.
            - Write your own token.
            - Degrade the lock to shared read-only.
            - Everything is fine now, proceed with normal work.

The key is that, after the initialization process above, the processes keep the shared read-only lock on the token file as long as they have any cached data on that repository. Collisions on the same machine are handled via the shared memory, and processes from other machines are locked out via the token file.

> Concerning the "corruption": The server will never cause wrong data to be stored but at worst will deliver outdated revprops. It is a transient issue. One way to cure it is to restart the server process.

Ah, if the symptoms are of that transient nature, I think it is probably not worth the effort.

> Another way is also possible but has not been implemented yet. There is a general request to make the caches listen to signals, e.g. to clear all caches if the server process receives SIG2.
> Call that at regular intervals and your machine will behave like a proxy does today: it only gives you a guarantee on the maximum out-of-dateness.

Best regards

Markus Schaber

-- 
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915