Is it possible to run elFinder on multiple php-fpm replicas?

[grossmannmartin]

elFinder heavily uses methods for manipulation with the local files.
When the application is running on several php-fpm workers, it's possible each command is handled by a different worker.

Is it then safe to presume, the application will behave properly?

From the reported issue (shopsys/shopsys#2172) it looks like the presence of the $abortCheckFile is required across commands.

As it's mentioned in shopsys/shopsys#2172

 The elfinder library uses some kind of file locks to detect that an abort command has completed. This lock file is created by storing the path in the $abortCheckFile variable and using the php function touch() to create a file according to this path.

The file is created either in the folder defined in the connectionFlagsPath settings, or in the folder defined in the commonTempPath settings or in the sys_get_temp_dir folder (see https://github.com/Studio-42/elFinder/blob/master/php/elFinder.class.php#L2515).

The problem is that the elfinder works with the server through ajax, so it may happen that one request creates a lock, the other request has to check it, but the check does not take place because the other request takes place on another pod (see https://github.com/Studio-42/elFinder/blob/master/php/elFinder.class.php#L5031).

If elFinder is not yet ready for the stateless clouds, do you plan to improve?

And the last question. As a workaround, it's possible to safely ignore thrown elFinderAbortException and return an empty response instead? (I'm using helios-ag/fm-elfinder-bundle, where I can do this, see shopsys/shopsys#2259)

Thank you for your answers and your time.

[grossmannmartin]

Hi, I don't want to bother you, but did you find time to think about this issue?

[nao-pon]

Yes, certainly elFinder is designed without considering accessing the same file system on multiple instances.

@grossmannmartin elFinder is connected to the server via classically HTTP communication and performs a file check to detect that the server has interrupted processing.

If you can't detect a server-side interruption, Ajax may remain open and remain as a zombie.

I don't have any ideas on how to get around it, but if you have any suggestions for improvement, please send a PR to the project.

[grossmannmartin]

thanks