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

[bugzilla]

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_bug.cgi?id=43790

   Summary: concurrent access issue on TagHandlerPool
   Product: Tomcat 6
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when doing performance test, i found the concurrent acess lock issue about JSP 
tag. Many threads are waiting for TagHandlerPool object, such as 
TagHandlerPool.reuse, TagHandlerPool.get. 
In TagHandlerPool and PerThreadTagHandlerPool class, object pool was used, but 
its synchronization cause the thread waiting/lock issue when a lot of JSP tags 
are using. Later, I test a ThreadLocal based TagHandler object instead of 
TagHandlerPool, the response time was reduced to 5s from 30s against 50 
concurrent user. 
As a suggestion, please remove object pool to replace with simple ThreadLocal 
solution. The same issues exist both Tomcat 5.X and 6.0.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[rjung]

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/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=591629&r1=591628&r2=591629&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Sat Nov  3 08:09:58 
2007
@@ -867,8 +867,8 @@
 return "JkMount can not have a path when defined in a location";
 }
 
-if (c[0] != '/' && c[0] != '?' && c[0] != '*')
-return "JkMount context should start with '/', '*' or '?'.";
+if (c[0] != '/')
+return "JkMount context should start with /";
 
 /*
  * Add the new worker to the alias map.
@@ -909,8 +909,8 @@
 else
 return "JkUnMount can not have a path when defined in a location";
 }
-if (c[0] != '/' && c[0] != '?' && c[0] != '*')
-return "JkUnMount context should start with '/', '*' or '?'.";
+if (c[0] != '/')
+return "JkUnMount context should start with /";
 uri = ap_pstrcat(cmd->temp_pool, "!", c, NULL);
 /*
  * Add the new worker to the alias map.

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=591629&r1=591628&r2=591629&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Sat Nov  3 08:09:58 
2007
@@ -895,8 +895,8 @@
 return "JkMount can not have a path when defined in a location";
 }
 
-if (c[0] != '/' && c[0] != '?' && c[0] != '*')
-return "JkMount context should start with '/', '*' or '?'.";
+if (c[0] != '/')
+return "JkMount context should start with /";
 
 /*
  * Add the new worker to the alias map.
@@ -938,8 +938,8 @@
 return "JkUnMount can not have a path when defined in a location";
 }
 
-if (c[0] != '/' && c[0] != '?' && c[0] != '*')
-return "JkUnMount context should start with '/', '*' or '?'.";
+if (c[0] != '/')
+return "JkUnMount context should start with /";
 
 uri = apr_pstrcat(cmd->temp_pool, "!", c, NULL);
 /*

Modified: tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c?rev=591629&r1=591628&r2=591629&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c Sat Nov  3 
08:09:58 2007
@@ -363,7 +363,7 @@
 return JK_FALSE;
 }
 
-if (*uri == '/' || *uri == '*' || *uri == '?') {
+if (*uri == '/') {
 uwr->uri = uri;
 uwr->context = uri;
 uwr->worker_name = jk_pool_strdup(&uw_map->p, worker);
@@ -397,7 +397,7 @@
  * not arrive here when using Apache.
  */
 jk_log(l, JK_LOG_ERROR,
-   "invalid context '%s': does not begin with '/', '*' or '?'",
+   "invalid context '%s': does not begin with '/'",
uri);
 JK_TRACE_EXIT(l);
 return JK_FALSE;

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?rev=591629&r1=591628&r2=591629&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Sat Nov  3 
08:09:58 2007
@@ -43,10 +43,6 @@
   
   
 
-  
-Apache: Allow JkMount and JkUnMount patterns to start with '*' and '?'
-in addition to '/'. (rjung)
-  
   
 43684: Replace JkMountFile by JkMountFileReload in
 uriworkermap.properties docs. (rjung)



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

Re: Are Sticky Sessions really necessary?

[Len Popp]

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
> Within an application marked as distributable, all requests that are
> part of a session
> must be handled by one Java Virtual Machine1 ("JVM") at a time. The
> container
> must be able to handle all objects placed into instances of the
> HttpSession class
> using the setAttribute or putValue methods appropriately.
> 
>
> regards
> Peter
>
> Am 02.11.2007 um 22:37 schrieb Len Popp:
>
> > You can indeed use session replication without sticky sessions, and
> > the session data will be copied to all the Tomcat servers. However it
> > may be inefficient. You probably have to use synchronous replication
> > to ensure the session data is consistent across the cluster, which
> > adds latency to the requests. And there could be a lot of extra
> > network traffic in the cluster if it's busy (which it is, otherwise
> > you wouldn't be doing load balancing).
> >
> > (I haven't used session replication in a high-load situation. Maybe
> > someone else can tell us how well it works.)
> > --
> > Len
> >
> > On 11/2/07, Stephen Wick <[EMAIL PROTECTED]> wrote:
> >> The Tomcat 5.5 "Clustering/Session Replication Guide" says, "Make
> >> sure
> >> that your loadbalancer is configured for sticky session mode."
> >> However,
> >> I don't see the term "Sticky" sessions anywhere in the Servlet 2.3 or
> >> 2.4 specifications.
> >>
> >> Are sticky sessions really required for clustering to function
> >> properly
> >> in Tomcat 5.5?  I thought that session replication would eliminate
> >> any
> >> need to direct a client session to one node in a cluster.
> >>
> >> If not, can we adjust the documentation to indicate that Sticky
> >> sessions
> >> are optional, for the appropriate reason (I'm guessing the advent of
> >> session replication in tomcat.)
> >>
> >> I am asking this question because I am having trouble with Sticky
> >> sessions in my load balancer, and I need to know whether or not I
> >> should
> >> pursue fixing this feature.  If tomcat doesn't really require sticky
> >> sessions, then I can leave my load balancer alone.  If tomcat does
> >> need
> >> the feature to function properly, then I need to go to some
> >> additional
> >> expense to resolve the issue with my load balancing appliance.
> >>
> >> Thank you for your time and expertise.
> >>
> >> Stephen Wick
> >> Interactive Developer
> >> Nicholson Kovac, Inc.
> >>
> >> References
> >> http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
> >>
> >
> > -
> > 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]

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

[rjung]

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.

Modified:
tomcat/connectors/trunk/jk/tools/jkrelease.sh

Modified: tomcat/connectors/trunk/jk/tools/jkrelease.sh
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/tools/jkrelease.sh?rev=591640&r1=591639&r2=591640&view=diff
==
--- tomcat/connectors/trunk/jk/tools/jkrelease.sh (original)
+++ tomcat/connectors/trunk/jk/tools/jkrelease.sh Sat Nov  3 09:07:39 2007
@@ -43,8 +43,9 @@
  FUNCTIONS ##
 
 usage() {
-echo "Usage:: $0 -t VERSION [-b BRANCH | -T | -d DIR]"
+echo "Usage:: $0 -t VERSION [-r revision] [-b BRANCH | -T | -d DIR]"
 echo "-t: version to package"
+echo "-r: revision to package"
 echo "-b: package from branch BRANCH"
 echo "-T: package from trunk"
 echo "-d: package from local directory"
@@ -74,10 +75,11 @@
  MAIN ##
 
 conflict=0
-while getopts :t:b:d:T c
+while getopts :t:r:b:d:T c
 do
 case $c in
 t) tag=$OPTARG;;
+r) revision=$OPTARG;;
 b) branch=$OPTARG
conflict=$(($conflict+1));;
 T) trunk=trunk
@@ -121,10 +123,14 @@
 usage
 exit 2
 fi
+if [ -n "$revision" ]
+then
+revision="-r $revision"
+fi
 if [ -n "$trunk" ]
 then
 JK_SVN_URL="${SVNROOT}/${SVNPROJ}/trunk"
-JK_REV=`svn info ${JK_SVN_URL} | awk '$1 == "Revision:" {print $2}'`
+JK_REV=`svn info $revision ${JK_SVN_URL} | awk '$1 == "Revision:" {print 
$2}'`
 if [ -z "$JK_REV" ]
 then
echo "No Revision found at '$JK_SVN_URL'"
@@ -135,7 +141,7 @@
 then
 JK_BRANCH=`echo $branch | sed -e 's#/#__#g'`
 JK_SVN_URL="${SVNROOT}/${SVNPROJ}/branches/$branch"
-JK_REV=`svn info ${JK_SVN_URL} | awk '$1 == "Revision:" {print $2}'`
+JK_REV=`svn info $revision ${JK_SVN_URL} | awk '$1 == "Revision:" {print 
$2}'`
 if [ -z "$JK_REV" ]
 then
echo "No Revision found at '$JK_SVN_URL'"
@@ -145,13 +151,13 @@
 elif [ -n "$local_dir" ]
 then
 JK_SVN_URL="$local_dir"
-JK_REV=`svn info ${JK_SVN_URL} | awk '$1 == "Revision:" {print $2}'`
+JK_REV=`svn info $revision ${JK_SVN_URL} | awk '$1 == "Revision:" {print 
$2}'`
 if [ -z "$JK_REV" ]
 then
echo "No Revision found at '$JK_SVN_URL'"
exit 3
 fi
-JK_DIST=${JK_CVST}-${tag}-dev-local-`date +%y%m%d%H%M%S`-${JK_REV}-src
+JK_DIST=${JK_CVST}-${tag}-dev-local-`date +%Y%m%d%H%M%S`-${JK_REV}-src
 else
 JK_VER=$tag
 JK_TAG=`echo $tag | sed -e 's#^#JK_#' -e 's#\.#_#g'`
@@ -166,10 +172,10 @@
 rm -rf ${JK_DIST}.tmp
 
 mkdir -p ${JK_DIST}.tmp
-svn export "${JK_SVN_URL}/jk" ${JK_DIST}.tmp/jk
+svn export $revision "${JK_SVN_URL}/jk" ${JK_DIST}.tmp/jk
 for item in ${COPY_TOP}
 do
-svn export "${JK_SVN_URL}/${item}" ${JK_DIST}.tmp/${item}
+svn export $revision "${JK_SVN_URL}/${item}" ${JK_DIST}.tmp/${item}
 done
 
 # Build documentation.
@@ -177,7 +183,7 @@
 ant
 cd ../../..
 
-# Copying things into source distribution
+# Copying things into the source distribution
 copy_files ${JK_DIST}.tmp $JK_DIST "$COPY_TOP"
 copy_files ${JK_DIST}.tmp/jk $JK_DIST "$COPY_JK"
 copy_files ${JK_DIST}.tmp/jk/build $JK_DIST "$COPY_BUILD"



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

Re: Are Sticky Sessions really necessary?

[Peter Rossbach]

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 application, but to build those application is a very  
hard job. You can test it with pooled replication mode, but it's high
risk to have inconsistence at normal runtime. You must have good  
synchronization points to handle multiple request at same session at  
lots of threads and processes.  Please, check how your browser client  
interact exactly with your application. At  my experience the sticky  
session constraint help to have a better and controlled server env :-)


Peter


Am 03.11.2007 um 16:16 schrieb Len Popp:


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
Within an application marked as distributable, all requests that are
part of a session
must be handled by one Java Virtual Machine1 ("JVM") at a time. The
container
must be able to handle all objects placed into instances of the
HttpSession class
using the setAttribute or putValue methods appropriately.


regards
Peter

Am 02.11.2007 um 22:37 schrieb Len Popp:


You can indeed use session replication without sticky sessions, and
the session data will be copied to all the Tomcat servers.  
However it

may be inefficient. You probably have to use synchronous replication
to ensure the session data is consistent across the cluster, which
adds latency to the requests. And there could be a lot of extra
network traffic in the cluster if it's busy (which it is, otherwise
you wouldn't be doing load balancing).

(I haven't used session replication in a high-load situation. Maybe
someone else can tell us how well it works.)
--
Len

On 11/2/07, Stephen Wick <[EMAIL PROTECTED]> wrote:

The Tomcat 5.5 "Clustering/Session Replication Guide" says, "Make
sure
that your loadbalancer is configured for sticky session mode."
However,
I don't see the term "Sticky" sessions anywhere in the Servlet  
2.3 or

2.4 specifications.

Are sticky sessions really required for clustering to function
properly
in Tomcat 5.5?  I thought that session replication would eliminate
any
need to direct a client session to one node in a cluster.

If not, can we adjust the documentation to indicate that Sticky
sessions
are optional, for the appropriate reason (I'm guessing the  
advent of

session replication in tomcat.)

I am asking this question because I am having trouble with Sticky
sessions in my load balancer, and I need to know whether or not I
should
pursue fixing this feature.  If tomcat doesn't really require  
sticky

sessions, then I can leave my load balancer alone.  If tomcat does
need
the feature to function properly, then I need to go to some
additional
expense to resolve the issue with my load balancing appliance.

Thank you for your time and expertise.

Stephen Wick
Interactive Developer
Nicholson Kovac, Inc.

References
http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html



 
-

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]

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

[bugzilla]

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_bug.cgi?id=43647





--- Additional Comments From [EMAIL PROTECTED]  2007-11-03 11:16 ---
Depending on when exactly the flush is done on the Tomcat side, it might be
enough to use the mod_jk side of the fix, which might be easier for you to
build. A development snapshot of mod_jk can be found at:

http://people.apache.org/~rjung/mod_jk-dev/

This builds exactly with the same procedure like a production release.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[bugzilla]

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_bug.cgi?id=43753





--- Additional Comments From [EMAIL PROTECTED]  2007-11-03 11:16 ---
Could you please check, if the development snapshot of mod_jk found at

http://people.apache.org/~rjung/mod_jk-dev/

fixes the problem for you?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[bugzilla]

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_bug.cgi?id=43516





--- Additional Comments From [EMAIL PROTECTED]  2007-11-03 11:19 ---
If you have some spare cycles: we needed to apply some changes to this fix. It
would be good to know, that the updated dev snapshot found at

http://people.apache.org/~rjung/mod_jk-dev/

still is OK for you.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: JK 1.2.26 ?

[Rainer Jung]

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 Burton schrieb:
> Rainer - 
> 
> This bug in the AJP protocol / isapi_redirect.dll is one we had to roll
> our own patch for recently, and it looks like it might have gotten left
> behind under the "Tomcat 5" product.
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=42003
> 
> This should be a relatively small but impactful change, and if it could
> get taken care of for a 1.2.26 release, that would be fantastic.
> 
> The necessary code changes are in a comment on the issue, but I don't
> have enough C mojo to conjure proper unit tests for the fix.  Also, as
> I'm new to this community, I'm not too familiar with the process for
> making fixes like this.  I'm happy to help out in whatever way makes
> sense.  In particular, I can test out a pre-release version of the DLL
> in our environment (as we have particular cases where this bug rears its
> head), if that's helpful.
> 
> Thanks,
> 
> -Dan

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

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

[rjung]

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://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml?rev=591660&r1=591659&r2=591660&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml Sat Nov  3 
11:44:08 2007
@@ -219,7 +219,7 @@
 
 
 workers.properties - A file that describes the host(s) and port(s) used 
by the workers (Tomcat processes).
-A sample workers.properties can be found under the conf directory.
+A sample workers.properties can be found under the conf directory in the 
source download.
 
 
 



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

Re: Are Sticky Sessions really necessary?

[Preston L. Bannister]

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.  In this case it's
"sticky sessions", a notion that once made some sense, but no longer.  There
are really only two design points that make sense for sessions:  1) sessions
kept in-memory (or on-disk) within a single machine, and 2) sessions kept in
an external service (database or specialized store).  There are a bunch of
intermediate solutions that used to make some sense - before web-oriented
databases, before massive scaling, before gigabit local nets, before cheap
and insanely fast single-box systems.

All the time spent maintaining intermediate solutions removes focus.  Java
is not losing out to PHP (and the like) due to lack of focus on the present,
not inferior technology.

Not that I expect the argument to make any headway in this venue, but
someone has to raise the issue.

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

[bugzilla]

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_bug.cgi?id=42038





--- Additional Comments From [EMAIL PROTECTED]  2007-11-03 14:16 ---
1) case-sensitivity

Most parts of URLs are case-sensitive in general (as stated by the respective
RFCs). Although on the windows platform file system pathes are not, and
therefore URLs pointing to file system objects usually behave case-insensitive,
mod_jk decides about forwarding to backends, whose case-sensitivity is unknown.

So we wont change the default for the Windows platform to case-insensitive. One
might argue, that it would make configuration for the windows platform easier,
if one could choose mappings to be case insensitive (not active by default). For
this we could extent the syntax of uriworkermap.properties resp. JkMount (in the
apache case). If you think that's an important feature, please open a separate
BZ for this feature and people can discuss it.

2) Root-Context mounts and unmounts

I'm thinking about your patch resp. something close to it.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

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

[rjung]

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.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c?rev=591694&r1=591693&r2=591694&view=diff
==
--- tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c Sat Nov  3 14:30:40 
2007
@@ -1283,13 +1283,13 @@
 
 if (JK_IS_DEBUG_LEVEL(logger))
 jk_log(logger, JK_LOG_DEBUG,
-   "check if [%s] is points to the web-inf directory",
+   "check if [%s] points to the web-inf directory",
 uri);
 
 if (uri_is_web_inf(uri)) {
 jk_log(logger, JK_LOG_EMERG,
"[%s] points to the web-inf or meta-inf directory. "
-   "Somebody try to hack into the site!!!",
+   "Somebody tries to hack into the site!!!",
uri);
 
 write_error_response(pfc, "404 Not Found",
@@ -1312,7 +1312,7 @@
 *(query - 1) = '\0';
 if (JK_IS_DEBUG_LEVEL(logger))
 jk_log(logger, JK_LOG_DEBUG,
-   "fowarding original URI [%s]",
+   "forwarding original URI [%s]",
uri);
 forwardURI = uri;
 }
@@ -1360,12 +1360,12 @@
 StringCbCopy(duri, INTERNET_MAX_URL_LENGTH, forwardURI);
 if (simple_rewrite(forwardURI)) {
 jk_log(logger, JK_LOG_DEBUG,
-   "rewriten URI [%s]->[%s]",
+   "rewritten URI [%s]->[%s]",
duri, forwardURI);
 }
 else if (rregex_rewrite(forwardURI)) {
 jk_log(logger, JK_LOG_DEBUG,
-   "rewriten URI [%s]->[%s]",
+   "rewritten URI [%s]->[%s]",
duri, forwardURI);
 }
 }



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

Re: Delays in mod_jk

[Rainer Jung]

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 we
need to pack our maintenance on top of request handling.

Nevertheless, we don't expect the shutdown process to take that long. In
fact, there is a timeout of 2 seconds only used for select in a loop
that tries to read pending data from a connection we want to shut down.
Usually this draining should not really happen.

When I test the code on Solaris, I see no waiting in the select for a
connection, that is idle. The select returns betwen 0 and 2 milliseconds
after calling it (at least that's what I get from logging).

So now the questions are:

- what is your OS?
- are there any network components between httpd and jboss, which could
influence connection shutdown negatively (firewall etc.)?
- was jboss very busy during this test?

If you can easily reproduce the behaviour, can you sniff a connection?

How do I test?

I use a simple JSP sleep.jsp:


<[EMAIL PROTECTED] session="false"%>
Sleeping ...
<%
Thread.sleep(100);
%>
Done.
=

For testing I configure connection_pool_timeout very low, e.g. 10
seconds and connection_pool_minsize to 1.

Then I send a couple of concurrent requests to the JSP to open a couple
of connections. For this I use the Apache httpd tool ab contained in the
bin directory

bin/ab -c 5 -n 100 http://myhost:myport/sleep.jsp

You can check via "netstat -an" if a couple of backend connections are
ESTABLISHED.

Now wait a minute and call the JSP once, e.g. with a browser.
mod_jk should then close all backend connections used by the httpd
process that handles this request (apart from 1 remaining connection).

If this works for you too, you can sniff the backend traffic after the
ab run and before the final request.

Regards,

Rainer

Larry Reisler schrieb:
> We are running JBOSS 4.21GA(Tomcat 6.0.10) with mod_jk 1.25 on Apache
> 2.2.x, and have run into something of a performance issue.
> 
> We have the system setup so that threads on mod_jk and tomcat timeout
> after 10 minutes (an heuristic which has been discussed in some of
> the documentation) using the properties on the mod_jk side: 
> worker.node1.connection_pool_timeout=600,and on the Tomcat side
> connectionTimeout="60".
> 
> We have noticed that some transactions to the apache server were
> running slow.  After looking at the logs, the mod_jk logs indicated
> that the transaction executed relatively quickly (eg. < .03 seconds)
> whereas the apache access logs indicated that the transaction took
> something more like 2.040 seconds.  After enabling trace logs on
> mod_jk, it became clear that sometimes before executing a
> transaction, mod_jk would call the maintain function, which in turn
> would close sockets that had exceeded the time limit of 10 minutes
> using jk_shutdown_socket.   As per the code message in
> jk_shutdown_socket, the socket would take two seconds to shut down,
> causing a delay (sometimes it would shut down two or three sockets,
> resulting in a delay of 2,4, or 6 seconds).  The time spent doing the
> maintenance was before the real work of sending the data to Tomcat,
> so the mod_jk.log did not reflect that in its timing.  Nevertheless,
> the transactions are being delayed.
> 
> I found that the number of delays was directly related to the
> connection_pool_timeout: a higher timeout meant fewer delays – this
> is what I would have expected given my understanding of the problem.
> 
> I tried setting worker.maintain on the mod_jk side to 10 seconds, but
> the problem still occurs.
> 
> A couple of questions come out of this: 1.  Should the thread
> processing the request be running maintain at all?  My understanding
> is that there is a separate maintenance thread that is running by
> default every 60 seconds.  Can’t that thread perform the maintenance
> exclusively? 2.  If the processing thread does have to run the
> maintain function, then maybe it could simply place the expired
> sockets on a queue for later processing by the maintain thread, or
> perhaps send the FIN packet and then place them on a queue. 3.  Is
> there some reason that Tomcat would not be sending the FIN packet to
> mod_jk immediately?
> 
> Thanks Larry Reisler

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