Skip to content
This repository has been archived by the owner on Jan 15, 2024. It is now read-only.

Commit

Permalink
Rip out internal connection pooling.
Browse files Browse the repository at this point in the history
We do not need to guarantee thread affinity so the complexity of the
internal connection pool and reaper is no longer needed. We simply now
just use the connection_pool gem.
  • Loading branch information
durran committed Dec 2, 2013
1 parent 861426c commit 307cb8f
Show file tree
Hide file tree
Showing 11 changed files with 40 additions and 830 deletions.
3 changes: 0 additions & 3 deletions lib/moped/connection.rb
Original file line number Diff line number Diff line change
@@ -1,8 +1,5 @@
# encoding: utf-8
require "moped/connection/manager"
require "moped/connection/pool"
require "moped/connection/queue"
require "moped/connection/reaper"
require "moped/connection/sockets"

module Moped
Expand Down
37 changes: 35 additions & 2 deletions lib/moped/connection/manager.rb
Original file line number Diff line number Diff line change
@@ -1,4 +1,6 @@
# encoding: utf-8
require "connection_pool"

module Moped
class Connection

Expand All @@ -11,6 +13,12 @@ module Manager
# Used for synchronization of pools access.
MUTEX = Mutex.new

# The default max size for the connection pool.
POOL_SIZE = 5

# The default timeout for getting connections from the queue.
TIMEOUT = 0.5

# Get a connection pool for the provided node.
#
# @example Get a connection pool for the node.
Expand All @@ -23,13 +31,38 @@ module Manager
# @since 2.0.0
def pool(node)
MUTEX.synchronize do
pools[node.address.resolved] ||=
Pool.new(node.address.ip, node.address.port, node.options)
pools[node.address.resolved] ||= create_pool(node)
end
end

private

# Create a new connection pool for the provided node.
#
# @api private
#
# @example Get a connection pool for the node.
# Manager.create_pool(node)
#
# @param [ Node ] node The node.
#
# @return [ ConnectionPool ] A connection pool.
#
# @since 2.0.0
def create_pool(node)
ConnectionPool.new(
size: node.options[:pool_size] || POOL_SIZE,
timeout: node.options[:pool_timeout] || TIMEOUT
) do
Connection.new(
node.address.ip,
node.address.port,
node.options[:timeout] || Connection::TIMEOUT,
node.options
)
end
end

# Get all the connection pools. This is a cache that stores each pool
# with lookup by it's resolved address.
#
Expand Down
209 changes: 0 additions & 209 deletions lib/moped/connection/pool.rb

This file was deleted.

94 changes: 0 additions & 94 deletions lib/moped/connection/queue.rb

This file was deleted.

Loading

4 comments on commit 307cb8f

@arthurnn
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😿

@brndnblck
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How you do this isn't a hard requirement, but the spec for all drivers does require that you can read your own writes for the same thread of execution even when using an unacknowledged write-concern level.

Last I checked, the connection_pool gem doesn't guarantee this. Has something changed?

@brndnblck
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ruby driver uses thread affinity to ensure the ability read-your-own-writes and while I'm not 100% against this approach, its also been the source of many nasty bugs for us. I'm not sure we'll take the same approach in our 2.0 driver.

The Python driver "solved" (I feel like they cheated a bit since its not default pooling behavior) by adding a client.start_request() method that you explicitly call before performing a given set of operations where you know you need this behavior.

http://emptysqua.re/blog/read-your-writes-consistency-pymongo/

In any case though, I don't think the connection_pool gem alone will satisfy all the requirements you need. This isn't generally an issue if you're using at least w=1 but its still a requirement to provide the ability to read back writes for w=0.

This may also be an issue for you:

There is no provision for repairing or checking the health of a connection; connections should be self-repairing.

@robertjpayne
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with brandonblack and there are more use cases for thread affinity connections as well. See #245 as well for TokuMX support though I know that will be a much smaller audience.

Please sign in to comment.