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 <mt...@apache.org> wrote: > On 08/18/2011 03:54 AM, t...@apache.org wrote: >> >> Author: timw >> Date: Thu Aug 18 01:54:31 2011 >> New Revision: 1158991 >> >> URL: http://svn.apache.org/viewvc?rev=1158991&view=rev >> 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: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
