Feature #33445
closed
Handle unavailable storages
0%
Description
We need an error handling for "Storage is not reachable"
Updated by Andreas Wolf about 12 years ago
This is especially important for remote storages, as these might easily become unavailable (network problems, server downtime etc).
The foremost problem is that we have to store this state internally, otherwise we always have to wait for a network timeout on each access (which might be many even within one request). We should mark a storage as unavailable for a certain amount of time in case of a timeout - but this should be handled on a per-driver level.
Updated by Andreas Wolf about 12 years ago
- Tracker changed from Task to Feature
- Subject changed from Filelist: Error handling for Storage is not reachable to Handle not available
- Status changed from New to Accepted
The filelist (and all other parts of the UI) should also react accordingly.
I agreed with Benni to have this in two flavors: If the configuration of a storage is invalid (e.g. it points to a non-existing folder), we will permanently disable the storage and an admin has to reactivate it (could be by saving the TCA record).
If a storage is temporarily unavailable (e.g. because of network errors), we should disable it for some minutes (on a per-user base in the backend) and then automatically check again. For the frontend we want to have as little impact as possible - which means we should e.g. not throw exceptions for inaccessible storages there.
Updated by Andreas Wolf about 12 years ago
- Subject changed from Handle not available to Handle unavailable storages
Updated by
Updated by Steffen Ritter over 11 years ago
- Target version changed from 6.0 beta1 to 6.0 beta 2
Updated by Alexander Opitz over 10 years ago
- Target version deleted (
6.0 beta 2)
Updated by Alexander Opitz over 10 years ago
- Project changed from 1401 to TYPO3 Core
Updated by Alexander Opitz over 10 years ago
- Category set to File Abstraction Layer (FAL)
- TYPO3 Version set to 6.0
Updated by Ingo Schmitt over 9 years ago
- Status changed from Accepted to Needs Feedback
Hey Tom,
does this issue still exist in 6.2.x
Updated by
Updated by Alexander Opitz almost 9 years ago
- Status changed from Needs Feedback to New
Updated by Sascha Egerer over 7 years ago
Andreas Wolf wrote:
The filelist (and all other parts of the UI) should also react accordingly.
I agreed with Benni to have this in two flavors: If the configuration of a storage is invalid (e.g. it points to a non-existing folder), we will permanently disable the storage and an admin has to reactivate it (could be by saving the TCA record).
If a storage is temporarily unavailable (e.g. because of network errors), we should disable it for some minutes (on a per-user base in the backend) and then automatically check again. For the frontend we want to have as little impact as possible - which means we should e.g. not throw exceptions for inaccessible storages there.
IMO if a storage points to a non existing folder that does not mean that the storage is invalid. If the local storage is a mounted folder and that becomes unavailable for a short time that must not mean that the storage is invalid. Thats the same case as for remote storages.
Maybe we should add an option to the storage to automatically reactivate it if its back?
Updated by Susanne Moog about 5 years ago
- Status changed from New to Needs Feedback
Can someone involved in the topic write a bit more about what needs to be done here and which cases need to be considered? As far as I can see, we currently have the "is Online" check for storages, which is automatically checked and set to false if a storage is offline. What else needs to be done?
Updated by Susanne Moog about 4 years ago
- Status changed from Needs Feedback to Closed
No feedback and clarification for a long time, closing the issue now.