RE: Bug in IIS filter?

["Sweetman, David" <dsweetma@xxxxxxxxxxxx>]

Brett,

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
logons.

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.

David

-----Original Message-----
From: Brett Lomas [mailto:b.lomas@xxxxxxxxxxxxxx] 
Sent: Friday, June 03, 2005 12:33 AM
To: cosign-discuss
Subject: Bug in IIS filter?



Hi all,

I have noticed a possibly bug in the IIS filter. I have not had to
actually dig
into the code as yet, but thought I would email here to see if anyone
know about
it or has seen it.

When the filter does a check for a ticket, which hasn't been registered
before
(i.e. if one goes to the protected content for the first time, and then
goes to
the page again without signing in) the daemon returns a 533 status
(ticket not
in DB). The code (the bit i have looked at) return a 0 and essentially
will try
to look at other connections, but somewhere something is closing that
connection
for no good reason. (I can see this via tcpdump on the machine, as the
remote
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
connection
pool do? Does the module open that many connections to the each of the
server or
what??


Thanks heaps.


Brett

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/