| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Ruby 2.4 introduces `report_on_exception` to control if it reports exceptions in thread,
this default value has been `false` in Ruby 2.4.
Refer https://www.ruby-lang.org/en/news/2016/11/09/ruby-2-4-0-preview3-released/
* Ruby 2.5 changes `report_on_exception` default value to `true`
since this commit https://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=61183&view=revision
This pull request suppresses expected exceptions by setting `report_on_exception` = `false`
it also supports Ruby 2.3 which does not have`report_on_exception`.
|
| |
|
|\
| |
| | |
Switch to LIFO for the connection pool
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
|/
|
|
|
| |
This debug print was added in 87f5e5e for finding the regression caused
by d314646 and the regression has already been fixed in 969339b.
|
| |
|
|
|
|
|
|
|
| |
```
go get -u github.com/client9/misspell/cmd/misspell
misspell -w -error -source=text .
```
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
|
|
|
| |
so let's test with a tiny inner-class model instead
|
|
|
|
|
|
| |
Some methods were added to public API in
5b14129d8d4ad302b4e11df6bd5c7891b75f393c and they should be not part of
the public API.
|
|
|
|
|
| |
I assume it's upset because of the change in d314646c965b045724e6bdb9d61dcecfabc0ba8f,
but I don't yet understand why.
|
|
|
|
|
|
| |
Two methods block new connections; we were already doing the right thing
for clear_reloadable_connections, but it's better placed in
with_new_connections_blocked, where it can work for disconnect too.
|
| |
|
|
|
|
|
|
| |
Under JRuby, the updates of the one shared variable interleaved,
causing threads to pick up each others' connections. I'm amazed
this worked on MRI.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
| |
Follow up to #20818.
`retrieve_connection` is passed `spec_name` instead of `klass` since #24844.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loaded model classes have their connections wrapped in transactions.
See #17776
In Rails 4 config.eager_load was changed to false in the test environment. This
means that model classes that connect to alternate databases with
establish_connection are not loaded at start up. If use_transactional_fixtures
is enabled, transactions are wrapped around the connections that have been
established only at the start of the test suite. So model classes loaded later
don't have transactions causing data created in the alternate database not to
be removed.
This change resolves that by creating a new connection.active_record
notification that gets fired whenever a connection is established. I then added
a subscriber after we set up transactions in the test environment to listen for
additional connections and wrap those in transactions as well.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConnectionHandler will not have any knowlodge of AR models now, it will
only know about the specs.
Like that we can decouple the two, and allow the same model to use more
than one connection.
Historically, folks used to create abstract AR classes on the fly in
order to have multiple connections for the same model, and override the
connection methods.
With this, now we can override the `specificiation_id` method in the
model, to return a key, that will be used to find the connection_pool
from the handler.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The concurrent-ruby gem is a toolset containing many concurrency
utilities. Many of these utilities include runtime-specific
optimizations when possible. Rather than clutter the Rails codebase with
concurrency utilities separate from the core task, such tools can be
superseded by similar tools in the more specialized gem. This commit
replaces `ActiveSupport::Concurrency::Latch` with
`Concurrent::CountDownLatch`, which is functionally equivalent.
|
|
|
|
|
| |
We must account for receiving one less call to #new_connection, but the
test otherwise remains valid.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Renamed `@reserved_connections` -> `@thread_cached_conns`. New name
clearly conveys the purpose of the cache, which is to speed-up
`#connection` method.
The new `@thread_cached_conns` now also uses `Thread` objects as keys
(instead of previously `Thread.current.object_id`).
Since there is no longer any synchronization around
`@thread_cached_conns`, `disconnect!` and `clear_reloadable_connections!`
methods now pre-emptively obtain ownership (via `checkout`) of all
existing connections, before modifying internal data structures.
A private method `release` has been renamed `thread_conn_uncache` to
clear-up its purpose.
Fixed some brittle `thread.status == "sleep"` tests (threads can go
into sleep even without locks).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `db:schema:cache:dump` rake task dumps the database schema structure
to `db/schema_cache.dump`. If this file is present, the schema details
are loaded into the currently checked out connection by a railtie while
Rails is booting, to avoid having to query the database for its schema.
The schema cache dump is only applied to the initial connection used to
boot the application though; other connections from the same pool are
created with an empty schema cache, and still have to load the structure
of each table directly from the database.
With this change, a copy of the schema cache is associated with the
connection pool and applied to connections as they are created.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a squash of the following commits, from first to last:
-
Fix minor, random things I’ve come across lately that individually
did not seem worth making a PR for, so I saved them for one commit.
One common error is using “it’s” (which is an abbreviation of “it is”)
when the possessive “its” should be used for indicating possession.
-
Changes include the name of a test, so remove the `[skip ci]` (thanks @senny).
-
Line wrap the changes at 80 chars and add one more doc fix.
-
Add a missing line wrap in the Contributing to Ruby on Rails Guide.
-
Line wrap the `TIP` section in the Contributing to Ruby on Rails Guide as well.
Rendering the guide locally with `bundle exec rake guides:generate` did
not show any change in on-screen formatting after adding the line wrap.
The HTML generated is (extra line added to illustrate where the line
wrap takes place):
<div class="info"><p>Please squash your commits into a single commit
when appropriate. This
simplifies future cherry picks and also keeps the git log
clean.</p></div>
-
Squash commits.
|
|
|
|
|
| |
Previously, any of the connection checkouts could have failed, and this
test would pass.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.. not a general timeout.
Now, if a thread checks out a connection then dies, we can immediately
recover that connection and re-use it.
This should alleviate the pool exhaustion discussed in #12867. More
importantly, it entirely avoids the potential issues of the reaper
attempting to check whether connections are still active: as long as the
owning thread is alive, the connection is its business alone.
As a no-op reap is now trivial (only entails checking a thread status
per connection), we can also perform one in-line any time we decide to
sleep for a connection.
|
|
|
|
|
|
|
|
| |
Follow-Up to https://github.com/rails/rails/pull/14348
Ensure that SQLCounter.clear_log is called after each test.
This is a step to prevent side effects when running tests. This will allow us to run them in random order.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
[ci skip]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a result of different commits, ConnectionPool had become
of two minds about exceptions, sometimes using PoolFullError
and sometimes using ConnectionTimeoutError. In fact, it was
using ConnectionTimeoutError internally, but then recueing
and re-raising as a PoolFullError.
There's no reason for this bifurcation, standardize on
ConnectionTimeoutError, which is the rails2 name and still
accurately describes semantics at this point.
History
In Rails2, ConnectionPool raises a ConnectionTimeoutError if
it can't get a connection within timeout.
Originally in master/rails3, @tenderlove had planned on removing
wait/blocking in connectionpool entirely, at that point he changed
exception to PoolFullError.
But then later wait/blocking came back, but exception remained
PoolFullError.
Then in 02b233556377 pmahoney introduced fair waiting logic, and
brought back ConnectionTimeoutError, introducing the weird bifurcation.
ConnectionTimeoutError accurately describes semantics as of this
point, and is backwards compat with rails2, there's no reason
for PoolFullError to be introduced, and no reason for two
different exception types to be used internally, no reason
to rescue one and re-raise as another. Unify!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The core of this fix is a threadsafe, fair Queue class. It is
very similar to Queue in stdlib except that it supports waiting
with a timeout.
The issue this solves is that if several threads are contending for
database connections, an unfair queue makes is possible that a thread
will timeout even while other threads successfully acquire and release
connections. A fair queue means the thread that has been waiting the
longest will get the next available connection.
This includes a few test fixes to avoid test ordering issues that
cropped up during development of this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#6441
An AR ConnectionSpec `wait_timeout` is pre-patch used for three
different things:
* mysql2 uses it for MySQL's own wait_timeout (how long MySQL
should allow an idle connection before closing it), and
defaults to 2592000 seconds.
* ConnectionPool uses it for "number of seconds to block and
wait for a connection before giving up and raising a timeout error",
default 5 seconds.
* ConnectionPool uses it for the Reaper, for deciding if a 'dead'
connection can be reaped. Default 5 seconds.
Previously, if you want to change these from defaults, you need
to change them all together. This is problematic _especially_
for the mysql2/ConnectionPool conflict, you will generally _not_
want them to be the same, as evidenced by their wildly different
defaults. This has caused real problems for people #6441 #2894
But as long as we're changing this, forcing renaming the
ConnectionPool key to be more specific, it made sense
to seperate the two ConnectionPool uses too -- these two
types of ConnectionPool timeouts ought to be able to be
changed independently, you won't neccesarily want them
to be the same, even though the defaults are (currently)
the same.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d2901f0fc4270a765717ad572d559dc49a56b3a8, reversing
changes made to 525839fdd8cc34d6d524f204528d5b6f36fe410c.
Conflicts:
activerecord/test/cases/connection_pool_test.rb
Reason: This change broke the build (http://travis-ci.org/#!/rails/rails/builds/1391490)
and we don't have any solution until now. I asked the author to try to
fix it and open a new pull request.
|
|
|
|
| |
These variables were issuing some "not used" warnings.
|
| |
|
| |
|