Wicked PDF takes around 2 minutes when in production - ruby-on-rails

I have an app and an API. The app runs in production on a server with Debian 7, which gives me problems with the gem. In the other hand, the API runs on another sever with Debian 9, in which there´s no problem with wicked_pdf. So, when I want to download a PDf file, I make a call to the API where I send specific parameters to render some images and text.
When I am in local development, with the app in port 3000 and the API in port 3001, there´s no problem. It works and the logs show 'Completed 200 OK in X ms' where X is never more than 7 or 8.
The problem comes when I deploy the API in it´s corresponding server. There´s no error like missing libraries, or syntax errors or no method errors. What happens is that the API takes around 2 minutes to render the file and show 'Completed 200 OK in 121000ms'. Obviously, by the time the task is completed, the app already timed out like 1 minute and 40 seconds earlier. I already changed wkhtmltopdf-binary version to 0.9.9 but the results are the same.

Related

CheckSum Verification Server Selection

I have a self generated certificate imported into the keystore, a cryptographic hash algorithm written (SHA-256), and now need to run a CheckSum on it. When I did this previously in the course I got a list off errors in the spring release I could not figure out. This time I have not selected a server to run through Apache tomcat. The newest version I can load from Eclipse is tomcat v8.0 I cannot get the tomcat v9.0 to populate the finish button when I select it, but can click on NEXT. There is a little lightbulb next to localhost in the server host name.
This is my first time doing this and don't know how to shift through a lot of the information out there. Just looking for some images to follow step by step to see if tomcat v8.0 would work, or if someone can help load tomcat v9.0 in my IDE that would be nice as well. Tried following a few YouTube videos but there seems to be something missing versus how they go though it compared to how I do, mostly because the v9.0 wont install or just finish the process.

webpack-dev-server extremely slow to load on new machine

I've been working on a project from my laptop for the past few months. When webpack compiles my code, reloading the page takes around 1 second.
I've now moved to my desktop, and loading the page takes about 11 seconds in Chrome. I'm using the same version of node, webpack-dev-server and webpack on both machines (windows 10).
Chrome:
Edge:
Blazing fast in Chrome on my other machine:
I've also disabled all the extensions to no avail. I can't find a pattern, but this is not consistent on edge, it would load for the same 11 seconds there as well, but not always. Any ideas how i could address this?
This wasn't related to webpack at all, it just looked weird. The issue seems to have something to do with steam (or steamVR), and there was a bug report for chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=1202090#c38
Opening two tabs, and reloading them side by side would not suffer from this 11 second delay. Updating steam seems to have resolved the issue.

Django+uwsgi: uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 248]

I have this weird issue in my django application. I am using the admin interface. When I try to load the change page it doesn't render completely and when i see in logs it says:
**uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 248]
IOError: write error**
The page has been working fine before and suddenly this started happening. And also the behavior is inconsistent. If I reload the page multiple times, few times it renders correctly. This issue is happening in production environment and I am not able to replicate it on my local. The production server is using uwsgi 1.9.10 with nginx and django 1.5. Also I am writing custom HTML on page and there is an inline table also on the same page.
Please let me know if anyone knows why it is happening...
that error means the client (browser) disconnected before getting the full response. Check your webserver logs, maybe you hit a timeout

JBoss not responding to valid URLs

I encountered strange behavior of an JBoss AS 7 on linux server. When I deploy war with my application, the server doesn't respond for valid HTTP requests for this app. When I try to GET a valid URL, I can see in logs, that backend functions (e.g. DAO methods) are called, debug logs shows that subsequent tags in my JSF are rendered, I even can see a message Rendering View index.xml, but the response never reaches the client.
When I use a non-existent URL (e.g. index.asd) response is 404 and when I use a wrong page name (e.g. inswxasd.xhtml) the response is 500. Thus it fails only with valid requests.
I tried to connect both remotely (using firefox) and locally (with wget) and I reproduced the problem. The strange thing is that I deploy the war that I already used and then it worked.
EDIT 1:
I've just noticed that when I send a request to, the server process takes 200% of CPU. Additionally it happens for only one application with stack: Hibernate, Spring, JSF 2.0, Primefaces.
EDIT 2:
Here is pastie with jstack output (jstack -l -F <PID>). All threads are blocked.
Additionally I noticed (using top and dumping stack of the JBoss process) that the problem is most probably caused by a thread called http--0.0.0.0-8080-1. Any ideas?
Thanks for help. I reverted the database to previous state, and it started to work. Apparently there was a problem in the data that caused this infinite loop. Now we need to find it, but as it is reproducible, I'll manage.

symfony actions are super slow on localhost

I've setup MAMP on OSX 10.6 and the exact same symfony code takes over 6 seconds to run on localhost and 200ms on my server. My web debug bar says the time hit comes from processing the action. I've tried it the production mode on localhost and the speed boost was minor, time went to 3 seconds instead of 6. Still ridiculously slow compared to my server.
The strange thing is that non symfony php code runs correctly and fast.
You can try Xdebug profiler to find out precisely which part of symfony is so slow.

Resources