File upload can fail with gunicorn sync workers (Windows File Explorer)
#332
Comments
|
Without having investigated in depth: |
|
Thank you for picking up on this! With With lock_storage:
class: wsgidav.lock_man.lock_storage.LockStorageShelve
kwargs:
storage_path: /var/lib/wsgidav/locks.shelve`Dockerfile# syntax=docker.io/docker/dockerfile:1
FROM docker.io/python:3-alpine
RUN pip install --no-cache-dir wsgidav lxml gunicorn
# Set workers: 1 to avoid the issue
COPY <<'EOF' /etc/wsgidav/wsgidav.yaml
host: 0.0.0.0
port: 8080
verbose: 6
server: gunicorn
server_args:
workers: 5
threads: 1
timeout: 1200
provider_mapping:
'/seafdav': '/srv/wsgidav'
#lock_storage: null
#lock_storage: true
lock_storage:
class: wsgidav.lock_man.lock_storage.LockStorageShelve
kwargs:
storage_path: /var/lib/wsgidav/locks.shelve
EOF
VOLUME ["/srv/wsgidav", "/var/lib/wsgidav"]
EXPOSE 8080
STOPSIGNAL SIGINT
CMD ["wsgidav", "--config=/etc/wsgidav/wsgidav.yaml", "--auth=anonymous"] |
|
The shelve module is not safe for concurrent access either. If concurrency is the root problem, the redis lock storage may be a better choice (See also #186) |
|
Oh, good catch! I gave docker-compose.yamlname: seafdav
configs:
wsgidav.yaml:
content: |
host: 0.0.0.0
port: 8080
verbose: 6
server: gunicorn
server_args:
workers: 5
threads: 1
timeout: 1200
provider_mapping:
'/seafdav': '/srv/wsgidav'
lock_storage:
class: wsgidav.lock_man.lock_storage_redis.LockStorageRedis
kwargs:
host: redis
port: 6379
services:
wsgidav:
depends_on:
- redis
build:
dockerfile_inline: |
FROM docker.io/python:3-alpine
RUN pip install --no-cache-dir wsgidav lxml gunicorn redis
VOLUME ["/srv/wsgidav", "/var/lib/wsgidav"]
EXPOSE 8080
STOPSIGNAL SIGINT
CMD ["wsgidav", "--config=/etc/wsgidav/wsgidav.yaml", "--auth=anonymous"]
configs:
- source: wsgidav.yaml
target: /etc/wsgidav/wsgidav.yaml
ports:
- "8080:8080"
volumes:
- ./wsgidav_data:/srv/wsgidav
networks:
- seafdav
redis:
image: docker.io/redis:7-alpine
networks:
- seafdav
networks:
seafdav:
name: seafdavIf concurrency is the actual cause, there is not much we can do here besides documentation, I guess. We can either
Maybe |
Describe the bug
When
wsgidavis run withgunicornand more than 1syncworker, the file upload can fail and a 0 byte file is produced.To Reproduce
Steps to reproduce the behavior:
wsgidavwithgunicronworkers.gunicornuses thesyncworker_class:[INFO] Using worker: synchttp://127.0.0.1:8080/seafdavExpected behavior
File gets uploaded
Screenshots, Log-Files, Stacktrace
Debug Log
Screenshot
Environment:
Which WSGI server was used (cheroot, ext-wsgiutils, gevent, gunicorn, paste, uvicorn, wsgiref, ...)?
gunicornwith 5syncworkersWhich WebDAV client was used (MS File Explorer, MS Office, macOS Finder, WinSCP, Windows, file mapping, ...)?
Additional context
#324 #2809
The
syncworker is the default forgunicorn, as far as I understand. The issue seems not occur whengthreadis used instead e.g., by settingworkers: 1threads: 5. (Then notest_if_header_dict() -> FAILEDmessages are not shown, and the file upload works.)The text was updated successfully, but these errors were encountered: