Comments (9)
This is quite weird. My best guess is you may have the middleware loaded twice (though the behavior you're seeing still doesn't make sense to me, even if that is true), or there's something about the use of .use
rather than .insert_before
that is causing weird behavior. Please see https://github.com/sharpstone/rack-timeout#rails-apps-manually and make sure it's being loaded appropriately.
From what I remember, you can check which middleware are loaded with rake middleware
, but you might need to run rake -T
to check what the actual name is.
from rack-timeout.
Thanks for the reply.
You are correct that we had the middleware included twice. This is an old code-base so perhaps our implementation pre-dates when you started auto-adding the middleware to Rails applications? Will try to sort this out and confirm if it fixes the issue.
Meanwhile I'm still concerned about the error / log messages. Seems odd that a time close to 25s would be stated when in fact only 15s have passed. Perhaps they could be improved?
from rack-timeout.
I am also confused by the logging. Can you confirm the version number you are/were running?
from rack-timeout.
Ah, I suspect the reason why is because the info that is ultimately displayed in the logs is "shared" between all instances of Rack::Timeout (obviously, only 1 instance is intended), since it all goes into the same key in the Rack request environment hash.
https://github.com/sharpstone/rack-timeout/blob/master/lib/rack/timeout/logging-observer.rb#L43
from rack-timeout.
Sorry for the slow feedback here.
Can you confirm the version number you are/were running?
We were and are running the latest version of rack-timeout
.
Can also confirm that removing the duplicate initialization fixed the issue.
Merry Christmas :)
from rack-timeout.
I think the only way to solve this problem directly is to check the middleware stack in the Railtie to see if it's already loaded:
https://github.com/sharpstone/rack-timeout/blob/master/lib/rack/timeout/rails.rb#L7
However, it could still happen where the middleware is loaded again after the Railtie fires, which I don't think is preventable or detectable from inside the middleware itself.
Rack Timeout could set and/or check something in the request env
to see if it's already touched the request, which would indicate the middleware was loaded multiple times, and provide an opportunity to either present a warning and/or not process the request through the middleware a second time.
from rack-timeout.
@dbackeus - I had the same issue, and solved it by "swapping" the middlewhere inserted by the gem via the Railtie code that @wuputah referenced with a version that would use different initial values.
In short, instead of doing
config.middleware.use Rack::Timeout, service_timeout: 25, wait_timeout: 25
you should be able to use
config.middleware.swap Rack::Timeout, Rack::Timeout, service_timeout: 25, wait_timeout: 25
from rack-timeout.
Some ideas/thoughts
- Use an API to either inspect or delete the current middleware: I see from Rails docs that
config.middleware.delete
is an API for removing an existing middleware. If this is idempotent and does not raise an error when you call it with a class that is not on the middleware stack then we could use it in the railtie. - Add a warning from Rails: In the
config.middleware.*
methods we could add a check to see if that class (or an instance of that class) has already been added. This would at least alert people to the problem earlier. The downside is that some people might be intentionally including the same class as different instances to achieve some goal via some pattern. The warning behavior would need to be disabled via a flag or env var. We could also allow people to error/raise when this happens instead of a warning. - Something else?
I'm not planning on working on this. If someone else wants to take a stab, open a PR here, or open one against Rails and then add a link back on this thread so people can chime in. If you send a PR for this to rack-timeout, I would want an codetriage.com/example_app that demonstrates the problem and can be solved by using your branch so that I can verify independently that it does what it says it does. For regressions, having the behavior tested would be better. But such a test is non-trivial (I think) and might slow the suite down (though I'm happy to be proven wrong).
from rack-timeout.
I fix the load twice problem by putting a require: false in gemfile and them requiring it on initializer with correct service_timeout.
# Gemfile
gem "rack-timeout", '~> 0.6.3', require: false
# config/initializers/rack_timeout.rb
require 'rack/timeout/base'
Rails.application.config.middleware.use Rack::Timeout, service_timeout: 30
from rack-timeout.
Related Issues (20)
- Improve rack-timeout docs to map raised exceptions to desired status code HOT 11
- Request still running/completing after timeout? HOT 5
- Proposal to deprecate `term_on_timeout: false` HOT 7
- Broken ActiveRecord connections after a timeout HOT 4
- Unicorn graceful shutdown seems incompatible with `TERM` usage HOT 4
- Push 0.6.1 to Rubygems HOT 4
- Prefer sending SIGKILL over SIGTERM to a process HOT 2
- is "active" observer turned off for non-debug? HOT 5
- PR needed/wanted: Incompatibility with Ruby on Windows HOT 1
- [Feature Request] Optionally notify observers only HOT 4
- Request: timeout exempt requests HOT 1
- problem with unicorn graceful restart HOT 2
- possibility to timeout only for GET requests ? HOT 1
- Puma and rack-timeout results in a null pointer after running for some time HOT 1
- Disable logging HOT 4
- ArgumentError: wrong number of arguments (given 2, expected 1) with Ruby 3.2.2 and Rails 6.1.4 HOT 2
- Question: RACK_TIMEOUT_TERM_ON_TIMEOUT on one cluster HOT 1
- RACK_TIMEOUT_TERM_ON_TIMEOUT=0 still does not allow TruffleRuby to run HOT 2
- Dynamic service_timeout HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rack-timeout.