DO NOT REPLY [Bug 43790] New: - concurrent access issue on TagHandlerPool

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r591629 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c native/common/jk_uri_worker_map.c xdocs/miscellaneous/changelog.xml

Author: rjung Date: Sat Nov 3 08:09:58 2007 New Revision: 591629 URL: http://svn.apache.org/viewvc?rev=591629&view=rev Log: Revert changes from r591512 and r591522. (was: Allow JkMount and JkUnMount patterns to start with '*' and '?' in addition to '/') Modified: tomcat/connectors/trunk/jk/n

Re: Are Sticky Sessions really necessary?

But isn't the purpose of session replication to allow different servers to handle the session? If not, what's it for? -- Len On 11/3/07, Peter Rossbach <[EMAIL PROTECTED]> wrote: > Hi, > > It is not only ineffizient and a risk, Read 7.7.2 at the spec: > > SRV.7.7.2 Distributed Environments > With

svn commit: r591640 - /tomcat/connectors/trunk/jk/tools/jkrelease.sh

Author: rjung Date: Sat Nov 3 09:07:39 2007 New Revision: 591640 URL: http://svn.apache.org/viewvc?rev=591640&view=rev Log: Add ability to package from an svn revision to jk release script. Works for trunk, branch and directory packaging, useful for the production of pre release testing tarballs.

Re: Are Sticky Sessions really necessary?

Hi Len, the normal servlet spec conform purpose is to handle administration down, app version migration or handle real crashes without lost your user session/context! This means not that tomcat replication cluster can't handle your "request stateless" szenario. It works with speziell applic

DO NOT REPLY [Bug 43647] - Content-Type changes unexpectedly from text/html to text/plain

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 43753] - JkEnvVar and Limit of content length HTTP request POST

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 43516] - mod_jk memory leak (apache reload)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: JK 1.2.26 ?

Please see my comment in BZ 42003. Most of the changes should not be necessary, because JK and Tomcat in recent releases have a config parameter, so only the iis patch is left. It would be nice, if you could test the combination of your iis patch with the config params. Regards, Rainer Dan Burt

svn commit: r591660 - /tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml

Author: rjung Date: Sat Nov 3 11:44:08 2007 New Revision: 591660 URL: http://svn.apache.org/viewvc?rev=591660&view=rev Log: Clarify docs. Modified: tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml Modified: tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml URL: http://

Re: Are Sticky Sessions really necessary?

On 11/3/07, Len Popp <[EMAIL PROTECTED]> wrote: > > But isn't the purpose of session replication to allow different > servers to handle the session? If not, what's it for? > This discussion touches on a bit of philosophy, and a set of design decisions built into the code, and no longer relevant.

DO NOT REPLY [Bug 42038] - JK uriworkermap ROOT mapping causes non-virtual exclusions to be ignored

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r591694 - /tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c

Author: rjung Date: Sat Nov 3 14:30:40 2007 New Revision: 591694 URL: http://svn.apache.org/viewvc?rev=591694&view=rev Log: Fix some log message typos for isapi. Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin

Re: Delays in mod_jk

Hi Larry, your analysis is correct, but the results nevertheless a little obscure. Yes, mod_jk has no internal timing of management threads. We will move mod_jk to the APR libraries when starting JK3, but at the moment we rely completely on the web server plugin API. Apache has no timing API, so