connection-pool: Connection pool built on top of resource-pool and streaming-commons.

[ bsd3, data, library, network ] [ Propose Tags ]

Connection poll is a family specialised resource pools. Currently package provides two variants:

  1. pool for TCP client connections,

  2. and pool for UNIX Sockets client connections.

This package is built on top of resource-pool and streaming-commons. The later allows us to use conduit-extra package for implementation of TCP or UNIX Sockets clients.

For examples and other details see documentation in Data.ConnectionPool module.


[Skip to Readme]
Versions [faq] 0.1.0.0, 0.1.1.0, 0.1.2.0, 0.1.2.1, 0.1.3, 0.2, 0.2.1, 0.2.2
Change log ChangeLog.md
Dependencies base (>=4.6 && <4.8), between (>=0.9.0.0), data-default-class (==0.0.*), monad-control (>=0.2.0.1), network (>=2.2.3), resource-pool (>=0.2.0.0 && <1), streaming-commons (>=0.1.3 && <0.1.6), time (>=1.0), transformers-base (>=0.4.2 && <0.5) [details]
License BSD-3-Clause
Copyright (c) 2014 Peter Trško
Author Peter Trško
Maintainer peter.trsko@gmail.com
Revised Revision 2 made by HerbertValerioRiedel at Wed Jan 20 21:43:02 UTC 2016
Category Data, Network
Home page https://github.com/trskop/connection-pool
Bug tracker https://github.com/trskop/connection-pool/issues
Source repo head: git clone git://github.com/trskop/connection-pool.git
this: git clone git://github.com/trskop/connection-pool.git(tag v0.1.1.0)
Uploaded by PeterTrsko at Wed Sep 10 17:06:40 UTC 2014
Distributions LTSHaskell:0.2.2, NixOS:0.2.2, Stackage:0.2.2
Downloads 4034 total (89 in the last 30 days)
Rating (no votes yet) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Hackage Matrix CI
Docs uploaded by user [build log]
All reported builds failed as of 2015-12-12 [all 1 reports]

Modules

[Index]

Flags

NameDescriptionDefaultType
pedantic

Pass additional warning flags including -Werror to GHC during compilation.

DisabledManual

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

Downloads

Note: This package has metadata revisions in the cabal description newer than included in the tarball. To unpack the package including the revisions, use 'cabal get'.

Maintainer's Corner

For package maintainers and hackage trustees


Readme for connection-pool-0.1.1.0

[back to package description]

Connection Pool

Hackage

Description

Connection poll is a family specialised resource pools. Currently package provides two

  1. pool for TCP client connections,
  2. and pool for UNIX Sockets client connections.

This package is built on top of resource-pool and streaming-commons. The later allows us to use conduit-extra package for implementation of TCP or UNIX Sockets clients.

Documentation

Stable releases with API documentation are available on Hackage

Examples

Simple code examples, including example from the following section, are available in example/ directory.

TCP Client Example

Here is a simple example that demonstrates how TCP client can be created and how connection pool behaves.

{-# LANGUAGE OverloadedStrings #-}
module Main (main)
  where

import Control.Monad (void)
import Control.Concurrent (forkIO, threadDelay)
import System.Environment (getArgs)

import Control.Lens ((.~), (&))
import Data.ConnectionPool
    ( createTcpClientPool
    , numberOfResourcesPerStripe
    , numberOfStripes
    , withTcpClientConnection
    )
import Data.Default.Class (Default(def))
import Data.Streaming.Network (appWrite, clientSettingsTCP)


main :: IO ()
main = do
    [port, numStripes, numPerStripe] <- getArgs
    pool <- createTcpClientPool
        (poolParams numStripes numPerStripe)
        (clientSettingsTCP (read port) "127.0.0.1")
    void . forkIO . withTcpClientConnection pool $ \appData -> do
       threadDelay 100
       appWrite appData "1: I'm alive!\n"
    void . forkIO . withTcpClientConnection pool $ \appData ->
       appWrite appData "2: I'm alive!\n"
  where
    poolParams m n =
        def & numberOfStripes .~ read m
            & numberOfResourcesPerStripe .~ read n

To test it we can use socat or some netcat like application. Our test will require two terminals, in one we will execute socat as a server listenting on UNIX socket and in the other one we execute above example.

Simple TCP server listening on port 8001 that prints what it receives to stdout:

$ socat TCP4-LISTEN:8001,bind=127.0.0.1,fork -

The fork parameter in the above example is important, otherwise socat would terminate when client closes its connection.

If we run above example as:

$ runghc tcp-example.hs 8001 1 1

We can see that socat received following text:

1: I'm alive!
2: I'm alive!

But if we increment number of stripes or number of connections (resources) per stripe, then we will get:

2: I'm alive!
1: I'm alive!

The reason for this is that we use threadDelay 100 in the first executed thread. So when we have only one stripe and one connection per stripe, then we have only one connection in the pool. Therefore when the first thread executes and acquires a connection, then all the other threads (the other one in above example) will block. If we have more then one connection available in our pool, then the first thread acquires connection, blocks on threadDelay call, but the other thread also acquires connection and prints its output while the first thread is still blocked on threadDelay. This example demonstrates how connection pool behaves if it reached its capacity and when it has onough free resources.

License

The BSD 3-Clause License, see LICENSE file for details.

Contributions

Contributions, pull requests and bug reports are welcome! Please don't be afraid to contact author using GitHub or by e-mail (see .cabal file for that).