Re: [JK] Shared memory design problems
On 03/30/2012 10:16 PM, Le Huy wrote: Have you look at how mod_proxy solves this issue, it seems that it does not suffer the problem that we are experiencing , and also does not need any share memory file. ... it uses shared memory (scoreboard in 2.0 and 2.2, mod_slotmem in 2.4) ... and it sucks ;) ... and it doesn't even support graceful restarts (all runtime data is lost) ... and its for httpd. Our shm was designed when there were no things like IIS workers, so its time to adapt the technology. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [JK] Shared memory design problems
Have you look at how mod_proxy solves this issue, it seems that it does not suffer the problem that we are experiencing , and also does not need any share memory file. On Wed, Mar 28, 2012 at 2:32 PM, Mladen Turk wrote: > On 03/28/2012 02:01 PM, jean-frederic clere wrote: >> >> What about a look on file that contains the id? It gets created and lock >> by the first worker that needs the shared memory and writes the id inside >> and unlock the file? Other workers will just read the id in the file. >> > > I started to work on 'get by id' record/slot concept. > There are many advantages over the 'presume we have a correct order' > > Currently if someone reorders worker list everything breaks apart > or at least gets overwritten by something else. > > The idea is that instead going trough worker/member list and > allocate next free slot, we actually search if the object with > the same id (combination of name, type and parent) exists and > if not then actually create a new shm record. > > This would mean that jk_shm_alloc_xxx won't reset data on > each restart (done by single proc in httpd and multiple in IIS) > Thus the sequence will actually be what it is: config update. > > > 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
Re: [JK] Shared memory design problems
On 03/28/2012 02:01 PM, jean-frederic clere wrote: What about a look on file that contains the id? It gets created and lock by the first worker that needs the shared memory and writes the id inside and unlock the file? Other workers will just read the id in the file. I started to work on 'get by id' record/slot concept. There are many advantages over the 'presume we have a correct order' Currently if someone reorders worker list everything breaks apart or at least gets overwritten by something else. The idea is that instead going trough worker/member list and allocate next free slot, we actually search if the object with the same id (combination of name, type and parent) exists and if not then actually create a new shm record. This would mean that jk_shm_alloc_xxx won't reset data on each restart (done by single proc in httpd and multiple in IIS) Thus the sequence will actually be what it is: config update. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [JK] Shared memory design problems
What about a look on file that contains the id? It gets created and lock by the first worker that needs the shared memory and writes the id inside and unlock the file? Other workers will just read the id in the file. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
