mistercrunch commented on PR #33300: URL: https://github.com/apache/superset/pull/33300#issuecomment-2905783843
As I mentioned I spent some cycles hacking a fix for it here too https://github.com/apache/superset/pull/31315, I believe the solution works but need thorough tested. It's not clean but I believe it releases connections. It's not elegant but may work. Few related points that were not touched here: - if you use connection pools, I think this is less of a problem, or at least solutions can be designed differently. At Preset we have our own ways of dealing with this as it relates to our multitenancy-specific implementation. Regardless the solution/fix here ideally need to work with different connection pool configurations. There's a bucket of complexity around greenlet/gevent stuff here, and the fact that some database drivers are not thread-safe - the real solution is to route all analytical workloads through "async queries" / celery workers. Ideally flask only serves normal, short lived web requests, flask should never wait on some external database we don't control and pass workloads over to celery. This solves for cloggage issues in web servers, but doesn't solve for "releasing the metadata database connections during extended external workloads". Logic need to be redefined for that regardless of where the work takes place... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
