I've looked into this further and I believe the leaked connections are due to
Network.Browser, this is a separate issue from that identified by Paul Brown.
The BrowserState in Network.Browser has a connection pool of up to five
connections. When a sixth is opened the oldest connection is closed. This
looks to be the only time that a connection is closed.
BrowserState's internals are not exported so there is no way for a user to
close them.
The net effect for HXT is that every time readDocument is called, using native
http, a single TCP connection is leaked.
I've attached a patch against the darcs version of http that cures my test
programs leak.
Cheers
Daniel
New patches:
[Make browse close pooled connections to prevent them leaking.
'Daniel McAllansmith <[EMAIL PROTECTED]>'**20080411025515
The closing of the connections needs to be made exception safe. Should try to
close every connection before breaking out with an exception. Currently an
exception may allow connections to leak.
] {
hunk ./Network/Browser.hs 656
-browse act = do x <- lift act defaultBrowserState
- return (snd x)
+browse act = do (bs, x) <- lift act defaultBrowserState
+ closePooledConnections bs
+ return x
hunk ./Network/Browser.hs 675
+-- |
+-- Close all connections that are in bs' connection pool.
+-- This should have some sort of exception handling, soldier on until
+-- all the connections have been closed. Not sure about portability
+-- issues.
+closePooledConnections :: BrowserState -> IO ()
+closePooledConnections = mapM_ close . bsConnectionPool
+
}
Context:
[Bump version number to 3001.1.0. Incremented minor number since the patch from Eric Mertens extends the API.
[EMAIL PROTECTED]
[Export getRequestHead and processRequest, add support for custom RequestMethods
Eric Mertens <[EMAIL PROTECTED]>**20080305190759]
[Include uriQuery in request line.
[EMAIL PROTECTED]
[Send abs_path as Request-URI to comply with HTTP 1.1 spec.
'Daniel McAllansmith <[EMAIL PROTECTED]>'**20080128053024
RFC2616 Section 5.1.2 specifies that abs_path MUST be used to identify a resource on a origin server or gateway, not absoluteURI which is for use with proxies.
Change Request's Show instance to use /path/to/resource rather than
http://server/path/to/resource.
]
[Bump version to 3001.0.4
[EMAIL PROTECTED]
[Expose Network.HTTP.Headers in cabal file
Eric Mertens <[EMAIL PROTECTED]>**20071212220235
Failure to do this breaks :browse functionality in GHCi
as well as makes these useful functions unavailable
]
[Resolved conflicts in Network.Stream.
[EMAIL PROTECTED]
[Resolve conflict in HTTP.cabal.
[EMAIL PROTECTED]
[Split Header functionality into Network.HTTP.Headers module.
[EMAIL PROTECTED]
[Added files to .cabal file, made deps explicit in Network.TCP module.
[EMAIL PROTECTED]
[Refactored Network.Stream.
[EMAIL PROTECTED]
[Made more deps explicit.
[EMAIL PROTECTED]
[Made dependencies explicit in import statements.
[EMAIL PROTECTED]
[Bumped version number to 3001.0.3.
[EMAIL PROTECTED]
[Change myrecv to allow a 0 length. Suggested by Eric Mertens.
[EMAIL PROTECTED]
On Wed, 2007-08-15 at 23:25 +0200, Bjorn Bringert wrote:
Why doesn't the existing code work? Does recv fail when given 0?
On Nov 30, 2007, at 23:36 , Eric Mertens wrote:
Yes, recv can not cope with an argument of 0
http://darcs.haskell.org/packages/network/Network/Socket.hsc
recv :: Socket -> Int -> IO String
recv sock l = recvLen sock l >>= \ (s,_) -> return s
recvLen :: Socket -> Int -> IO (String, Int)
recvLen sock@(MkSocket s _family _stype _protocol status) nbytes
| nbytes <= 0 = ioError (mkInvalidRecvArgError "Network.Socket.recv")
]
[Set version number to 3001.0.2.
[EMAIL PROTECTED]
[Change version to 3001.0.1.
[EMAIL PROTECTED]
[Don't treat any chunk size starting with '0' as a 0 chunk size.
[EMAIL PROTECTED]
RadosÅaw Grzanka reported that Network.HTTP can't get http://www.podshow.com/feeds/gbtv.xml, see http://article.gmane.org/gmane.comp.lang.haskell.cafe/31783
This turned out to be a bug in how Network.HTTP handled Chunked Transfer Encoding. The web server sent the chunk size as "00004000" (according to RFC 2616 this can be non-empty sequence of hex digits). However, Network.HTTP treated any chunk size starting with '0' as a chunk size of 0, which indicates the end of the chunked encoding.
]
[TAG 3001.0.0
Duncan Coutts <[EMAIL PROTECTED]>**20071021133823]
Patch bundle hash:
2606de184a3abe46c8095959a11a2f60575ceada
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
