https://issues.apache.org/bugzilla/show_bug.cgi?id=52659
Bug #: 52659
Summary: Shared memory becomes corrupted
Product: Tomcat Connectors
Version: 1.2.32
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: isapi
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
Hi
my platform
IIS7.5 on W2008R2 sp1 (thre are 2 setup in a NLB config)
1.2.32 64 connector
Connecting to 6.2Final Jboss
We have a client programme that opens a connection and uses keep alive to keep
the connection open. We typically have 200-300 connections open at one time.
Our application pool on IIS was setup in a web garden mode, so for use that
mean there was 4 process ids for the virtual web site the plugin was connected
to.
So when we had a manual recycle happen all hell broke lose, the client were
getting 500's back from the server. for any page that was related to the
virtual web site... it would fail at the filter entry point. looks like the
connector had become corrupt and was failing everything.
So from some investigating we fix it by moving to pessimistic locking .... and
changing to non overlapping recycles.
we fixed opp locking is really for single processes + multi threading not multi
processes and multithreads!
I am not 100% sure why the over lapping recycle failed and I believe corrupted
the shm memory but i believe it has something to do with IIS restarting the
application pool and I presume with the shared memory block.
We saw that the error became exasperated when there were more clients
attempting to connect. if there was only 20-40 clients, no problem it
worked... but 200 and it went haywire.
one interesting test we did was to reboot one node of the NLB cluster, and when
it restared it went straight into 500 mode, because 200 client were trying to
connect.
Can you some how make the option for the connection to default to pessimistic
mode instead of op.. This i think might be the problem with the over lapping
recycle
Alex
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
