tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Whittington <>
Subject Re: svn commit: r1158991 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Date Wed, 16 Nov 2011 21:15:06 GMT
OK, finally getting time to have another look at this... summarises
the situation - basically the SHM filename used now is not unique
enough when there are multiple ISAPI Redirectors on a single website.
My current proposal is to use the extension_uri to distinguish between
the configurations (on the assumption that this will be the same on
every site in a web server farm).


On Thu, Aug 18, 2011 at 8:08 PM, Tim Whittington <> wrote:
> Yeah - not sure what I was smoking on that one.
> Have reverted for another think.
> The basic problem we have is that the shared memory code assumes a
> single worker configuration, and when you have multiple ISAPI
> Redirectors on a single IIS with different configs that goes a bit
> wonky. For a start, the SHM size is calculated by the first redirector
> to start (and so may be too small for the other one), and then there's
> the issue of the workers in the SHM not aligning.
> A possible solution might be a shm_config_name property that
> distinguishes one redirector config from another (that should be
> consistent across all processes).
> The redirector DLL path could be used instead if that was reliable - I
> don't know enough about IIS clusters to know if they span multiple
> machines.
> If anyone's got any other ideas I'd be interested.
> cheers
> tim
> On Thu, Aug 18, 2011 at 4:40 PM, Mladen Turk <> wrote:
>> On 08/18/2011 03:54 AM, wrote:
>>> Author: timw
>>> Date: Thu Aug 18 01:54:31 2011
>>> New Revision: 1158991
>>> URL:
>>> Log:
>>> Use the DLL handle to make the shared memory file name used by the ISAPI
>>> Redirector unique for each DLL - the redirector supports multiple instances
>>> per website, and without this multiple redirectors could access the same
>>> shared memory file, corrupting the contents (evident when LB workers are
>>> used on IIS 7).
>> Hmm, isn't that actually disabling the shared memory purpose?
>> There is no point to have shared memory if it can't be shared
>> across the processes.
>> Your change makes no sense to me, cause now the shared memory
>> is unique to each worker process which can be easily solved by
>> not using the shared memory at all.
>> IMHO if IIS7 corrupts the shared memory, we should find a way
>> to better synchronize the access to it from multiple
>> processes instead just making it unique to each process.
>> Regards
>> --
>> ^TM
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message