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]
