Hi, 

I just ran into a problem with the loadbalancing stuff.

I built mod_jk.so from the 4.0.2 connector package and replaced my 
mod_jk.so (TC3.3 Version) with this one in apache/libexec (1.3.19).

By just changing a link back and forth between the two versions, I tested
our TC3.3 based application against the two versions of mod_jk.
If this is not enough and I am missing something, please let me know.
Otherwise exactly the same setup 

All works perfectly with the new mod_jk when I use normal ajp13 workers 
(one webapp), but fails when I use a loadbalancing worker pointing to 
another webapp on a different Tomcat instance.

I do not have the mod_jk.log here at home. Will send it in a couple of 
hours when I am in the office.

What else would be required for debugging? 


Note, We use the loadbalancer just for switching tomcats. Only one 
instance of the two loadbalanced Tomcats is active most of the time.
(by changing the lbvalue)

Thanks,
Hans

 

> -----Ursprungliche Nachricht-----
> Von: Mike Anderson [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 13. Februar 2002 02:17
> An: [EMAIL PROTECTED]
> Betreff: RE: Native Connector problems
> 
> 
> The problem is that the default cache size is one and in the ajp_init
> function
> in jk_ajp_common.c we return from inside of an if when we initialize
> the cache
> so the secrect member of the structure never gets initialized.  This
> caused
> some GPFs in certain cases on some of my builds.
> 
> I've checked in the fix.  All I did was move the line that initializes
> secret up above
> the if statement.
> 
> Remy, would it be possible to relabel jk_ajp_common.c
> rev. 1.24 as the rev for tomcat_402?  I've built and tested this fix on
> NetWare
> and the resolved my GPFs and bad behavior talking to older
> installations
> of Tomcat (i.e. 3.3).  I was able to use the same module to talk to 
> Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server.
> I love it when a plan comes together :-)
> 
> Mike Anderson
> 
> 
> >>> [EMAIL PROTECTED] 02/12/02 05:19PM >>>
> >One of the last changes on the connector ( the secret ) 
> >introduced a bug,
> >when worker_cache is enabled. The secret will not be initialized, and
> 
> >that may creates all kind of serious problems.
> 
> Could you detail the problem ?
> 
> --
> To unsubscribe, e-mail:  
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to