Cassini-lib server stops responding when request count hits 0.


When using the cassini lib dll, the server stops responding after a certain amount of time.
Looking at the code we can see that CassiniServer.cs sets the timeout to 60 seconds:
_server = new Server(port, virtualPath, applicationPath, ipAddress,hostname, 60000);
In Server.cs, in DecrementRequestCount, if the timeout is > 0 and request count < 1, a timer is started:
    private void DecrementRequestCount()
        if (_requestCount < 1)
            _requestCount = 0;
            if (_timeoutInterval > 0)
                _timer = new Timer(TimeOut, null, _timeoutInterval, Timeout.Infinite);
However this timer is never stopped when a new request comes in, the timer reference is merely set to null:
private void IncrementRequestCount()
        _timer = null;
This means when request count hits 0 the server stops responding, whether or not a new request comes in.


Sky wrote Aug 27, 2010 at 7:18 PM

Request counting was implemented to enable auto shutdown in CI environments but is only relevant in out-of-process instances, e.g. external exe.

So this really should not be present in the .lib build and, truthfully, I was never happy with the way it was implemented.

Perhaps the utility of the feature is phantom and does not justify the complexity that is introduced and the resultant bugs, in any build.


The story that drove that 'feature' was a need, due to platform compilation issues or process separation needs, to use an exe to serve tests.

If I were to remove auto-shutdown, the least amount of compensation would be to enable explicit shutdown via WMI.

So, in the short term, request counting and auto-shutdown should be omitted from the .lib build, and in longer term a better strategy needs to be found for the .exe builds.

thanks for the feedback.

Sky wrote Aug 29, 2010 at 8:32 PM

Actually, My last comment accurately describes my feelings about request count, but is not relevant to the condition that you describe.

I misread your question.

CassiniServer is meant to be used in testing environment where the lifespan of a server is short.

The behavior you describe is by design. If a test fixture derived from CassiniDevServer does not receive a request within it's idle threshold, it is shut down.

This prevents test that break the test runner from creating zombie servers.

The behavior you describe is by design. It seems you may be misusing the class, most likely due to a lack in the documentation.

See [url:http://cassinidev.codeplex.com/wikipage?title=Using%20CassiniDev%20with%20unit%20testing%20frameworks%20and%20continuous%20integration&referringTitle=Documentation]

If you wish to host content in a persistent manner, you are better served using CassiniDev.lib and instantiating a CassiniDev.Server to your specs. You can use CassiniDevServer as an example of how to do this, less the idle time-out of course.

wrote Aug 29, 2010 at 8:37 PM

dugrless wrote Aug 30, 2010 at 12:03 AM

Regarding this being closed as "by design":

So, just to be clear: the fact that IncrementRequestCount does not stop the current timer, but instead sets it to null, leading to the fact that (as stated in the original bug report) "when request count hits 0 the server stops responding, WHETHER OR NOT a new request comes in"... this is by design!?

'Cause I have to say: that's a pretty bad design.

dugrless wrote Aug 30, 2010 at 12:53 AM

Sorry; that was more snarky than I'd intended. My point was simply that, irrespective of how CassiniDevServer is used, the timer code should stop the timer before setting it to null.

Sky wrote Aug 30, 2010 at 1:27 AM

this behavior is by design. CassiniDevServer is intended as a base for short lived test fixtures, as (briefly) shown in documentation.

Direct use of CassiniDev.Server is recommended for persistent hosting. The source of CassiniDevServer can be used as an example of how to do this. Less the idle-time shutdown which is what prompted this issue.

** Closed by Sky 8/29/2010 1:37 PM

Sky wrote Aug 30, 2010 at 1:27 AM

The bad code is not by design, the behavior, as I understood your question is.

I can see where you are getting at and you are correct. This will be corrected in the next push.

And don't worry about calling shitty code shitty code.

Sure, there can be more politic ways of pointing out binary idiocy but where's the fun in that?

As long as you are right, that is ;-)

Thanks for the bug.

wrote Aug 30, 2010 at 1:28 AM

Sky wrote Aug 30, 2010 at 3:11 AM

Try the latest in source and let me know how it works out.

wrote Sep 1, 2010 at 11:15 PM

dugrless wrote Feb 2, 2011 at 3:55 PM

Sorry it's taken me so long to get back to this; I didn't see that it was in the Sep release until just now.

I've looked at the latest code ( and the two methods referenced above seem to be exactly the same. Can you point me to the code that was changed?

Sky wrote Mar 19, 2011 at 10:07 AM

had a regression issue. expect changes to be reflected in next push/publish. Thanks for the heads up.

egecan wrote Apr 13, 2011 at 2:29 PM

Is there any developments on this issue? I don't want to add a "me too" comment, for sure but I need to know if there is a plan to get rid of idle shutdown in dll release.

klimmbimm wrote Feb 1, 2012 at 12:57 PM

Though it is mentioned at the latest source code release (http://cassinidev.codeplex.com/SourceControl/list/changesets) that this issue should be fixed, my compiled CassiniDev4-lib.dll stops responding after a while without requests.

Fiddler tells me: HTTP/1.1 502 Fiddler - Connection Failed
[Fiddler] The socket connection to localhost failed. <br /> Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigerte

What to do?

klimmbimm wrote Feb 2, 2012 at 2:55 PM

OK, I understood that the timout is a feature and not a bug. But how can I avoid any timeout of the server?

klimmbimm wrote Feb 3, 2012 at 12:22 PM

I opened a new discussion about this: http://cassinidev.codeplex.com/discussions/290617

wrote Feb 21, 2013 at 11:19 PM

wrote May 16, 2013 at 10:51 AM

wrote May 16, 2013 at 10:51 AM

wrote Jun 14, 2013 at 7:26 AM