django-unicorn
django-unicorn copied to clipboard
adamghill
Error 500 in production
Every thing runs fine in development but when I try to run on the production server I get this message. I will say that some calls work about 20% of the time. Not sure what else to do or what info to give as it works well in development.
For production I use a docker container with nginx as a proxy.
Can unicorn assets be served by whitenoise? Would I need to have nginx handle serving this url?
It's curious that things work 20% of the time. You are showing the JS console error, but can show the Python error log on the server (or do you use something like Sentry, Datadog, etc.)? That will give you the Python traceback and might give us some more clues.
Hmm, I've never seen that happen only in production before. Is employee_services.components.employee_disabilities.EmployeeDisabilitiesView the correct class? Do you have different settings for production than local dev? Maybe UNICORN app settings are different per environment?
Yes it's the correct class. I have not looked into the unicorn app settings yet, I like to use default settings unless necessary.
On Sat, May 21, 2022, 15:01 Adam Hill @.***> wrote:
Hmm, I've never seen that happen only in production before. Is employee_services.components.employee_disabilities.EmployeeDisabilitiesView the correct class? Do you have different settings for production than local dev? Maybe UNICORN app settings https://www.django-unicorn.com/docs/settings/#apps are different per environment?
— Reply to this email directly, view it on GitHub https://github.com/adamghill/django-unicorn/issues/408#issuecomment-1133752643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFFXNU5XQ5QWPPIWAZW5HLVLEXHPANCNFSM5WIHEVSA . You are receiving this because you authored the thread.Message ID: @.***>
I would like to add that I do have django-htmx in my project, as i was planning to convert components to unicorn.
I removed htmx and tried again. this was the resulting error message
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/django/core/handlers/exception.py", line 47, in inner
response = get_response(request)
File "/usr/local/lib/python3.10/site-packages/django/core/handlers/base.py", line 181, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "
Yeah, I wouldn't expect htmx to interfere with Unicorn, but I'm glad you tried just in case. That error is raised at https://github.com/adamghill/django-unicorn/blob/main/django_unicorn/components/unicorn_view.py#L867 which should only happen if the EmployeeDisabilitiesView class could not be instantiated. I'm not sure how else to debug this problem that only happens 20% of time and only in production, but I'd love to help out however I can.
https is not technically a requirement, but probably a good idea so that the JSON payloads are protected.
I understand that. I recently tried again as I upgraded to Django 4. The application in now not public and only used on the LAN. The first action to the unicorn component works, but any other action gives the same browser error as before. I will investigate more on my down time and give the feedback.
On a side note I really like the project and wondered if there was anyway I can help (non financial for now)
I'm sorry it's still not working. :/ I'll try to dig into this again when I have time.
Since this is just a side project of mine, any help is appreciated! PRs for features/bug fixes, documentation updates, adding better test coverage, etc. :)
Does this having anything to do with Gunicorn at all?
When I start my application with something like gunicorn --workers=4 app.wsgi a lot of requests fail, but some go through.
If I start gunicorn with only 1 worker, then everything works perfectly.
Also, if I start it with 'gunicorn --workers=4 --worker-class=gevent app.wsgi' and use gevent, then again, everything works 100% of the time.
@adamghill Is this expected behaviour?
Hmm, the number of workers shouldn't matter. My gunicorn.conf for django-unicorn.com.
One thing I didn't ask above: what are your cache settings in production? Unicorn uses cache to store component information and I'm wondering if you are using local memory the cache would fail for some of the workers, but would work for one of them perhaps? I always use redis in production, so maybe that's why I never saw this before?
I was using in memory cache, 3 workers.
On Wed, Nov 23, 2022 at 1:01 PM Adam Hill @.***> wrote:
Hmm, the number of workers shouldn't matter. My gunicorn.conf https://github.com/adamghill/django-unicorn.com/blob/main/gunicorn.conf for django-unicorn.com.
One thing I didn't ask above: what are you cache settings in production? Unicorn uses cache to store component information and I'm wondering if you are using local memory the cache would fail for some of the workers, but would work for one of them perhaps? I always use redis in production, so maybe I never saw this before?
— Reply to this email directly, view it on GitHub https://github.com/adamghill/django-unicorn/issues/408#issuecomment-1325390745, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFFXNWBA5DHQXNVFJEJH7DWJZEVJANCNFSM5WIHEVSA . You are receiving this because you authored the thread.Message ID: @.***>
If you are able to try it with a filesystem cache (if you only have one server running) or memcache/redis if you have more than one server that would be helpful. I can also come up with some fallback mechanisms if caching is not available.
Ok, I'll check it out. I really think this can be the real issue
On Wed, 23 Nov 2022, 17:42 Adam Hill, @.***> wrote:
If you are able to try it with a filesystem cache (if you only have one server running) or memcache/redis if you have more than one server that would be helpful. I can also come up with some fallback mechanisms if caching is not available.
— Reply to this email directly, view it on GitHub https://github.com/adamghill/django-unicorn/issues/408#issuecomment-1325693597, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFFXNTP65RMDI5Q5WYG6Z3WJ2FU3ANCNFSM5WIHEVSA . You are receiving this because you authored the thread.Message ID: @.***>
FWIW I had the same issue, and changing from a memory cache to a Memcached instance has seemed to fix it.
Thanks @adamghill for the pointer with this!
