Comment 1 for bug 649171

About the new version
~~~~~~~~~~~~~~~~~

There are many new useful features and important rewrites in 0.91. After some silent coding and polishing support for more OS's in early 2010, I spent two months adding new features, testing and fixing based on user requests and feedback. Though I still have some new features on my TODO list, they must wait, because the inferior 0.35.1 has been around for too long and 0.91 is a long time ready. Now I'm going to mark 0.91rc6 stable, because at this point, it's been used in various production environments for half a year without a single issue reported.

Current stable 0.35.1 had some unnecessary limits, had issues with HTTP protocol abuse by certain Java libraries talking through MS ISA and altogether didn't handle some unusual corner cases well. I strongly recommend upgrading to the upcoming 0.91.

Couple of words about 0.35.1 stability
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Current stats from a random Cntlm server: IBM pSeries 560 (64bit/big-endian AIX6.1, 6x 3.6GHz POWER6 CPU, 8GB RAM). Apart from actual production, it's also used for accessing Internet from some prod-net non-Windows terminals and for downloading huge installation media and updates directly from the clusters.

# uptime
  12:13PM up 449 days, 23:04, 6 users, load average: 2.84, 2.45, 2.17

# ps aux | grep [c]ntlm
cntlm 5243088 0.0 0.0 2368 884 - A Jun 02 9:49 cntlm -U cntlm -P /var/run/cntlm/cntlmd.pid

# perl -MDate::Calc=Delta_Days -e 'printf "Sep 28 - Jun 02 = %d days\n", Delta_Days(2010,6,2, 2010,9,28)'
Sep 28 - Jun 02 = 118 days

This is the old 0.35.1, mind you: used by tens of users for about 4 months - mainly for http(s) browsing and some permanent, auto-reconnect SSH port forwarding sessions to outside the corporate proxy via Tunnel directives. There were never any restarts required to fix anything.

As I only suspend to RAM, my notebook has currently 49 days uptime (usually ~60) and I use Cntlm in corporate networks heavily: browsing, FTP uploading, Usenet, SSH tunnelling, VPN, VoIP, etc.

If there are cases where users feel that a restart is required, I'd really appreciate some reports and details. Try running Cntlm in verbose mode with a trace file and when a problem occurs, isolate it from the trace and send it to me. When I don't learn about your issue, I cannot help you prevent it.

Sometimes people mail me (or submit a request on SF.net) about some issue and how they're forced to restart, but every single time, after analysing the issue, the cause is confirmed to be the client application and/or the parent proxy's policy.

Regards,
David Kubicek