Commit Graph

9 Commits

Author SHA1 Message Date
FinnStutzenstein
23842fd496
Synchronize autoupdate code in the client
If autoupdates are too fast, the first one may not be fully executed. Especially when the maxChangeId is not yet updated, the second Autoupdate will trigger a refresh, because for the client it "lay in the future". This can be prevented by synchronizing the autoupdate-handling code with a mutex.
2020-05-22 15:23:53 +02:00
FinnStutzenstein
bb2f958eb5 Redis: Wait for replication on writes
Since channels_redis does not support dedicated read-redis instances, the
autoupdate message may be received before the data was replicated. All workers
read the autoupdate message from the write host, so there is a race between
getting this message and a finished replication. For large payloads, the
replication is slower in the most cases (even more in a distributed setup, where
the master and replica are on different nodes). The easy way is to wait for
replication. But there is one difficulty: The number of replicas has to be
known. There is a new settings-variable "AMOUNT_REPLICAS" which defaults to 1.
It needs to be set correctly! If it is too high, every autoupdate will be
delayed by 1 seconds because of a timeout witing for non-existent replicas. If
it is too low, some autoupdates may be wrong (and not detectable by the client!)
becuase of reading from non-synchronised relicas.

The other possibility is to fork channel_redis and add the feature of a
read-only redis. This ould help, because on a single redis instance all commands
are ordered: First, the data is synced, then the autoupdate message. Attention:
This means, if redis-replicas are scaled up, one must make sure to read from the
same instance. I think this is not possible in the way how dockers overlay
networks work. The only way would be to open one connection and reuse the
connection from channels_redis in OpenSlides. This would mean a heavy
integration of channels_redis (meaning including the source code in our repo).

For the first fix, this one is easy and should work.
2020-04-01 13:09:48 +02:00
FinnStutzenstein
cc4ca61964 Adding a second optional redis for read only accesses 2019-12-03 12:30:31 +01:00
Emanuel Schütze
e16ca335de Updated requirements
- Added websockets to production.txt
- Import channels_redis in redis.py only for big mode (if use_redis=true)
2019-09-13 10:29:19 +02:00
FinnStutzenstein
0319deba23 no semaphore 2019-09-10 15:00:55 +02:00
FinnStutzenstein
2aa0275dca Logging prefix and handling redis connection errors 2019-09-02 08:09:28 +02:00
Oskar Hahn
77a1975369 Use redis connection pool 2019-03-27 22:51:33 +01:00
Oskar Hahn
eddbd86d3a Run black 2019-01-08 21:51:52 +01:00
Oskar Hahn
cd34d30866 Remove utils.collections.Collection class and other cleanups
* Activate restricted_data_cache on inmemory cache
* Use ElementCache in rest-api get requests
* Get requests on the restapi return 404 when the user has no permission
* Added async function for has_perm and in_some_groups
* changed Cachable.get_restricted_data to be an ansync function
* rewrote required_user_system
* changed default implementation of access_permission.check_permission to
  check a given permission or check if anonymous is enabled
2018-11-03 20:48:19 +01:00