macournoyer / thin Goto Github PK
View Code? Open in Web Editor NEWA very fast & simple Ruby web server
Home Page: https://rubygems.org/gems/thin
A very fast & simple Ruby web server
Home Page: https://rubygems.org/gems/thin
If Thin receives a request with request line:
GET /level1/level2;user=alice/level3/doc.txt HTTP/1.1
then Thin cuts the URI path and leaves:
env{"PATH_INFO"} => "/level1/level2"
Why? I've looked for such behavior in RFC 3986 and RFC 2616 but I don't find a reason to remove all the path content after ";".
Is there any reason I miss? I've tryed other http servers running with Rack and the don't cut it.
Regards.
When running thin 1.2.11, rails 2.3.11 under ruby 1.9.2, if I visit this URL:
http://localhost:3000/acupuncture+cañon-city+co
I get this error:
The version of eventmachine-eventmachine is newer than eventmachine on rubyforge sometimes,but after I installed eventmachine-eventmachine,thin can't use it.Is it possible that thin dependents on eventmachine,and macournoyer-thin dependents on eventmachine-eventmachine?
Thin does such a good job managing connections and processes (daemonization etc) that I think people would like to use it as an abstraction upon EM for non http servers. These are going to get more common (think WebSockets). At the moment I'm hacking non-http support in (see gist) - but I wonder if this will ever be in core?
https://github.com/macournoyer/thin/blob/master/lib/thin.rb#L45
The rescue block there hides error messages on badly compiled library code. Took a while to track this one down as my thins were imploding, but I couldn't figure out why it couldn't find the Thin::HttpParser.
When I tried to load it in my environment, I saw that it had an invalid ELF header (which is my bad), but the rescue totally gulped the message.
In Thin::Headers
, only certain headers are permitted to be written more than once. According to RFC 1945 section 7.1, an HTTP response may contain arbitrary entity extension headers. According to section 4.2., message headers may be repeated. Therefore, it seems that thin is modifying specification-compliant responses without cause. A small example; note that the X-Foo
header should have been repeated according to the rack spec.
For reference, mongrel behaves the same way as thin. Unicorn behaves according to the spec.
In thin-1.2.7/lib/rack/adapter/rails.rb
def rack_based?
rails_version = ::Rails::VERSION
rails_version::MAJOR >= 2 && rails_version::MINOR >= 2 && rails_version::TINY >= 3
end
This test returns false for Rails::VERSION::MAJOR >= 3 (i.e., Rails 3)
Thus, it resorts to loading your rails app as a CGI app, and then runs into issues with ActionController::CgiRequest when loading the app programmatically:
run Rack::Adapter::Rails.new(:root => '/Users/rrobinson/Development/charleston/server')
I reported this possible bug but it was closed:
http://github.com/macournoyer/thin/issues/closed#issue/6
Please before closing it read the thread I open in Rack maillist:
http://groups.google.com/group/rack-devel/browse_thread/thread/f48d0f995357a3de
If you close this report agains please tell me where exactly Rack SPECS state that PATH_INFO must be cut after a semicolon.
Regards.
It would be useful if Thin had a configuration option that allowed for Exceptions raised in a web app to propage beyond Thin. In particular, in testing frameworks such as Cucumber(+Capybara), Exceptions raised in web apps are silently logged and ignored; the request loads as blank page, and it makes it difficult to figure out the source of the error.
I opened an issue for Capybara: teamcapybara/capybara#329 but decided it would make more sense if we didn't have to monkey patch Thin to achieve this.
What I'm suggesting is that https://github.com/macournoyer/thin/blob/master/lib/thin/connection.rb#L130 could have something like this:
raise $! if raise_errors?
Any thoughts?
Hello,
I've installed Thin on Windows Server 2008 R2 and i'm able to fire up a single instance with thin, but when I try to specify options with clustering I receive ambigiousError messages:
C:\Web\Esco>thin start -p 3000 -s 4 -c C:/Web/Esco -e production
C:/Ruby/lib/ruby/gems/1.9.1/gems/thin-1.2.11-x86-mingw32/lib/thin/runner.rb:142:
in `parse!': ambiguous option: -s (OptionParser::AmbiguousOption)
from C:/Ruby/lib/ruby/gems/1.9.1/gems/thin-1.2.11-x86-mingw32/lib/thin/r
unner.rb:48:in `initialize'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/thin-1.2.11-x86-mingw32/bin/thin:6
:in `new'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/thin-1.2.11-x86-mingw32/bin/thin:6
:in `<top (required)>'
from C:/Ruby/bin/thin:19:in `load'
from C:/Ruby/bin/thin:19:in `<main>'
Is this intended behavior on Windows?
I can fire up the manually through a BAT-file, but this kinda kills the ability to control them with capistrano etc.
I use a prefix option to set up my rails app under thin 1.2.5, it works with the rails adaptor.
When I upgraded to 1.2.7, the prefix did not work, I believe because it now starts with the rack adaptor automatically.
It should either work, or spit out a warning saying that prefixes don't work with the rack adaptor.
The docs suggest that this is possible:
You can also install Thin as a runlevel script (under /etc/init.d/thin) that will start all your servers after boot.
sudo thin install
When trying it on my Mac, however, it yields:
$ sudo thin install
Unknown command: install. Use one of start, stop, restart, config
I'll keep googling around, but some extra documentation on this (and on the recommended way to monitor things) would be quite welcome.
I installed thin via gem install thin
which installed thin-1.2.8-x86-mingw32. Then when I tried to start rails via rails server thin
I crashed on line 48 in thin.rb: require "#{Thin::ROOT}/#{$1}/thin_parser"
When I investigated the gem there is no 1.9 directory under the thin lib directory. I removed the #{$1}/ from the path but it still crashes because it can't find thin_parser.so but that DOES exist under lib.
I noticed in version 1.2.8 the 1.8 and 1.9 directories do exist so I manually copied them over to my 1.2.9 directory and now it starts.
Here is the list of all rails versions installed : rails (3.0.1, 2.3.5, 2.3.4, 2.3.2, 2.2.2, 2.0.2)
I installed rails 3.0.1 recently and even though my environment.rb was specifying 2.3.5, thin didn't seem to load it properly :
RAILS_GEM_VERSION = '2.3.5' unless defined? RAILS_GEM_VERSION
It works with webrick.
When thin is booting as a daemon (with the -d flag), if the rails app fails to start for any reason, thin fails to return with an exit code of 1. It really should do this. :)
Usecase:
Proposition:
Allow pinning methods to Thin::Connection#receive_data after trace but before @request.parse.
Current example workaround:
I try "gem install macournoyer-thin" and get an error "Faild to build gem native extension."
See:
https://gist.github.com/863752
Is pipelining not implemented or am I doing something wrong?
Thin handles the first request but won't respond to the second until it timeouts.
thin start -V -R config.ru
gives me:
GET / HTTP/1.1
User-Agent: EventMachine HttpClient
Host: localhost:3000
GET / HTTP/1.1
User-Agent: EventMachine HttpClient
Host: localhost:3000
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 2
Connection: keep-alive
Server: thin 1.2.7 codename No Hup
hi
As of 1.2.8, the x86-mingw32 binary gem is only linked against Ruby 1.8.
While Windows users using the RubyInstaller can force a source build using the DevKit and gem install thin --platform=ruby
it would be more convenient if the binary x86-mingw32 gem was fat similar to Nokogiri, Amalgalite, Sqlite3, FFI and IIRC the upcoming EventMachine 1.0.0
Is it possible? I haven't find the way, but linking thin.log to /dev/null
I was trying to use Thin 1.2.6 under Windows XP and Ruby 1.9.1p243 (mingw32) and I got the following error:
c:\test>ruby script\server thin => Booting Thin => Rails 2.3.5 application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server Exiting c:/Ruby/lib/ruby/gems/1.9.1/gems/thin-1.2.6-x86-mingw32/lib/thin/server.rb:216:in `trap': unsupported signal SIGHUP (ArgumentError) from c:/Ruby/lib/ruby/gems/1.9.1/gems/thin-1.2.6-x86-mingw32/lib/thin/server.rb:216:in `setup_signals' from c:/Ruby/lib/ruby/gems/1.9.1/gems/thin-1.2.6-x86-mingw32/lib/thin/server.rb:130:in `initialize' from c:/Ruby/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/thin.rb:10:in `new' from c:/Ruby/lib/ruby/gems/1.9.1/gems/rack-1.0.1/lib/rack/handler/thin.rb:10:in `run' from c:/Ruby/lib/ruby/gems/1.9.1/gems/rails-2.3.5/lib/commands/server.rb:111:in `' from script/server:3:in `require' from script/server:3:in `'
Previous version of Thin has worked fine for me.
I've been using thin v1.2.4 and recently wrote a gem http://github.com/marksands/Markview that relies on vegas and thin. I run my tests using turn
which has worked, but now I upgrade to v1.2.7 and it gives me this mumbo jumo:
/usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/daemonizing.rb:86:in `restart': Can't restart, no 'on_restart' proc specified (ArgumentError)
from /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/server.rb:217:in `setup_signals'
from /usr/local/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call'
from /usr/local/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
from /usr/local/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
from /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/backends/base.rb:57:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/server.rb:156:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/handler/thin.rb:14:in `run'
from /usr/local/lib/ruby/gems/1.8/gems/vegas-0.1.4/lib/vegas/runner.rb:160:in `run!'
from /usr/local/lib/ruby/gems/1.8/gems/vegas-0.1.4/lib/vegas/runner.rb:103:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/vegas-0.1.4/lib/vegas/runner.rb:71:in `initialize'
from ./test/render_test.rb:25:in `new'
from ./test/render_test.rb:25:in `test_Vegas_runs_application'
from ./test/render_test.rb:25:in `fork'
from ./test/render_test.rb:25:in `test_Vegas_runs_application'
from /usr/local/lib/ruby/1.8/test/unit/testcase.rb:78:in `__send__'
from /usr/local/lib/ruby/1.8/test/unit/testcase.rb:78:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:34:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `each'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:34:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `each'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run'
from /usr/local/lib/ruby/1.8/test/unit/ui/testrunnermediator.rb:46:in `run_suite'
from /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:67:in `start_mediator'
from /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:41:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/lib/turn/controller.rb:145:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/lib/turn/command.rb:137
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/bin/turn:3:in `load'
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/bin/turn:3
from /usr/local/bin/turn:19:in `load'
from /usr/local/bin/turn:19
/usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/daemonizing.rb:86:in `restart': Can't restart, no 'on_restart' proc specified (ArgumentError)
from /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/server.rb:217:in `setup_signals'
from /usr/local/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call'
from /usr/local/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
from /usr/local/lib/ruby/gems/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
from /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/backends/base.rb:57:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/thin-1.2.7/lib/thin/server.rb:156:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/handler/thin.rb:14:in `run'
from /usr/local/lib/ruby/gems/1.8/gems/vegas-0.1.4/lib/vegas/runner.rb:160:in `run!'
from /usr/local/lib/ruby/gems/1.8/gems/vegas-0.1.4/lib/vegas/runner.rb:103:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/vegas-0.1.4/lib/vegas/runner.rb:71:in `initialize'
from ./test/render_test.rb:25:in `new'
from ./test/render_test.rb:25:in `test_Vegas_runs_application'
from ./test/render_test.rb:25:in `fork'
from ./test/render_test.rb:25:in `test_Vegas_runs_application'
from /usr/local/lib/ruby/1.8/test/unit/testcase.rb:78:in `__send__'
from /usr/local/lib/ruby/1.8/test/unit/testcase.rb:78:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:34:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `each'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:34:in `run'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `each'
from /usr/local/lib/ruby/1.8/test/unit/testsuite.rb:33:in `run'
from /usr/local/lib/ruby/1.8/test/unit/ui/testrunnermediator.rb:46:in `run_suite'
from /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:67:in `start_mediator'
from /usr/local/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:41:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/lib/turn/controller.rb:145:in `start'
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/lib/turn/command.rb:137
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/bin/turn:3:in `load'
from /usr/local/lib/ruby/gems/1.8/gems/turn-0.7.0/bin/turn:3
from /usr/local/bin/turn:19:in `load'
from /usr/local/bin/turn:19`
So, I uninstall v1.2.7 and revert to v1.2.4 and everything works fine. I'm not sure why it's giving me that error.
Here's the code that v1.2.7 doesn't like:
pid = fork { Vegas::Runner.new(Markview::Application, 'markview', :foreground => true, :skip_launch => true, :debug => true) }
sleep(1)
Process.detach(pid)
Process.kill( 'HUP', pid)
When I run rackup specifying the -s thin I get a segfault answering a request. Same thing with /usr/local/bin/thin -R config.ru start.
fmueller:/opt/ext/snippy[experimental*]$ /usr/local/bin/rackup config.ru -s thin >> Thin web server (v1.2.2 codename I Find Your Lack of Sauce Disturbing) >> Maximum connections set to 1024 >> Listening on 0.0.0.0:9292, CTRL+C to stop /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/request.rb:50: [BUG] unknown type 0x22 (0xc given) ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-darwin9.7.0] -- control frame ---------- c:0023 p:---- s:0091 b:0091 l:000090 d:000090 CFUNC :initialize c:0022 p:---- s:0089 b:0089 l:000088 d:000088 CFUNC :new c:0021 p:0019 s:0086 b:0086 l:000085 d:000085 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/request.rb:50 c:0020 p:---- s:0083 b:0083 l:000082 d:000082 FINISH c:0019 p:---- s:0081 b:0081 l:000080 d:000080 CFUNC :new c:0018 p:0017 s:0078 b:0078 l:000077 d:000077 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/connection.rb:35 c:0017 p:0042 s:0075 b:0075 l:000067 d:000074 BLOCK /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/em/connection.rb:43 c:0016 p:---- s:0073 b:0073 l:000072 d:000072 FINISH c:0015 p:---- s:0071 b:0071 l:000070 d:000070 CFUNC :instance_eval c:0014 p:0017 s:0068 b:0068 l:000067 d:000067 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/em/connection.rb:36 c:0013 p:0156 s:0063 b:0063 l:000062 d:000062 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/eventmachine.rb:1490 c:0012 p:---- s:0052 b:0052 l:000051 d:000051 FINISH c:0011 p:---- s:0050 b:0050 l:000049 d:000049 CFUNC :run_machine c:0010 p:0212 s:0047 b:0047 l:000046 d:000046 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/eventmachine.rb:242 c:0009 p:0065 s:0040 b:0040 l:000e68 d:000e68 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/backends/base.rb:57 c:0008 p:0139 s:0036 b:0036 l:000035 d:000035 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/server.rb:156 c:0007 p:0115 s:0033 b:0033 l:000032 d:000032 METHOD /usr/local/lib/ruby1.9/gems/1.9.1/gems/rack-1.0.0/lib/rack/handler/thin.rb:14 c:0006 p:0897 s:0027 b:0027 l:001a14 d:001a14 TOP /usr/local/lib/ruby1.9/gems/1.9.1/gems/rack-1.0.0/bin/rackup:176 c:0005 p:---- s:0013 b:0013 l:000012 d:000012 FINISH c:0004 p:---- s:0011 b:0011 l:000010 d:000010 CFUNC :load c:0003 p:0109 s:0007 b:0007 l:001b74 d:000ee8 EVAL /usr/local/bin/rackup:19 c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH c:0001 p:0000 s:0002 b:0002 l:001b74 d:001b74 TOP :47140 --------------------------- -- Ruby level backtrace information----------------------------------------- /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/request.rb:50:in `initialize' /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/request.rb:50:in `new' /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/request.rb:50:in `initialize' /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/connection.rb:35:in `new' /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/connection.rb:35:in `post_init' /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/em/connection.rb:43:in `block in new' /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/em/connection.rb:36:in `instance_eval' /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/em/connection.rb:36:in `new' /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/eventmachine.rb:1490:in `event_callback' /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/eventmachine.rb:242:in `run_machine' /usr/local/lib/ruby1.9/gems/1.9.1/gems/eventmachine-0.12.8/lib/eventmachine.rb:242:in `run' /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/backends/base.rb:57:in `start' /usr/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.2/lib/thin/server.rb:156:in `start' /usr/local/lib/ruby1.9/gems/1.9.1/gems/rack-1.0.0/lib/rack/handler/thin.rb:14:in `run' /usr/local/lib/ruby1.9/gems/1.9.1/gems/rack-1.0.0/bin/rackup:176:in `' /usr/local/bin/rackup:19:in `load' /usr/local/bin/rackup:19:in `' -- C level backtrace information ------------------------------------------- 0x2f7e02 0 libruby1.9.dylib 0x002f7e02 rb_vm_bugreport + 82 0x20ce3c 1 libruby1.9.dylib 0x0020ce3c rb_warning + 444 0x20ce9b 2 libruby1.9.dylib 0x0020ce9b rb_bug + 43 0x20f6d3 3 libruby1.9.dylib 0x0020f6d3 rb_check_type + 387 0x14c6a8d 4 thin_parser.bundle 0x014c6a8d Thin_HttpParser_init + 39 0x2f0b89 5 libruby1.9.dylib 0x002f0b89 rb_f_eval + 697 0x2f12db 6 libruby1.9.dylib 0x002f12db rb_funcall2 + 283 0x210aeb 7 libruby1.9.dylib 0x00210aeb rb_obj_call_init + 75 0x24562a 8 libruby1.9.dylib 0x0024562a rb_class_new_instance + 42 0x2e3605 9 libruby1.9.dylib 0x002e3605 rb_iseq_compile + 1125 0x2e7c6d 10 libruby1.9.dylib 0x002e7c6d rb_raise_method_missing + 1037 0x2ea47b 11 libruby1.9.dylib 0x002ea47b rb_raise_method_missing + 11291 0x2ef8fb 12 libruby1.9.dylib 0x002ef8fb rb_raise_method_missing + 32923 0x2f0dec 13 libruby1.9.dylib 0x002f0dec rb_f_eval + 1308 0x2f12db 14 libruby1.9.dylib 0x002f12db rb_funcall2 + 283 0x210aeb 15 libruby1.9.dylib 0x00210aeb rb_obj_call_init + 75 0x24562a 16 libruby1.9.dylib 0x0024562a rb_class_new_instance + 42 0x2e3605 17 libruby1.9.dylib 0x002e3605 rb_iseq_compile + 1125 0x2e7c6d 18 libruby1.9.dylib 0x002e7c6d rb_raise_method_missing + 1037 0x2ea47b 19 libruby1.9.dylib 0x002ea47b rb_raise_method_missing + 11291 0x2ef8fb 20 libruby1.9.dylib 0x002ef8fb rb_raise_method_missing + 32923 0x2f3e68 21 libruby1.9.dylib 0x002f3e68 rb_yield + 2168 0x2f432d 22 libruby1.9.dylib 0x002f432d rb_mod_module_exec + 109 0x2e3605 23 libruby1.9.dylib 0x002e3605 rb_iseq_compile + 1125 0x2e7c6d 24 libruby1.9.dylib 0x002e7c6d rb_raise_method_missing + 1037 0x2ea47b 25 libruby1.9.dylib 0x002ea47b rb_raise_method_missing + 11291 0x2ef8fb 26 libruby1.9.dylib 0x002ef8fb rb_raise_method_missing + 32923 0x2f0dec 27 libruby1.9.dylib 0x002f0dec rb_f_eval + 1308 0x2e7529 28 libruby1.9.dylib 0x002e7529 rb_funcall + 345 0x1185ff1 29 rubyeventmachine.bundle 0x01185ff1 _ZNSt11_Deque_baseIN14PipeDescriptor12OutboundPageESaIS1_EED2Ev + 273 0x118644c 30 rubyeventmachine.bundle 0x0118644c _ZNSt11_Deque_baseIN14PipeDescriptor12OutboundPageESaIS1_EED2Ev + 1388 0x117bd61 31 rubyeventmachine.bundle 0x0117bd61 _ZN18AcceptorDescriptor4ReadEv + 273 0x117eb58 32 rubyeventmachine.bundle 0x0117eb58 _ZN14EventMachine_t14_RunSelectOnceEv + 520 0x1182313 33 rubyeventmachine.bundle 0x01182313 _ZN14EventMachine_t8_RunOnceEv + 35 0x118239c 34 rubyeventmachine.bundle 0x0118239c _ZN14EventMachine_t3RunEv + 92 0x11744c9 35 rubyeventmachine.bundle 0x011744c9 evma_run_machine + 41 0x11864cb 36 rubyeventmachine.bundle 0x011864cb _ZNSt11_Deque_baseIN14PipeDescriptor12OutboundPageESaIS1_EED2Ev + 1515 0x2e7c6d 37 libruby1.9.dylib 0x002e7c6d rb_raise_method_missing + 1037 0x2ea47b 38 libruby1.9.dylib 0x002ea47b rb_raise_method_missing + 11291 0x2ef8fb 39 libruby1.9.dylib 0x002ef8fb rb_raise_method_missing + 32923 0x2efc38 40 libruby1.9.dylib 0x002efc38 rb_iseq_eval + 264 0x213629 41 libruby1.9.dylib 0x00213629 rb_load + 345 0x213762 42 libruby1.9.dylib 0x00213762 rb_load + 658 0x2e3605 43 libruby1.9.dylib 0x002e3605 rb_iseq_compile + 1125 0x2e7c6d 44 libruby1.9.dylib 0x002e7c6d rb_raise_method_missing + 1037 0x2ea47b 45 libruby1.9.dylib 0x002ea47b rb_raise_method_missing + 11291 0x2ef8fb 46 libruby1.9.dylib 0x002ef8fb rb_raise_method_missing + 32923 0x2efb0f 47 libruby1.9.dylib 0x002efb0f rb_iseq_eval_main + 159 0x20ff99 48 libruby1.9.dylib 0x0020ff99 ruby_exec_node + 169 0x2125fe 49 libruby1.9.dylib 0x002125fe ruby_run_node + 94 0x1fef 50 ruby1.9 0x00001fef main + 95 0x1f56 51 ruby1.9 0x00001f56 start + 54 [NOTE] You may encounter a bug of Ruby interpreter. Bug reports are welcome. For details: http://www.ruby-lang.org/bugreport.html Abort trap
I am trying to run toto locally on thin and I am getting the following error:
/var/lib/gems/1.9.1/gems/thin-1.2.7/lib/thin.rb:6:in require': no such file to load -- openssl (LoadError) from /var/lib/gems/1.9.1/gems/thin-1.2.7/lib/thin.rb:6:in
<top (required)>'
from /var/lib/gems/1.9.1/gems/thin-1.2.7/bin/thin:5:in require' from /var/lib/gems/1.9.1/gems/thin-1.2.7/bin/thin:5:in
<top (required)>'
from /var/lib/gems/1.9.1/bin/thin:19:in load' from /var/lib/gems/1.9.1/bin/thin:19:in
I am running thin on an Ubuntu 10.04 VM. If I try to "apt-get install openssl" I am told that I already have the latest version, and I if I try "gem install openssl" I am told that there is no gem package with that name.
How can I solve that dependency?
thin_parser.so segfaults with thin 1.2.8 running under ruby 1.9.2p136 on windows 7 x64 (i386-mingw32).
After cloning the latest repositories code, building and installing the gem (it built as 1.2.4), the issue still occurs.
C:/Ruby192/lib/ruby/gems/1.9.1/gems/thin-1.2.4/lib/thin_parser.so: [BUG] Segmentation fault
ruby 1.9.2p136 (2010-12-25) [i386-mingw32]
-- control frame ----------
c:0017 p:-15094038 s:0052 b:0052 l:000051 d:000051 TOP
c:0016 p:---- s:0050 b:0050 l:000049 d:000049 CFUNC :require
c:0015 p:0013 s:0046 b:0046 l:000045 d:000045 METHOD <internal:lib/rubygems/custom_require>:29
c:0014 p:0203 s:0041 b:0041 l:000040 d:000040 TOP C:/Ruby192/lib/ruby/gems/1.9.1/gems/thin-1.2.4/lib/thin.rb:44
c:0013 p:---- s:0039 b:0039 l:000038 d:000038 FINISH
c:0012 p:---- s:0037 b:0037 l:000036 d:000036 CFUNC :require
c:0011 p:0073 s:0033 b:0033 l:000029 d:000032 BLOCK <internal:lib/rubygems/custom_require>:33
c:0010 p:0014 s:0030 b:0030 l:000029 d:000029 METHOD <internal:lib/rubygems/custom_require>:29
c:0009 p:0011 s:0025 b:0025 l:000024 d:000024 TOP C:/git/web-application/web_interface.rb:1
c:0008 p:---- s:0023 b:0023 l:000022 d:000022 FINISH
c:0007 p:---- s:0021 b:0021 l:000020 d:000020 CFUNC :require_relative
c:0006 p:0023 s:0017 b:0017 l:000016 d:000016 TOP C:/git/web-application/betfair-bot.rb:2
c:0005 p:---- s:0012 b:0012 l:000011 d:000011 FINISH
c:0004 p:---- s:0010 b:0010 l:000009 d:000009 CFUNC :load
c:0003 p:0051 s:0006 b:0006 l:000b14 d:00162c EVAL -e:1
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:000b14 d:000b14 TOP
---------------------------
-- Ruby level backtrace information ----------------------------------------
-e:1:in `<main>'
-e:1:in `load'
C:/git/web-application/application.rb:2:in `<top (required)>'
if I try to start thin with thin start
I get the error
Missing the Rails 2.3.8 gem. Please
gem install -v=2.3.8 rails
, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or survey out RAILS_GEM_VERSION to use the latest version installed.
Rails Version 2.3.8 is installed on the system.
I'm experiencing an issue with thin stopping. It will only die to a kill -9 or after time out on "thin stop". Regular "kill PID" doesn't work, and ctrl-c when in non-daemon mode leaves it "Stopping..." forever. Repeated ctrl-c returns the same "Stopping..." response without ever dying.
Using Ruby 1.8.7-p334, Rails 2.3.10, and Thin 1.2.8 on Fedora 14.
Thanks.
I have custom environment in rails app - 'staging' environment. Using thin with it is extreemly slow
Here is some output: http://pastebin.com/QGXDW8nQ
it can't run with thin start
but script/server thin
works fine, I have added config.gem 'thin'
to my environment.rb but am unable to run script/server thin --socket tmp/redmine.socket
Thin fails to load on ruby 1.8.7 with error message:
uninitialized constant Thin::Request::Encoding (NameError)
from /Library/Ruby/Gems/1.8/gems/thin-1.2.5/lib/thin/request.rb:19
Uses of Encoding should be conditional (only for ruby 1.9) to support older ruby versions.
After switching to Ruby 1.9 stack, the new version of Thin just wont stop unless kill -9'ed...
Ruby version: ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]
Thin: thin 1.2.11 codename Bat-Shit Crazy
All dependencies are the latest official builds from rubygems.org
thin at /home/jazen/.rvm/gems/ruby-1.9.2-rc2@blog/bundler/gems/thin-232e9ca did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
If you need to use this package without installing it from a gem repository, please contact [email protected] and ask them to modify their .gemspec so it can work with `gem build`.
The validation message from Rubygems was:
["lib/thin_parser.so", "spec/rails_app/log", "spec/rails_app/log/mongrel_debug"] are not files
/jzn
I'm experiencing a strange issue with send_data. Strange because it happens only on Safari (I tried with Safari 4.0.5). Maybe a Safari related problem, but it's not happening with mongrel, reason why I'm posting this issue here. I'll try to be short:
This happens with all version of thin since 1.2.4. I didn't try older versions.
I tried many different combinations in send_data options, but nothing helped.
I know it's a weird Safari issue, but not solving this leads me to use mongrel or something else for deploy.
Thanks
alex$ thin start
/Users/alex/.rvm/gems/ruby-1.8.7-p174@somegemset/gems/thin-1.2.10/lib/thin_parser.bundle: [BUG] Segmentation fault
ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.7.1]
Abort trap
Mac OS X
Version 10.6.7
Processor 2.2 GHz Intel Core i7
Memory 4 GB
Thin is throwing segmentation errors when I run "thin start" or even rake db:migrate
If there is any more information I can give you to help out diagnosing this, please let me know.
Alex
I'm unable to monitor thin with monit because it's process name contains whitespace.
# ps aux | grep thin
gitosis 28109 0.0 15.3 253032 117244 ? D Jun11 0:33 thin server (/usr/share/redmine/tmp/sockets/thin.0.socket)
gitosis 28115 0.0 0.1 229912 872 ? S Jun11 0:14 thin server (/usr/share/redmine/tmp/sockets/thin.1.socket)
My monit rc file for thin.
check process thin-0
with pidfile /var/run/redmine/thin.0.pid
start program = "/etc/init.d/thin start"
stop program = "/etc/init.d/thin stop"
if totalmem > 150.0 MB for 10 cycles then restart
if failed unixsocket /var/run/redmine/sockets/default/thin.0.socket then restart
if failed unixsocket /var/run/redmine/sockets/default/thin.1.socket then restart
if cpu is greater than 40% for 2 cycles then alert
if cpu usage > 95% for 3 cycles then restart
if 5 restarts within 10 cycles then timeout
Here's how monit behaves:
# monit validate
'thin-0' process is not running
'thin-0' trying to restart
'thin-0' start: /etc/init.d/thin
[start] /etc/thin1.8/redmine.yml ...
Starting server on /usr/share/redmine/tmp/sockets/thin.0.socket ...
/var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/daemonizing.rb:171:in `remove_stale_pid_file': /usr/share/redmine/tmp/pids/thin.0.pid already exists, seems like it's already running (process ID: 28109). Stop the process or delete /usr/share/redmine/tmp/pids/thin.0.pid. (Thin::PidFileExist)
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/daemonizing.rb:42:in `daemonize'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/controllers/controller.rb:61:in `start'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:185:in `send'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:185:in `run_command'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:151:in `run!'
from /var/lib/gems/1.8/gems/thin-1.2.11/bin/thin:6
from /usr/local/bin/thin:19:in `load'
from /usr/local/bin/thin:19
Starting server on /usr/share/redmine/tmp/sockets/thin.1.socket ...
/var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/daemonizing.rb:171:in `remove_stale_pid_file': /usr/share/redmine/tmp/pids/thin.1.pid already exists, seems like it's already running (process ID: 28115). Stop the process or delete /usr/share/redmine/tmp/pids/thin.1.pid. (Thin::PidFileExist)
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/daemonizing.rb:42:in `daemonize'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/controllers/controller.rb:61:in `start'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:185:in `send'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:185:in `run_command'
from /var/lib/gems/1.8/gems/thin-1.2.11/lib/thin/runner.rb:151:in `run!'
from /var/lib/gems/1.8/gems/thin-1.2.11/bin/thin:6
from /usr/local/bin/thin:19:in `load'
from /usr/local/bin/thin:19
^C'thin-0' failed to start
It also does not work if I make monit check the process thin
nor "thin server (/usr/share/redmine/tmp/sockets/thin.1.socket)"
. The first because there no such process, the second because white-space and commas are not allowed in process names on monitrc files.
I'm currently unable to to start up my Thin cluster on an Ubuntu server.
The gem is not installed, but beeing managed through bundler.
I had a cluster running before, but Capistrano does not seem to be able to start it up anymore, nor can I fire it up manually either.
I had a yml config file that I used in the the following command:
bundle exec thin restart -C thin.yml
But this either starts only up a single instance of Thin, or i receive error messages about duplicate PID entries in the pid file or not pids found at all in the config file.
This is the content of the yml file:
pid: tmp/pids/thin.pid
address: 0.0.0.0
timeout: 30
wait: 30
port: 4000
log: log/thin.log
max_conns: 1024
require: []
environment: production
max_persistent_conns: 512
server: 4
daemonize: true
chdir: /var/www/apps/current
I'm testing Rack with Thin 1.2.5 using both HTTP queries with relative URI and absolute URI.
I use map "/" in my Rack builder so it gets any request.
However when I get the value of env["PATH_INFO"] I get an empty string when using absolute URI:
a) Relative URI:
GET /pres-rules/mydoc.xml HTTP/1.1
=> env['PATH_INFO'] = "/pres-rules/mydoc.xml"
b) Absolute URI:
GET http://127.0.0.1:9292/pres-rules/mydoc.xml HTTP/1.1
=> env['PATH_INFO'] = ""
This doesn't occur using webrick.
PS: As per RFC 2616 (HTTP/1.1) a HTTP request allows absolute request uri:
http://tools.ietf.org/html/rfc2616#section-5.1.2
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
I noticed that Thin does not comply with the HTTP 1.1 requirement for handling duplicate Header names:
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the message,
by appending each subsequent field-value to the first, each separated by a
comma. The order in which header fields with the same field-name are
received is therefore significant to the interpretation of the combined field
value, and thus a proxy MUST NOT change the order of these field values
when a message is forwarded.
-- http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
require 'sinatra/base'
class App < Sinatra::Base
get '/' do
puts env.inspect
end
end
run App
$ rackup -s thin
>> sock = TCPSocket.new('localhost',4567)
>> sock.write("GET / HTTP/1.1\r\n")
>> sock.write("Content-Type: text/plain\r\n")
>> sock.write("Content-Type: charset=utf8\r\n")
>> sock.write("\r\n" * 2)
{"SERVER_SOFTWARE"=>"thin 1.2.7 codename No Hup", "SERVER_NAME"=>"localhost", "rack.input"=>#<StringIO:0x00000001efad48>, "rack.version"=>[1, 0], "rack.errors"=>#<IO:<STDERR>>, "rack.multithread"=>false, "rack.multiprocess"=>false, "rack.run_once"=>false, "REQUEST_METHOD"=>"GET", "REQUEST_PATH"=>"/", "PATH_INFO"=>"/", "REQUEST_URI"=>"/", "HTTP_VERSION"=>"HTTP/1.1", "CONTENT_TYPE"=>"charset=utf8", "GATEWAY_INTERFACE"=>"CGI/1.2", "QUERY_STRING"=>"", "SERVER_PROTOCOL"=>"HTTP/1.1", "rack.url_scheme"=>"http", "SCRIPT_NAME"=>"", "REMOTE_ADDR"=>"127.0.0.1", "async.callback"=>#<Method: Thin::Connection#post_process>, "async.close"=>#<EventMachine::DefaultDeferrable:0x00000001efa0a0>, "rack.request.query_string"=>"", "rack.request.query_hash"=>{}}
If I run the same test against WEBrick, it properly combines the duplicate Content-Type
headers:
{"CONTENT_TYPE"=>"text/plain, charset=utf8", "GATEWAY_INTERFACE"=>"CGI/1.1", "PATH_INFO"=>"/", "QUERY_STRING"=>"", "REMOTE_ADDR"=>"127.0.0.1", "REMOTE_HOST"=>"localhost.localdomain", "REQUEST_METHOD"=>"GET", "REQUEST_URI"=>"http://localhost.localdomain:9292/", "SCRIPT_NAME"=>"", "SERVER_NAME"=>"localhost.localdomain", "SERVER_PORT"=>"9292", "SERVER_PROTOCOL"=>"HTTP/1.1", "SERVER_SOFTWARE"=>"WEBrick/1.3.1 (Ruby/1.9.2/2010-12-25)", "rack.version"=>[1, 1], "rack.input"=>#<Rack::Lint::InputWrapper:0x00000002687110 @input=#<StringIO:0x00000002697cb8>>, "rack.errors"=>#<Rack::Lint::ErrorWrapper:0x00000002687020 @error=#<IO:<STDERR>>>, "rack.multithread"=>true, "rack.multiprocess"=>false, "rack.run_once"=>false, "rack.url_scheme"=>"http", "HTTP_VERSION"=>"HTTP/1.1", "REQUEST_PATH"=>"/", "rack.request.query_string"=>"", "rack.request.query_hash"=>{}}
It looks like when Thin uses a config.ru under Ruby 1.9, it evaluates it under the Rack module, which breaks code that relies on the top-level File, instead of Rack::File. See:
http://github.com/documentcloud/cloud-crowd/issues/closed#issue/6
If this is really a problem with Rack/Ruby1.9, instead of Thin, feel free to close the ticket.
I have leveraged rufus-scheduler and resque to schedule jobs for a rails application. The scheduler runs as an initializer, which is executed when the web server starts up. When I use WEBrick, the scheduler works 100% of the time. When using Thin, the scheduler sometimes fails to execute work when it is supposed to.
Thin 1.2.11
Ruby Version: ruby 1.9.2p0 (2010-08-18 revision 29036) [i486-linux]
Platform: Debian 5.0.8 Lenny
Rufus-scheduler version: 2.0.9
Has anyone else experienced similar behavior?
Have been seeing a few occurrences like this:
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:466:in `load_missing_constant': uninitialized constant Thin::HttpParser (NameError)
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:106:in `const_missing_not_from_s3_library'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/aws-s3-0.6.2/lib/aws/s3/extensions.rb:206:in `const_missing'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/request.rb:52:in `initialize'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/connection.rb:35:in `new'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/connection.rb:35:in `post_init'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/eventmachine-0.12.10/lib/em/connection.rb:45:in `new'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/eventmachine-0.12.10/lib/em/connection.rb:36:in `instance_eval'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/eventmachine-0.12.10/lib/em/connection.rb:36:in `new'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:1430:in `event_callback'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/backends/base.rb:61:in `start'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/server.rb:159:in `start'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/controllers/controller.rb:86:in `start'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/runner.rb:185:in `send'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/runner.rb:185:in `run_command'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/lib/thin/runner.rb:151:in `run!'
from /app/da7ce784-f915-4376-b405-641717334754/home/.bundle/gems/ruby/1.8/gems/thin-1.2.8/bin/thin:6
from /usr/ruby1.8.7/bin/thin:19:in `load'
from /usr/ruby1.8.7/bin/thin:19
I'm a bit unsure this is the place to post this, or whether to post it at all, but...
Trying to get thin running with the default app created by the rails 3 beta. First issue I ran across is detailed in this lighthouse ticket (posted by someone else). I got around this by applying the change in a094f3a.
This led to another issue, which I believe is discussed in Issue #5. Changing the File.read call in lib/rack/adapter/loader.rb:38 to ::File.read got around this I think, but finally led me to my current trace:
>> Thin web server (v1.2.5 codename This Is Not A Web Server) >> Maximum connections set to 1024 >> Listening on 0.0.0.0:3000, CTRL+C to stop /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/lib/thin/backends/tcp_server.rb:16:in `connect': no such file to load -- thin/connection (LoadError) from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/lib/thin/backends/base.rb:49:in `block in start' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/lib/thin/backends/base.rb:57:in `start' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/lib/thin/server.rb:156:in `start' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/lib/thin/controllers/controller.rb:80:in `start' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/lib/thin/runner.rb:177:in `run_command' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/lib/thin/runner.rb:143:in `run!' from /usr/local/ruby-1.9.1-p376/lib/ruby/gems/1.9.1/gems/thin-1.2.5/bin/thin:6:in `' from /usr/local/ruby-1.9.1-p376/bin/thin:19:in `load' from /usr/local/ruby-1.9.1-p376/bin/thin:19:in `'
After successfully installing thin v1.2.11 on Win7 via gem install thin --platform=ruby
, thin is unusable as the loading scheme can't find the newly built lib/thin_parser.so
Example patch => https://gist.github.com/911713
Hey there,
Thin is a nice and fast web server, but on the other hand it steals me a couple of hours regularly by suddenly not working. Now there is such an issue again and I don't know how to solve it. Let's start with my setup:
I'm running Thin as a service in socket mode (with NGINX) that can be restarted with:
$ sudo service thin restart
# OR
$ sudo /etc/init.d/thin restart
Here's my configuration for the rails 3 project I'm having problems with:
# /etc/thin/PROJECT.yml -> /var/www/PROJECT/config/thin.yml
---
pid: ./tmp/pids/thin.pid
timeout: 30
wait: 30
log: ./log/thin.log
max_conns: 1024
require: []
environment: development
max_persistent_conns: 512
servers: 3
daemonize: true
socket: ./tmp/sockets/thin.sock
chdir: /var/www/PROJECT
As a side note for anyone having problems that thin is simply not starting as a socket server: the "./" in front of the path is very important for your success!
But now more on my problem with Thin. I found out that Thin throws errors in /var/www/PROJECT/log/thin.0.log as long as the gems I use in my project aren't installed system-wide - /var/lib/gems/1.8/ -, though I'm using Bundler to install them locally - /var/www/PROJECT/vendor/bundler/ -. Big problem here is that I'm having more than one application and all of them using different versions of gems.
Here goes my question: How can I tell Thin to look for (load) those gems that are locally installed via Bundler (instead of those that are (not) installed via Rubygems system-wide)?
In daemonizing.rb:
def pid
File.exist?(pid_file) ? open(pid_file).read.to_i : nil
end
Now, if you have stale EMPTY pid file you will get 0 after to_i, thin will check if process 0 is running, of cource it is, and will not run.
This commit will not work in all cases: ddd91ee
Explanation: after 30 seconds of inactivity server will close connection no mater if status is 1xx or not
thin/lib/thin/backends/base.rb
Line 130 in 51f8169
Proof: Open 101 connection and wait 30 sec. Easy to check with Cramp and websocket connection. Current workaround:
https://github.com/lifo/cramp/blob/415d4b0f66fa8375ecb444aeac9524d3cad07273/lib/cramp/websocket/thin_backend.rb#L3
Must bo fired before server_start is called.
Any thoughts about how to fix that?
There was no new release of Thin since nearly year. This would be nice to release one - especially that last version still doesn't have SSL support, which would be very appreciated. Currently if you want to use SSL you need to use steamcannon branch. About that - it would be nice to merge some commits from goldmann branch that add some SSL goodness.
I am not sure what it chokes on, but it chokes on my ubunto slice. For example when I reboot
it sits there waiting for thin to stop, and even if I manually run /etc/init.d/thin stop it will say its stopping and just gets stuck, and then the next time I run it, it will go to the second one (in a cluster) and stop, etc
Thin is calling 'has_key?' on the response header object even though the rack specification says that it only needs to respond to 'each' and yield key/value strings.
See the rack issue: rack/rack#193
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.