Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 08 15:53
    DanielStevenLewis commented #2910
  • Aug 02 23:41
    julienbfabre commented #1449
  • Jul 30 18:51
    rodzyn commented #2709
  • Jul 30 18:11
    rodzyn synchronize #2709
  • Jul 30 18:10
    rodzyn synchronize #2709
  • Jul 28 14:23
    MSP-Greg commented #2911
  • Jul 28 08:48
    dentarg commented #2911
  • Jul 28 06:15
    kirylpl edited #2911
  • Jul 28 06:14
    kirylpl opened #2911
  • Jul 27 16:46
    DanielStevenLewis edited #2910
  • Jul 27 16:39
    DanielStevenLewis edited #2910
  • Jul 27 16:38
    DanielStevenLewis opened #2910
  • Jul 23 01:47
    MSP-Greg commented #2909
  • Jul 23 01:37
    MSP-Greg synchronize #2909
  • Jul 23 01:37

    MSP-Greg on 5-6-5

    History.md - remove feature sec… (compare)

  • Jul 23 01:37
    nateberkopec commented #2909
  • Jul 23 01:36
    MSP-Greg commented #2909
  • Jul 23 01:35
    MSP-Greg commented #2909
  • Jul 23 01:33
    MSP-Greg commented #2909
  • Jul 23 01:31
    nateberkopec commented #2909
Andrew A Smith
@aasmith
I can also produce a small rack-based example of the problem if needed.
Andrew A Smith
@aasmith
(workers N in this case is >= 2).
Andrew A Smith
@aasmith
Digging in further, it seems the same child worker PID is getting selected, even it is unavailable/busy on a current request :/
*even if
Andrew A Smith
@aasmith
OK, so I think the issue is queue_requests being true, combined with only one thread per worker. As I understand, a worker in any state would be selected to handle the request. When there are multiple threads, this issue does not arise. Setting queue_requests to false fixes this.
Should there possibly be a warning raised if threads are 1:1 and queue_requests is true? It seems like this is a bad default in this situation.
raelik
@raelik
If I'm not mistaken, the purpose of queue_requests is to serve as a stand-in if a reverse proxy (such as nginx) is not being used.
Simon
@stoivo
Hello, Is there any migration step to update from 2.11.3 to 3.4.0?
Evan Phoenix
@evanphx
@stoivo Nope, just upgrade it.
Simon
@stoivo
Can't be easier, thanks @evanphx
Anton Antonov
@syndbg
Hi Guys, I'm having some Puma problems. The workers are timing out for no good reason
! Terminating timed out worker: 27501
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27504
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27508
Jun 28 13:46:54 myapp[26409]: [26409] ! Terminating timed out worker: 27513
this happens almost immediately after a restart of the Puma service
the machine resources barely scratch 5%
Anton Antonov
@syndbg
^ scratch the above. The cause was that the database wasn't accessible and Rails couldn't boot in less than the Puma worker timeout setting.
Ryan Condron
@rebelweb
puma is logging all requests as 127.0.0.1 instead of their IP Address I am using the X-Forwarded-For header in nginx, my nginx is custom compiled using chef omnibus if that makes a difference. Trying to debug so my request isn't 127.0.0.1, actual ip is (10.10.20.137). Any pointers?
Ryan Condron
@rebelweb
This message was deleted
Mike Pastore
@mwpastore
@rebelweb You have proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;?
Ryan Condron
@rebelweb
Yes and I am loggin $proxy_add_x_forwarded_for to my nginx log and it is returning a value
ip is 216.x.x.x so it isn't even an internal address.
Mike Pastore
@mwpastore
what version of puma?
Ryan Condron
@rebelweb
3.4.0
one thing unique to me is I am using chef omnibus so everything is compiled manually nginx, ruby, etc.
Mike Pastore
@mwpastore
Are you using ActionDispatch::RemoteIp?
I am just whitelisting ::1 and 127.0.0.1 nothing else
Mike Pastore
@mwpastore
I think something in your middleware is doing the wrong thing. Take a look at this issue on puma/puma: https://github.com/puma/puma/pull/873#issuecomment-178099895
Try adding this to your Puma config: set_remote_address header: "X-Forwarded-For”
Ryan Condron
@rebelweb
I removed all custom middleware
trying the puma configuration change
still seeing 127.0.0.1
Mike Pastore
@mwpastore
can you add like a logger.debug request.env[‘HTTP_X_FORWARDED_FOR’] somewhere in there? (edit: sorry, wrong var name, try that one)
I didn’t have to do anything special for Puma to parse X-Forwarded-For from Varnish and HAproxy, so this is all a bit mysterious
Ryan Condron
@rebelweb
its not returning anything. this is weird
i am wondering now if the rollbar gem could be causing this
raelik
@raelik
@rebelweb The only way the rollbar gem would be interfering (that I know of) is if you've added X-Forwarded-For to Rollbar.configuration.scrub_headers
But even that should only scrub the headers that get sent to Rollbar, and not actually remove them from the rack request.
Ryan Condron
@rebelweb
I have figured it out it was the way my directives were setup. I had my proxy_set_header directive before the try files directive that lead to location that did the proxy pass. Everything is working now. Thanks everyone for the help guidance.
raelik
@raelik
ohhh, yeah, that'll do it.
ezchen92
@ezchen92
What is an SSL socket as listed in the readme? is that better than a normal unix socket?
ezchen92
@ezchen92
Thanks @raelik
ezchen92
@ezchen92
Does anyone have a minimal nginx/puma conf? I am running into issues getting it to work as a reverse proxy - could it be because I am running as the root user?(permissions)
Mehmet Aydogdu
@mehmetaydogduu
Hi
My rails app is too slow
Using puma
raelik
@raelik
@likelazyeyes I would start looking for other culprits as to why your app is slow.
Dave Allie
@daveallie
Hey guys, I was just wondering if anyone has any idea as to when the next puma version is coming? Would really like to see the fix for #1002 released :D
Mike Pastore
@mwpastore
@daveallie You can always use master! Or even just the 46416cb49ed2f16614f019cee969bb8f5d0a6146 commit, which includes this fix