Attending ApacheCon next week?

[Rainer Jung]

Hi,

who is going to attend ApacheCon next week?

I will be there the whole time starting saturday. I would very much like
to meet the tomcat developers attending the conference. So, who will be
there and which days will you be attending?

I've got no idea how many of you know each other personally, but I think
the information is interesting for more people than just me.

Looking forward to meeting you

Rainer


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

Re: sendRedirect and absolute paths

[Rainer Jung]

Users questions should be posted on the users list. Please post all
follow ups to the users list. See http://tomcat.apache.org/lists.html
for what should be discussed on what list.

You might find a configurative solution at

http://tomcat.apache.org/tomcat-5.5-doc/config/http.html

especially

proxyName   

If this Connector is being used in a proxy configuration, configure this 
attribute to specify the server name to be returned for calls to 
request.getServerName(). See Proxy Support for more information.


proxyPort   

If this Connector is being used in a proxy configuration, configure this 
attribute to specify the server port to be returned for calls to 
request.getServerPort(). See Proxy Support for more information.


scheme  

Set this attribute to the name of the protocol you wish to have returned 
by calls to request.getScheme(). For example, you would set this 
attribute to "https" for an SSL Connector. The default value is "http". 
See SSL Support for more information.


Rainer Jung


Tino Schwarze wrote:

On Thu, Feb 16, 2006 at 03:24:52PM -0800, Casey Haakenson wrote:

We have a customer who is hitting our web GUI through a fairly
complicated SSH proxy scheme.  For example, when they hit a page on our
site such as /redirect.jsp we do a
response.sendRedirect("/newpage.jsp").  This results in a 302 status
code and a Location header with the full URI
(http://somesite.com/newpage.jsp) which is the incorrect URL since the
proxy has been rewriting the URL's so far and this new one is the one
that the proxy is hitting not the original one the browser thinks it's
viewing.

Anyway, I have tested a change to CoyoteResponse.sendRedirect:1114 (we
are using 4.1.24) to send the "relative absolute" ("/newpage.jsp") path
back to the browser in the Location header.  This appears to solve the
problem and work in all browsers I've been able to test, but am worried
that since you guys went to so much trouble making it include the
protocol, hostname, port, etc that this may break some odd browser or
case I'm not fully understanding at the moment.


AFAIK it's against HTTP specs. Redirects have to be absolute. For
example, lynx complains ("redirect URL is not absolute" or something
alike). IMO there's only one practical solution: Tell your application
which URLs will be used to access it and prepare the redirect URLs
according to the request (you can evaluate X-Forwarded-Host and similar
headers to get the original hostname).

Bye, Tino.


-
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: AW: Tomcat Connector 1.2.15 - JkOption "FlushPackets"-Bug

[Rainer Jung]

Hi Mladen,

are you sure? I have the impression default is

c->options = JK_OPT_FWDURIDEFAULT;

and

#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPAT
#define JK_OPT_FWDURICOMPAT 0x0001

but needed is

#define JK_OPT_FLUSHPACKETS 0x0020

It looks like JK_OPT_FLUSHPACKETS is only set when JkOption parsed.

Anything I missed?

Regards,

Rainer

Fenlason, Josh wrote:


Are you sure that + is the default for the FlushPackets option?  I had a
similar issue where I was trying to stream data from a servlet.  Once I
added 'JkOptions +FlushPackets' to my mod_jk config, everything worked
as expected.
,
Josh.



-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 20, 2006 3:47 AM

To: Tomcat Developers List
Subject: Re: AW: Tomcat Connector 1.2.15 - JkOption "FlushPackets"-Bug


Peter Rossbach wrote:


I thing you mus set
JkOptions +FlushPackets



No need. Default is +.

Regards,
Mladen.


-
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: AW: Tomcat Connector 1.2.15 - JkOption "FlushPackets"-Bug

[Rainer Jung]

Ah, sorry, I read your mail out of context (at least not with enough 
context).


So mod_jk default is -ForwardPackets and setting +ForwardPackets or 
ForwardPackets is the same.


Since in some mails singular was used and in some mails plural: the 
correct spelling is "FlushPackets".


Mladen Turk wrote:

Rainer Jung wrote:

Hi Mladen,

are you sure? I have the impression default is



I meant that the '+' is default:

if (action == '-') {
conf->options &= ~opt;
}
else if (action == '+') {
conf->options |= opt;
}
else {  /* for now +Opt == Opt */
conf->options |= opt;
}

So it shouldn't make any difference between:
JkOptions +FlushPackets
and
JkOptions FlushPackets


Regards,
Mladen.

-
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]

Cluster maintenance and improvement

[Rainer Jung]

Hi Filip, hi all developers,

I think TC clustering from a users perspective got more robust in the 
last two years. Whe we started playing around with it in 2004 it was 
great, that we all basic functionality already worked, but you might 
remember, that I contributed a couple of fixes to make DeltaManager 
finally work in around 5.0.27.


When we started to check robustness for mission-critical production I 
found some limitations, that made clustering (in our use case) a little 
fragile, and I'm thankful to Peter, that he included the fastasync 
replication mode.


During early stages of 5.5 the amount of changes to cluster introduced 
some instability and finally broke it (the compression change), but the 
bugs were resolved very quickly after user feedback. At the end everyone 
was confident, that TC cluster was stable again starting from 5.5.15.


At the moment TC 5.5 core is in maintenance mode. Commiters for core 
Tomcat usually only apply bug changes to 5.5, no major changes were 
applied to the core parts. So the release schedule for 5.5 is mainly 
correlated to bug fixes.


Major Changes to TC cluster might result in a conflict between TC 
releases (bug driven) and Cluster releases (refactoring driven), at 
least as long as TC core and the cluster module are released together.


So I would also very much appreciate a conservative refactoring and 
enhancement strategy for 5.5 cluster. Major changes (better: risk) 
should be directly done in TC 6 (which is not that far away).


I agree, taht there is a lot of code refactoring necessary for the 
cluster as a basis for adding more and important functionality.


But in the last two years the amount of people doing real production 
with TC cluster increased a lot. I think it would really help to have a 
conservatively maintained branch and one that is open for the very much 
needed restructuring of the code.


What do you think?

Regards,

Rainer

Filip Hanik - Dev Lists wrote:

new features and new development has historically always been done 
against the head revision.

If you want to put something into maintenance, then that becomes a branch

for example

VERSION
  | ---> HEAD REV ---> NEW DEVELOPMENT
  |
  | ---> BRANCH   ---> MAINTENANCE MODULE

in our case

5.5.15
  | ---> HEAD REV ---> NEW CLUSTER DEVELOPMENT
  |
  | ---> OLD CLUSTER COMPONENT BRANCH   ---> MAINTENANCE MODULE FOR THE 
WAY IT IS TODAY


To calm your nerves a little bit, I don't plan to pull out the JMX, nor 
to make major server.xml conf changes for 5.5.x, but it is on the 
horizon for TC6.
For 5.5.x the server.xml will remain similar to what it is today, ie, 
almost backwards compatible (minus the changes I already made).

TC 6 will have a completely new conf.
TC 5.5.x will have a TC6 style new conf enabled added for the users that 
want to take advantage of plugging in their own message interceptors and 
to do primary/secondary backup replication which I intend to have 
complete by 5.5.16/17 depending on when those releases get cut.


The compression flag will get taken out of the protocol, replaced with a 
default compression interceptor is compress="true". so functionality 
will not change for the users either.


Filip



Peter Rossbach wrote:


Hey Filip,

what I see is you want make an innovative step. Great, I m very 
motivated to

help that we implement a next generation.

But, why do we this implementation not inside a sandbox, branch or 
separate module?


Last year I learned that big changes are great, but it is easy to make 
failures at very little
details, like the compress flag bug. To design a new implementation is 
risky. A lot of
projects and people now use very succesfull the current tomcat 5.5.15 
cluster. Some people are
waiting that we release the cross context replication to support 
portal development. Please, I do not want to stop the innovation, but 
why do we not start the new cluster design at a separate module and 
set the current code base at maintaince mode?



Peter Roßbach



Am 23.02.2006 um 12:59 schrieb Filip Hanik - Dev Lists:


Peter Rossbach wrote:

>I have add the compress flag inside the protocol.
>It is usefull to send message with an without compression.
>For short messages it is not usefull to compress, it is an overhead.

There is no question whether compression is useful or not.
The compression flag should have never been added in the protocol in 
the first place,
Compression can and should be done on a higher level, and the 
algorithm should be pluggable.
Adding it to the protocol is like adding a compression flag to a TCP 
frame, and its a hack,

And it caused 4 stable releases of tomcat to be broken.

The flag should have been a flag in the payload,
configurable by the component requesting to send the data as that 
component is suitable for making that decision


compression will still be configurable on a per message basis, but 
with a different design.


>Before 5.5.15 you made a vote that we carefull with protocol changes,

I 

Re: Cluster maintenance and improvement

[Rainer Jung]

Hi Filip,

thanks for taking it seriously!


1. If we don't primary/secondary will not be available until TC.6

> 3. Many people are opting out of clustering today because of lack of
> primary/sec. all-to-all is too inefficient for the general public

I understand your primary motivation. It#s true, primary/secondary would 
be a major improvement. There is one feature that exists now and was not 
available in 2004, that relaxes some of the all-to-all problems. We 
donated enhancements to mod_jk which were taken up by Mladen Turk: the 
domain attribute for a worker. So what is already possible today, is a 
static grouping of cluster nodes into domains. From the tomcat 
perspective that means, you configure multiple disjoint clusters. From 
the mod_jk perspective this means, that you sessions will always be 
routed to a node inside the same tomcat cluster (domain in mod_jk 
notation), and only if all nodes in the domain are in error state, the 
requests are routed to some node who does not have the session. In some 
way it is a very basic static promary/secondary feature and it only 
works in conjunction with mod_jk.


This is very bare bone, but I know several people who build their 4 to 9 
cluster nodes on top of that construction. In fact, susually they had 
their nodes segmented in network terms in smaller groups anyhow, so 
breaking up the cluster into domains fitted their needs well.


Of course, having a dynamic and more transparent primary/secondary 
construction is much more useful. I just want to indicate, why I know 
serveral users, who could work successfully with "all-to-all", 
restricted to domains.



2. TC 6 doesn't have a skeleton nor a date yet.
5. The instability caused in 5.5.10-5.5.14 could have easily been 
detected and should have not lasted for four releases. I doubt we should 
see that again.

> 6. I'm ready and have the time and commitment to support any changes I
> make. I am happy to have a 5.5.15-cluster branch for bug fixes
>   This way when 5.5.16 comes out, the users can choose which one to use.
>
> To delay this out of plain "fear of breaking" doesn't seem reasonable to
> me, if the code base is so messed up that we are too afraid to "touch"
> it, then it needs to be fixed sooner than later.
>

I'm very happy about your commitment - really! We really need to push 
the clustering forward and it's fantastic to have you back!


I like your idea of a 5.5.15 maintenance branch. But I'm not sure, if we 
share the same idea, how that will be maintained.


For me it would be OK to freeze the actual cluster code in the 5.5.15 
maintenance branch. The only changes to this branch would be


- bug fixes for important bugs without work-arounds which will only need 
changes in small parts of the code (low complexity)

- security fixes
- bug fixes needed for compatibility with TC core 5.5, e.g. adoption of 
changes to Manager or Session.


So I would like to keep that branch stable, but compatible with 5.5. 
Would that be OK for you?


4. Many of the needed features needed for a more complete clustering 
solution are not possible today due to the tight coupling between 
components.
But I would be stretching myself thin trying to maintain two code bases. 
This maintenance branch is easy to create, just branch the entire 
cluster module plus ClusterRuleSet.java, and it is complete.


I agree, so do we have the same idea of the amount of maintenance for 
the maintenance branch? I'm pretty sure, Peter will be happy keeping 
that branch in shape (I think he leaves for holidays now, but he will be 
back next week).


I have no problem putting this up for a vote, but so far, the only 
justifications are concerns, when I believe I can offer more features 
and an easier codebase to maintain.




Voting is good, exchange of arguments as well. I think some of our 
concerns are not just theoretically. Major changes are needed and major 
changes usually break things for some time. So we are just trying to 
find out how to combine the grown user base and the needed improvements. 
I think your idea of a maintenance branch is just right.


Rainer



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

Re: Cluster maintenance and improvement

[Rainer Jung]

Hi Remy,


1. If we don't primary/secondary will not be available until TC.6
2. TC 6 doesn't have a skeleton nor a date yet.


It could have that tomorrow.

...
I agree with Peter: it's obvious no one should be doing major 
refactoring of existing components in 5.5.x. You could create a separate 
"cluster2" module if you still want to do the work in Tomcat 5.5.x, 
however.


So in general we have three options:

A) maintenance branch inside 5.5.15
B) cluster2 module
C) making changes in TC 6

Whichever way we choose, I think we need two lines of development:

a) one which tries to stick closely to the 5.5.15 code and only picks up 
security fixes and changes needed to keep compatibility with 5.5.x.


b) another one which gets all the refactoring, new features and 
improvements.


We have to make decisions:

- maintenance for a): If we let die a) for TC 6, we should document that 
decision, so would deprecate a) now. This sounds a little harsh, but 
that's in fact what we then do. It would be nice to support a) at least 
12 months after announcement of deprecation.


- release bundles: I think a) and b) should be available for download 
when a new 5.5 release is done. I don't really care about having 
seperate download file or not.


- default configuration entries in server.xml

Concerning A), B) or C):

Remy: what do you think, about how long dows it take to make a first 
alpha releaseof TC 6. I didn't follow closely the state of Specs and 
implementations. I expect that to still need 2 to 3 months. If I'm 
right, that means C) will not work out for Filip, because then he lacks 
the necessary amount of users playing around with the new code.


Decision between B) and C) depends more on the kind of message one needs 
to send to the user base. My impression is, that at the end the cluster 
code will have huge differences to it's state today and it would be more 
correct to have cluster2. But I could live with all parallel options, as 
long as we keep the old code compatible with 5.5.x and we document the 
plan for the future (maintenance/deprecation) for the user base.


Rainer


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

Re: New clustering module proposal - WAS: Long rants

[Rainer Jung]

+1 (non-binding)

Filip Hanik - Dev Lists wrote:

+1 from myself

Filip Hanik - Dev Lists wrote:
Sounds like there is a consensus amongst folks. So to summarize 
everyones thoughts, let me know if this sounds like a solution 
agreeable to everyone.


1. Keep 5.5.x as a maintenance module as it was of 5.5.15 + cross context

2. Break out cluster config from catalina.jar to catalina-cluster.jar 
that way we can enable more than one config
  In Catalina.java have a ClusterRuleSetFactory.getClusterRuleSet() 
that will load the rule set run time.


3. Create two new modules (to use for TC6 and as an optional library 
for TC 5.5.x)

  a) Name:groupcom
 Lib : catalina-groups.jar
 Purpose: Group messaging component
  b) Name: ha
 Lib : catalina-cluster.jar
 Purpose: session replication logic, context attribute replication 
and other new features



Lets gather one round of feedback and then vote so that I can move on 
with new dev.


Filip





-
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: svn commit: r380835 -/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java

[Rainer Jung]

Hi Filip,

I did a little exercise with Java 6 and Solaris DTrace.

The change is in fact OK, although I first thought that the DeltaRequest 
will no longer be initialized:


DeltaManager.createSession() calls

   ManagerBase.createSession()

which in turns calls

  DeltaManager.createEmptySession()
 DeltaManager.getNewDeltaSession()
DeltaSession.()
   DeltaSession.resetDeltaRequest()

So the DeltaRequest still gets initialized correctly :)

Thanks

Rainer

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Fri Feb 24 14:19:22 2006
New Revision: 380835

URL: http://svn.apache.org/viewcvs?rev=380835&view=rev
Log:
Fix for bug 
http://issues.apache.org/bugzilla/show_bug.cgi?id=38740

looks like we got trigger happy with the resetDeltaRequest
Thanks to Nick Wesselman and Rainer Jung that pointed this out.


Modified:

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java

Modified: 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java?rev=380835&r1=380834&r2=380835&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
 Fri Feb 24 14:19:22 2006
@@ -605,7 +605,6 @@
 }
 
 DeltaSession session = (DeltaSession) super.createSession(sessionId) ;

-session.resetDeltaRequest();
 if (distribute) {
 sendCreateSession(session.getId(), session);
 }
@@ -633,7 +632,6 @@
 counterSend_EVT_SESSION_CREATED++;
 send(msg);
 }
-session.resetDeltaRequest();
 }
 
 /**




-
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]

DTrace analysis of TC-Cluster Multicast

[Rainer Jung]

Hi,

I started to trace TC cluster with DTrace. I did a first simple exam for
the mcast subcomplex. CPU usage and especially elapsed times might be
slightly larger than expected, because I used the more intrusive
extended DTrace probes.

All tests were done with JDK 1.6.0 build 72 on Solaris 10 SPARC, using a
T2000 system (8 cores with 4 Threads each).

Method  allocationelapsed  cpu
mcast/McastServiceImpl.send()1328B   40ms6.7ms
mcast/McastServiceImpl.receive()  744-760B   23-510ms3.5ms

So this does not look very bad, but I inspected, where cpu time is used
and objects get allocated:

1) send cpu time, elapsed time and allocation, per send

  cpu elapsed alloc
6.7ms  40.3ms 1328B  McastServiceImpl.send()

6.3ms  37.6ms 1296BMcastMember.getData()

1.3ms   7.6ms  136B   ... getName().getBytes();
0.9ms   5.3ms  120B   ... getDomain().getBytes();
3.6ms  21.2ms  880B   ... java.net.InetAddress.getByName(host)...

It's interesting, that the last three statements are responsible for 85%
of the allocation and 90% of the cpu usage. This seems unnecessary,
because for sending multicast heartbeat, name, domain and host do not
change, so they could be buffered easily.

2) receive cpu time, elapsed time and allocation, per receive

  cpu  elapsedalloc
3.5ms 23-510ms 744-760B McastServiceImpl.receive()

0.1ms  3-485ms   0B   socket.receive()
2.8ms   17.9ms 640B   McastMember.getMember()

1.4ms8.1ms  160Bnew String(named),
1.0ms5.6ms  128Bnew String(domaind),
0.1ms0.6ms  112BaddressToString(addr),

0.3ms2.7ms   16B  ... membership.memberAlive(m)  [Only 50%]
0.2ms2.3ms   32B  ... membership.expire(timeToExpiration);
...

The calls to memberAlive are much faster in ~50% of the calls.

Here most interesting is the fact, that the string construction takes
70% of total cpu time. I inspected, why this is so. For the next trace I
had to increase the depth I traced, so elapsed times go a little up. The
columns are:

- ">" or "<": ">" means start of method, "<" end of method
- stack depth relative to the receive method
- cpu time
- elapsed time
- allocated bytes
- class and method


3 -  -- java/lang/String.
4 -  -- java/lang/String.
5 -  -- java/lang/StringCoding.decode
6 -  -- java/lang/StringCoding.decode
7 -  -- java/lang/StringCoding.deref

< 7 0.1ms  0.7ms0 java/lang/StringCoding.deref

7 -  -- java/lang/StringCoding$StringDecoder.decode
8 -  -- java/nio/ByteBuffer.wrap

< 8 0.1ms  0.5ms   48 java/nio/ByteBuffer.wrap

8 -  -- java/nio/CharBuffer.wrap

< 8 0.1ms  0.5ms   48 java/nio/CharBuffer.wrap

8 -  -- java/nio/charset/CharsetDecoder.decode

< 8 0.7ms  4.4ms0 java/nio/charset/CharsetDecoder.decode
< 7 1.1ms  7.8ms  160 java/lang/StringCoding$StringDecoder.decode
< 6 1.2ms  9.1ms  160 java/lang/StringCoding.decode
< 5 1.2ms  9.5ms  160 java/lang/StringCoding.decode
< 4 1.3ms 10.1ms  160 java/lang/String.
< 3 1.3ms 10.2ms  160 java/lang/String.

So we can see, that most of the cpu time is needed inside

- java/nio/charset/CharsetDecoder.decode: 0.7ms
- java/lang/StringCoding.deref: 0.1ms
- java/nio/ByteBuffer.wrap: 0.1ms
- java/nio/CharBuffer.wrap: 0.1ms

Maybe it would help to use a more byte-oriented format in the heartbeat
messages and to not convert from it. String conversions might be
restrictable to the case when logging in debug mode.

Cheers,

Rainer


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

Re: DTrace analysis of TC-Cluster Multicast

[Rainer Jung]

I agree, heartbeat is not that important w.r.t. performance. I used it 
as a simple test for how DTrace will be able to help. And at least in 
that nearly trivial test case the results are already interesting.


Another thing that DTrace can check is lock contention. So there's more 
to come :)


Do you have a working build of groupcom? I could trace some of the group 
communication.


I hope you will not sacrifice synchronization correctness for 
performance ...


Rainer

Filip Hanik - Dev Lists wrote:
Cool Rainer, interesting numbers. Can you run the same numbers on the 
new module groupcom.
I have done some optimizations there, for example, the name isn't 
broadcasted. And I am about to remove the domain, instead of having a 
default one. also, I agree, lets not translate the 4byte IP and the 
4byte port when receiving it. instead, member comparisons can be done on 
the byte array level, excellent suggestion.


After that I won't be spending to much focus on this issue, as a 
heartbeat do not really have to be optimized. The heartbeat runs *very* 
infrequently and it not a critical piece.


Instead I am gonna start reworking the data senders, there are way too 
many synchronized calls locking down the sockets, the code is somewhat 
cluttered then I am gonna move on to serialization. In the current 
cluster module, too much gets serialized, in the new module "ha" I have 
already removed a lot of serialization and will continue stripping it out.


Filip

Rainer Jung wrote:

Hi,

I started to trace TC cluster with DTrace. I did a first simple exam for
the mcast subcomplex. CPU usage and especially elapsed times might be
slightly larger than expected, because I used the more intrusive
extended DTrace probes.

All tests were done with JDK 1.6.0 build 72 on Solaris 10 SPARC, using a
T2000 system (8 cores with 4 Threads each).

Method  allocationelapsed  cpu
mcast/McastServiceImpl.send()1328B   40ms6.7ms
mcast/McastServiceImpl.receive()  744-760B   23-510ms3.5ms

So this does not look very bad, but I inspected, where cpu time is used
and objects get allocated:

1) send cpu time, elapsed time and allocation, per send

  cpu elapsed alloc
6.7ms  40.3ms 1328B  McastServiceImpl.send()

6.3ms  37.6ms 1296BMcastMember.getData()

1.3ms   7.6ms  136B   ... getName().getBytes();
0.9ms   5.3ms  120B   ... getDomain().getBytes();
3.6ms  21.2ms  880B   ... java.net.InetAddress.getByName(host)...

It's interesting, that the last three statements are responsible for 85%
of the allocation and 90% of the cpu usage. This seems unnecessary,
because for sending multicast heartbeat, name, domain and host do not
change, so they could be buffered easily.

2) receive cpu time, elapsed time and allocation, per receive

  cpu  elapsedalloc
3.5ms 23-510ms 744-760B McastServiceImpl.receive()

0.1ms  3-485ms   0B   socket.receive()
2.8ms   17.9ms 640B   McastMember.getMember()

1.4ms8.1ms  160Bnew String(named),
1.0ms5.6ms  128Bnew String(domaind),
0.1ms0.6ms  112BaddressToString(addr),

0.3ms2.7ms   16B  ... membership.memberAlive(m)  [Only 50%]
0.2ms2.3ms   32B  ... membership.expire(timeToExpiration);
...

The calls to memberAlive are much faster in ~50% of the calls.

Here most interesting is the fact, that the string construction takes
70% of total cpu time. I inspected, why this is so. For the next trace I
had to increase the depth I traced, so elapsed times go a little up. The
columns are:

- ">" or "<": ">" means start of method, "<" end of method
- stack depth relative to the receive method
- cpu time
- elapsed time
- allocated bytes
- class and method


3 -  -- java/lang/String.
4 -  -- java/lang/String.
5 -  -- java/lang/StringCoding.decode
6 -  -- java/lang/StringCoding.decode
7 -  -- java/lang/StringCoding.deref

< 7 0.1ms  0.7ms0 java/lang/StringCoding.deref

7 -  -- java/lang/StringCoding$StringDecoder.decode
8 -  -- java/nio/ByteBuffer.wrap

< 8 0.1ms  0.5ms   48 java/nio/ByteBuffer.wrap

8 -  -- java/nio/CharBuffer.wrap

< 8 0.1ms  0.5ms   48 java/nio/CharBuffer.wrap

8 -  -- java/nio/charset/CharsetDecoder.decode

< 8 0.7ms  4.4ms0 java/nio/charset/CharsetDecoder.decode
< 7 1.1ms  7.8ms  160 java/lang/StringCoding$StringDecoder.decode
< 6 1.2ms  9.1ms  160 java/lang/StringCoding.decode
< 5 1.2ms  9.5ms  160 java/lang/StringCoding.decode
< 4 1.3ms 10.1ms  160 java/lang/String.
< 3 1.3ms 10.2ms  160 java/lang/String.

So we can see, that most of the cpu time is needed inside

- java/nio/charset/CharsetDecoder.decode: 0.7ms
- java/lang/StringCoding.deref: 0.1ms
- java/nio/ByteBuffer.wrap: 0.1ms
- java/nio/CharBuffer.wrap: 0.1ms

Maybe it would help to use a more byte-orie

[Proposal] Small manager improvement

[Rainer Jung]

I have a small patch that I think improves the session listing in the 
manager webapp:


The doc says


Session Statistics

Display the default session timeout for a web application, and the 
number of currently active sessions that fall within ten-minute ranges 
of their actual timeout times. For example, after restarting Tomcat and 
then executing one of the JSP samples in the /examples web app, you 
might get something like this:



Actually that's not true and I have the impression the code does 
something not very useful which we can very easily tranform to something 
really useful:


At the moment the code calculates a histogramm of the different 
maxInactiveInterval values for all sessions of a context. Now most 
contexts I know, work with a fixed maxInactiveInterval for all sessions 
  in the context. As a result, all of the sessions are in the same 
histogram class and instead of the possible up to 60 lines of result 
histogram, the code always simply produces a single line showing again 
the total number of sessions - which is already included on the same 
page further down. So no real sense in that.


With a few lines of change we could easily list a histogram of how far 
sessions are away from their idle timeout. That seems to be a much more 
interesting information for monitoring, e.g. it enables to make a well 
informed decision on shrinking or sizing up session timeouts. This would 
also be in better alignment with the documntation of manger. This is 
sugestion 1a.


What I would even like better is instead printing a hitogramm of the 
actual idle time of the sessions. I think for most admins this is a more 
easily understandable metric.


So suggestion 1b: change sessions-function in manager webapp to show a 
histogram of session idle distribution instead of maxActiveTimeout 
distribution.


Suggestion 2: another small fix would allow a manager user to 
prematurely expire all sessions which are idle for a longer time than 
the amount of minutes she types into a text field (before she presses 
the new expire button.


I have a use case for this: some applications work with long running 
sessions (employee applications) that might have relatively big 
sessions. These applications typically have a timeout of several hours 
to allow resumption of work after lunch breaks, meeting etc. Often such 
apps depend on other external applications. When those have a bad day, 
the users of the web app might experience very long response times. So 
they decide to try a new login to the web app. From that point in time 
their old sessions are no longer used, but still stay in memory for 
several more hours. As soon as the external app has another hickup, 
another round of sessions gets lost by the same user behaviour. A well 
informed admin could now react to such a non-standard situation by 
deciding to expire all sessions which are idle longer than the amount of 
minutes she decides, e.g. one hour.


I did all that for TC5 and for 5.5 it's mostly the same. If their is 
interest in it, I would provide patches, including doc patches. I still 
would need spanish and japanese translations for "expire". :)


Feedback is highly welcome.


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

Re: svn commit: r389946 [3/5] - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/ant/jmx/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/loader/ java

[Rainer Jung]

Hi Remy,

I saw you taking over classes from commons modeler into tc 6. Just 
yesterday William Barker commited a very small and non-risky patch I 
submitted two years ago to bugzilla against Registry.convertValue():


http://issues.apache.org/bugzilla/show_bug.cgi?id=31608

The method has conversions for Integer and Boolean, but not for Long. It 
is used in Tomcats manager webapp (manager/jmxproxy) and many of 
tomcat's internal JMX parameters are longs and can therefore not yet 
been set via the manager webapp.


It would be very nice, if you could apply the patch to tc 6 copy of 
Regitry.java. Four your convenience I include it here:


Index: Registry.java
===
--- Registry.java   (revision 390034)
+++ Registry.java   (working copy)
@@ -713,6 +713,9 @@
 } else if( "java.lang.Integer".equals( type ) ||
 "int".equals( type )) {
 objValue=new Integer( value );
+} else if( "java.lang.Long".equals( type ) ||
+"long".equals( type )) {
+objValue=new Long( value );
 } else if( "java.lang.Boolean".equals( type ) ||
 "boolean".equals( type )) {
 objValue=new Boolean( value );

Thank you!

[EMAIL PROTECTED] wrote:

Added: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java
URL: 
http://svn.apache.org/viewcvs/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java?rev=389946&view=auto
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java 
(added)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/modeler/Registry.java Wed 
Mar 29 16:55:22 2006

...

+public Object convertValue(String type, String value)
+{
+Object objValue=value;
+
+if( type==null || "java.lang.String".equals( type )) {

+// string is default
+objValue=value;
+} else if( "javax.management.ObjectName".equals( type ) ||
+"ObjectName".equals( type )) {
+try {
+objValue=new ObjectName( value );
+} catch (MalformedObjectNameException e) {
+return null;
+}
+} else if( "java.lang.Integer".equals( type ) ||
+"int".equals( type )) {
+objValue=new Integer( value );
+} else if( "java.lang.Boolean".equals( type ) ||
+"boolean".equals( type )) {
+objValue=new Boolean( value );
+}
+return objValue;



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

mod_jk trunk: wrong version in configure.in?

[Rainer Jung]

While playing around with svn checkout of mod_jk trunk (1.2.16-dev) I 
saw, that in jk/native/configure.in there is still a line


   VERSION=1.2.14




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

Re: mod_jk trunk: wrong version in configure.in?

[Rainer Jung]

William A. Rowe, Jr. wrote:
If you run automake, it's still brought in, so necessary to keep it in 
sync.


Exactly, I was using buildconf.sh and the wrong version went into the 
Makefile and portable.h. From portable.h it looks like it's going 
nowhere, the one in the Makefile seems to be relevent for distribution 
building, which Mladen said does not exist. So we might be able to throw 
it out completely.



Mladen Turk wrote:


Rainer Jung wrote:

While playing around with svn checkout of mod_jk trunk (1.2.16-dev) I 
saw, that in jk/native/configure.in there is still a line


   VERSION=1.2.14



Right, but it's irrelevant.
We have jk_version.h. I think this was
meant to be used for packaging tasks
that BTW doesn't exist.

Regards,
Mladen.



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

Re: Challenges for Java hosting

[Rainer Jung]

Some hints, although I didn't go deeper into it and most of it might 
still be experimental:


1) Java Isolate API JSP-221

http://java.sys-con.com/read/99716.htm

http://jcp.org/en/jsr/detail?id=121

2) Building on top Java Resource Consumption Management API JSR-284

http://jcp.org/en/jsr/detail?id=284

http://research.sun.com/techrep/2003/abstract-124.html

http://research.sun.com/projects/barcelona/papers/middleware04.pdf

3) Sun's experimental JVM, implementing parts of it:

http://java.sun.com/developer/technicalArticles/Programming/mvm/

https://mvm.dev.java.net/

[you'll need to get the JDK Researcher role for that last one via 
https://mvm.dev.java.net/]


4) Maybe 1) and 2) are things to discuss with project Harmony?

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

Bug in TC class loading

[Rainer Jung]

I logged a bug a couple of days ago:

http://issues.apache.org/bugzilla/show_bug.cgi?id=39218

Since nobody gave any response, I wanted to ping the list.

The current implementation of the server, common and shared class 
loaders use the catalina.properties file to make the group of 
repositories which are searched for classes configurable.


Unfortunately the order of repositories in the entries is not respected. 
Instead they are rearranched into packed (jar files), unpacked (class 
directories) and a URL list. Then all unpacked are searched first, after 
that all jars and at the end all URLs.


A typical user would understand the configuration lines in 
catalina.properties as an analogy to the usual classpath of the system 
classloader. And I think that's intended. He would rely on the fact, 
that the order of entries is respected by the class loader. So he will 
order his patches etc. in the most obvious way. We throw away the order 
and rearrange via undocumented rules.


I attached a patch to bugzilla adding another signature to the creation 
of the classloader, allowing to pass in all repositories in the correct 
order. It's not a major redesign of the loading, because I want to keep 
the risk of breaking something minimal.


Any comments?

An example:

The tomcat product deployer might add a patch into 
CATALINA_HOME/server/classes (they don't want to overwrite the original 
jar files and adding them into server/lib is no way, since there is no 
way of knowing, in which order *.jar will be evaluated).


The application project team prepares an instance in CATALINA_BASE and 
deploys a newer version or a collection of patches as a jar file into 
CATALINA_HOME/server/lib.


They prepare a catalina.properties file with

server.loader=${catalina.base}/server/lib/*.jar,\
${catalina.home}/server/classes,\
${catalina.home}/server/lib/*.jar

Their version of the patch will not be loaded, because we regroup the 
entries and ${catalina.home}/server/classes will come first!




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

Re: Bug in TC class loading

[Rainer Jung]

svn: Commit failed
...
403 Forbidden (http://svn.apache.org)

Seriously: I would like to, but I'm only a contributor  :)

Remy Maucherat wrote:

Rainer Jung wrote:


I logged a bug a couple of days ago:

http://issues.apache.org/bugzilla/show_bug.cgi?id=39218



I found this was a reasonable addition. If you commit something and I 
don't like it, I know how to complain.


Rémy


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

[Proposal] mod_jk lb changes

[Rainer Jung]

Hi List, hi Mladen (master of mod_jk):

a year ago we changed to algorithm in mod_jk, that "counts" weighted 
requests in the lb worker to decide, which balanced worker should 
receive the next request.


The new algorithm three main advantages:

a) using only integers
b) using only a limited range of values
c) behaving well when one balanced worker went out of service for a 
longer time and then came back


Unfortunately the algorithm has another deficiency and I propose to do 
it in yet another way.


The problem is: the algo needs to update counters on all balanced 
workers not only on the worker that gets the request. No in more complex 
balancer configurations we have different groups of workers eligible for 
a request. A request might carry a session and the right worker is dwn, 
then the whole domain (replicas) are eligible. A request might not carry 
a session, then all available workers are eligible. Although we have 
different groups depending on the type of request and the status of the 
workers we only update one common set of load counters. This leads to 
incorrect balancing decisions, whenever these situations get mixed.


My proposal is to go back basically to the old way of doing it, but with 
an implementation, that still respects a) and c) and to some extend also b).


A) During initialization we calculate the smallest common multiple L of 
all balancing weights (lb factor) l_1,...,l_n and set 
L_1=L/l_1,...,L_n=L/l_n. That's cheap, the algo is well known and all is 
exact integer operations.


B) We use a 64Bit load counter and for each request we do not only add 
1, instead we add L_i whenever worker i gets chosen.


C) We always choose the eligible worker with the smallest load counter 
(and we can use a rotating offset like it is already implemented for 
traffic).


D) During maintenance we divide all load counters by some constant. Best 
would be a power of 2, so we can simply shift right all load counters. 
This way we shape the counters with a simple approximation of an 
exponential curve, so the influence of incrementing the counters in the 
past gets less important the longer away it is.


E) If we divide in D) by 2 each minute, then the counters will never 
exceed 2 times the maximum a counter can reach in a single minute.  For 
most weight factors and loads this will easily fit into a 64 Bit 
integer. We can furthermore care about overflows by prematurely shifting 
right whenever the counters get to big (with very high load aging the 
counters earlier on demand).


I could supply a patch including documentation. I think that would be 
low risk, because that patch would only influence how the load counters 
are handled, and would not interfere with changing worker status and 
decision logic.


Comments?

Rainer

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

Re: [Proposal] mod_jk lb changes

[Rainer Jung]

Good news.

Will you cut another mod_jk version close to 5.5.17 (it will be to late
for that one), or are you planning to keep 1.2.16 in development for at
least 1-2 weeks further on?

In any case I will prepare a patch.

Any other comments?

Mladen Turk wrote:

Rainer Jung wrote:

Hi List, hi Mladen (master of mod_jk):


I could supply a patch including documentation. I think that would be 
low risk, because that patch would only influence how the load 
counters are handled, and would not interfere with changing worker 
status and decision logic.


Comments?



That would be perfect. I agree with all your observations.
The major problem are long-running error workers, and your
proposal for maintain them like for the traffic method
is the most appropriate thought.

Regards,
Mladen.


-
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: [Proposal] mod_jk lb changes

[Rainer Jung]

OK, I expect to send the patches late Friday german time (tomorrow, but
in 3 minutes today).

Mladen Turk wrote:

Rainer Jung wrote:

Good news.

Will you cut another mod_jk version close to 5.5.17 (it will be to late
for that one), or are you planning to keep 1.2.16 in development for at
least 1-2 weeks further on?



We had a preliminary vote two weeks ago, and everyone agreed
to go for the 1.2.16, so if your patches
do not require any config changes we can include them within
1.2.16, because they are very valuable.

I suppose the jk will be out by next Friday.
I'll call for a vote as soon as you finish the
maintain for the request, so that folks have
a chance to test it.

Regards,
Mladen.

-
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: svn commit: r394031 - /tomcat/connectors/trunk/jni/native/os/unix/system.c

[Rainer Jung]

Hi Mladen,

I've got another one for that file. You optimized the original Solaris
contribution by changing division with a value to multiplication with
the reciprocal value. Unfortunately we are in integer land and the
divisor was bigger than 1, so now we always multiply by 0 :(

Patch attached an CC to mturk in case the attachment gets stripped.

Rainer

Index: jni/native/os/unix/system.c
===
--- jni/native/os/unix/system.c (revision 394052)
+++ jni/native/os/unix/system.c (working copy)
@@ -53,6 +53,7 @@
 #if defined(sun)
 #define MAX_PROC_PATH_LEN 64
 #define MAX_CPUS 512
+#define CPU_TIME_RESOLUTION 1000
 #define PSINFO_T_SZ sizeof(psinfo_t)
 #define PRUSAGE_T_SZ sizeof(prusage_t)
 
@@ -148,8 +149,7 @@
 int res = 0;   /* general result state */
 /* non-static variables - sysinfo/swapctl use */
 long ret_sysconf;  /* value returned from sysconf 
call */
-long tck_dividend; /* factor used by transforming 
tick numbers to milliseconds */
-long tck_divisor;  /* divisor used by transforming 
tick numbers to milliseconds */
+long tck_divisor;  /* divisor used for 
transforming tick numbers to time units */
 long sys_pagesize = sysconf(_SC_PAGESIZE); /* size of a system memory 
page in bytes */
 long sys_clk_tck = sysconf(_SC_CLK_TCK); /* number of system ticks per 
second */
 struct anoninfo info;  /* structure for information 
about sizes in anonymous memory system */
@@ -237,18 +237,7 @@
 rv = apr_get_os_error();
 }
 else {
-tck_dividend = 1000;
-tck_divisor = sys_clk_tck;
-for (i = 0; i < 3; i++) {
-if (tck_divisor % 2 == 0) {
-tck_divisor = tck_divisor / 2;
-tck_dividend = tck_dividend / 2;
-}
-if (tck_divisor % 5 == 0) {
-tck_divisor = tck_divisor / 5;
-tck_dividend = tck_dividend / 5;
-}
-}
+tck_divisor = sys_clk_tck / CPU_TIME_RESOLUTION;
 if (kstat_ctl == NULL) {
 kstat_ctl = kstat_open();
 kid = kstat_ctl->kc_chain_id;
@@ -276,12 +265,11 @@
 for (i = 0; i < cpu_count; i++) {
 new_kid = kstat_read(kstat_ctl, kstat_cpu[i], NULL);
 if (new_kid >= 0) {
-long tck_r = tck_dividend / tck_divisor;
 cpu = ((cpu_stat_t *)kstat_cpu[i]->ks_data)->cpu_sysinfo;
-pvals[7] += (jlong)(((long)cpu.cpu[CPU_IDLE]) * tck_r);
-pvals[7] += (jlong)(((long)cpu.cpu[CPU_WAIT]) * tck_r);
-pvals[8] += (jlong)(((long)cpu.cpu[CPU_KERNEL]) * tck_r);
-pvals[9] += (jlong)(((long)cpu.cpu[CPU_USER]) * tck_r);
+pvals[7] += (jlong)(((long)cpu.cpu[CPU_IDLE]) / 
tck_divisor);
+pvals[7] += (jlong)(((long)cpu.cpu[CPU_WAIT]) / 
tck_divisor);
+pvals[8] += (jlong)(((long)cpu.cpu[CPU_KERNEL]) / 
tck_divisor);
+pvals[9] += (jlong)(((long)cpu.cpu[CPU_USER]) / 
tck_divisor);
 }
 }
 }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC native 1.1.3 ready?

[Rainer Jung]

I sent a patch for the Solaris part of tcnative to Mladen and the list 
this morning which is not yet included. The Bug is *not* critical (CPU 
used and idle in the manager status page for Solaris will be 0 always).


Rainer

Yoav Shapira wrote:

Hi,
Is tcnative 1.1.3 ready?  The default build properties is still
choking when trying to download it from our archive location...

Yoav

--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

-
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: Vote for Refactoring ManagerBase/DeltaManager

[Rainer Jung]

Peter Rossbach wrote:
Yes, thing a real refactoring must start at ManagerBase. Then we get  a 
better interface for easier subclassing Manager like DeltaManager  at 
existing cluster and ha modules and other implementation like JBoss.


I thing we have now some options:

a) Refactoring at tomcat 5.5 later port to 6.0
b) Refactoring at tomcat 6.0 later backport to 5.5
c) no refactoring

I vote for a) +1

Peter


For me the right choice would depend on the size and risk of the 
refactoring. 5.5 is assumed to be pretty stable now. So I would have a 
tendency to vote for b) unless I get a better idea about how small and 
well-understood the changes would be.


Peter: since you think a) is the way to go: could you point out, what 
the amount of changes would be?


Thanks!

Rainer

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

Re: [VOTE] Tomcat v5.5.17 Stability

[Rainer Jung]

Apache Tomcat v5.5.17 is:
[X] Stable - no major issues


Tested with Java 1.6.0-beta2-b72 under Solaris 10 with a simple 2 node 
cluster in fastasync mode.




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

Re: The purpose of provided tomcat-users.xml

[Rainer Jung]

What about commented out entries for the admin and manager roles and 
resp. users and password set to "changeme"?



Peter Rossbach wrote:
Yes, defaults are very fine, but secret parameter need active user  
interaction.


also -1

Peter



Am 28.04.2006 um 11:54 schrieb Remy Maucherat:


Mladen Turk wrote:


Hi,
The provided tomcat-users.xml is obviously used
as an example.
Can we tweak that so that it actually allows
the admin and manager users?



Sorry, but it's a bad idea.


The purpose would be the same (example), but
it will allow to run the provided web apps without
additional editing.



And most people wouldn't be changing them, creating a security  problem.


Any objections if I put the 'real' values there?



-1.

Rémy



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

Re: Memory leak? (issues.apache.org)

[Rainer Jung]

I'm wondering if we should split the (possibly huge) char arrays in 
BodyContentImpl into smaller chunks of char arrays. Each chunk will be 
able to grow big enough to handle the usual cases efficiently (e.g. 
64KB). Whenever a bigger size is needed we allocate more of these chunks 
from a pool. After using the BodyContentImpl we give back all chunks 
except for the first to the chunk pool.


This way performance should not really suffer, but the char arrays can 
be efficiently shrinked for apps needing generating large responses 
every now and then.


The case in which this will be worse is, when most of the requests 
generate large responses. For this case, maximum chunk size could be 
configurable.


I didn't dig through the code, whether the change from a simple char 
array to a flexible list of char arrays will be a difficult one, but I 
will go through it and try to implement it, if there's no big warning 
coming from the list.


Remy Maucherat wrote:

Jeff Turner wrote:


1 May:  93 Objects (126Mb)
2 May:  107 Objects (263Mb)
3 May:  492 Objects (486MB)



BodyContentImpls are pooled and reused since it makes JSP processing 
significantly faster. If the application is evil, and uses body tags 
with huge bodies (it seems to be the case here), then there could be a 
problem.


Large buffers may be discarded after usage, by setting the 
"org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER" system property 
to "true". Unfortunately, performance will go down and GC activity will 
go up.


If you would like to limit the amount of resident memory that is used, 
you can disable pooling of buffer objects completely using the 
"org.apache.jasper.runtime.JspFactoryImpl.USE_POOL" system property set 
to "false". The performance will go down further due to object 
allocations and GC activity, but you may have a few CPU cycles to spare.


BTW, you can set system properties in the catalina.properties file 
(although you may set them on the command line too).


Rémy

-
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]

TC 6: What needs to be done?

[Rainer Jung]

Hi,

Remy started a thread talking about source tree reorg. It soon turned 
into a discussion about various integration questions.


I would be interested in discussing a couple of questions concerning TC 
6, most of them already came up during the last week. I hope it's not to 
much shortly before the weekend :)


My focus is: do other commiters also think some of these things should 
be improved, and who would be willing to care about some of these topics.


1) Configuration Management
===

My impreesion is, that to much configuration is hard-coded in RuleSet 
classes. Of course everyone can easily add properties to existing 
components, but adding subcomponents nedds changes in core RuleSet 
classes. Am I wrong? Should we change that to allow more complex 
subsystems handling their configuration rules independently of the core? 
One such example is the current stable clusster module.


2) Deployer
===

Is it worth trying to implement a new deployer? I've no concrete design 
in my head now, but I had the impression, that although the current 
deployer works, there is an option that a redesign would make it more 
user friendly.


3) Manager
==

There is a lot of code duplication between the different Manager 
implementations. Some refactoring will help.


4) Core vs. Component Bundling, especially Cluster Module
=

What should be included in the core download. I'm not really talking 
about the code structure in subversion. It's the question of the right 
size of standard download. I think the current bundlings are OK, except 
that we have to decide how to handle the cluster modules. Any more 
module like things coming up?


Concerning the cluster modules: I would propose to make both of them 
optional modules. For this to be easily usable one question will be, 
what the user has to do, to integrate his cluster download into the core 
distribution. At the moment, the cluster config for the stable version 
is already contained in server.xml. Here the discussion has a close 
relation to 1). I think it would help to be able to simply change the 
cluster module used via config/system property inside a core 
configuration and to configure the details of clustering itself inside a 
configuration object provided by the additional cluster module download.


5) Default Cluster
==

Assuming that we will provide an easy way of switching between the 
implementations, we should decide on the default cluster module, when 
the time for the first 6.0 beta is coming closer. The main criterium 
then should be code stability for the new module.


In every case we need to support usage of the old module with TC 6, so i 
think it needs to stay compatible. but we should clearly state, that the 
old module will no longer be actively developped and we should even 
deprecate it in TC 6, so we don't need to support it behind TC 6.


6) Timeline
===

How much we will change for TC 6 also depends on how much time we are 
willing to give it. Is there any time limit we should preserve, to 
deliver a JEE 5 web container not too far behind the standard approval? 
I assujme everyone wants TC 6 to show up before end of the year (beta), 
but how much earlier will it need to be available?


7) Build, Test
==

I think automated Gump builds should be helpful. Is there a need for 
more automted testing?


Mnny questions, not so many opinions in this mail. But I think it's the 
right time to discuss about these topics to form a consensus about TC 6.


- Rainer


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

Re: Memory leak? (issues.apache.org)

[Rainer Jung]

... and I definitely want to choose the size of one chunk not to small,
e.g. one of the will be able to grow until 64KB, so that usually you 
will only need one of them. Only for jumbo pages we will start gluing 
them together...


So I'll dig my head into BodyContentImpl ...

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:


Rainer Jung wrote:

I'm wondering if we should split the (possibly huge) char arrays in 
BodyContentImpl into smaller chunks of char arrays. Each chunk will 
be able to grow big enough to handle the usual cases efficiently 
(e.g. 64KB). Whenever a bigger size is needed we allocate more of 
these chunks from a pool. After using the BodyContentImpl we give 
back all chunks except for the first to the chunk pool.


This way performance should not really suffer, but the char arrays 
can be efficiently shrinked for apps needing generating large 
responses every now and then.



This could be a good idea, but performance would suffer, I think: if 
one request needs 100 buffers, then you'll have 100 synced operations 
to retrieve them from the pool (only one to put them back, hopefully 
;)). It could then be cheaper to always allocate new objects.


yes, but in TC6 we can use java.util.concurrent, and get a little bit 
more juice out of it, there is a pretty big difference between the lock 
free thread safe operations and the lock algo ones we use today 
(synchronized)



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

Re: TC 6: What needs to be done?

[Rainer Jung]

So people think it TC 6 should be focused on JEE 5 compatibility and 
other major changes should only be done, if they pose no risk on an 
early date. Somehow we are to late in the J2EE time frame.


On the other hand, major changes to e.g. the configuration management 
should not be done for a release that looks like a minor release (6.1), 
because then users will be very irritated that they have to learn a very 
new configuration world. So as a consequence we might need to prepare 
for a TC 6.5 or TC 7 until end of this year?


This will look strange at a first glance (why two major releases so 
shortly after each other), but if we decide to focus TC 6 on JEE 5 
compatibility and early delivery it looks like a logical consequence.


- Rainer

Jess Holle wrote:

[EMAIL PROTECTED] wrote:

Would it be suitable to focus on JEE 5 compliance in the short run for 
a soon to be released TC 6, then enhance the value adds of TC for a 
6.1 release later this year?
  


That sounds a lot better to me...

--
Jess Holle

-
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: Memory leak? (issues.apache.org)

[Rainer Jung]

From my understanding PageContextImpls are pooled, but not the JSP 
output (body). Those are written using JspWriterImpls that buffer only 
8KB of output.


If you are using tags, then their content is kept in a char array inside 
BodyContentImpls. Each (pooled) PageContextImpl has a stack of these and 
the stack and the BodyContentImpl including the char array are not 
resized after usage. The pooled PageContextImpl keeps references to those.


The LIMIT_BUFFER makes the BodyContentImpl resizing to 512 Bytes in case 
it grew larger.


Jeff Turner wrote:

Hi,

On Thu, May 04, 2006 at 11:10:20AM +0200, Remy Maucherat wrote:

Jeff Turner wrote:

1 May:  93 Objects (126Mb)
2 May:  107 Objects (263Mb)
3 May:  492 Objects (486MB)
BodyContentImpls are pooled and reused since it makes JSP processing 
significantly faster. If the application is evil, and uses body tags 
with huge bodies (it seems to be the case here), then there could be a 
problem.


Just wondering - are all JSP bodies pooled, or only tag bodies? Eg.
would this JSP's body be pooled:

<%= for (int i=0; i<100; i++) { out.print("womble"); } %>

Or only if it were wrapped in JSP tag.

Large buffers may be discarded after usage, by setting the 
"org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER" system property 
to "true". Unfortunately, performance will go down and GC activity will 
go up.


It appears to have fixed the leak on issues.a.o.


Cheers,
Jeff

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


--
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
53111 Bonn

Tel.: 0228/98549-0
Fax:  0228/98549-50
www.kippdata.de
===
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
D-53111 Bonn

Tel.: +49/0228/98549-0
Fax:  +49/0228/98549-50
www.kippdata.de

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

Re: svn commit: r537640 - /tomcat/connectors/trunk/jk/native/configure.in

[Rainer Jung]

Mladen Turk wrote:

[EMAIL PROTECTED] wrote:

Rearrange configure.in, such that in case we
got with-apxs we detect CC from apxs and warn,
if the CC environment variable differs.


Is this really needed?
I mean having that the apxs wouldn't work for
any custom module thought.

I think that instead fixing other people mistakes
(here I mean the package producers) we should only
give our users 'howto' instead trying to fix whatever
(in this example Debian maker of httpd) fault might be.
If we start doing that, then we can forget libtool at all.

>

What I have read about the subject the reason for the
patch is because of platform or libtool.
I wonder if on that platform any apxs command can be done.
If not, and if it's cause either because of platform or
libtool bug we should not try to maintain out patches
just to address those issues. I'm sure the user
community will address those problems to the originators
of the bugs itself.


Actually I was running into the same problem long ago myself, without 
any platform being guilty and the problem is not very well documented 
(w.r.t. Google).


I regularly build httpd with a different specs file for GCC to 
statically link in libgcc. To do this, the stablest way is setting 
CC="gcc -specs=/my/specsfile".


If you do something like this, the libtool generated while building 
httpd will contain


CC="gcc -specs=/my/specsfile"

If you use this libtool later on with a value of CC which does not start 
with "gcc -specs=/my/specsfile", libtool throws an error and your build 
will stop.


So I think the problem is the subtle way the build toolchain depends on 
the build environment during httpd build vs. mod_jk build. Warning in 
case of incompatibilities seems to be reasonable.


At least 90% of this patch are coming from moving the with-apxs part in 
front. Only few logic was added to configure.in: setting CC from apxs 
(if it is not set in the environment), before running the compiler tests 
and the final warning about differences between apxs CC and environment CC.


This way, we learn the CC command from apxs (as we should) and we warn, 
if there are incompatibilities with what the user has chosen.



That's why, -1 on anything trying to 'patch' the
misbehavior of the documented tools for any platform.


I think it's not trying to patch misbehaviour, but simply using the 
toolchain to build extension modules for httpd in the way it is meant to 
be. There is a good reason for "apxs -q CC" and we already used "apxs -q 
CFLAGS".


I would have preferred the documentation thing, if there wouldn't have 
been a clean way to rearrange the configure.in, but I don't see a new 
problem from the way it is now (maybe i'm simply blind).



Regards,
Mladen


Still vetoing?

Regards,

Rainer

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

Re: svn commit: r537640 - /tomcat/connectors/trunk/jk/native/configure.in

[Rainer Jung]

Mladen Turk wrote:

Rainer Jung wrote:


Still vetoing?



No, I just said that I don't like the way we
try to fix other peoples faults.
I'm sure it would leads us to no where pretty soon.

What I'm saying is that the problem you fixed
is not something all of our users are seeing.
It is *platform* dependent, and that's all.

I'm -1 on starting to fix what-ever-we-can-fix
just because some tool is broken on one platform,
and its usage clearly states that we use it correctly.

So, it's not an veto, cause it works on platforms
that are not affected with tools or build bugs,
but like said, we'll pretty soon end up to nowhere
if we try to maintain our build in such way.
Just imagine, what if libtool folks fix that?
Our patch will be obsolete, or we'll end up on
checking the features or bug fixes depending on the
libtool vesion used.


Agreed.


It is clear that we are using both libtool and
apxs according to the specs. If some platform
has a wrong or invalid version of the tool it's
not our problem, and IMHO we would make a big
mistake if we continue to fix that.


Not totally agreed: we didn't try to detect the compiler used to build 
httpd via apxs in the old version. We do now, at least if the user 
doesn't set one himself. I think that's more according to the way apxs 
should be used. We already did that for CFLAGS.


Most of the time this doesn't count, because it's gcc, gcc, gcc, ...


Regards,
Mladen.


Have a nice evening.

Rainer

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

Re: Changing JK_OPT_FWDURIDEFAULT to JK_OPT_FWDURICOMPATUNPARSED

[Rainer Jung]

I didn't follow this, but the comment in the httpd 2.x module code says:

/*
 * The 2.2 servlet spec errata says the uri from
 * HttpServletRequest.getRequestURI() should remain encoded.
 * [http://java.sun.com/products/servlet/errata_042700.html]
 *
 * We use JkOptions to determine which method to be used
 *
 * ap_escape_uri is the latest recommanded but require
 *   some java decoding (in TC 3.3 rc2)
 *
 * unparsed_uri is used for strict compliance with spec and
 *  old Tomcat (3.2.3 for example)
 *
 * uri is use for compatibilty with mod_rewrite with old Tomcats
 */

We do (pseudo code):

JK_OPT_FWDURICOMPATUNPARSED:
s->req_uri = r->unparsed_uri;
if (s->req_uri != NULL) {
char *query_str = strchr(s->req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}

JK_OPT_FWDURICOMPAT (the DEFAULT):
s->req_uri = r->uri;

JK_OPT_FWDURIESCAPED:
s->req_uri = ap_escape_uri(r->pool, r->uri);
break;


And finally our docs state:

The three following options +ForwardURIxxx are mutually exclusive. ...
By default, the option ForwardURICompat is turned on. You can turn this 
off by switching on one of the other two.


JkOptions ForwardURICompat, you ask mod_jk to send the URI to Tomcat 
normally, which is less spec compliant but mod_rewrite compatible, use 
it for compatibility with Tomcat 3.2.x engines (on by default).


JkOptions ForwardURICompatUnparsed, the forwarded URI is unparsed, it's 
spec compliant but broke mod_rewrite.


JkOptions ForwardURIEscaped, the forwarded URI is escaped and Tomcat 
(since 3.3 rc2) will do the decoding part.


So what we do is what is documented. Breaking the default should have 
serious reasons at least. For 1.3/3.0 we could consider changing more 
easily of course.


Why do you think the default is bad?

Regards,

Rainer

Jean-Frederic wrote:

Hi,

I think that the default value of JK_OPT_FWDURIDEFAULT is bad and should
be JK_OPT_FWDURICOMPATUNPARSED.

Any comments?

Cheers

Jean-Frederic


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

Re: Changing JK_OPT_FWDURIDEFAULT to JK_OPT_FWDURICOMPATUNPARSED

[Rainer Jung]

Why do you think the default is bad?


Because it breaks the spec's and allows unexpected handling of url that
are encoded (for example: /context-A/%252E%252E/context-B that is send
to Tomcat as /context-A/%2E%2E/context-B and mapped by Tomcat
as /context-B).


So what how do you suggest to handle a change.

- Being secure by default, i.e. really changing the default in 1.2 and 
putting a big note about it in the docs, the news page and maybe the 
download README


or/and

- Staying compatible in 1.2, changing in 1.3 but putting a big note in 
the docs page about the options concerning the security relevance of the 
options.


Regards,

Rainer

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

[VOTE] Releasing Tomcat Connectors 1.2.23

[Rainer Jung]

Hello to all Tomcat project members,

mod_jk 1.2.23 is available for testing under

http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/

It has been created from a branch based on 1.2.22 with only one code 
change (default forwarding option for Apache httpd module) and the 
corresponding clarification in the docs.


Please have a look. The updated documentation can be found at

http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/jk-1.2.23

So here's the vote. Because we need to release soon, the vote, which 
will be open until today, Friday May 18, 24:00 GMT. I know this is 
pretty short, but I'm confident, that all usual suspects are on board.


Apache Tomcat Connectors 1.2.23 is:
[ ] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are

Thank you,

Rainer


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

Re: [VOTE] Releasing Tomcat Connectors 1.2.23

[Rainer Jung]

Apache Tomcat Connectors 1.2.23 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are


Tested on Linux 64 Bit.

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

Re: New branch ?

[Rainer Jung]

Hi,

I think Yoav might have misunderstood your suggestion. I interprete the 
branch you posted as the one, you suggest to use for the maintenance of 
the existing 6.0.x source and to use trunk to proceed with working on 
annotations, comet etc.


What I would find a little strange, would be using

http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/

as the trunk and working on 6.next there. Unfortunately svn does neither 
have tags nor branches, so we are free to produce very complicated 
constructions if we like :)


My impression is, that

http://svn.apache.org/repos/asf/tomcat/tc6.0.x/

in fact is a branch, namely the 6.0 development branch and should 
contain all 6.0 development. The mainstream parts in


http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/

(it's actually the head of 6.0), the more experimental parts, which are 
still planned for first release in 6.0 and not in 6.next would be 
developped in


http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches

So development which is targeted against 6.next in my opinion should go 
into


http://svn.apache.org/repos/asf/tomcat/trunk/

(which means we would have several paths with the word trunk in them) or 
we reorganize (puuh) by moving


http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/

into

http://svn.apache.org/repos/asf/tomcat/branches/tc6.0.x/
http://svn.apache.org/repos/asf/tomcat/branches/
http://svn.apache.org/repos/asf/tomcat/tags/

and delete the then empty 
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/


Of course this will break a lot and at the end we will most likely use a 
construction close to what we have now, but this layout seems to be the 
most traditional.


Regards,

Rainer

Remy Maucherat wrote:

Yoav Shapira wrote:

Hola,

On 5/18/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:

http(s)://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/tc6.0.x ?


Or 
http(s)://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/annotationsAndComet 



If it gets that experimental, it should go to the sandbox instead. 
Overall, I don't like a branch named against a random feature.


If development remains in trunk, then the version number or eventual 
release is not implied by anything.


Rémy


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

[RESULT][VOTE] Releasing Tomcat Connectors 1.2.23

[Rainer Jung]

We received five stable votes (Mark, Mladen, Günter, Jim and me) and no 
other votes.


Since we should do this release quick, I'm now starting to publish the 
release.


Thanks to everyone who helped in immediate testing!

Regards,

Rainer


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

[ANN] Apache Tomcat JK 1.2.23 Web Server Connector released

[Rainer Jung]

The Apache Tomcat team is pleased to announce the immediate availability
of version 1.2.23 of the Apache Tomcat Connectors.

It contains connectors, which allow a web server such as Apache HTTPD,
Microsoft IIS and Sun Web Server to act as a front end to the Tomcat web
application server.

This version contains only one security fix:

CVE-2007-1860: Information disclosure
(patch for CVE-2007-0450 was insufficient)

With the mod_jk default configuration, double encoded URLs could break 
JkMount access control. A complete fix might need configuration 
adjustments. Please consult


http://tomcat.apache.org/security-jk.html

for a more detailed description. Please note, that this issue only 
affected the Apache HTTPD module mod_jk.


Source distribtions can be downloaded from an
Apache Software Foundation mirror at:

http://tomcat.apache.org/download-connectors.cgi

Binary distributions for a number of different operating systems and
web servers can be downloaded from an
Apache Software Foundation mirror at:

http://tomcat.apache.org/download-connectors.cgi

Documentation for using JK with Tomcat 3.3, 4.1, 5.0 and 5.5
can be found at:

http://tomcat.apache.org/connectors-doc/

Thank you,

-- The Apache Tomcat Team




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

Improving mod_jk URI forwarding

[Rainer Jung]

Hi,

now that we changed the default way how to forward URIs from mod_jk to 
Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to 
propose a better long term solution.


What's the problem?
===

- Access control is often defined in terms of URI prefixes, because they 
are mapped to web applications


- URIs can contain character sequences that change the URI prefix (like 
"/../"


- URIs can contain encoded characters

The general rule to apply access control is to first decode encoded 
characters, then normalize the path by resolving the special character 
sequences and then apply access control.


In a system with cascaded components we might check access control on a 
frontend component but finally process the request on a backend 
component. The backend component might not know about the frontend 
component and thus again decode and normalize the request URI.


Now it becomes important, that the result of this decode and normalize 
on the backend does not differ from decode and normalize on the 
frontend, which did the access control check. It is especially 
important, that decoding is not done twice in a row, because then a 
malicious user could use double encoded special character sequences.


How do we handle it in mod_jk
=

By default, we now chose to forward the original undecoded and 
unnormalized URL via mod_jk to Tomcat. Unfortunately this has serious 
drawbacks, because all  internal Apache httpd processing is done on the 
decoded normalized URL. One such example is mod_rewrite. Combinations of 
mod_rewrite and mod_jk are typical for more complex sites. mod_rewrite 
is only able to rewrite the decoded normalized URI, so any rewriting 
gets obsolete if mod_jk forwards the original request URI.


The other two existing options in mod_jk are forwarding the decoded 
request (which results in the double encode issue) and forwarding an 
encoded form of the decoded request.


The last option sounds interesting, but has a massive drawback. It uses 
Apache httpd encode function, which also encodes ';' as "%3B". But at 
the moment the AJP connector on the Tomcat side looks for session IDs in 
the request URI before decoding the URI. It only checks for 
";jsessionid=" and not for "%3bjsessionid=" or "%3Bjsessionid=".


What do I propose
=

My proposal is to use the encoded URI to forward to Tomcat. This should 
be safe, because encoding before forwarding and afterwards decoding in 
Tomcat should be the identity. To keep mod_jk compatible with the 
existing AJP connector, I suggest to use a variant of ForwardURIEscaped, 
where we escape all the characters we escape with ForwardURIEscaped, 
except for the semicolon ';'. This should still be safe, because the 
percent sign is the decoding indicator and we wil still encode '%' as 
'%25' to prevent double decoding.


Another option would be to only encode '%' when forwarding. For the same 
reasons this should be save and will produce less overhead.


I did a test implementation for the both approaches. Patches are under

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

(for 1.2.23 and for trunk).

The new options are "JkOption ForwardURIEscapedPartial" (do not escape 
';') and "JkOption ForwardURIEscapedMinimal" (only escape '%').


I only tested the patch against trunk, but the 1.2.23 port I coded is 
completely straightforward, so it should also work.


Could you please think about the problem and test if you still find a 
way to break the partial or minimal escaping solution? No directory 
traversal should be possible and both should work well with mod_rewrite 
and URL encoded session IDs. Maybe you can think of other ways breaking 
the combination mod_jk/Tomcat, which are not related to double encoding.


Since we have 1.2.23 out, there is no hurry. I would welcome comments on 
the safety of this approach.


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Mladen Turk wrote:

My proposal is that we make our own decoder if the URI is encoded
and then do a match and forward that.



As far as I understand you suggestion, this would not help.
There's nothing wrong with "our" decoder (the httpd decoder), what's 
wrong is, that the decoded URI gets decoded a second time by Tomcat. 
Double decoding is the fault (there's a nice comment about that in httpd 
source code).



Hope I don't speak complete rubbish :)

Anyhow, I simply don't like adding new features and options.
Think we done a lot of them recently.

If there is a problem we should hide the problem from
the user and do that internally instead adding new config.


I think the new proposed way of forwarding (the '%' encoding) is the 
one, which will efficiently hide the problem.


The point why we can't just let things stay like they are now is,

- one option does not work with mod_rewrite
- one option is not safe
- one option does not work with URL encoded sessions IDs

This is not new, it's like that since a long time. What is new, is that 
we now take the unsafety serious and end up with either broken sessions 
or broken mod_rewrite interop.


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Jean-Frederic wrote:

On Sat, 2007-05-19 at 14:27 +0200, Rainer Jung wrote:

Hi,

now that we changed the default way how to forward URIs from mod_jk to 
Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to 
propose a better long term solution.


What's the problem?
===


I think we still miss something... The mapping (map_uri_to_worker) uses
r->uri. Should we use s->req_uri or a carefully normalised uri to do the
mapping? Fixing s->req_uri doesn't help to fix the mapping (where the
problem comes from).


Yes, the mapping uses r->uri, and it has to, because the maping must go 
against a uudecoded normalized URI. But to be consistent with Tomcats 
view of the URI, we should send a URI to Tomcat, which gets interpreted 
in the same way. My proposal is to send r->uri to Tomcat with encoded 
'%'. That way decoding by Tomcat should result in the same URI r->uri 
and since this one was already normalized by Apache, Tomcat 
normalization should not change it any more.


So fixing s->req_uri in my opinion does help to fix the mapping (which 
was correct!), because it prevents Tomcat from changing the URI in a 
wrong way.


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Mladen Turk wrote:

You got me wrong. I suggest we decode the encoded uri, do mapping,
remove ;jsessionid=xxx and send that to the Tomcat.
This way tomcat won't have double encoding issue.
And it's completely legitimate if we comply to the RFC.

This would also solve malicious mapping attempts like /app1/../app2
before they even hit tomcat.


It would not help. Tomcat *does* another decoding in the connector!

If the URI contains %252e%252e (example) httpd correctly decodes this as 
%2e%2e and it is correct to not decode this a second time. httpd and 
mod_jk do not normalize this away after the first decoding, because it 
is not equal to "..". So if we forward the decoded and normalized URI to 
Tomcat, the Tomcat connector decodes a second time and then this will be 
".." and normalized away on the Tomcat side.


Furthermore: I don't understand your comment about removing 
";jsessionid". We cannot remove it, this will kill the session. But as 
you know that yourself I must have misunderstood your first sentence.


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Jean-Frederic wrote:

What about url like /context-a/../context-b/?
There could be a problem if the goal is not to map /context-b.
Should we normalise /context-a/../context-b/ to /context-b and then do
the mapping.


If the *original* URI is "/context-a/../context-b/" then apache httpd 
normalizes this (correctly) to "/context-b/". If JkMount matches 
/conext-a" we don't forward, if it matches "/context-b" we forward. I 
don't get the point here. What kind of problem (encoding, decoding, 
mod_jk, Tomcat) do you want to produce with sch a URI?


By the way: for such a simple URI httpd and Tomcat both do the same 
normalization (resulting in "/context-b").


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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Mladen Turk wrote:

Jean-Frederic wrote:


What about url like /context-a/../context-b/?
There could be a problem if the goal is not to map /context-b.
Should we normalise /context-a/../context-b/ to /context-b and then do
the mapping.



Yes. It would require some programming of course, but
it'll solve the issues without adding extra config options.


??

This normalization is already done by httpd and used in mod_jk, totally 
independent of the existing forwarding option. Request without any 
special characters are not my concern here. For those simple requests of 
course all existing forwarding options result in the same forwarded URI.


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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Look, what I'm saying is that we should simplify all the JkOptions
ForwardURI* . IMHO they all originate from the fact that uri in the Apache
can come from multiple pre-processing stages that modify the original
URI. The solution is very simple but it would require that we write
the URI decoder. When the uri comes to the mod_jk before doing any mapping
or anything else we should decode that uri and then use it,
and send that uri to the Tomcat (the one we rewrote).


OK Mladen, I understand that, but I think it's not correct. I read the 
discussion threads from 2001 which let to those options and they come 
from the fact, that different Tomcat version handle the forwarded URIs 
in different ways. I think this part of the discussion is in fact only 
historic and yes I agree we don't actually need those options any more.


But: none of the existing options does the right thing. That's why I 
suggested another way of handling the forward. I think my sugeggested 
variant "forward r->uri with encoded '%'" is the right way of handling it.


And no: I don't think we need our own decoder. Apache http decoder is OK 
(as long as we talk about httpd). It does nothing wrong. For instance it 
would be very bad to instead decode iteratively until not more '%' are 
in the URL, that's definitely wrong.


Decoding and forwarding the result to Tomcat is exactly our default 
until 1.2.22 and produces the security problem. There's nothing wrong 
with the decoder, only with decoding two times, once in mod_jk and a 
second time in Tomcat.


Regards,

Rainer



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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Mladen Turk wrote:

Rainer Jung wrote:


OK Mladen, I understand that, but I think it's not correct.


Might be.



But: none of the existing options does the right thing. That's why I 
suggested another way of handling the forward. I think my sugeggested 
variant "forward r->uri with encoded '%'" is the right way of handling 
it.




So, what is the actual problem. If there is something that is
potentially malicious we should deal with that without any specific
additional config.

Can you write a simple example of the uris that make the problem
and why we would need to encode the %.

How it is passed now, and how it would be passed with your
proposal.


Original URI:

/myapp/%252e%252e/otherapp/danger

JkMount /myapp/*

Apache httpd will correctly decode the URI to

/myapp/%2e%2e/otherapp/danger

mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.

How does it forward it? That depends on the chosen forwarding option.

Old default: forwarding as /myapp/%2e%2e/otherapp/danger

Tomcat's AJP connector now does an automatic decoding of the request, 
which ends up as /myapp/../otherapp/danger. Then Tomcat normalizes this 
as /otherapp/danger and we serve content from a context we didn't want to.


The other options we have at the moment:

New default: forwarding the original request URI 
"/myapp/%252e%252e/otherapp/danger". Tomcat does decoding to 
"/myapp/%2e%2e/otherapp/danger" and there is no normalization possible. 
So Tomcat checks for something called %2e%2e/otherapp/danger in the 
context /myapp and will most likely find nothing, so throw an error.


3rd option (escaped forwarding): will forward 
"/myapp/%252e%252e/otherapp/danger", so the same result as with our new 
default (OK).


The problem is: the new default ignores rewrites done by mod_rewrite and 
a lot of people use mod_rewrite together with mod_jk.


The third option, that also fixes the problem will break any normal 
request with a jsessionid:


"/myapp/valid;jsessionid=12345" gets forwarded as 
"/myapp/valid%3Bjsessionid=12345" and Tomcat's AJP connector does not 
detect the jsessionid and Tomcat actually looks for a ressource 
valid%3Bjsessionid=12345 in /myapp.


My proposal: forward the httpd internal URI with only encoded '%':

So we would forward "/myapp/%252e%252e/otherapp/danger" but keep 
compatibility with mod_rewrite and with jsessionid.


Of course one could als improve the situation by changing the AJP 
connector implementation on the Tomcat side and in the long run this 
might be interesting, but I find my suggestion better, because:


- it will be compatible with existing Tomcat AJP connector
- it should solve al three problems (security, mod_rewrite, jsessionid)
- it is not heavy on performance, we only need to do something if the 
request after httpd decoding still has a '%' in it.


What I would like very much, if anybody would think about URIs maybe 
breaking this %' encoding construction. I personally think it's safe, 
because encoding '%' in a decoded URI and afterwards decoding again 
should behave as the identity on the URI. So Tomcat at the end should 
work on the same URI, that we have used for our matching.


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Maybe that helps: mod_proxy_ajp (httpd 2.2.4) does something very similar.

In mod_proxy_ajp.c function proxy_ajp_canon() calls ap_proxy_canonenc().

This function for a reverse proxy request does encode a couple of chars 
in the already decoded URI before forwarding it. It encodes all chars 
except: a-zA-Z0-9 (alnum) and "$-_.+!*'(),;:@&=". So '%' will be encoded 
before forwardin and ';' not. This behaviour fits to my theory, but none 
of our options are close to this.


We could also borrow the behaviour/code from there.

Regards,

Rainer


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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Before I answer, let me first ask a question: What's wrong withg my 
suggestion? Or even better: use the encoding done with mod_proxy_ajp?



Original URI:

/myapp/%252e%252e/otherapp/danger

JkMount /myapp/*

Apache httpd will correctly decode the URI to

/myapp/%2e%2e/otherapp/danger

mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.



It does not IMO, and that's what I'm talking.
Inside mod_jk we should decode
/myapp/%2e%2e/otherapp/danger to
/myapp/../otherapp/danger


No, If the original URI was /myapp/%252e%252e/otherapp/danger, then it 
is not correct to end up with /otherapp/danger as a decoded URL. A 
percent sign is a valid character in a ressource path. If one wants to 
use it in ressource paths, one needs to encode it ('%25'), and it is not 
allowed to decode '%25XX' again after decoding to '%XX' once.


So %252e -> %2e and that's it, no further decoding. It is not a '.', 
because it is decoded already.


Why do you think, that

/myapp/%252e%252e/otherapp/danger

is equivalent to

/myapp/../otherapp/danger ?


Do a normalization of the uri that will end up as
/otherapp/danger before hitting map_uri_to_worker
If there is no JkMount for /otherapp/ it will be
denied, if it is, the rewritten uri /otherapp/danger
will be send instead /myapp/%2e%2e/otherapp/danger.
Of course we can simply send /myapp/%2e%2e/otherapp/danger
to tomcat if the match is OK for /otherapp/,
and let the tomcat do a normalization once again.


As I said, double decoding ("again") is not allowed and is the source of 
all evil.



In that case we won't need to encode the normalized
uri inside mod_jk once more.


I'm sure we need to, because double encoding is not allowed, but Tomcat 
unfortunately does a second decoding.


Some evidence:

0) RFC 2396, RFC 3986
=

http://www.ietf.org/rfc/rfc2396.txt

Section 2.4.2. When to Escape and Unescape:

"Implementers should be careful not to
   escape or unescape the same string more than once, since unescaping
   an already unescaped string might lead to misinterpreting a percent
   data character as another escaped character, or vice versa in the
   case of escaping an already escaped string."

and even stricter the younger

http://tools.ietf.org/html/rfc3986

2.4. When to Encode or Decode

"Implementations must not
   percent-encode or decode the same string more than once, as decoding
   an already decoded string might lead to misinterpreting a percent
   data octet as the beginning of a percent-encoding, or vice versa in
   the case of percent-encoding an already percent-encoded string."

1) IIS Bug
==

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0333

which leads to

http://www.microsoft.com/technet/security/Bulletin/MS01-026.mspx

"What's wrong with the decoding operation?
There's nothing wrong with the decoding operation per se. The 
vulnerability results because, through an implementation flaw, the 
decoding operation is performed a second time, after the security checks 
on the request have been completed."


2) mod_security Bug
===

http://www.modsecurity.org/download/CHANGES

"BUG Fixed a double URL-decoding bug (Apache first, then us), which
could sometimes lead to a false positive."

3) DAV Bugs
===

http://dav.sourceforge.net/

"The following bugs should have gone:

* [ 1519718 ] davfs2 fails to properly decode complex escape sequences
* [ 1522903 ] chokes on directory names containing ' _ % characters
* [ 1539444 ] mounting of webdav drive fails
* [ 1539445 ] unable to access files in mounted webdav drive
* [ 1558525 ] davfs2-1.0.2_p20060820 mount fails

These bugs were related to ... and incorrect double url-decoding of urls."

Regards,

Rainer

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

Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released

[Rainer Jung]

I'm trying to follow this thread, I hope i'm not duplicating things.

Mark Thomas wrote:

Guenter Knauf wrote:

this makes me ask a couple of questions:

Remember we only *have* to make the source available. Anything we do
on the binary front is just being helpful and the release manager is
unlikely to have access to build binaries for all platforms.


1) why do some folders list older versions while others do not?

Probably because they are the latest stable version for that platform.


Yes, I tried to delete all older versions of binaries (tried = as far as 
permissions allowed), but for sme platforms we don't have 1.2.23 
binares, so I kept the latest available ones.


There is an open point, if we can find a way of distributing contributed 
builds. I know we could get some, but there were valid concerns, if we 
shold sign those with our own keys. So we would need some notion of 
"contributed" and could put the binaries there.



2) why do we have a history of the last 3 versions with Win32 but no history 
for any other platform?

Because the old version weren't cleaned out. They should have been.


I had no permissions to delete them, I'll write to the owners directly 
to remove them.



3) where do the older versions go?

They are automatically copied to archive.apache.org which is linked
off the Tomcat homepage.


4) why do we prefix the directories with 'jk-' although 'jk' is already in the 
path?

No particular reason I am aware of. We just do.


Seems to be history, and you decided to drop it for Netware :)


For NetWare I would like to have at least the 1.2.15 release up again since 
that was last version where I supported Apache 1.3.x and Netscape - I point to 
this version in the README but obviously nobody can download anymore (except 
from my personal homedir). Sure its no problem for me just copy this over, but 
first I wanted to discuss that here, and ask if I probably missed that there's 
somewhere an archive from where older versions can be downloaded...

This is not correct. It is available along with all other versions in
the archive.


Then I would like to have at least the last three versions always up, + the 
last version we have for any platforms where we cant build self, or where the 
maintainer is currently busy and some versions behind.

-1.
dist (and the mirrors) should only have the current stable version and
 the latest non-stable release if there has been once since the last
stable release.


This makes also sense in case it turns out later that we broke something with a 
release, and users may have to switch back.

Again, that is what the archives are for.


So if the archives are important, we could replace the link text 
"archives..." with something a little more prominent. Suggestions?


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

Re: [VOTE] Release build 6.0.13

[Rainer Jung]

I fixed this (BZ 42459) now in r539895.

Remy Maucherat wrote:

Tim Funk wrote:

The only 2 things I noticed (which aren't a big deal)

The index pages had a bad links to the docs. (Now fixed)

The status screen has a rendering bug when a webapp is stopped. I 
didn't have a chance to dig into it - but its not a big deal either.


I can confirm this. It does not prevent using the page, but it becomes a 
bit hard to read.


Rémy


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

Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released

[Rainer Jung]

Then I found on the main docu page:
http://tomcat.apache.org/connectors-doc/
that there are direct links to the previous source versions, but all end up in 
a 'NOT FOUND';
should we change these to point to the archive now?

I would point all of these to the download pages. We should never
include links directly to the Apache download area fo rthe latest
release. We should use the mirrors. Pointing to our download pages is
the quickest way of doing this.


Good point. I'll look into the index page and the various news pages to 
make their links more lasting. Unfortunately since the download script 
has no intelligence concerning old releases and the archive this will 
also mean making them more unspecific.


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Jean-Frederic wrote:

On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my 
suggestion? Or even better: use the encoding done with mod_proxy_ajp?


For me there is nothing wrong except it adds 2 JKoptions or 3 :-)


If we think the new way is the correct way, we could have it as the 
default, letting the old ones there for compatibility with existing 
configurations as non standard options. The new one would not need an 
explicit name if it gets to be the standard.



We know that Tomcat is going to normalise a url we have already
normalised. Shouldn't we check that a second normalisation (like the
Tomcat one) gives a different url and if yes have a flag to return
"forbidden"? (Yes that would be a 4th option).


Here I try to argue, that encoding '%' before forwarding and decoding by 
tomcat should lead to the identity operation. I though a little more 
about it and most likely encoding '+' is also necessary, because besides 
the '%' decoding, Tomcat will most likely (I have to check) also decode 
'+' -> ' '. At the end I tend to use the same function, that's used in 
mod_proxy_ajp to reencode before forwarding (although only encoding '%' 
and '+' would be faster).


Rejecting requests with double encoding can already be done by 
mod_rewrite, because mod_rewrite operates on the decoded URI, so you 
only need to check for '%' (and '+' if you like).


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL
+++
Because that is what the SPEC's says.


I doubt, that the SPEC is very relevant for the reverse proxy situation 
of mod_jk. I read the old discussions, and I really got the impression 
that not much of SPEC compliance was left over.


What are we really talking about w.r.t. SPECs?

Regards,

Rainer



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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Jean-Frederic wrote:

On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my 
suggestion?


Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL
+++
Because that is what the SPEC's says.


The Servlet SPEC says, that the web container should not decode 
RequestURI. So if the reverse proxy tries to come close to this 
requirement, it needs to send the URI as unencoded as it can.


Now the reverse proxy should have the ability to modify the URI (in the 
sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 
is only able to operate on the decoded URI, we have no chance of making 
this interoperable with forwarding the original undecoded URI.


Using the encoding from mod_proxy_ajp we at least try to produce a URI 
which is as close to the original one, as we can achieve. At least 
logically the new URI is fine.


All in all I think that "compat unparsed" will result in more user 
problems as default then the new proposed way.


The whole discussion is:

1) At the moment all options have a problem (mod_rewrite, sessions, 
security)


2) My proposal should be checked if it is secure. If so, it fixes 
mod_rewrite, sessions and security. This seems to have some value. If 
you (community) agree on that value, I find it correct to add this 
option. The answers might depend on


- encode only '%'
- encode '%' and '+' (easy, performing, but needs some thinking about 
correctness)

- encode like in mod_proxy_ajp (not as performing but more complete)

3) Yes, it will influence how well the container can obey the spec (as 
two of the three existing options also do). So we could discuss, if the 
value is huge enough, that we make it the default (and thus need no more 
explicit option name), or we keep "compat unparsed" the default and add 
a new option.


Regards,

Rainer

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

Re: Improving mod_jk URI forwarding

[Rainer Jung]

Why do you think, that

/myapp/%252e%252e/otherapp/danger

is equivalent to

/myapp/../otherapp/danger ?


Because it is on the Tomcat side and it ends up
as /otherapp/danger.


No it is not. If you send

/myapp/%252e%252e/otherapp/danger

to Tomcat, it will map the URL into the /myapp context (which is correct).


Now, your suggestion would send an faulty uri for
something that shouldn't be passed by the mod_jk at
the first place, because *we know* how the uri will
be decoded on Tomcat.


Unless we change the AJP connector, there are only three possibilities:

- either we iterate over URL decoding unless no more '%' signs are in it
- or we deny all URLs with '%25' in them
- or we reencode the URL

As I understand you, the first two are more what you are about. But this 
will not allow any requests to be processed, which have a percent 
character as part of their ressource description. But those URLs are valid!


Once again: I think that reencoding and afterwards decoding by Tomcat is 
the identity operation. So we are in the very god situation, that all 
mod_jk/httpd logic has been done against the same URL, that will be used 
by Tomcat.


I tried to provide some evidence, why a *decoded* URL of the form

/myapp/%2e%2e/otherapp/danger

is valid, is unequal to /otherapp/danger and belongs to the /myapp 
context. Also I showed, why double decoding usually is assumed to be bad 
practise. Assume there s some content scanning in front of Apache and we 
double decode, then the same problem will be between the component in 
front and us. We will end up by simply denying everything with '%25' in 
it and I find that much more inadequate then reencoding the URL.


Why do you think it is a "faulty uri" and we shouldn't pass it along? 
Simply reencode and erything is fine.


Regards,

Rainer

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

Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released

[Rainer Jung]

William A. Rowe, Jr. wrote:

Rainer Jung wrote:

I had no permissions to delete them, I'll write to the owners directly
to remove them.


You can often find someone with root perms hanging out on #asfinfra on
irc.freenode.net, or can email [EMAIL PROTECTED] to ask for perms to be
reset to 664 as they were -supposed- to be in the first place.

Do email the owners to beg them to fix their umask.  I recommend that
instead of your .profile/.bash_profile, you fix them in your .bashrc and
.cshrc files, so that scp picks them up by default when depositing files
via scp.  umask 002  is all you are looking for to ensure 664 ownership.


We fixed it bilateral, no need to escalate.

Things like this often happen, when you use archives to transfer your 
files to p.a.o. Another reason is, that my fingers have a builtin "-p" 
when I do cp or scp. Then the umask unfortunately doesn't help. Of 
course we all know, how to handle this, but it can break relatively easy.


Regards,

Rainer


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

Re: Announcing releases of tomcat native

[Rainer Jung]

Mladen Turk wrote:

It is part of Tomcat release and that shouldn't change.
Each tomcat release has a detection of the Tomcat native, and
it prints out the suggested version compared with the one user is
running.

For 6.0.13 the required version is 1.1.8 and recommended
is 1.1.10 and that is clearly printed whenever Tomcat is started.
I'm not sure what more is needed.


I think he's trying to provide packages for a distro. So he wants to 
provide 1.1.8, 1.1.9, 1.1.10, ... whenever they are released (available).


At the moment, the only way to learn about the releases for him is 
looking into a tomcat download, unpacking the included tcnative source 
and checking, if it is new and he needs to provide a new package. This 
is not very robust and furthermore that way he only will recognize 
tcnative versions bundled with a Tomcat download.


Regards,

Rainer

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

mod_jk build: threading detection broken

[Rainer Jung]

Hi,

this while mail only concerns non Win and non Netware platforms.

Our detection of multi-threading during configure for mod_jk is broken. 
We rely on the fact, that APR set -D_REENTRANT during build for 
multi-threaded APR. But in fact


- APR doesn't set it for various platforms including AIX and Mac OS X
- APR sets it for the other platforms independant of building a 
multi-threaded Apache httpd or not


So as a result, for Linux, Solaris and BSD we always build mod_jk with 
thread locks, for AIX and Mac OS X we never have the thread locks (and 
therefore we can produce wonderful crashes).


I checked installed Apache httpd to find out, how we could detect the 
threading model of the apache httpd against we compile. Unfortunately we 
can only find out the name of the MPM, but not (at least not in a robust 
way) if it is threaded or not.


Since there are so many MPMs out there and i don't want to manage a long 
table with all those names, I think we have no good way of detecting the 
threading model.


I suggest, that we build against httpd 2.x always thread-safe, at least 
unless the existing flag -enable-prefork is used and document this 
behaviour.


This will in fact not change existing behaviour for the platforms 
Solaris, Linux and BSD and will fix problems on AIX and Mac OS X.


Comments?

Regards,

Rainer


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

Re: mod_jk build: threading detection broken

[Rainer Jung]

William A. Rowe, Jr. wrote:

Rainer Jung wrote:

I checked installed Apache httpd to find out, how we could detect the
threading model of the apache httpd against we compile. Unfortunately we
can only find out the name of the MPM, but not (at least not in a robust
way) if it is threaded or not.


ap_mpm_query (ap_mpm.h) is what you want.  Yes - you can ask
AP_MPMQ_IS_THREADED on win32, netware, unix, etc etc.


I guess no. We are talking about build time, not runtime. I know about 
the query API, but here we want to use defines to decide on the type og 
lock we are using.


Of course we could do it during runtime with if/than/else, but from the 
existing situation I describe for the most prominent platforms my 
suggestion should be OK.


Would be a nice add-on for apxs by the way.

Regards,

Rainer



Bill


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

Re: mod_jk build: threading detection broken

[Rainer Jung]

Henri Gomez wrote:

BTW, configure fail since some release and can't works with apx2-mpm
(The SLES apxs2 for mpm mode). I located the problem in configure and
will report it later.


Yes, let me know.


BTW, on i5/OS, the -D_REENTRANT is forced in module compilation.


OK, so my proposal wouldn't make a difference on i5 too. Good.

Regards,

Rainer

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

Re: mod_jk build: threading detection broken

[Rainer Jung]

Hi Henri,

Henri Gomez wrote:

BTW, the same configure with the apxs-prefork also set the
-D_REENTRANT on SLES 9 ;(


Yes, those flags all come from apxs. The difference with my new commit 
is, that we don't use them to decide, if we should synchronize between 
threads.


Now we only use JK_PREFORK, which gets set either when you are compiling 
against Apache 1.3, or if you use --enable-prefork.


I committed these changes this morning in r543093.

Regards,

Rainer


alaska:~/tomcat-connectors-1.2.23-src/native # make
Making all in common
make[1]: Entering directory 
`/root/tomcat-connectors-1.2.23-src/native/common'

/bin/sh /usr/share/apache2/build/libtool --silent --mode=compile gcc
-I/usr/include/apache2-prefork -g -O2 -O2 -fsigned-char
-fmessage-length=0 -Wall -fPIC -Wall -fno-strict-aliasing
-D_LARGEFILE_SOURCE -g -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -pthread -DHAVE_APR
-I/usr/include/apache2-prefork -I/usr/include/apache2-prefork -g -O2
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -I /usr/lib/java/include -I
/usr/lib/java/include/ -c jk_ajp12_worker.c -o jk_ajp12_worker.lo
/bin/sh /usr/share/apache2/build/libtool --silent --mode=compile gcc
-I/usr/include/apache2-prefork -g -O2 -O2 -fsigned-char
-fmessage-length=0 -Wall -fPIC -Wall -fno-strict-aliasing
-D_LARGEFILE_SOURCE -g -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -pthread -DHAVE_APR
-I/usr/include/apache2-prefork -I/usr/include/apache2-prefork -g -O2
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -I /usr/lib/java/include -I
/usr/lib/java/include/ -c jk_connect.c -o jk_connect.lo



2007/5/31, Henri Gomez <[EMAIL PROTECTED]>:

The SLES 9 problem with apxs-worker is fixed (bad configuration).

I just check the configure and build and -D_REENTRANT is set :

powerpc32 ./configure --with-apxs=/usr/sbin/apxs2-worker



make


make[1]: Entering directory 
`/root/tomcat-connectors-1.2.23-src/native/common'

/bin/sh /usr/share/apache2/build/libtool --silent --mode=compile gcc
-I/usr/include/apache2-worker -g -O2 -O2 -fsigned-char
-fmessage-length=0 -Wall -fPIC -Wall -fno-strict-aliasing
-D_LARGEFILE_SOURCE -g -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -pthread -DHAVE_APR
-I/usr/include/apache2-worker -I/usr/include/apache2-worker -g -O2
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -I /usr/lib/java/include -I
/usr/lib/java/include/ -c jk_ajp12_worker.c -o jk_ajp12_worker.lo
/bin/sh /usr/share/apache2/build/libtool --silent --mode=compile gcc
-I/usr/include/apache2-worker -g -O2 -O2 -fsigned-char
-fmessage-length=0 -Wall -fPIC -Wall -fno-strict-aliasing
-D_LARGEFILE_SOURCE -g -Wmissing-prototypes -Wstrict-prototypes
-Wmissing-declarations -pthread -DHAVE_APR
-I/usr/include/apache2-worker -I/usr/include/apache2-worker -g -O2
-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -I /usr/lib/java/include -I
/usr/lib/java/include/ -c jk_connect.c -o jk_connect.lo



2007/5/31, Rainer Jung <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> > BTW, configure fail since some release and can't works with apx2-mpm
> > (The SLES apxs2 for mpm mode). I located the problem in configure and
> > will report it later.
>
> Yes, let me know.
>
> > BTW, on i5/OS, the -D_REENTRANT is forced in module compilation.
>
> OK, so my proposal wouldn't make a difference on i5 too. Good.
>
> Regards,
>
> Rainer


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

Re: svn commit: r543093 - in /tomcat/connectors/trunk/jk: native/common/jk_mt.h xdocs/miscellaneous/changelog.xml xdocs/webserver_howto/apache.xml

[Rainer Jung]

Could you try to find out, how pthread_t is defined on OS X?
Does the following patch help?

Index: jk_util.c
===
--- jk_util.c   (revision 542900)
+++ jk_util.c   (working copy)
@@ -1686,12 +1686,87 @@
 pthread_getunique_np(&t, &tid);
 return ((int)(tid.intId.lo & 0x));
 #else
-int tid = (int)(t & 0x);
+int tid = ((int)t) & 0x;
 return tid;
 #endif /* AS400 */
 }
 #endif


Regards,

Rainer

Peter Rossbach wrote:

Hi Rainer,


your _REENTRANT fix trigger a next MAC OS X problem:

eragon:~/workshop/tomcat-connectors-1.2.23-src/native peter$ make
Making all in common
/opt/local/share/apr-1/build/libtool --silent --mode=compile gcc 
-I/Users/peter/workshop/apache2/include -Wall -g -O2 -DHAVE_APR  
-I/opt/local/include/apr-1 -I/opt/local/include/apr-1 -Wall -DDARWIN 
-DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I 
/Library/Java/Home/include -I /Library/Java/Home/include/ -c 
jk_ajp12_worker.c -o jk_ajp12_worker.lo
/opt/local/share/apr-1/build/libtool --silent --mode=compile gcc 
-I/Users/peter/workshop/apache2/include -Wall -g -O2 -DHAVE_APR  
-I/opt/local/include/apr-1 -I/opt/local/include/apr-1 -Wall -DDARWIN 
-DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I 
/Library/Java/Home/include -I /Library/Java/Home/include/ -c 
jk_connect.c -o jk_connect.lo
/opt/local/share/apr-1/build/libtool --silent --mode=compile gcc 
-I/Users/peter/workshop/apache2/include -Wall -g -O2 -DHAVE_APR  
-I/opt/local/include/apr-1 -I/opt/local/include/apr-1 -Wall -DDARWIN 
-DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I 
/Library/Java/Home/include -I /Library/Java/Home/include/ -c 
jk_msg_buff.c -o jk_msg_buff.lo
/opt/local/share/apr-1/build/libtool --silent --mode=compile gcc 
-I/Users/peter/workshop/apache2/include -Wall -g -O2 -DHAVE_APR  
-I/opt/local/include/apr-1 -I/opt/local/include/apr-1 -Wall -DDARWIN 
-DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I 
/Library/Java/Home/include -I /Library/Java/Home/include/ -c jk_util.c 
-o jk_util.lo

jk_util.c: In function 'jk_gettid':
jk_util.c:1723: error: invalid operands to binary &
make[1]: *** [jk_util.lo] Error 1
make: *** [all-recursive] Error 1


testet with apache 2.2.4.

Regards
peter



Am 31.05.2007 um 11:28 schrieb [EMAIL PROTECTED]:


Author: rjung
Date: Thu May 31 02:27:59 2007
New Revision: 543093

URL: http://svn.apache.org/viewvc?view=rev&rev=543093
Log:
Always build thread safe against Apache httpd 2.0/2.2
(unless configure detects --enable-prefork).
_REENTRANT flag for APR is not a safe threading detection
for all platforms.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_mt.h
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml

Modified: tomcat/connectors/trunk/jk/native/common/jk_mt.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_mt.h?view=diff&rev=543093&r1=543092&r2=543093 

== 


--- tomcat/connectors/trunk/jk/native/common/jk_mt.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_mt.h Thu May 31 
02:27:59 2007

@@ -33,18 +33,10 @@
 #define getpid()   ((int)GetThreadGroupID())
 #endif

-/*
- * All WIN32 code is MT, UNIX code that uses pthreads is marked by 
the POSIX

- * _REENTRANT define.
- */
-#if defined (WIN32) || defined(_REENTRANT) || (defined(NETWARE) && 
defined(__NOVELL_LIBC__))

 #ifdef JK_PREFORK
 #define _MT_CODE 0
 #else
 #define _MT_CODE 1
-#endif
-#else
-#define _MT_CODE 0
 #endif

 /*

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diff&rev=543093&r1=543092&r2=543093 

== 

--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml 
(original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu 
May 31 02:27:59 2007

@@ -27,6 +27,10 @@
   
   
 
+  
+  Always build with thread support, unless flag --enable-prefork
+  is set during for configure. (rjung)
+  
   
   i5/OS (AS/400) V5R4 port where Apache 2.0 modules should now 
use UTF8. (hgomez)

   

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?view=diff&rev=543093&r1=543092&r2=543093 

== 

--- tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml 
(original)
+++ tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml Thu 
May 31 02:27:59 2007

@@ -838,25 +838,26 @@
 

 
-If you want to build mod_jk for Apache 1.3 and 2.0/2.2, you should
+If you want to build mod_jk for different version of Apache httpd, 
like 1.3, 2.0 and 2.2,

+y

Re: Gotta submit a Board report this month...

[Rainer Jung]

- Lots of Tomcat talks at ApacheCon EU Amsterdam (Filip, Mladen)
- 2 mod_jk releases (1.2.22, 1.2.23), 1.2.23 was a security release

Yoav Shapira wrote:

... by June 18th at the latest, because the Board meeting is on June
20th.  But since I'll be leaving the country on vacation the preceding
weekend, our deadline is a bit earlier, let's say June 15th.

This is just an early heads-up.  Anyone have comments on what should
go in, besides the standard list of releases we've done since the last
report?

Yoav


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

Re: svn commit: r546531 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_global.h common/jk_url.c common/jk_url.h common/list.mk.in

[Rainer Jung]

Sorry for being offline for 2 weeks :(
Sorry for the long post coming :((

I just now read the URL rewriting discussion. Although the discussion 
seems to have come to an end, I find it worthwhile to actually add some 
structure to it:


1) How to forward the URL

I already suggested a different forwarding default in my discussion 3 
weeks ago. It was very close to what we ended up now and there are only 
minor points to decide upon.


Since Tomcat does an additional decoding we have to prevent double 
decoding in order to ensure correct URL mapping (independent of 
security; an encoded percent is legitimate and needs to be handled 
correctly as a percent at the end).


My original proposal included only reencoding percent signs (and maybe 
spaces), because all other URL characters will not get double decoded by 
Tomcat. If we don't trust this assumption, we could of course reencode a 
lot more characters, like mod_proxy does. There will be some performance 
penalty, because we could check pretty fast, if there are '%' or ' ' 
characters in the URL, and in case they are not, there's nothing to do 
in my proposal. mod_proxy has a far longer list of chars to reencode and 
so it doesn't do checking and instead runs the reencode loop directly.


The mod_proxy people have a good reason for encoding more characters: 
the same code gets used for http, ftp and ajp forwarding. We could be 
able to know, how the AJP connector works (do we?), so we could choose 
to not reencode for instance characters above 127.


But Remy made a good point: different components might have different 
decoding settings. I'm not sure, if this would apply to percent 
encoding, but it gives my thoughts a litle warning.


At the moment there exist the following implementations:

- Compat: forward the decoded URI, security issues

- CompatUnparsed: forward the original request URI, breaks mod_rewrite

- Proxy: Reencode using mod_proxy "full" reencoding (save for semicolon, 
i.e. URL session encoding), secure, adds some performance penalty


- Escaped: Reencode fully, safe but breaks URL encoded sessions,

- Minimal (the one I suggested): OK with mod_rewrite and sessions, a 
little faster than Proxy, but maybe open to not yet thought upon 
security threats, maybe also problematic if mod_jk and the backend use 
different character sets (I don't know if AJP URLs would be binary 
compatible for chars above 128 between mod_jk and the backend).


All in all I also vote for "Proxy" as the new default, maybe with a 
little optimization by first checking the URL, if there are actual 
characters from the reencoding set in there (in most cases there won't, 
and we don't need to copy character by character).


I strongly vote for leaving the old options in there for 1.2. Because 
for a long time default configurations had one of the old options as an 
explicit parameter in them (so they are not using the default), we 
should add a warning on startup, that the option is deprecated and 
removing it will most likely make the configuration safer and more 
interoperable with different environments. I would still allow using it.



2) Mladen's patch

The core idea of Mladen's patch was to check the URL against a known 
classical way of breaking the combination mod_jk and Tomcat. Even after 
fixing this breakage by re-encoding the URL before forwarding, I find it 
worth of thinking about his patch.


Apache httpd for instance has a parameter to *allow* URLs with encoded 
slashes  which is by default *off*:


AllowEncodedSlashes Off

This disables some suspicious URLs stopps many of the standard break in 
attempts.


So at least I see some reason for options to make the combination more 
sensible to evil URLs. Encoded slashes as well as encoded backslashes or 
encoded percent signs might be good candidates.


Since those URL parts can have legitimate use, those can only be 
options, and one can discuss, if the default should be on or off. They 
will help to harden the security.


Since mod_jk is for multiple web servers and maybe backends, there is 
some reason to actually implement those checks, even if some 
combinations might do it in front or behind mod_jk.


I would propose a check for encoded slashes, backslashes and encoded 
percent signs, combined in one option "DenyUnsafeURL", which in 1.2 will 
be off by default. Room for discussion here!



3) IIS, Netscape

We need to investigate, how we forward from IIS and Netscape. For IIS, 
Mladen will know. Netscape uses decoded URL like Apache, so we'll switch 
to the same handling as the new default in Apache.


Regards,

Rainer


Remy Maucherat wrote:

Mladen Turk wrote:

That's why I suggested to stop for a while and see all the possibilities.


We've talked about it for a while (see the length of this thread ...), 
and I consider it is time to think over code: apply the proposed patch 
which aims to harmonize with mod_proxy, and see what actual problems it 
causes, if any. This means I am vetoing r54413

Re: Serious non-native AJP connector issue

[Rainer Jung]

Jess,

I didn't really carefully think about the case of a saturated pool. But 
nevertheless some hints:


1) There is always one thread waiting for the accept, which is a usual 
pool thread. So an offset of one between threeads processing requests 
and the pool size is normal.


2) There is no orderly shutdown in AJP13 for a connection, neither from 
the httpd side, not from the Tomcat side. mod_jk will realize closed 
connections and reopen them, but I have the impression, that mod_proxy 
fails a backend when it gets a connection error.


Tomcat in my experience reliably closes a connection and frees the 
thread, when the web server does.


Most of the time it makes sense to have a connectionTimeout 
(Milliseconds) and a connection_pool_timeout (seconds, mod_jk) resp. ttl 
(seconds, mod_proxy) which are in sync. But: they will never harmonize 
completely, because mod_jk only checks for the need to throw away closed 
connections during maintenance (every 60 seconds or whatever is 
configured with worker.maintain) and I think mod_proxy checks the ttl 
whenever a connection is put back into the pool.


3) Does it happen with mod_jk too?

4) Weird guesses:

- max is limited with mod_proxy to the number of threads per process 
configured in your MPM (worker?).


This is 25 by default. So if we want to have an easy to understand 
scenario, set your threads per process to say 60 and min=max=50 as well 
as removing the smax and the ttl.. That way 50 connections should be 
started on startup (per httpd process; check with netstat), and we 
shouldn't see any resizing during your ab test. Now start your ab test 
before Tomcat will timeout (I remember that connectionTimeout had some 
default value, even if you don't set it, but it is in the minutes).


If you don't run into trouble then, we know your observation has to do 
with resizing of connection pools.


*Maybe*: ab is too fast and can come back with new requests faster, than 
the connections go back into the pool after the end of a request in 
httpd. Not very reasonable, but possible. Of cource the pool is 
synchronized and the lock doesn't need to behave fair, i.e. when it gets 
contended, it's not clear if the oldest waiting thread gets it first.


Regards,

Rainer

Jess Holle wrote:

H

I just redid my tests with:

   BalancerMember ajp://localhost:8010 min=15 max=*50* smax=30 ttl=900
   keepalive=Off timeout=900

and

   

and

   ab -n 100 -c *50* http://jessh03l.ptcnet.ptc.com/TestApp/test.jsp?secs=3

I (after about 3 seconds) get

   SEVERE: All threads (51) are currently busy, waiting. Increase
   maxThreads (51) or check the servlet status

and I eventually get exactly 1 lost request.  I'm baffled as to why this 
can occur.


Something's still doesn't seem quite right here.

What's even weirder is that I only get this issue with the first ab run 
after restarting Tomcat.  If I do the same test again (any number of 
times) I don't lose any requests.


I can get the same result by restarting and doing 2 ab runs with "-n 
100" in fairly short secession, so this isn't some ab error.  By "fairly 
short", I don't mean very short -- I left a good 5 seconds between runs.


I find that using a max of 49 in Apache seems to work reliably, but I'm 
struggling to understand: (1) why I have to have 2 more Tomcat connector 
threads allowed than the number of connections I can possibly have and 
(2) whether "2" is always the safe buffer or whether I'll need 9 on an 8 
CPU box or some such.


--
Jess Holle


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

Re: svn commit: r549328 - in /tomcat/connectors/trunk/jk/java/org/apache: coyote/ajp/AjpAprProcessor.java jk/common/JkInputStream.java

[Rainer Jung]

It works.

Tested with slightly more than 4 GB. Tomcat now correctly returns the 
content length header, and mod_jk passes it to the client.


Access logging behaves the same as before (broken for Apache 1.3 and 2.0 
and Tomcat as well).


Thanks!

[EMAIL PROTECTED] wrote:

Author: billbarker
Date: Wed Jun 20 19:21:36 2007
New Revision: 549328

URL: http://svn.apache.org/viewvc?view=rev&rev=549328
Log:
Allow for large-file support on downloads as well as uploads.

Reported By: Rainer Jung

Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java

Modified: 
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java?view=diff&rev=549328&r1=549327&r2=549328
==
--- tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java 
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java 
Wed Jun 20 19:21:36 2007
@@ -961,9 +961,9 @@
 if (contentLanguage != null) {
 headers.setValue("Content-Language").setString(contentLanguage);
 }
-int contentLength = response.getContentLength();
+long contentLength = response.getContentLengthLong();
 if (contentLength >= 0) {
-headers.setValue("Content-Length").setInt(contentLength);
+headers.setValue("Content-Length").setLong(contentLength);
 }
 
 // Other headers


Modified: 
tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java?view=diff&rev=549328&r1=549327&r2=549328
==
--- tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java 
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java Wed 
Jun 20 19:21:36 2007
@@ -300,9 +300,9 @@
 if( contentLanguage != null ) {
 headers.setValue("Content-Language").setString(contentLanguage);
 }
-int contentLength = res.getContentLength();
+long contentLength = res.getContentLengthLong();
 if( contentLength >= 0 ) {
-headers.setValue("Content-Length").setInt(contentLength);
+headers.setValue("Content-Length").setLong(contentLength);
 }
 int numHeaders = headers.size();
 outputMsg.appendInt(numHeaders);


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

Re: svn commit: r549328 - in/tomcat/connectors/trunk/jk/java/org/apache:coyote/ajp/AjpAprProcessor.java jk/common/JkInputStream.java

[Rainer Jung]

Not really: I tested >4GB downloads. Instead of setContentLength() you 
can also setHeader for "Content-Length". Then you have the freedom to 
format a larger number, because this API takes strings. It works for me.


Regards,

Rainer


Tim Whittington wrote:
This would limit dynamic (servlet) responses (and for practical purposes 
requests) to 32bit, but Tomcat could still serve static content with a 64bit 
content length.
 
tim
 
 


* *


*Tim Whittington
Development Unit Manager - Concerto Portal*
[EMAIL PROTECTED] 
P: +64 9 638 0600 x3873
M: +64 21 307 925
F: +64 9 638 0699
S: tim.whittington 
www.orionhealth.com 


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

Summary URL handling mod_jk 1.2.24

[Rainer Jung]

After all the discussions I did some commits today to produce a 
consistent URi handling result for the Apache, IIS and Netscape connectors.


Here is the summary:

1) How do the web servers pass URLs to the plugins?

- Apache: decoded, normalized
- Netscape: decoded, normalized
- IIS: original URL

2) How do we manipulate them before checking against forwarding rules?

- Apache: no additional manipulation
- Netscape: no additional manipulation
- IIS: decode and normalize

3) How de we forward, if we find a match?

All web servers: reencode using the mod_proxy code. Some safe characters 
will not get reencoded (exactly like in mod_proxy), for example the 
semicolon ';'.


Interesting: the list of safe characters comes from Apache httpd trunk 
and differs from 2.2.x by not encoding '~'.


4) Safety, Interoperability

Since we reencode problematic characters, especially '%', the attacks we 
discussed are not possible. Since we use the internal URL as a basis for 
reencoding, interoperability with mod_rewrite etc. is fine. Since 
semicola are not reencoded, URL encoded session ids are fine.


5) Hardening

There is an additional option (Apache: RejectUnsafeURI, IIS/Netscape: 
reject_unsafe), which will reject URLs which contain a percent sign '%' 
or backslash '\' after decoding. Since a percent sign after decoding is 
legitimate, the option is off by default. Users who know, that their 
apps do not use percent signs, can turn this option on as an early line 
of defense (e.g. against buggy servlets etc.).


6) Code cleanuup

I shortened the reencoding implementation because I think, having to 
much unused code gives us the wrong impression, that it is actively 
maintained code. The original code form mod_proxy contains a lot of 
different cases, and we use only one of those.


I also reverted Mladen's patch, but carried over his central idea for 
5). I really think (and tested), that it is not necessary in general 
(because here Apache and Netscape already do what his new methods were 
supposed to add).



Regards,

Rainer

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

Re: JK3 roadmap?

[Rainer Jung]

Whenever I had a couple of hours I was doing small tests with scripting.

I think the most valuable first step would be the transformation to APR.
Unfortunately this is something I could hekp with, but I wouldn't want
to lead, because my experience with APR programing is only medium.

Once APR would be there, I would start working on management threads.

But APR is the necessary big first step (at least that's what I think) ...

Regards,

Rainer


Mladen Turk schrieb:
> jean-frederic clere wrote:
>> I have noted that nothing has happened in tomcat/connectors/trunk/jk3.
>> Nearly 2 months without real road map nor clear specifications, what
>> is wrong?
>>
> 
> I don't think anything is wrong. We are waiting for the list of
> requirements, and any suggestion from yours or anybody else side
> is more then welcome.
> 
> Regards,
> Mladen.
> 
> -
> 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: JK3 roadmap?

[Rainer Jung]

Just in case anyone likes to make his words persist: Mladen created a
roadmap file some weeks ago which includes the basic thoughts we
(Mladen, Jean-Frederic and me) had during ApacheCon about bigger JK
improvements.

/tomcat/connectors/trunk/jk3/ROADMAP

Regards,

Rainer

Remy Maucherat schrieb:
> Filip Hanik - Dev Lists wrote:
>> Mladen Turk wrote:
>>> jean-frederic clere wrote:
 I have noted that nothing has happened in tomcat/connectors/trunk/jk3.
 Nearly 2 months without real road map nor clear specifications, what
 is wrong?

>>>
>>> I don't think anything is wrong. We are waiting for the list of
>>> requirements, and any suggestion from yours or anybody else side
>>> is more then welcome.
>> Comet support, that means, keep the connection open to receive/send
>> data in either direction.
>> Able to turn off buffering, so that data can get transferred directly
>> during Comet connections.
>>
>> That's one that I know people would like to see
> 
> I understand we're talking about the native side here. My opinion on
> this is it's not an absolute necessity, as most of the time the proxy
> server will have not much to do except handling the connection, so it
> should be able to dedicate the necessary threads. Of course, except for
> specialized event based web servers, it's not possible to get rid of the
> thread/process per request, so there's a large feasibility issue.
> 
> On the Java side, I plan to adapt the o.a.coyote.ajp package to support
> comet and save threads in Tomcat, which is easy to do since the
> connector structure is the same as HTTP (actually, it's simpler). I will
> do it when the API and code gets really stable for the HTTP connector.
> 
> Rémy
> 
> -
> 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: [VOTE] Release build 5.5.24

[Rainer Jung]

I'll test sometime during this week and will vote then. Sorry for not 
responding faster/earlier. I really appreciate that you are doing the 
release work, because 5.5 still needs to be supported in a reliable way.


Filip Hanik - Dev Lists wrote:
if we want this release to go out, we need folks to vote on it. This 
release was requested May 30, binaries were cut June 13th.
If we don't get any votes, I'll hold off for a couple of months, and 
then propose a 5.5.25 in August


Filip

Filip Hanik - Dev Lists wrote:

reminder to vote.
Wanted to run this vote through the weekend, and finalize on Monday 
noon MST.


Filip

Filip Hanik - Dev Lists wrote:
Candidate binaries are available here: 
http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.24/


According to the (slightly) updated release process, the 5.5.24 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable


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

Re: Feature request /Discussion: JK loadbalancer improvements for high load

[Rainer Jung]

Hi,

implementing a management communication between the lb and the backend 
is on the roadmap for jk3. It is somehow unlikely, that this will help 
in your situation, because when doing a GC the jvm will no longer 
respond to the management channel. Traditional Mark Sweep Compact GC is 
not distinguishable from the outside from a halt in the backend. Of 
course we could think of a webapp trying to use the JMX info on memory 
consumption to estimate GC activity in advance, but I doubt that this 
will be a stable solution. There are notifications, when GCs happen, but 
at the moment I'm not sure, if such events exist, before, or only after 
a GC.


I think a first step (and a better solution) would be to use modern GC 
algorithms like Concurrent Mark Sweep, which will most of the time 
reduce the GC stop times to some 10s or 100s of milliseconds (depending 
on heap size). CMS comes with a cost, a little more memory needed and a 
little more CPU needed, but the dramatically decreased stop times are 
worth it. Also it is quite robust since about 1-2 years.


Other components will not like long GC pauses as well, like for instance 
cluster replication. There you configure the longest pause you accept 
for missing heartbeat packets before assuming a node is dead. Assuming a 
node being dead because of GC pauses and then the node suddenly works 
without having noticed itself that it outer world has changed is a very 
bad situation too.


What we plan as a first step for jk3 is putting mod_jk on the basis of 
the apache APR libraries. Then we can relatively easily use our own 
management threads to monitor the backend status and influence the 
balancing decisions. As long as we do everything on top of the request 
handling threads we can't do complex things in a stable way.


Getting jk3 out of the door will take some longer time (maybe 6 to 12 
months'for a release). People willing to help are welcome.


Concerning the SLAs: it always makes sense to put a percentage limit on 
the maximum response times and error rates. A 100% below some limit 
clause will always be to expensive. But of course, if you can't reduce 
GC times and the GC runs to often, there will be no acceptable 
percentage for long running requests.


Thank you for sharing your experiences at Langen with us!

Regards,

Rainer

Yefym Dmukh wrote:

Hi all,
sorry for the stress but it seems that it is a time to come back to  the 
discussion related to the load balancing for JVM (Tomcat).


Prehistory:
Recently we made benchmark and smoke tests of our product at the sun high 
tech centre in Langen (Germany). 
 
As the webserver apache2.2.4 has been used, container -10xTomcat 5.5.25 
and as load balancer - JK connector 1.2.23 with busyness algorithm. 

Under the high load the strange behaviour was  observed: some 
tomcat workers temporary got the non-proportional load, often 10 times 
higher then the others for the relatively long periods.  As the result the 
response times that usually stay under 500ms went up to 20+ sec, that in 
its turn  made the overall test results almost two time worst as 
estimated. 

At the beginning we were quite confused, because we were 
sure that it was not the problem of JVM configuration and supposed that 
the reason is in LB logic of mod_jk, and the both suggestions were right. 

Actually the following was happening: the LB sends requests and gets the 
session sticky, continuously sending the upcoming requests to the same 
cluster node. At the certain period of time the JVM started the major 
garbage collection (full gc) and spent, mentioned above, 20 seconds. At 
the same time jk continued to send new requests and the sticky to node 
requests that led us to the situation where the one node broke the SLA on 
response times. 

I ^ve been searching the web for awhile to find the LoadBalancer 
implementation that takes an account the GC activity and reduces the load 
accordingly case JVM is close to the major collection, but nothing found.


Once again the LB of JVMs under the load is really an issue for production 
and with optimally distributed load you are able not only to lower the 
costs, but also able to prevent bad customer experience, not to mention 
broken SLAs. 


Feature request:

All lb algorithms have to be extended with the bidirectional 
connection with jvm:

 Jvm -> Lb: old gen size and the current occupancy
 Lb -> Jvm: prevent node overload and advice gc on dependent on 
parameterized free old gen space in %. 
 


All the ideas and comments are appreciated.

Regards,
Yefym.


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

Re: Feature request /Discussion: JK loadbalancer improvements for high load

[Rainer Jung]

OK, this culd make sense, i.e. heap nearly full on node1 failover to 
other cluster member node2 (replcation assumed) and trigger GC by 
System.gc() on node1. Interesting idea ... (for JK3 and beyond).


Yefym Dmukh wrote:

Mladen wrote:

This won't help much. The sticky session requests must be served
by the same node (group of nodes if using domain clustering),
and your requests will still be delayed by the JVM instance GC cycle
(It has to happen sometime, and you cannot depend on request
void intervals)


The main point was to use the stop-the-world collectors PROACTIVELY 
managed by lb in order to:
eliminate the memory and cpu usage overhead ConcurrentXXX 
ParallelXXX (i.e. up to 50% for mem ) collectors..
prevent the overloading of the single node that falls in GC-cycle. 
 
reduce the complexity of jvm tunning


With an algorithm:
heap is almost full -> do not send the requests to the node 
anymore and load the other nodes (wait some timeto give the chance 
for the current workers to do the jobs), advise stop-the-world. Heap free? 
Resume the load.



Certainly this makes sense (if any) only for the setups with many small 
jvms that have small CPU (or limited for the current needs) and huge Mem 
size for the stateless applications or the applications with the short 
session lifecycle.


Also may be it would make sense for the domained installations, in GC 
cycles the other domain members will takeover the jobs. 
all this makes sense only in case if the load balancer manages not only 
the load but also GC cycles: kind of ideal JVMs level load-balancer for 
the high load.


Regards,
Y.


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

Re: Removing the examples (JSP/servlet) in TC Binaries

[Rainer Jung]

I'm not sure. They provide an easy entry point for people using Tomcat 
because it is so simple to just use them. There are a couple of choices:


- leave the examples in the download and take their security serious. 
This is what we do now.


- leave the examples in the download, but don't bother about their 
security, as long as they don't compromise the container security (e.g. 
don't bother about XSS issues for the example webapps).


- move the examples into a separate download, and add some notes about 
that to the docs. This will also be a better production setup, but 
people might miss the separate download.


- move the examples into a separate directory, so that they are not 
active by default. Add a note about how to activate them. Also a better 
production setup, but we'll get a lot of questions, why the examples do 
not work.


I think the real question is, should we still take security serious for 
the example webapps. If no, then we should decide, which way we disable 
them. I don't have a very strong opinion, because I don't feel fine by 
delivering insecure example webapps, even if they are disabled. How 
should people be made aware of security in webapps, if even our example 
webapps are unsafe.


On the other hand: do we think the status of the example webapps 
concerning security is OK now, or do we think they would need a thorough 
review?


Regards,

Rainer

jean-frederic clere wrote:

Hi,

The examples (servlet and JSP) have caused a list of security issues.
I think we should remove them from the Tomcat binary packages (6.0 and 
5.x at least).

Any comments?

Cheers

Jean-Frederic


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

Quality check mod_jk 1.2.24-dev

[Rainer Jung]

Hi all,

The next version of mod_jk is approaching its release. A code snapshot 
(revision 59730) is available at:


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

It is in the same format as a release download, so easy to build.
Under the same URL you can find the updated documentation.

It would be nice, if we could get some testing feedback from the 
community. Feel free to post any observations.


Depending on your feedback we plan to tag the release at the end of the 
week.


The most important changes are:

Features/Improvements
-

- performance improvement in connection checking
- handle correctly up- and downloads bigger than 2GB
- Web servers: new default mode "ForwardURIProxy" for encoding the 
forwarding URL. Combines safety and interoperability with mod_rewrite 
and URL session encoding
- Security: new option RejectUnsafeURI resp. reject_unsafe to harden 
against possibly malicious URLs
- Load Balancer: add configuration item max_reply_timeouts, to make lb 
tolerant against occasional reply timeouts. Fully managed by status worker.
- Status Worker: rename worker status names by using OK/substatus and 
ERR/substatus. Especially use OK/IDLE instead of N/A. Only display 
change, no functional change.

- new recovery options for recovering idempotent HTTP methods HEAD and GET.
- Logging: milli- or microseconds timestamp

Fixes
-

- always build with thread support, unless flag --enable-prefork is set
during for configure. Fixes builds on some platforms, e.g. AIX and Mac OS X.
- fixed a deadlock in lb worker, which was exposed on Solaris for 
threaded Apache MPMs.

- interoperability with mod_rewrite
- various fixes for Apache on iSeries

Docs


- new HowTo about our various timeout settings
- correct documentation for worker attributes retries and 
recovery_options and their meaning w.r.t the different worker types.

- clarify relation between worker names and jvmRoute for load balancing.
- IIS: Document auth_complete and uri_select.
- add comments on iSeries builds.

The full change log is available under:

http://people.apache.org/~rjung/mod_jk-dev/docs/miscellaneous/changelog.html

Thanks for your valuable time!

Regards,

Rainer


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

Tagging JK 1.2.24

[Rainer Jung]

Hi,

we had exactly 10 downloads of our quality check tarball since the 
announcement yesterday. Three of the testers reported back positively 
(one of them via direct mail), no reports were negative. Since I 
received already a lot of positive feedback from the preceding internal 
testing (6 testers, 7 platforms, all web server types), I propose to tag 
1.2.24 at 10:00 GMT and immediately start a vote. I hope the vote goes 
through, so we might announce the release early next week.


All changes I did since the test tarball only affected the docs, no code 
change.


Regards,

Rainer



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

[VOTE] Releasing Tomcat Connectors 1.2.24

[Rainer Jung]

Hello to all Tomcat project members,

JK 1.2.24 has been available for testing for some days as a svn 
snapshot. Only very small bugs have been found and fixed. So I would 
like to proceed with the release vote.


If you want to take a look, the final source distribution can be 
downloaded from:


http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/

The updated documentation can be found at

http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/

Binaries might be available under

http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/binaries/

So here's the vote. Because we already had several days of testing, the 
vote will be closed on Monday July 30, 24:00 GMT.


Apache Tomcat Connectors 1.2.24 is:

[ ] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are

Thank you,

Rainer


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

Re: [VOTE] Releasing Tomcat Connectors 1.2.24

[Rainer Jung]

Yoav Shapira wrote:

Hey,

On 7/27/07, Rainer Jung <[EMAIL PROTECTED]> wrote:

JK 1.2.24 has been available for testing for some days as a svn
snapshot. Only very small bugs have been found and fixed. So I would
like to proceed with the release vote.


The bugs were fixed and 1.2.24 retagged with the same tag?


Fix yes, retag no. If a version contains more complex changes, we allow 
pre release testing against a dev tarball we provide with the same 
script, that we also use for releases. Those tarballs still contain a 
"-dev" naming and are distriuted via people.apache.org. The bugs have 
been fixed during this phase. Tagging happened after fixing earlier today.



[ X ] Stable - no major issues, no regressions


No issues at all for me, but I'm a pretty light user of the connectors.


Thanks for voting.


Yoav


Rainer

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

[Fwd: Fw: Re: [VOTE] Releasing Tomcat Connectors 1.2.24]

[Rainer Jung]

Forwarding for Günter Knauf, his provider is blacklisted
on tomcat-dev at the moment, so he sent it to me directly.

 Original Message 
Hi,

Apache Tomcat Connectors 1.2.24 is:



[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are


tested on NetWare 6.5, 6.0, 5.1; Apache 2.2, 2.0, 1.3, and Netscape.

greets, Gnter.


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

Bugzilla configuration

[Rainer Jung]

Hi,

I updated the link for Bugzilla on the JK docs to Tomcat 6.

http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%206

Now I noticed, that Tomcat 6 has no longer a JK:Native component. 
Furthermore nearly all of the old components are gone.


Only two components are there: "catalina" and "jasper".

For Tomcat 5 we had the following list of components:

Catalina
Catalina:Cluster
Catalina:Modules
Connector:AJP
Connector:Coyote
Connector:HTTP
Jasper
Native:Integration
Native:JK
Native:Packaging
Servlet & JSP API
Servlets:CGI
Servlets:SSI
Servlets:WebDAV
Tester
Unknown
Webapps:Administration
Webapps:Documentation
Webapps:Examples
Webapps:Manager

Apart from the admin webapp, my impression is, that all components still 
exist. I propose to add them to the list of components.


At least for the JK:Native I would like very much to have that.

BTW: The TC 5 and TC 6 Bugzilla page still has 
[EMAIL PROTECTED] instead of dev@tomcat.apache.org as the 
owner of all components. Maybe a good time to change that too.


I we agree, who can do those changes?

Regards,

Rainer

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

Re: Bugzilla configuration

[Rainer Jung]

Yoav Shapira wrote:

Catalina
Catalina:Cluster
Catalina:Modules
Connector:AJP
Connector:Coyote
Connector:HTTP
Jasper
Native:Integration
Native:JK
Native:Packaging
Servlet & JSP API
Servlets:CGI
Servlets:SSI
Servlets:WebDAV
Tester
Unknown
Webapps:Administration
Webapps:Documentation
Webapps:Examples
Webapps:Manager

Apart from the admin webapp, my impression is, that all components still
exist. I propose to add them to the list of components.


I really like having fewer components, but not so mcuh to -1 your
proposal.  Let's see what others think.


OK, you are right. We certainly can drop some of them. Maybe the 
following list is better?


Catalina
Cluster
Connectors
Documentation
Jasper
Native:Integration
Native:JK
Native:Packaging
Servlet & JSP API
Webapps:Examples
Webapps:Manager
Others

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

Re: [VOTE] Releasing Tomcat Connectors 1.2.24

[Rainer Jung]

Rainer Jung wrote:
So here's the vote. Because we already had several days of testing, the 
vote will be closed on Monday July 30, 24:00 GMT.


Apache Tomcat Connectors 1.2.24 is:

[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are


Voting now, the chosen vote closure of 24:00 GMT is nonsense, since I'm 
GMT +2 ...


Will publish result and release and do announcement tomorrow morning.

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

[RESULT][VOTE] Releasing Tomcat Connectors 1.2.24

[Rainer Jung]

We received six stable votes (Henri, Yoav, Mladen, Peter, Günter and me) 
and no other votes.


I'm now starting to publish the release.

Thanks for supporting this release.

Regards,

Rainer

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

[ANN] Apache Tomcat JK 1.2.24 Web Server Connector released

[Rainer Jung]

The Apache Tomcat team is pleased to announce the immediate availability
of version 1.2.24 of the Apache Tomcat Connectors.

It contains connectors, which allow a web server such as Apache HTTPD,
Microsoft IIS and Sun Web Server to act as a front end to the Tomcat web
application server.

This version contains several enhancements and fixes a number of minor
bugs of the previous version 1.2.23.

See http://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html
for a complete list of changes.

Source distribtions can be downloaded from an Apache Software Foundation 
mirror at:


http://tomcat.apache.org/download-connectors.cgi

Binary distributions for a number of different operating systems and
web servers can be downloaded from an Apache Software Foundation mirror at:

http://tomcat.apache.org/download-connectors.cgi

Documentation for using Apache Tomcat Connectors can be found at:

http://tomcat.apache.org/connectors-doc/

Thank you,

-- The Apache Tomcat Team





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

Re: Juli/Logging

[Rainer Jung]

Hi David,

our default bundled JULI only has a binding for java.util.logging. On

http://tomcat.apache.org/tomcat-6.0-doc/extras.html

there is a very short description, how one builds a JULI, that is log4j 
enabled. The static binding was chosen, because commons-logging auto 
detection provided to many problems w.r.t. redeployment and classloader 
leaks.


My personal opinion: java.util.logging very much lacks a good formatter. 
The default 2 line formatting of messages, splitting timestamps and 
message in separate lines, is not really useful in production. Many ad 
hoc log analysis practices work on a line oriented basis.


Regards,

Rainer

David Blevins wrote:

So another topic,

There's a thread going on in OpenEJB at the moment about possibly 
switching away from log4j for the reason that the logging config gets 
easily messed up in embedded environments (maven, specificaly) and of 
course to have one less dependency -- the 3.0 server is a bit beefier 
than the 1.0.


I remembered not seeing log4j or commons logging in Tomcat 6 and started 
investigating -- how I discovered the inlining.  Seems juli is a trimmed 
down version of commons-logging (attractive), but it isn't obvious 
what's driving the actual logging.  Didn't see any inlined log4j 
classes.  Are you using java.util.Logging or something else?


Also noticed the javadoc of juli says it allows for per-classloader 
configuration of logging.  What exactly does that mean?


Thanks!

-David


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



--
--
kippdata
informationstechnologie GmbH   Tel: 0228 98549 -0
Bornheimer Str. 33aFax: 0228 98549 -50
53111 Bonn www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
===
kippdata
informationstechnologie GmbH   Tel: +49 228 98549 -0
Bornheimer Str. 33aFax: +49 228 98549 -50
D-53111 Bonn   www.kippdata.de

HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann

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

Re: Juli/Logging

[Rainer Jung]

David Blevins wrote:
My personal opinion: java.util.logging very much lacks a good 
formatter. The default 2 line formatting of messages, splitting 
timestamps and message in separate lines, is not really useful in 
production. Many ad hoc log analysis practices work on a line oriented 
basis.


Was wondering about that.  I've heard people grumble about 
java.util.logging, but haven't (till now) heard anything specific.  
Maybe I wasn't paying close enough attention, but the Tomcat 6 log files 
still seem to follow the one line per message format.  How did you pull 
that off?


That's what I get:

Aug 1, 2007 10:26:37 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-28680
Aug 1, 2007 10:26:37 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2854 ms
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.13
Aug 1, 2007 10:26:40 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-28680

One line for timestamp, class and method, a second line for log level 
and message. That's the format of the default formatter, the simple log 
format.


That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


Regards,

Rainer

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

Re: Juli/Logging

[Rainer Jung]

Hi Remy,

if we only want to give an alternative for the SimpleFormatter:

that one is not configurable, so it's capabilities are printing out a 
localized timestamp, after that the class and method, a localized level 
string, and last the log message. All of those are basically given by 
the log record, level localization is provided by the Level class, 
Timestamp is not problem (milliseconds in the log record), and should 
also contain the millisesond fraction.


Of course we could add configurability in a next step, which would 
basically mean an accesslog/log4j like pattern string for the log line.


The log record carries the following information:

- level
- message
- milliseconds timestamp
- source class and method name
- thread id
- logger name
- sequence number (interesting feature, so one can easily describe, 
which message instance in a log one is talking about)


and more complex objects

- thrown (throwable associated with the record)
- resource bundle and/or resource bundle name to format message string
- parameters, log data extension

The simple objects could be configured by a simple pattern character, 
the more complex ones need more thought :)


I think already the direct simpleformatter replacement, even without 
configurability would be an improvement!


If that formatter would work with j.u.l. i.e. without juli, I would love 
it even more. The configurability of course might add a slight 
dependency to juli (where do we get the parameters from, i.e. how do we 
pass the information from logging.properties to the formatter). Not 
really a dependency, but probably additional setters that are called by 
juli, and when using the formatter in j.u.l one would have to write the 
code that calls the setters oneself (or use juli).


Regards,

Rainer


Remy Maucherat wrote:

Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


What should it look like ?

Rémy




 Object[]   getParameters()
  Get the parameters to the log message.
 ResourceBundle getResourceBundle()
  Get the localization resource bundle
 String getResourceBundleName()
  Get the localization resource bundle name
 long   getSequenceNumber()
  Get the sequence number.
 Throwable  getThrown()
  Get any throwable associated with the log record.

 void   setParameters(Object[] parameters)
  Set the parameters to the log message.
 void   setResourceBundle(ResourceBundle bundle)
  Set the localization resource bundle.
 void   setResourceBundleName(String name)
  Set the localization resource bundle name.
 void   setSequenceNumber(long seq)
  Set the sequence number.
 void   setThrown(Throwable thrown)
  Set a throwable associated with the log event.

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

Re: Juli/Logging

[Rainer Jung]

Forget the previous post, it contained garbage at the end

Hi Remy,

if we only want to give an alternative for the SimpleFormatter:

that one is not configurable, so it's capabilities are printing out a 
localized timestamp, after that the class and method, a localized level 
string, and last the log message. All of those are basically given by 
the log record, level localization is provided by the Level class, 
Timestamp is not problem (milliseconds in the log record), and should 
also contain the millisesond fraction.


Of course we could add configurability in a next step, which would 
basically mean an accesslog/log4j like pattern string for the log line.


The log record carries the following information:

- level
- message
- milliseconds timestamp
- source class and method name
- thread id
- logger name
- sequence number (interesting feature, so one can easily describe, 
which message instance in a log one is talking about)


and more complex objects

- thrown (throwable associated with the record)
- resource bundle and/or resource bundle name to format message string
- parameters, log data extension

The simple objects could be configured by a simple pattern character, 
the more complex ones need more thought :)


I think already the direct simpleformatter replacement, even without 
configurability would be an improvement!


If that formatter would work with j.u.l. i.e. without juli, I would love 
it even more. The configurability of course might add a slight 
dependency to juli (where do we get the parameters from, i.e. how do we 
pass the information from logging.properties to the formatter). Not 
really a dependency, but probably additional setters that are called by 
juli, and when using the formatter in j.u.l one would have to write the 
code that calls the setters oneself (or use juli).


Regards,

Rainer


Remy Maucherat wrote:

Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


What should it look like ?

Rémy


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

Re: Juli/Logging

[Rainer Jung]

That's why it would be nice if someone took the burden of writing a 
better log formatter for j.u.l.


Got it.  Yea, that format is certainly grep unfriendly.

Looks like Harmony has a formatter we could copy from and fix to not add 
the new line.


http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java 


Yes, that could be a good starting point (although that implementation 
does not care about localization).


Thanks for the pointer!

Regards,

Rainer

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

Re: Serious regression in JK 1.2.24

[Rainer Jung]

Hi,

OK with me. I've one outstanding patch related to fail on status. I 
think Ben short is testing today. I wrote mails about it to the user 
list and the patch is not committed yet. It's


http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch

(in short: fail on status has to be moved to a place a little earlier, 
because at the moment headers are set before fail on status. So if we do 
a retry and get different headers back, we produce an answer with an 
undefined mix of headers. In the users case we set Content-Length from 
the failure response, and the retry on another node succeeded with a 
chunked encoding ...)


Also there is one outstanding fix concerning nsapi on netware (which now 
has an unneeded dependency on shm).


We could review all changes since 1.2.24 (that's not much) and then skip 
the quality check phase, instead directly roll an oficial test/vote 
tarball. Would tomorrow be OK for that?


Regards,

Rainer

Mladen Turk wrote:

Hi,

We have a problem with 1.2.24 that luckily is not security leak,
but it is security related.

The problem is that 401 from Tomcat without body
(a standard HTTP_UNAUTHORIZED) is treated as 401, meaning
that Apache is returning 401 page instead passing 401
to the client.

I already patched the SVN.
Can we roll 1.2.25?

Regards,
Mladen.


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

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

[Rainer Jung]

Hi Mladen,

I don't full yunderstand this fix. From your other mail i though it's a 
regression, but the code in this region is the same at least since 
1.2.18 (more than a year). So I have the impression, that this is not a 
regression. If so, I would prefer to not push 1.2.25 through with very 
high speed, i.e. 1.2.24 would still be pretty useful as an update.


Regards,

Rainer

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Wed Aug  1 23:06:18 2007
New Revision: 562022

URL: http://svn.apache.org/viewvc?view=rev&rev=562022
Log:
Fix the 401 not passed to the client.

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/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?view=diff&rev=562022&r1=562021&r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Wed Aug  1 23:06:18 
2007
@@ -2159,7 +2159,8 @@
 if (rc > 0) {
 /* If tomcat returned no body and the status is not OK,
let apache handle the error code */
-if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {
+if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST &&
+ r->status != HTTP_UNAUTHORIZED) {
 jk_log(conf->log, JK_LOG_INFO, "No body with status=%d"
" for worker=%s",
r->status, worker_name);

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?view=diff&rev=562022&r1=562021&r2=562022
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Wed Aug  1 23:06:18 
2007
@@ -2250,7 +2250,8 @@
 
 /* [EMAIL PROTECTED] : under i5/OS sent_bodyct is not set correctly */

 /*   check for header_only to see if there was a body */
-if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST) {
+if (!r->sent_bodyct && r->status >= HTTP_BAD_REQUEST &&
+ r->status != HTTP_UNAUTHORIZED) {
 jk_log(xconf->log, JK_LOG_INFO, "No body with status=%d"
" for worker=%s",
r->status, worker_name);

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diff&rev=562022&r1=562021&r2=562022
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Wed Aug  1 
23:06:18 2007
@@ -23,6 +23,16 @@
   new documentation project for JK was started.
   
 
+
+  
+  
+
+  
+Pass the 401 as OK instead sending 401 for authentication. (mturk)
+  
+
+  
+
 
   
   


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

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

[Rainer Jung]

OK, I'll go into it. I think I would propose a slightly different patch, 
but I'll investigate, why 23 and 24 are different.


The reason why I started to pose querstions is, that I found it a little 
strange to make an exception for exactly one status code.


My impression is: the code was supposed to let httpd produce the error 
page in case we got an error status without any content. But: for a 401 
we actually do get a body content from tomcat. So in fact something is 
wrong with sent_bodycnt. I'll investigate.


Regards,

Rainer

Mladen Turk wrote:

Rainer Jung wrote:

Hi Mladen,

I don't full yunderstand this fix. From your other mail i though it's 
a regression, but the code in this region is the same at least since 
1.2.18 (more than a year). So I have the impression, that this is not 
a regression.


You can try 1.2.23 (it works). 1.2.24 doesn't. With patch it works again.
I'm not sure if the patch is correct, because it might be that
request_rec->sent_bodyct flag is setup differently in 1.2.24

If so, I would prefer to not push 1.2.25 through with very high speed, 
i.e. 1.2.24 would still be pretty useful as an update.




But it doesn't work.
You can try 1.2.23 with Tomcat manager app. The browser displays login
window for username/password. 1.2.24 displays 401 page from Apache.

Regards,
Mladen


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

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

[Rainer Jung]

Update: The problem seems to be coming from a global change of AS400 
defines, which unintentionally also hit two ifndefs, which were 
transformed into ifdefs. As a result, we didn't flush any more, so small 
responses were not flushed before we came to the line checking 
sent_bodyct. That way the whole response got replaced by the apache 
error page.


Important: as far as I can see, this should not have introduced a 
problem with Apache 1.3. I didn't yet test, but if there is a problem 
with 401 for Apache 1.3, then there is also another cause we have to 
look for. I'll test but wanted to quickly give an information update.


And: In case we receive an empty body from Tomcat and an error status 
code (>=400), we still throw away the response and let Apache generate a 
new one. More precisely this means, that we throw away all the headers. 
In the 401 case, this way we detected the original problem. I'm not 
sure, if we should really let Apache generate a new local error page 
including headers, if we get an http error code with empty body.


We could also just  pass the response with empty body back to the client.

In fact I was thinking earlier about giving people the chance to decide, 
if they want their error pages coming from apache or from Tomcat. This 
is too complex for a fast fix (as we can see from the 401 example), but 
I think some more thinking after fixing the actual issue would be good.


Regards,

Rainer

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

mod_jk 1.2.24 withdrawal?

[Rainer Jung]

I think the problem with JK 1.2.24 is big enough to release soon. I 
would also suggest to officially withdraw 1.2.24 from the download and 
web site (with a comment indicating the problem) so that people will not 
run into more complex problems related to the missing flush. Although 
we've got no indication, that there will be a security problem, the 
missing flushing can lead to undefined behaviour.


Users needed to wait for a post 1.2.23 update for 2.5 months, so 1-2 
more weeks will be OK.


Additionally the question is: should we include other fixes or strictly 
only 1.2.24 + this fix. If we remove 1.2.24 I think the other fixes 
listed below will be safe. I would propose to include them and run 
through the usual Quality check + release cycle, we've done a couple of 
times for JK.


r560736 (fuankg): additional defines in jk_globalh. if __GNUC__ is 
defined for WIN32 or Netware. This should enable gcc builds on these 
platforms. Looks like very low risk, because until now we don't support 
building with gcc on these platforms, so the change looks like it can't 
break anything.


r560739 (fuankg): Change in Netware Makefile for Apache 1.3. I think 
Günter knows best, if this should be released.


r560823 (rjung): changed pid_t print format detection for Solaris. 
Tested with gcc and cc for 32 Bit and 64 Bit build on Solaris Sparc. Not 
tested for Solaris x86, but until now I think we do not actively support 
this.


r560831 (rjung): Fix nsapi crash with debug log during startup. Very 
local change, low risk.


r562085 (rjung): Fix 401 problem. That's the one we definitely need.

Outstanding changes:

fail on status
--

http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch

Improve nsapi shut down
---

Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c  (revision 562051)
+++ netscape/jk_nsapi_plugin.c  (working copy)
@@ -320,14 +320,15 @@
 uri_worker_map_free(&uw_map, logger);
 }

+if (init_map) {
+jk_map_free(&init_map);
+}
+
+jk_shm_close();
 wc_close(logger);
 if (logger) {
 jk_close_file_logger(&logger);
 }
-
-if (init_map) {
-jk_map_free(&init_map);
-}
 }


Improve nsapi returning correctly when errors occur
---

Index: netscape/jk_nsapi_plugin.c
===
--- netscape/jk_nsapi_plugin.c  (revision 562051)
+++ netscape/jk_nsapi_plugin.c  (working copy)
@@ -382,10 +382,14 @@
 }
 else {
 if ((result == JK_CLIENT_ERROR) && (is_error == 
JK_HTTP_OK)) {

+rc = REQ_EXIT;
+protocol_status(sn, rq, is_error, NULL);
 jk_log(logger, JK_LOG_INFO,
"service() failed because client 
aborted connection");

 }
 else {
+rc = REQ_ABORTED;
+protocol_status(sn, rq, is_error, NULL);
 jk_log(logger, JK_LOG_ERROR,
"service() failed with http error %d", 
is_error);

 }


nsapi and shm
--

For Netware nsapi now has a build dependency on shm although it doesn't 
use it. More generally, we need to check which way we should use shm for 
nsapi on which platform. I think the nsapi and general platforms 
considerations should not be done before 1.2.25, but everything else 
looks OK to me.


Regards,

Rainer

Mladen Turk wrote:

[EMAIL PROTECTED] wrote:

Author: rjung
Date: Thu Aug  2 05:10:48 2007
New Revision: 562090

URL: http://svn.apache.org/viewvc?view=rev&rev=562090
Log:
Revert the quickfix r562022. It looks like we found the real problem
with r562085.



Perfect. The fix makes login working once again.

Regards,
Mladen


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

Re: mod_jk 1.2.24 withdrawal?

[Rainer Jung]

I withdrew the release from the server:

- removed 1.2.24 source and binaries from www.apache.org/dist/...
- put back 1.2.23 source and binaries from archive
- reverted the download page and added a warning
- added a withdrawal note to the index and news page in the live online 
docs.


It will take the usual time to sync to www.a.o/tomcat.a.o and the mirrors.

I'm going to send a note to the users and dev list.

Regards,

Rainer

Mladen Turk wrote:

I agree. Remove 1.2.24 and include all the patches.
Let's roll that ASAP.

Regards,
Mladen.


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

[ANN] Withdrawal of Apache Tomcat JK 1.2.24 Web Server Connectors

[Rainer Jung]

The Apache Tomcat team needs to withdraw release 1.2.24 of the Apache 
Tomcat Connectors.


The release contains a bug that prevents the correct flushing of parts 
of responses from the web server to the client. This might result in 
unpredicted communication behaviour. We therefore have removed the 
source and binary distributions from the origin server.


A fix for the problem has already been committed. We expect release of 
version 1.2.25 in sometime next week.


We apologise for any inconvenience,

-- The Apache Tomcat Team





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

Re: Juli/Logging

[Rainer Jung]

Hi Costin (and Remy),

I had a quick look at the JdkLoggerFormatter (found in an old revision 
of the sandbox, it's not there any more):


this formatter uses a *very* compact format. E.g. the timestamp is just 
the milliseconds and the log level is abbreviated with a single 
character. Although technically very useful, I doubt that most admins 
will like it at first sight, so it might not be a good default 
replacement for the JDK simple formatter. Still searching ...


Regards,

Rainer

Costin Manolache wrote:

I think something is missing - DirectJDKLog is looking for a
JdkLoggerFormatter that would do
the trick. I may have forgot to add it, I have it on my machine ( I hate too
the default format ).
There's also a config override allowing default properties to be loaded from
a different location.

Costin

On 8/2/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:

Rainer Jung wrote:

That's why it would be nice if someone took the burden of writing a
better log formatter for j.u.l.

Got it.  Yea, that format is certainly grep unfriendly.

Looks like Harmony has a formatter we could copy from and fix to not
add the new line.



http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java

Yes, that could be a good starting point (although that implementation
does not care about localization).

It might be better to use log4j code as a starting point as it already
has the pattern processing code.

Rémy


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

Re: svn commit: r562194 - in /tomcat/connectors/trunk/jk: native/common/jk_ajp13.h native/common/jk_ajp_common.c native/common/jk_lb_worker.c xdocs/miscellaneous/changelog.xml xdocs/reference/workers

[Rainer Jung]

And in fact it doesn't matter. I found it more logical, to have 
JK_STATUS_ERROR and JK_STATUS_FATAL_ERROR closer together (for those 
reading the code). The constants are not used outside JK, so there is no 
compatibility problem.


It looks like your are closely following todays JK changes. I really 
appreciate that! Unless you find problems, I just now commited my last 
change (hopefully) for 1.2.25.


Regards,

Rainer

Jim Jagielski wrote:


On Aug 2, 2007, at 1:42 PM, [EMAIL PROTECTED] wrote:

== 


--- tomcat/connectors/trunk/jk/native/common/jk_ajp13.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp13.h Thu Aug  2 
10:42:23 2007

@@ -45,7 +45,8 @@
 #define JK_CLIENT_RD_ERROR  (-6)
 #define JK_CLIENT_WR_ERROR  (-7)
 #define JK_STATUS_ERROR (-8)
-#define JK_REPLY_TIMEOUT(-9)
+#define JK_STATUS_FATAL_ERROR   (-9)
+#define JK_REPLY_TIMEOUT(-10)



I'm curious... One reason to use C #defines is to abstract
out the macro and their values. So why, when adding
entries to we force JK_REPLY_TIMEOUT to always be
the lowest value? It shouldn't matter what the
"real" values are, right? This is especially true if we
ever want to leak these out externally :)


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