CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Bug in IIS filter?

The user will see a blank web page. The filter will also report an error to the cosign log and to the Windows Event Log.

--Jarod Malestein

--On Friday, June 24, 2005 1:03 PM +1200 Brett Lomas <b.lomas@xxxxxxxxxxxxxx> wrote:

Hey David, and everyone.

My boos wanted me to ask what happens when this limit in used
connections is reached? What will the user see?



On Sat, 2005-06-04 at 01:02, Sweetman, David wrote: > 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 >

Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010