RE: jk2 buglets
> -Original Message- > From: [EMAIL PROTECTED] > > > Assuming that the next mod_jk2 release wants to go with > the present > > > APR > > > (0.94) or even the CVS (pre 1.0?) then we need to kludge > mod_jk on > > > solaris 8 (at least) to not use APR for this bit. > > > > > > > No it's gonna be 0.95 (the one distributed with httpd-2.0.48) > > This has yet to be released as a standalone package (latest > is 0.94) CVS version number is now up to 1.0. > > Where does that leave Apache 1.3 users? > Yes, I forgot that. 0.95 for Apache2 and 0.94 for the 1.3. > > Can we not add a !define to exclude using APR for the shm on > solaris, until APR is fixed? > You can do that during building APR, so apr.h will lack the APR_HAS_SHMEM and the jk2_shm will not be compiled. No need to put that in the jk2. One might compile the apr from CVS, which might work. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> -Original Message- > From: Guenter Knauf > > > If it's a APR bug are there any patches that we can propose? > no. > The problem is the NetWare OS self. We had formerly no SHM > > > The netware, and windows doesn't need shm at all. > that's not true from APR sight: if I look into apr.h for > NetWare I have not one define for SHM, but looking at apr.h Look, the shm in jk2 is _eventually_ needed only on multi-child mpm's which netware isn't, so why all the fuzz? > I really would like to have APR_HAS_MMAP on NetWare since a > couple of other interesting modules rely on it; and be sure > that I bother them at Novell enough with this. > Cool :-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi, >> > Also, we adopted the APR as mandatory, so, all platform >> specific code >> > except JNI has to go out (sooner or later). >> sure, I know - but you cant expect that every APR also >> supports SHM/MMAP; so cant we take only those things which >> are common to all platforms? > Does it work in APR from CVS? no. > If not then it's a bug in APR. no. > If it's a APR bug are there any patches that we can propose? no. The problem is the NetWare OS self. We had formerly no SHM support at all on NetWare, and since about a year we got mmap() silently, but with EXPERIMENTAL status. Since we ship recent NetWare versions with Apache (1.3 with NW6 and 2.0 with NW6.5) I cant introduce another Apache with experimental stuff in it - instead I have to rely on what's officially released - NW admins are just used to fetch a binary and drop it in, they have no plan of recompiling Apache, nor they are able to do even if they would like since NetWare doesnt ship with a compiler at all. > The netware, and windows doesn't need shm at all. that's not true from APR sight: if I look into apr.h for NetWare I have not one define for SHM, but looking at apr.h from Win32 platform I can see: #define APR_HAS_SHARED_MEMORY 1 #define APR_HAS_MMAP 1 > The final solution would be adding jk2_shm_ (for specific platform), > inside commons/arch. > I'm not in favor of using #defines to solve that. +1. > If the number of needed platform specific workarounds is too high, then we > made a mistake switching to APR, but I doubt. no, the switch is OK, but it was probably only too early to make it mandatory. I would have left the old code in; it was known to work, and didnt bite someone; and at least for Apache 1.3 I'm not happy with the change to APR. If I had choosen to make APR mandatory I also would have dropped Apache 1.3 support at all from mod_jk2. > Let's make and test, and then we'll see how to solve the particular > problem for a XXX.XXX platform. what we all need is time - those working at APR, as well as the OS core folks - I'm sure all these things will be fixed sooner or later, but unless Apache 2.x gets widely accepted there will not be so much pressure to fix those things I feel I'm next month at Novell and will certainly discuss this issue with the core OS team - after that I hope I have an idea if we get mmap() and friends exported by the OS officially, and how long it may take. I really would like to have APR_HAS_MMAP on NetWare since a couple of other interesting modules rely on it; and be sure that I bother them at Novell enough with this. Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> > -Original Message- > > From: [EMAIL PROTECTED] > > > > Assuming that the next mod_jk2 release wants to go with the > > present APR > > (0.94) or even the CVS (pre 1.0?) then we need to kludge > > mod_jk on solaris 8 (at least) to not use APR for this bit. > > > > No it's gonna be 0.95 (the one distributed with httpd-2.0.48) This has yet to be released as a standalone package (latest is 0.94) CVS version number is now up to 1.0. Where does that leave Apache 1.3 users? > > I was going to add an && defined(foo) to the APR defined > > lines, however I do not know the right foo to add __sun seems > > too broad. The next more complex fix is to alter the > > Makefile with a -d. > > > > What do people think? > > > > Look at my today post (JK2 shm). > It's going to use the shm. > If the platform is missing APR_HAS_SHARED_MEMORY the shm will > be disabled. > Also you can alway set the shm to disabled if the APR platform MMAP is > buggy. Which at the moment is Solaris based Apache 1.3 users. Can we not add a !define to exclude using APR for the shm on solaris, until APR is fixed? Otherwise we need to document this "feature" for all those people who might want to build mod_jk2 on solaris for apache 1.3.x which is not easy for many people. IMHO much better to have a release that works (even with work arrounds) than one that requires furthur fettling, often by people who have no idea what they are doing. Greg > > MT. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 buglets
[EMAIL PROTECTED] wrote: -Original Message- From: Mladen Turk [mailto:[EMAIL PROTECTED] In case of single child mpm, nothing. On others, jkstatus at least. Also, we adopted the APR as mandatory, so, all platform specific code except JNI has to go out (sooner or later). MT. That is fine, assuming that APR works on all platforms. Which presently is not the case. It's should (and will) be fixed by APR team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> -Original Message- > From: Mladen Turk [mailto:[EMAIL PROTECTED] > > In case of single child mpm, nothing. > On others, jkstatus at least. > > Also, we adopted the APR as mandatory, so, all platform > specific code except > JNI has to go out (sooner or later). > > MT. That is fine, assuming that APR works on all platforms. Which presently is not the case. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> -Original Message- > From: Guenter Knauf > >> but what will we all loose if then the scoreboard isnt active?? > >> > > > In case of single child mpm, nothing. > > On others, jkstatus at least. > so the scoreboard is only for collecting stats? > And for load balancing stats. > > Also, we adopted the APR as mandatory, so, all platform > specific code > > except JNI has to go out (sooner or later). > sure, I know - but you cant expect that every APR also > supports SHM/MMAP; so cant we take only those things which > are common to all platforms? Does it work in APR from CVS? If not then it's a bug in APR. If it's a APR bug are there any patches that we can propose? > I mean, I see there's a workaround for HPUX, so why not a > workaround for NetWare and Solaris and whatever else platform > with broken shm too? Apache2 works without shm/mmap in > general, so it would be fine if mod_jk2 doesnt expect more > than Apache2 from APR > The netware, and windows doesn't need shm at all. There is one child process, so all the data is available to each worker thread. All the workarounds has to go out, except the platform specific channels. The final solution would be adding jk2_shm_ (for specific platform), inside commons/arch. I'm not in favor of using #defines to solve that. If the number of needed platform specific workarounds is too high, then we made a mistake switching to APR, but I doubt. Let's make and test, and then we'll see how to solve the particular problem for a XXX.XXX platform. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi Mladen, >> but what will we all loose if then the scoreboard isnt active?? >> > In case of single child mpm, nothing. > On others, jkstatus at least. so the scoreboard is only for collecting stats? > Also, we adopted the APR as mandatory, so, all platform specific code > except JNI has to go out (sooner or later). sure, I know - but you cant expect that every APR also supports SHM/MMAP; so cant we take only those things which are common to all platforms? I mean, I see there's a workaround for HPUX, so why not a workaround for NetWare and Solaris and whatever else platform with broken shm too? Apache2 works without shm/mmap in general, so it would be fine if mod_jk2 doesnt expect more than Apache2 from APR Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 buglets
In my apache 2.0.48 install the version of apr is 0.95. Glenn On Mon, Mar 01, 2004 at 05:04:17PM -, [EMAIL PROTECTED] wrote: > > > > -Original Message- > > From: Guenter Knauf [mailto:[EMAIL PROTECTED] > > Sent: 27 February 2004 16:13 > > To: [EMAIL PROTECTED] > > Subject: RE: jk2 buglets > > > > > > hmm, you could check to use the old mmap code which Henri > > just has checked in again; get latest jk_shm.c from cvs and > > modifiy it to ignore APR_HAS_MMAP and use HAVE_MMAP instead; > > if that works then we know for sure that APR mmap supportg is > > somehow broken on Solaris, and you have to ask in the apr > > group for a fix... > > > > Guenter. > > Good call. Ignoring APR results in an so that starts and responds > apparently without error. > > Assuming that the next mod_jk2 release wants to go with the present APR > (0.94) or even the CVS (pre 1.0?) then we need to kludge mod_jk on solaris 8 > (at least) to not use APR for this bit. > > I was going to add an && defined(foo) to the APR defined lines, however I do > not know the right foo to add __sun seems too broad. The next more complex > fix is to alter the Makefile with a -d. > > What do people think? > > Thanks Guenter. > > Greg > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> -Original Message- > From: Guenter Knauf > > Look at my today post (JK2 shm). > > It's going to use the shm. > > If the platform is missing APR_HAS_SHARED_MEMORY the shm > will be disabled. > > Also you can alway set the shm to disabled if the APR > platform MMAP is > > buggy. > > but what will we all loose if then the scoreboard isnt active?? > In case of single child mpm, nothing. On others, jkstatus at least. Also, we adopted the APR as mandatory, so, all platform specific code except JNI has to go out (sooner or later). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi, > Look at my today post (JK2 shm). > It's going to use the shm. > If the platform is missing APR_HAS_SHARED_MEMORY the shm will be disabled. > Also you can alway set the shm to disabled if the APR platform MMAP is > buggy. but what will we all loose if then the scoreboard isnt active?? Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> -Original Message- > From: [EMAIL PROTECTED] > > Assuming that the next mod_jk2 release wants to go with the > present APR > (0.94) or even the CVS (pre 1.0?) then we need to kludge > mod_jk on solaris 8 (at least) to not use APR for this bit. > No it's gonna be 0.95 (the one distributed with httpd-2.0.48) > I was going to add an && defined(foo) to the APR defined > lines, however I do not know the right foo to add __sun seems > too broad. The next more complex fix is to alter the > Makefile with a -d. > > What do people think? > Look at my today post (JK2 shm). It's going to use the shm. If the platform is missing APR_HAS_SHARED_MEMORY the shm will be disabled. Also you can alway set the shm to disabled if the APR platform MMAP is buggy. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> -Original Message- > From: Guenter Knauf [mailto:[EMAIL PROTECTED] > Sent: 27 February 2004 16:13 > To: [EMAIL PROTECTED] > Subject: RE: jk2 buglets > > > hmm, you could check to use the old mmap code which Henri > just has checked in again; get latest jk_shm.c from cvs and > modifiy it to ignore APR_HAS_MMAP and use HAVE_MMAP instead; > if that works then we know for sure that APR mmap supportg is > somehow broken on Solaris, and you have to ask in the apr > group for a fix... > > Guenter. Good call. Ignoring APR results in an so that starts and responds apparently without error. Assuming that the next mod_jk2 release wants to go with the present APR (0.94) or even the CVS (pre 1.0?) then we need to kludge mod_jk on solaris 8 (at least) to not use APR for this bit. I was going to add an && defined(foo) to the APR defined lines, however I do not know the right foo to add __sun seems too broad. The next more complex fix is to alter the Makefile with a -d. What do people think? Thanks Guenter. Greg > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi Greg, > Same sort of issue: > [Fri Feb 27 15:12:08 2004] (error ) [jk_shm.c (163)] shm.create(): error > creating /tmp/cr.sandwich.pfizer.com_81.shm 2117992 22 0x1f5020 Invalid > argument > [Fri Feb 27 15:12:08 2004] (error ) [jk_shm.c (238)] shm.create(): error > mmapping /tmp/cr.sandwich.pfizer.com_81.shm > ( 22 = Invalid argument ) > Ideas? hmm, you could check to use the old mmap code which Henri just has checked in again; get latest jk_shm.c from cvs and modifiy it to ignore APR_HAS_MMAP and use HAVE_MMAP instead; if that works then we know for sure that APR mmap supportg is somehow broken on Solaris, and you have to ask in the apr group for a fix... Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> > /* First make sure the file exists and is big enough > */ > rc=apr_file_open( &file, shm->fname, > APR_READ | APR_WRITE | APR_CREATE | APR_BINARY, > APR_WREAD|APR_WWRITE|APR_WEXECUTE, > globalShmPool); Thanks Guenter, Same sort of issue: [Fri Feb 27 15:12:08 2004] (error ) [jk_shm.c (163)] shm.create(): error creating /tmp/cr.sandwich.pfizer.com_81.shm 2117992 22 0x1f5020 Invalid argument [Fri Feb 27 15:12:08 2004] (error ) [jk_shm.c (238)] shm.create(): error mmapping /tmp/cr.sandwich.pfizer.com_81.shm ( 22 = Invalid argument ) Ideas? Come Monday I'll have a rummage in jk_shm.c and apr. Greg > > Guenter. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi, > Permissions should be ok. It does create a file, but with 0 size (even > though we have set something like 16m) > ie: > -rw-r--r-- 1 root other 0 Feb 27 12:31 > cr.sandwich.pfizer.com_81.shm > Compared to the old version (same config bar the name and old conector > used) > -rwxr-xr-x 1 root root 1000448 Feb 24 11:14 shm.file hmm, seems not so ok to me; I believe the init creates the file, and the child cant access it... can you please try to change the file open in jk_shm.c at line 100 and test if it perhaps fixes the issue? /* First make sure the file exists and is big enough */ rc=apr_file_open( &file, shm->fname, APR_READ | APR_WRITE | APR_CREATE | APR_BINARY, APR_WREAD|APR_WWRITE|APR_WEXECUTE, globalShmPool); Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> -Original Message- > From: Guenter Knauf [mailto:[EMAIL PROTECTED] > Sent: 27 February 2004 13:20 > To: [EMAIL PROTECTED] > Subject: RE: jk2 buglets > > > Hi Greg, > >> look at your apr.h for APR_HAS_MMAP and tell us how this is set... > > > #define APR_HAS_MMAP 1 > > thats strange. Is is possible that there's a permission issue > with creating the file? > Can you please try to configure the shm file to be created in > a public writable dir, f.e. /tmp or such? Permissions should be ok. It does create a file, but with 0 size (even though we have set something like 16m) ie: -rw-r--r-- 1 root other 0 Feb 27 12:31 cr.sandwich.pfizer.com_81.shm Compared to the old version (same config bar the name and old conector used) -rwxr-xr-x 1 root root 1000448 Feb 24 11:14 shm.file Greg > > Guenter. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi Greg, >> look at your apr.h for APR_HAS_MMAP and tell us how this is set... > #define APR_HAS_MMAP 1 thats strange. Is is possible that there's a permission issue with creating the file? Can you please try to configure the shm file to be created in a public writable dir, f.e. /tmp or such? Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
> Hi, > > Testing the jk2-2.0.3 cvs we seem to get this error, which > makes 2.0.3-dev > > useable for us. > you mean 2.0.4-dev? > > > I can only assume others are not seeing this (apache 1.3.26 > + mod_perl) on > > Solaris 2.8 (sparc). Has anyone had any success with 1.3.x > on Solaris > > with the jk2-dev code? > > look at your apr.h for APR_HAS_MMAP and tell us how this is set... #define APR_HAS_MMAP 1 Thanks Guenter. Greg > > Guenter. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi, > Testing the jk2-2.0.3 cvs we seem to get this error, which makes 2.0.3-dev > useable for us. you mean 2.0.4-dev? > I can only assume others are not seeing this (apache 1.3.26 + mod_perl) on > Solaris 2.8 (sparc). Has anyone had any success with 1.3.x on Solaris > with the jk2-dev code? look at your apr.h for APR_HAS_MMAP and tell us how this is set... Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Dear All, Testing the jk2-2.0.3 cvs we seem to get this error, which makes 2.0.3-dev useable for us. I can only assume others are not seeing this (apache 1.3.26 + mod_perl) on Solaris 2.8 (sparc). Has anyone had any success with 1.3.x on Solaris with the jk2-dev code? I an getting apr and apr-utils from CVS to see it this helps, otherwise I'll get acquainted with apr/shm and jk_shm.c! Greg [Fri Feb 27 09:58:28 2004] (error ) [jk_shm.c (233)] shm.create(): error mmapping /tmp/cr.sandwich.pfizer.com_81.shm [Fri Feb 27 09:58:28 2004] (error ) [jk_shm.c (158)] shm.create(): error creating /tmp/cr.sandwich.pfizer.com_81.shm 0 22 0x44e020 Invalid argument [Fri Feb 27 09:58:28 2004] (error ) [jk_shm.c (233)] shm.create(): error mmapping /tmp/cr.sandwich.pfizer.com_81.shm --- ab started [Fri Feb 27 09:59:21 2004] (error ) [jk_shm.c (350)] shm.createSlot() no shared memory head [Fri Feb 27 09:59:21 2004] (error ) [jk_endpoint.c (49)] workerEnv.init() create slot epStat.0 failed [Fri Feb 27 09:59:29 2004] (error ) [jk_shm.c (350)] shm.createSlot() no shared memory head - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
Dues to the environment the word "upgrade" tends to send shivers down some of my team! We have a strict complaince system to work under. This is not just a tomcat issue, but an Opensource issue where bug fixes are released as "upgrades". Most vendors release patches so that an existing version can continued to be used. Which is our case is handy. We might look at 4.1.3x in a few months depending on issues with 4.1.29. Thanks anyway! Greg > -Original Message- > From: David Rees [mailto:[EMAIL PROTECTED] > Sent: 26 February 2004 19:33 > To: [EMAIL PROTECTED] > Subject: RE: jk2 buglets II > > > [EMAIL PROTECTED] wrote: > > > > This seemed to be an issue with tomcat 4.1.24. > > > > Using 4.1.29 resolves this issue. > > > > Thanks for the pointers, especially the one to open my eyes > and check > > which tomcat version I was using. > > While you're at it, you should upgrade to 4.1.30 which fixes > some memory > leaks and other minor issues which could crop up as well. > > -Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
I tried that, but Solaris (8) diff does not support unified diff's (according to my Solaris 8 man page), but in the interests of unity: --- jk_shm.c.org2004-02-23 14:40:01.0 + +++ jk_shm.c2004-02-26 11:03:38.0 + @@ -198,7 +198,7 @@ env->l->jkLog(env, env->l, JK_LOG_ERROR, "shm.create(): error creating %s %d %d %#lx %s\n", - shm->fname, finfo.size, rc, globalShmPool, error ); + shm->fname, (int) finfo.size, rc, (int) globalShmPool, error ); shm->privateData=NULL; return rc; } Greg > -Original Message- > From: Guenter Knauf [mailto:[EMAIL PROTECTED] > Sent: 26 February 2004 11:32 > To: [EMAIL PROTECTED] > Subject: RE: jk2 buglets > > > Hi, > > > Sorry, this seems to be a bad week. > > > The diff should be: > > > $ diff jk_shm.c.org jk_shm.c > can you please use unified diffs: > > diff -u jk_shm.c.org jk_shm.c > > this is the preferred patch form with all ASF stuff... > > Guenter. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
[EMAIL PROTECTED] wrote: > > This seemed to be an issue with tomcat 4.1.24. > > Using 4.1.29 resolves this issue. > > Thanks for the pointers, especially the one to open my eyes and check > which tomcat version I was using. While you're at it, you should upgrade to 4.1.30 which fixes some memory leaks and other minor issues which could crop up as well. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi, > Sorry, this seems to be a bad week. > The diff should be: > $ diff jk_shm.c.org jk_shm.c can you please use unified diffs: diff -u jk_shm.c.org jk_shm.c this is the preferred patch form with all ASF stuff... Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Sorry, this seems to be a bad week. The diff should be: $ diff jk_shm.c.org jk_shm.c 201c201 < shm->fname, finfo.size, rc, globalShmPool, error ); --- > shm->fname, (int) finfo.size, rc, (int) globalShmPool, error ); Greg > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 26 February 2004 10:45 > To: [EMAIL PROTECTED] > Subject: RE: jk2 buglets > > > Hi All, > > We have been giving the latest CVS code for mod_jk2 a > thorough test to look > towards using it as our next production release. > > Happy to say that thus far it seems fine. > > The following still looks like a bug to me so I have attached > a diff (not > huge) of jakarta-tomcat-connectors/jk/native2/jk_shm.c : > > $ diff jk_shm.c jk_shm.c.org > 201c201 > < shm->fname, (int) finfo.size, rc, (int) > globalShmPool, error ); > --- > > shm->fname, finfo.size, rc, > globalShmPool, error ); > > finfo.size needs to be cast to an int avoid a stack overflow, > as on a lot of > platforms finfo.size and globalShmPool can be longs on > solaris hosts that > have large file support or 64bit mode. These are derived > from size_t in > /usr/include/sys/types.h (used by APR). > > I would have thought that the AMD opteron's might have the same issue. > > Does the above make sense? > > Could someone agree/disagree and commit/not commit appropriately. > > Thanks. > > Greg > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: 23 February 2004 16:32 > > To: [EMAIL PROTECTED] > > Subject: jk2 buglets > > > > > > Hi All, > > > > We have been running into different issues with jk2 > > concerning shared memory > > (on Solaris 8) > > > > Calls to the function jk2_shm_create fail logging the > following in the > > jk2.log file, > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets
Hi All, We have been giving the latest CVS code for mod_jk2 a thorough test to look towards using it as our next production release. Happy to say that thus far it seems fine. The following still looks like a bug to me so I have attached a diff (not huge) of jakarta-tomcat-connectors/jk/native2/jk_shm.c : $ diff jk_shm.c jk_shm.c.org 201c201 < shm->fname, (int) finfo.size, rc, (int) globalShmPool, error ); --- > shm->fname, finfo.size, rc, globalShmPool, error ); finfo.size needs to be cast to an int avoid a stack overflow, as on a lot of platforms finfo.size and globalShmPool can be longs on solaris hosts that have large file support or 64bit mode. These are derived from size_t in /usr/include/sys/types.h (used by APR). I would have thought that the AMD opteron's might have the same issue. Does the above make sense? Could someone agree/disagree and commit/not commit appropriately. Thanks. Greg > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 23 February 2004 16:32 > To: [EMAIL PROTECTED] > Subject: jk2 buglets > > > Hi All, > > We have been running into different issues with jk2 > concerning shared memory > (on Solaris 8) > > Calls to the function jk2_shm_create fail logging the following in the > jk2.log file, > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
Thanks Dave, This seemed to be an issue with tomcat 4.1.24. Using 4.1.29 resolves this issue. Thanks for the pointers, especially the one to open my eyes and check which tomcat version I was using. Feel a bit of a muppet! Greg > -Original Message- > From: David Rees [mailto:[EMAIL PROTECTED] > Sent: 23 February 2004 21:43 > To: Tomcat Developers List > Subject: RE: jk2 buglets II > > > On Mon, February 23, 2004 1at 0:28 am, [EMAIL PROTECTED] wrote: > >> Does restarting the Tomcat instance free up the stuck processes? > > > > Yup. Apache seems to recover fine, as the socket gets reset. > > OK, can you figure out what Tomcat is doing when these processes get > stuck? It seems that you may have some threads hanging up in Tomcat. > Apache will wait forever for a response from Tomcat, or until the > connection is broken. > > -Dave > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
On Mon, February 23, 2004 1at 0:28 am, [EMAIL PROTECTED] wrote: >> Does restarting the Tomcat instance free up the stuck processes? > > Yup. Apache seems to recover fine, as the socket gets reset. OK, can you figure out what Tomcat is doing when these processes get stuck? It seems that you may have some threads hanging up in Tomcat. Apache will wait forever for a response from Tomcat, or until the connection is broken. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
> Does restarting the Tomcat instance free up the stuck processes? > > -Dave > Yup. Apache seems to recover fine, as the socket gets reset. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 buglets II
[EMAIL PROTECTED] wrote, On 2/23/2004 8:37 AM: We seem to have another buglet with mod_jk2 2.0.2. We seem to be unable to recreate the bug using ab, but when one of our busiest servers has been running for a few hours we get apache children "stuck" (at times upto 100 children are blocked, which is how we found the issue as the server appeared slow). Does restarting the Tomcat instance free up the stuck processes? -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
> > > Which Tomcat on the remote side ? > > > > 3.3, 4.0, 4.1, 5.0 ? > > Sorry forgot that: Sorry being an idiot. This is presently on 4.1.24. Leave this with me... I've made a mistake and need to retest with 4.1.29. Due to having to qualify (extensively test and document) out installs we are always behind the bleeding edge. Appologies. Greg > > 4.1.29 with jdk 1.4.2_02 > > Greg > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jk2 buglets II
> Which Tomcat on the remote side ? > > 3.3, 4.0, 4.1, 5.0 ? Sorry forgot that: 4.1.29 with jdk 1.4.2_02 Greg > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 buglets II
[EMAIL PROTECTED] wrote: We seem to have another buglet with mod_jk2 2.0.2. We seem to be unable to recreate the bug using ab, but when one of our busiest servers has been running for a few hours we get apache children "stuck" (at times upto 100 children are blocked, which is how we found the issue as the server appeared slow). Looking at server-status we the stalled children appear as: 1-0 18136 1/426/426 W 0.9916600 0.3 1.40 1.40xx xx GET /homepage/components/GetTime.jsp HTTP/1.1 The time since last request (SS in this case 1660) goes up as you would expect, yet this is the 2nd slot child. Graceful restarts do not help. The child remains in an apparent "W" (write state). This only happens to JK2 served content. Truss reveals: # truss -p 18136 read(39, 0x00505820, 4) (sleeping...) signotifywait() (sleeping...) lwp_sema_wait(0xFE30DE60) (sleeping...) (etc ..) Any ideas on debugging this? This bug is present in CVS and from 2.0.2. Thanks again. (I will shut up soon!) Which Tomcat on the remote side ? 3.3, 4.0, 4.1, 5.0 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk2 buglets II
We seem to have another buglet with mod_jk2 2.0.2. We seem to be unable to recreate the bug using ab, but when one of our busiest servers has been running for a few hours we get apache children "stuck" (at times upto 100 children are blocked, which is how we found the issue as the server appeared slow). Looking at server-status we the stalled children appear as: 1-0 18136 1/426/426 W 0.9916600 0.3 1.40 1.40xx xx GET /homepage/components/GetTime.jsp HTTP/1.1 The time since last request (SS in this case 1660) goes up as you would expect, yet this is the 2nd slot child. Graceful restarts do not help. The child remains in an apparent "W" (write state). This only happens to JK2 served content. Truss reveals: # truss -p 18136 read(39, 0x00505820, 4) (sleeping...) signotifywait() (sleeping...) lwp_sema_wait(0xFE30DE60) (sleeping...) (etc ..) Any ideas on debugging this? This bug is present in CVS and from 2.0.2. Thanks again. (I will shut up soon!) Greg Cope GCS Ltd Assign to: CIT, Sandwich - ISG Phone: (44) 01304 642040 Fax: (44) 01304 652118 LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addresee(s) only. Access to this e-mail by anyone else is unauthorised. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorised and may be unlawful. If you are not an addressee, please inform the sender immediately. Pfizer Limited is registered in England under No. 526209 with its registered office at Ramsgate Road, Sandwich, Kent CT13 9NJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jk2 buglets
Hi All,
We have been running into different issues with jk2 concerning shared memory
(on Solaris 8)
Calls to the function jk2_shm_create fail logging the following in the
jk2.log file,
[Mon Feb 23 12:12:00 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/shm.file 2117728 2117992 0x16
[Mon Feb 23 12:12:00 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/shm.file
[Mon Feb 23 12:12:00 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/shm.file 3864680 0 16
[Mon Feb 23 12:12:00 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/shm.file
[Mon Feb 23 12:12:03 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/shm.file 4382816 4383080 0x16
[Mon Feb 23 12:12:03 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/shm.file
[Mon Feb 23 12:12:03 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/shm.file 5124200 0 16
[Mon Feb 23 12:12:03 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/shm.file
On investigation it appears that there are some casting issues in this
function on the line,
/* Now mmap it
*/
rc=apr_mmap_create( &aprMmap, file, (apr_off_t)0,
(apr_size_t)finfo.size, APR_MMAP_READ |
APR_MMAP_WRITE,
globalShmPool );
if( rc!=JK_OK ) {
char error[256];
apr_strerror( rc, error, 256 );
>>env->l->jkLog(env, env->l, JK_LOG_ERROR,
>> "shm.create(): error creating %s %d %d %#lx %s\n",
>> shm->fname, finfo.size, rc, globalShmPool, error );
shm->privateData=NULL;
return rc;
}
As some of these fields are long's when build with large file support, on
solaris 2.8,
Changing the code to:
/* Now mmap it
*/
rc=apr_mmap_create( &aprMmap, file, (apr_off_t)0,
(apr_size_t)finfo.size, APR_MMAP_READ |
APR_MMAP_WRITE,
globalShmPool );
if( rc!=JK_OK ) {
char error[256];
apr_strerror( rc, error, 256 );
>>env->l->jkLog(env, env->l, JK_LOG_ERROR,
>> "shm.create(): error creating %s %d %d %#lx %s\n",
>> shm->fname, (int) finfo.size, rc, globalShmPool,
error );
shm->privateData=NULL;
return rc;
}
Reports the error better, but unfortunately it still fails to mmap correctly
(we changed the filename)
Mon Feb 23 15:21:42 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/cr.sandwich.pfizer.com_81.shm 2117992 22 0x1f5020 Invalid
argument
[Mon Feb 23 15:21:42 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/cr.sandwich.pfizer.com_81.shm
[Mon Feb 23 15:21:42 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/cr.sandwich.pfizer.com_81.shm 0 22 0x1f5020 Invalid argument
[Mon Feb 23 15:21:42 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/cr.sandwich.pfizer.com_81.shm
[Mon Feb 23 15:21:46 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/cr.sandwich.pfizer.com_81.shm 4383080 22 0x41e020 Invalid
argument
[Mon Feb 23 15:21:46 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/cr.sandwich.pfizer.com_81.shm
[Mon Feb 23 15:21:46 2004] (error ) [jk_shm.c (199)] shm.create(): error
creating /tmp/cr.sandwich.pfizer.com_81.shm 0 22 0x41e020 Invalid argument
[Mon Feb 23 15:21:46 2004] (error ) [jk_shm.c (274)] shm.create(): error
mmapping /tmp/cr.sandwich.pfizer.com_81.shm
(We changed the shared memory file name).
Are we doing something wrong, or is this a buglet.
Regards & Thanks.
Greg Cope
GCS Ltd
Assign to: CIT, Sandwich - ISG
Phone: (44) 01304 642040
Fax: (44) 01304 652118
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addresee(s) only. Access to this e-mail
by anyone else is unauthorised. If you are not an addressee, any disclosure
or copying of the contents of this e-mail or any action taken (or not taken)
in reliance on it is unauthorised and may be unlawful. If you are not an
addressee, please inform the sender immediately.
Pfizer Limited is registered in England under No. 526209 with its registered
office at Ramsgate Road, Sandwich, Kent CT13 9NJ
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
