cosign-discuss at umich.edu
general discussion of cosign development and deployment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bug in IIS filter?
Regarding your question on the connection pool size:
This number determines the number of connections established between the
IIS Server and the central CoSign server for the purpose of verifying
When I conducted load testing on IISCosign a couple years ago, I found
this to be the single most important setting related to server load. A
greater number of connections are needed for a greater number of
concurrent users. In our testing, a connection pool setting of 23 was
needed to handle 500 users authenticating in a ~5 minute period.
From: Brett Lomas [mailto:b.lomas@xxxxxxxxxxxxxx]
Sent: Friday, June 03, 2005 12:33 AM
Subject: Bug in IIS filter?
I have noticed a possibly bug in the IIS filter. I have not had to
into the code as yet, but thought I would email here to see if anyone
it or has seen it.
When the filter does a check for a ticket, which hasn't been registered
(i.e. if one goes to the protected content for the first time, and then
the page again without signing in) the daemon returns a 533 status
in DB). The code (the bit i have looked at) return a 0 and essentially
to look at other connections, but somewhere something is closing that
for no good reason. (I can see this via tcpdump on the machine, as the
peer port changes when this happens).
Of course, this mean the next connection then suffers the penalty of the
connection being established again.
Also a quick question, what does the connection pool size and the
pool do? Does the module open that many connections to the each of the
This mail sent through University of Auckland