<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to 4: JIComTransport fix for file descriptor leak</title><link>https://sourceforge.net/p/j-interop/patches/4/</link><description>Recent changes to 4: JIComTransport fix for file descriptor leak</description><atom:link href="https://sourceforge.net/p/j-interop/patches/4/feed.rss" rel="self"/><language>en</language><lastBuildDate>Fri, 06 Aug 2010 19:03:34 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/j-interop/patches/4/feed.rss" rel="self" type="application/rss+xml"/><item><title>JIComTransport fix for file descriptor leak</title><link>https://sourceforge.net/p/j-interop/patches/4/</link><description>I'm attaching a modified version of the JIComTransport class \(as well as a patch of the same\) that fixes the file descriptor leak we're seeing when blocking reads are down without specifically creating a Selector. As far as I can determine, the external
behavior of the class is unchanged.

I've testing this by running a new WMI request every 5 seconds in a new thread for 100 iterations. The file descriptor count has been constant, aside from a temporary increase when the read is actually occurring.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Robert Clark</dc:creator><pubDate>Fri, 06 Aug 2010 19:03:34 -0000</pubDate><guid>https://sourceforge.net42f54c3336717416991f8211bf987c74c81eb8f2</guid></item></channel></rss>