This repository is private.
All pages are served over SSL and all pushing and pulling is done over SSH.
No one may fork, clone, or view it unless they are added as a member.
Every repository with this icon (
) is private.
Every repository with this icon (
This repository is public.
Anyone may fork, clone, or view it.
Every repository with this icon (
) is public.
Every repository with this icon (
commit 177a35e711e3b21eac0eb19f03aeae7626e490f5
tree 4042c7492cc57d79dc6935ffc0677f5f4426740b
parent ddd552504bd682d64aa63bd06aa3f74818d48493
tree 4042c7492cc57d79dc6935ffc0677f5f4426740b
parent ddd552504bd682d64aa63bd06aa3f74818d48493
... |
... |
|
... |
... |
|












This is quite misleading because as far as I know this is not enough to make Rails actually thread-safe, right?
@alpha: The work to enable this happened in dozens of earlier changesets, there’s nothing magic here.
Testing indicates that actionpack and activesupport are threadsafe now. We have to merge the connection pooling branch before we can tick the box for active record.
So no, it’s not misleading, you just missed all the fun stuff in earlier commits :)
Thanks for you swift reply. I’ve just started to follow Rails development closer, so I’m not fully informed.
Does this mean that all the issues pointed by Zed in the post below have been resolved? http://www.mail-archive.com/mongrel-users@rubyforge.org/msg00243.html
great news
I’d take zed’s comments with a few grains of salt, some good stuff there and the traditional hyperbole.
The DB connection issue is real and remains outstanding. That’s why we need the connection pool branch from nick sieger before we’re ‘done’ here.
Talk of requests crossing threads or objects moving magically between threads is vague hand waving that likely never happened. We’ve heard this before with respect to active record connections, but no one has ever provided a reproducible test case, or a plausible theory that could explain it.
We’re bound to have missed something, threading bugs are notoriously difficult to track down. The more testers the merrier ;)
I’d take zed’s comments with a few grains of salt, some good stuff there and the traditional hyperbole.
The DB connection issue is real and remains outstanding. That’s why we need the connection pool branch from nick sieger before we’re ‘done’ here.
Talk of requests crossing threads or objects moving magically between threads is vague hand waving that likely never happened. We’ve heard this before with respect to active record connections, but no one has ever provided a reproducible test case, or a plausible theory that could explain it.
We’re bound to have missed something, threading bugs are notoriously difficult to track down. The more testers the merrier ;)
I’d take zed’s comments with a few grains of salt, some good stuff there and the traditional hyperbole.
The DB connection issue is real and remains outstanding. That’s why we need the connection pool branch from nick sieger before we’re ‘done’ here.
Talk of requests crossing threads or objects moving magically between threads is vague hand waving that likely never happened. We’ve heard this before with respect to active record connections, but no one has ever provided a reproducible test case, or a plausible theory that could explain it.
We’re bound to have missed something, threading bugs are notoriously difficult to track down. The more testers the merrier ;)
Time to disable the giant Mongrel lock around Rails and do some testing :)
We haven’t finished the work, AR will still leak connections like crazy, but initial testing is positive. If you have some other non-AR apps you can test, we’d love to hear about breakage (in lighthouse + the core list ;)) I’ve been using this app as a test base, if you can reproduce breakages with patches to that, then send them my way.
http://github.com/NZKoz/sillytestapp/tree/master
I think most of Zed’s problems will have gone away. However, in my own [none rails] tests about a year ago, the problem of methods ‘mysteriously’ being assigned to the wrong thread occurred, and also that of sockets sometimes reading input from another [different] socket also occurred. That being said, the Mongrel guys haven’t experienced that much [it only occurs with very heavy load], and using eventMachine you can avoid it further. But it is still in there…lurking…
If you were to use eventmachine and a single-threaded style architecture [ex: ruby 1.9 + fibers so that it mimics multi-threaded] then I believe you have even less of the same problems. Good luck. -=R
I think most of Zed’s problems will have gone away. However, in my own [none rails] tests about a year ago, the problem of methods ‘mysteriously’ being assigned to the wrong thread occurred, and also that of sockets sometimes reading input from another [different] socket also occurred. That being said, the Mongrel guys haven’t experienced that much [it only occurs with very heavy load], and using eventMachine you can avoid it further. But it is still in there…lurking…
If you were to use eventmachine and a single-threaded style architecture [ex: ruby 1.9 + fibers so that it mimics multi-threaded] then I believe you have even less of the same problems. Good luck. -=R