mljar / runmercury-website

RunMercury.com website with Mercury framework documentation
https://RunMercury.com
Apache License 2.0
6 stars 4 forks source link

Site stuck on "Waiting for worker.." #26

Closed khilshah closed 4 months ago

khilshah commented 6 months ago

Hello,

Big fan of your work, it's a very interesting interface for building an ever expanding set of applications :)

I have an application I have deployed on AWS EC2. The application runs just fine on my local machine (Apple M2, 8 GB) however on the EC2 it just remains on "Waiting for worker..". If you scroll over the worker icon, the pop-up says "Worker: Queued" with a session ID below. The EC2 instance is t3a.large (2vCPU, 8 GB).

Attached a screenshot.

Screenshot 2024-03-01 at 14 26 14

Is this to do with NGINX configuration? Any advice?

pplonski commented 6 months ago

Hi, there is some issue with our docker, please check here https://github.com/mljar/mercury/issues/420 We need to fix it.

khilshah commented 6 months ago

Thanks for coming back to me so quickly, Piotr. Just for further information, I did not use docker to deploy. Outline relevant steps below.

  1. Installed pyenv and virtualenv on the EC2 machine with all required libraries
  2. Git cloned repo
  3. Installed nginx
  4. Configured ~/../../etc/nginx/conf.d/reverse_proxy.conf to capture server IP and redirect to localhost

I have been trying different options on NGINX config file like increasing client_max_body_size but no joy :(

khilshah commented 6 months ago

I think I have resolved it, @pplonski.

For starters, I was serving my application using mercury run 0.0.0.0:8501 rather than simply mercury run, because of the way my EC2 security group was set up.

So I decided to modify the security group rather than mercury config. It still had the same message. I ran it manually with mercury run --verbose to see if I could spot the error and was getting a lot of Connection Failures with the requests library and furthermore, connections being made using port 8501, which should not have been the case once I had reverted to the OG method to run mercury apps.

The solution was to remove the virtual env and do a fresh install of the virtual environment - it seems to me mercury saves some configuration into the environment files - could you confirm?