DO NOT REPLY [Bug 42669] New: - Unhelpful error message when using zip installation on Mac OS X

[bugzilla]

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

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

   Summary: Unhelpful error message when using zip installation on
Mac OS X
   Product: Tomcat 6
   Version: unspecified
  Platform: Macintosh
OS/Version: Mac OS X 10.4
Status: NEW
  Severity: normal
  Priority: P3
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I am on Max OS X, Java 1.5.0_07.

1. Download the zip distribution of Tomcat 6.0.13
2. Unzip it using e.g. muCommander
3. In Terminal, do:
cd apache-tomcat-6.0.13/bin/
chmod +x startup.sh
chmod +x catalina.sh
./startup.sh
4. The following error message appears:

The BASEDIR environment variable is not defined correctly
This environment variable is needed to run this program

The real error is that additional .sh files need to be given execution
privileges for Tomcat to work, but this is not apparent at all from the error
message. The error message is misleading.

The workaround is either to do chmod +x *.sh, or use the tar.gz distribution.

BTW, other people have come across this problem, you will find several
references to this error message if you google it.

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

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

Re: Serious non-native AJP connector issue

[Jess Holle]

Bill Barker wrote:
It seems that we lost building the NIO/AJP connector in Tomcat, but since i 
recognize you from [EMAIL PROTECTED], you will have seen that already :).  Last time 
I tested, the experimental NIO/AJP connector performed better than either 
the default or the APR connector on Solaris (surprise, surprise), and came 
in dead last on Windows.
  

Thanks for all the helpful information, Bill.

I wonder if the results of for the NIO/AJP connector would be any 
different on Windows with a later JVM (e.g. Java 6 Update 1).  I would 
*hope* that Sun would fix the NIO issues on Windows to the point that it 
would out-perform Java-Blocking-IO/AJP.


--
Jess Holle

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

DO NOT REPLY [Bug 42673] New: - SSI virtual include broken for context path with slashes

[bugzilla]

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

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

   Summary: SSI virtual include broken for context path with slashes
   Product: Tomcat 6
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Keywords: PatchAvailable
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If the context path of an application contains slashes (e.g. "a/b") the method
getPathWithoutContext of class
org.apache.catalina.ssi.SSIServletExternalResolver simply cuts from the second
slash, so for url "/a/b/do?.." it tries to include "b/do?.." instead of "do?..".

The patch is to include the context path and strip the path off:

Line 419
String noContext = getPathWithoutContext(normContext.getContextPath(), 
normalized);

Line 356ff
protected String getPathWithoutContext(final String contextPath, final String
servletPath) {
   if (servletPath.startsWith(contextPath)) {
  return servletPath.substring(contextPath.length());
}
return servletPath;
}

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

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

Re: Serious non-native AJP connector issue

[Jess Holle]

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

DO NOT REPLY [Bug 42565] - jsp /expression language

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 06:45 ---
The problem seems to be with the "false?true:false" part of the expression (the
same excepion is thrown specifying just "${false?true:false}".

As a workaround, adding a space before the colon seems to resolve it - both the
following work OK:

${false?true :false}
${true? (false?true :false):false}

Now to understand JavaCC/JJTree to work out why...

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

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

DO NOT REPLY [Bug 32017] - Tomcat 5.5 manager fails to undeploy Struts app

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 08:04 ---
It appears that the problem remains. I have a similar problem with mail.jar 
that has to be in .../common/lib, not in my webapps .../WEB-INF/lib. Otherwise, 
after a mail is sent using javax.mail.Transport.send(msg) the JAR file will 
become locked, preventing hot redeploy.

It does not help to set the following in the
webapp's META-INF/context.xml




Platform: Win XP, Tomcat 5.5.15



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

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

Re: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

Costin Manolache wrote:

On 6/14/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:


Costin Manolache wrote:
>> >
>> >
>> > Sounds better - but as Remy explained you would first need to 
explain

>> > why blocking is needed in this context and how to deal with the
>> confusion
>> > of mixing blocking and non-blocking for users, and the 
implementation

>> > complexities it adds.
>> trunk doesn't mix them. a comet connection is either blocking or non
>> blocking, it doesn't shift between the two,
>> and it allows developers to choose what they want. Just like a
>> SocketChannel in java.nio.
>> there is nothing confusing about that, unless java.nio is 
confusing :)

>
>
>
> Well, nio is far from perfect - but that's not the point.
>
> Servlets have a very nice blocking mechanism already - it's the
> servlet API
> :-).
> The question is why would you need to have a Commet connection 
blocking.





because comet is not a servlet, and the ease of use for having blocking

write and read is huge,
especially when Tomcat can notify you when you can write or read, there
is no need to scratch your head and try to use non blocking.
non blocking is more complex, and not for everyone.




I'm not sure I understand - there is a perfectly fine blocking read/write
interface, it's the
plain servlet API.

you're hung up on the servlet API, there is a *huge* difference. :)
If you stick with the servlet API, the thread and connection is a 1 to 1 
mapping. Ie, if you want to do comet over a regular servlet,

you can't have more connections than max threads.
With comet, this limitation goes away. And this limitation or the 
removal thereof has nothing to do with blocking or non blocking,


With comet, you get an event when you need to read or can write, when 
you actually do the read/write the IO logic of it is blocking,
but to you as a developer it is almost transparent. since it would only 
block in extremely rare cases, even with blocking IO.


Please note, that neither Remy nor I have yet really talked about non 
blocking reads, so you might think sandbox is non blocking, well it is not.
It is buffering, but not non blocking. a true non blocking read, would 
require a rewrite of all the buffer filters to keep state between read 
invocations.


We get away from this on the write, cause we can store the last write 
and keep it at the bottom layer. this is not a true non blocking write, 
as this implementation prevents any further write attempts by throwing 
an IOException or IllegalStateException.


I also agree that 'blocking' mode is sometimes easier to code than
event-based, and
I can see the benefit of doing some stuff in blocking mode and some in
non-blocking.

My concern was making the read and write blocking in a commet servlet 
based

on
a config in the CometEvent.

The alternative is to have the comet servlet allways non-blocking for
read/write, but
provide a convenience method that will simulate the blocking read or 
write (

which is
easy, all you need is a blocking waitForEvent(time) ). Benefits:
- the read/write implementation is simpler ( no need to check the config
mode or do tricks ),
- comet is easier to understand
- you can do more advanced things, like using reads in non-blocking 
mode and

writes in blocking
mode.

The code using waitForEvent() is a bit more complicated than the code for
blocking read/write (
but if you want the simplest solution - use regular servlet ), and it is
simpler than a pure
callback based model.





> I think it's very reasonable to add a blocking waitForEvent() to allow
> servlets have a
> simpler ( but less efficient ) implementation.





Comet inherently is a "wait for event" system. Tomcat acts as a

multiplexer/dispatcher,and fires events into the CometProcessor.



Comet seems to be an event-based system, that's why setting it to 
'blocking

mode' is so
confusing and bad. I'm not sure I agree it has to be a 'blocking wait for
event' system - in Remy
examples at least it is not.



The "waitForEvent()" method is obsolete in the Comet implementation, as

you are either on a Tomcat thread,
which you can activate at any time or you are on a async thread, and not
sure why you would need to block an async background thread.
>
> Think about utilities that take the event as param - would they 
need to

> check first
> if it's blocking or not ? And what would blocking give you in addition
to
> waitForEvent() -
> which is actually better since it allows you to un-block on any event,
> not
> only a specific
> read/write.
I can see that there is a huge misunderstanding of how comet actually
does work and what it actually is.
It is true that is essentially just a TCP socket between server and
client, but in addition to that,
Tomcat provides a shell around it, and instead of you having to manage
when to read or when to write,
tomcat becomes an event API.



Sure, it hides some limitations of NIO ( the IO thread that has to do all
things )
and adds some higher-level HTTP stuff.

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

DO NOT REPLY [Bug 42669] - Unhelpful error message when using zip installation on Mac OS X

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 09:20 ---
This is not a support forum, you could have asked the question on the user list.
You should use the tar.gz for all other platforms but windows.
if you use it on MacOS or Unix systems, chmod +x *.sh is in order to make it 
work

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

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

Re: Proposed simplification of CometEvent

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
Please note, that neither Remy nor I have yet really talked about non 
blocking reads, so you might think sandbox is non blocking, well it is not.
It is buffering, but not non blocking. a true non blocking read, would 
require a rewrite of all the buffer filters to keep state between read 
invocations.


It is non blocking, as the low level read is always non blocking (in the 
sandbox design).


Rémy


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

DO NOT REPLY [Bug 42669] - Unhelpful error message when using zip installation on Mac OS X

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 09:27 ---
I am not asking for support - as you see, I resolved the issue myself and I
don't need help. 

I am trying to help the product provide a friendlier experience for others who
hit this issue, so *they* don't have to scratch their head thinking what they've
done wrong. Well, if you don't want to help your users, I am not going to try to
convince you.



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

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

Re: Proposed simplification of CometEvent

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

public class ExampleCometStockStreamer implements CometProcessor {
  ...
  public class StockUpdater extends Thread {
public void run() {
  ...
  StockUpdates[] updates = fetchUpdates();
  Client[] clients = getClients(updates);
  for (int i=0; inow its starting to look funny, In the trunk version of the example, I'm 
interested if the socket buffer is ready to receive data,
but the sandbox version of it simply doesn't care, it just calls for a 
tomcat thread.

sandbox:
 client.getEvent().callback(); -> no guarantee for writeability
trunk:
 client.getEvent().register(OP_WRITE) -> event fires when network buffer 
is ready to receive data.


The only thing funny here is your example. The writes done in the 
callback event are blocking if needed. For an equivalent of your code, 
you could do

if (isWriteable()) { callback(); }
etc

All of these examples are not very good, I think :( In most of these, 
you should not be using Comet I think: CPU usage will skyrocket, 
killing off the benefits over regular Servlets with blocking IO.
Of course the examples aren't very "real world'ish", the point was to 
simply show the differences in the API.


However, I think we have uncovered a larger problem than "what API do we 
pick" right now. The concept of Comet is very clear to the two of us.
I know how your impl would work, and I'm pretty sure you know how mine 
would work. But beyond that, the basics around Comet is still not well 
explained nor understood.
While we are debating method names and implementation details, our 
thread is being misunderstood.


Actually, I believe many people understand event based IO, so I don't 
see the problem. I am not debating an implementation detail or a method 
name (I would like to get good method names ideas, actually), I am 
arguing against your API design, which does not make sense to me.


I think starting to work on the Bayeux impl, or some other examples, 
will shine some more light on this.


Great, I will be able to port this impl to a reasonable API :)

Rémy


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

Re: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Please note, that neither Remy nor I have yet really talked about non 
blocking reads, so you might think sandbox is non blocking, well it 
is not.
It is buffering, but not non blocking. a true non blocking read, 
would require a rewrite of all the buffer filters to keep state 
between read invocations.


It is non blocking, as the low level read is always non blocking (in 
the sandbox design).

so is the trunk impl, if you consider that non blocking. but if you use
request.getInputStream().read() - that would require all the filters to 
be modified to keep the state of the last read,

so that request.getInputStream().read() can indeed return 0.

in trunk, I found a way to get away with this, I did the following on 
the isReadable()


isReadable() == available()>0 || InternalNioInputBuffer.hasData()==true 
|| InternalNioInputBuffer.read()>0


where the last InternalNioInputBuffer.read() is non blocking.

are you of a different understanding that the filters would not need any 
modification to make request.getInputStream().read() non blocking?


Filip

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

Re: Proposed simplification of CometEvent

[Costin Manolache]

Ok, so let me double check: the low level socket in sandbox is allways read
after a poll() / select(),
and never with a blocking read() ?

After the poll(): the Comet servlet, in a tomcat thread will be able to call
read() in the input
stream, and that will return data or 0 if no more data is available ( or -
call isReadable() and then read(),
or whatever else - but the socket will not be put in blocking mode ) ?

If this is true for sandbox - big +1.

Costin

On 6/15/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:


Filip Hanik - Dev Lists wrote:
> Please note, that neither Remy nor I have yet really talked about non
> blocking reads, so you might think sandbox is non blocking, well it is
not.
> It is buffering, but not non blocking. a true non blocking read, would
> require a rewrite of all the buffer filters to keep state between read
> invocations.

It is non blocking, as the low level read is always non blocking (in the
sandbox design).

Rémy


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

Re: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

Costin Manolache wrote:
Ok, so let me double check: the low level socket in sandbox is allways 
read

after a poll() / select(),
and never with a blocking read() ?

huh? :)



After the poll(): the Comet servlet, in a tomcat thread will be able 
to call

read() in the input
stream, and that will return data or 0 if no more data is available ( 
or -

call isReadable() and then read(),
or whatever else - but the socket will not be put in blocking mode ) ?

and some more huh :)

it is an implementation detail if the socket is blocking or non 
blocking, and has nothing to do

with read() returning 0 or not.

now we are talking about the implementation, not the API. I can 
implement inputstream.read() to return 0 on both blocking and non 
blocking sockets.
btw, for the NIO connector, we only have non blocking sockets, the API 
is an abstraction from the socket layer,




If this is true for sandbox - big +1.
not sure how the above relates to sandbox or trunk, since they use the 
same sockets the same way.

Filip


Costin

On 6/15/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:


Filip Hanik - Dev Lists wrote:
> Please note, that neither Remy nor I have yet really talked about non
> blocking reads, so you might think sandbox is non blocking, well it is
not.
> It is buffering, but not non blocking. a true non blocking read, would
> require a rewrite of all the buffer filters to keep state between read
> invocations.

It is non blocking, as the low level read is always non blocking (in the
sandbox design).

Rémy


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





No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.15/848 - Release Date: 6/13/2007 12:50 PM
  



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

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: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

since we are getting pretty far off track here, I've started a Wiki page 
on what comet is and isn't.

http://wiki.apache.org/tomcat/WhatIsComet

It will be helpful in the future, or we can assimilate this into our 
docs eventually, but for now, I think it is a good drawing board to 
clear out things as we agree on them


Filip


Filip Hanik - Dev Lists wrote:

Costin Manolache wrote:
Ok, so let me double check: the low level socket in sandbox is 
allways read

after a poll() / select(),
and never with a blocking read() ?

huh? :)



After the poll(): the Comet servlet, in a tomcat thread will be able 
to call

read() in the input
stream, and that will return data or 0 if no more data is available ( 
or -

call isReadable() and then read(),
or whatever else - but the socket will not be put in blocking mode ) ?

and some more huh :)

it is an implementation detail if the socket is blocking or non 
blocking, and has nothing to do

with read() returning 0 or not.

now we are talking about the implementation, not the API. I can 
implement inputstream.read() to return 0 on both blocking and non 
blocking sockets.
btw, for the NIO connector, we only have non blocking sockets, the API 
is an abstraction from the socket layer,




If this is true for sandbox - big +1.
not sure how the above relates to sandbox or trunk, since they use the 
same sockets the same way.

Filip


Costin

On 6/15/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:


Filip Hanik - Dev Lists wrote:
> Please note, that neither Remy nor I have yet really talked about non
> blocking reads, so you might think sandbox is non blocking, well 
it is

not.
> It is buffering, but not non blocking. a true non blocking read, 
would
> require a rewrite of all the buffer filters to keep state between 
read

> invocations.

It is non blocking, as the low level read is always non blocking (in 
the

sandbox design).

Rémy


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





No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 
269.8.15/848 - Release Date: 6/13/2007 12:50 PM
  



-
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: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

Ok, one use case scenario would be AJAX requests with asynchronous 
responses on the server, I can see this be extremely common,
I've tried to add in comments to make the example clear, and I don't see 
this example as stupid, as there are a lot more AJAX client frameworks 
than Comet client frameworks.


So there are two things we are show casing
1. The ability to write asynchronously
2. The ability to pipeline HTTP requests (assumption: only dealing with 
GET requests, no HTTP request body)
3. Difference between Comet non blocking and Comet blocking read and 
writes (note, not related to sockets, API only)


What I'd like to point out is that this example, becomes easier with 
blocking read/writes, so I've added that at the bottom for comparison


Let me know if I've made any mistakes here, so that we can work with a 
correct example.


Non blocking read and writes

public class ExampleDelayedAjaxResponse implements CometProcessor {
 ...
 public class DelayedResponder extends Thread {
   public void run() {
 ...
 Client[] clients = getClients();
 for (int i=0; i   } else { //we didn't write it all, trigger a WRITE event when we are done with the write 
  event.register(OP_WRITE);

   }
 } else {
   //we are not able to write, let us know when we can
   event.register(OP_WRITE);
 }
 //remove the client from the  async thread
 //since we have received the data for this client.
 clients.remove(event);
   }
 }
 ...
   }
 }
 ...
 public void event(CometEvent event) throws IOException, ServletException {
   ...
   if ( event.getEventType() == CometEvent.EventType.BEGIN ) {
 //configure non blocking
 event.configureBlocking(false);
 //deregister for READ since we want to enable pipe lining on the connection 
 //for the next HTTP request

 event.unregister(OP_READ);
 //add the client to the list
 clients.add(event);
   } if ( event.getEventType() == CometEvent.EventType.READ ) {
 //read client Id and stock list from client
 //and add the event to our list
 assert("this should never happen");
   } if ( event.getEventType() == CometEvent.EventType.WRITE ) {
 //unregister from the write event
 event.unregister(OP_WRITE);
 //we can now write
 byte[] data = getDelayedResponse(event);  
 if ( data != null ) {

   event.getHttpServletResponse().getOutputStream().write(data);
 }
 if( data==null || event.isWriteable() ) {
   event.close();
 }
  
   } if ( event.getEventType() == CometEvent.EventType.END ) {
 clients.remove(event);  
   } else if (...) {

 ...
   }
   ...
 }
}

Blocking read and writes 


public class ExampleDelayedAjaxResponse implements CometProcessor {
 ...
 public class DelayedResponder extends Thread {
   public void run() {
 ...
 Client[] clients = getClients();
 for (int i=0; i //deregister for READ since we want to enable pipe lining on the connection 
 //for the next HTTP request

 event.unregister(OP_READ);
 //add the client to the list
 clients.add(event);
   } if ( event.getEventType() == CometEvent.EventType.READ ) {
 //read client Id and stock list from client
 //and add the event to our list
 assert("this should never happen");
   } if ( event.getEventType() == CometEvent.EventType.WRITE ) {
 //unregister from the write event
 event.unregister(OP_WRITE);
 //we can now write
 byte[] data = getDelayedResponse(event);  
 //note we don't have to check for null data here

 event.getHttpServletResponse().getOutputStream().write(data);
 event.close();
   } if ( event.getEventType() == CometEvent.EventType.END ) {
 clients.remove(event);
   } else if (...) {
 ...
   }
   ...
 }
}
 
I think this makes a good use case of where blocking makes life easier, and less complex code. Big difference for both the async thread and the Comet processor.

And this is why I think we should support both, please note 
event.configureBlocking has nothing to do with the underlying socket, just the 
inputstream.read/write.
the underlying socket is an implementation detail.

Remy, would you mind showing this example with sandbox API, I think with a real 
world example, I can understand your API better, and maybe you mine :)

Filip




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

Re: Proposed simplification of CometEvent

[Filip Hanik - Dev Lists]

Filip Hanik - Dev Lists wrote:

Costin Manolache wrote:
Ok, so let me double check: the low level socket in sandbox is 
allways read

after a poll() / select(),
and never with a blocking read() ?

huh? :)



After the poll(): the Comet servlet, in a tomcat thread will be able 
to call

read() in the input
stream, and that will return data or 0 if no more data is available ( 
or -

call isReadable() and then read(),
or whatever else - but the socket will not be put in blocking mode ) ?

and some more huh :)

it is an implementation detail if the socket is blocking or non 
blocking, and has nothing to do

with read() returning 0 or not.

now we are talking about the implementation, not the API. I can 
implement inputstream.read() to return 0 on both blocking and non 
blocking sockets.

correction, should read
I can implement inputstream.read() to return 0 on both blocking and non 
blocking *Comet events*, (since sockets are always non blocking)


btw, for the NIO connector, we only have non blocking sockets, the API 
is an abstraction from the socket layer,




If this is true for sandbox - big +1.
not sure how the above relates to sandbox or trunk, since they use the 
same sockets the same way.

Filip


Costin

On 6/15/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:


Filip Hanik - Dev Lists wrote:
> Please note, that neither Remy nor I have yet really talked about non
> blocking reads, so you might think sandbox is non blocking, well 
it is

not.
> It is buffering, but not non blocking. a true non blocking read, 
would
> require a rewrite of all the buffer filters to keep state between 
read

> invocations.

It is non blocking, as the low level read is always non blocking (in 
the

sandbox design).

Rémy


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





No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 
269.8.15/848 - Release Date: 6/13/2007 12:50 PM
  



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






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

svn commit: r547788 - /tomcat/trunk/webapps/docs/aio.xml

[fhanik]

Author: fhanik
Date: Fri Jun 15 14:27:12 2007
New Revision: 547788

URL: http://svn.apache.org/viewvc?view=rev&rev=547788
Log:
minor correction


Modified:
tomcat/trunk/webapps/docs/aio.xml

Modified: tomcat/trunk/webapps/docs/aio.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?view=diff&rev=547788&r1=547787&r2=547788
==
--- tomcat/trunk/webapps/docs/aio.xml (original)
+++ tomcat/trunk/webapps/docs/aio.xml Fri Jun 15 14:27:12 2007
@@ -154,7 +154,7 @@
   
   
 The previous section touched a little bit on the comet connection 
lifecycle. 
-It is important to remember that comet events are based around IO on an 
actual socket.
+It is important to remember that comet events are based around IO events 
of an actual socket.
 To clarify the Comet API, it has been created to resemble the java.nio 
channel/selector APIs.
 In the case of Comet, Tomcat is the selector and using the CometEvent 
object, you can 
 register and unregister your Comet event for different event type 
notifications.
@@ -189,7 +189,7 @@
   EventType.BEGIN: will be called at the beginning 
  of the processing of the connection. It can be used to initialize any 
relevant 
  fields using the request and response objects. During the BEGIN event you 
may also configure 
- your comet connection for blocking or non blocking mode. using the 
configure
+ your comet connection for blocking or non blocking mode. using the 
configureBlocking(boolean)
  method on the comet event object. Between the end of the processing  
  of this event, and the beginning of the processing of the end or error 
events,
  it is possible to use the response object to write data on the open 
connection.



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

svn commit: r547792 - /tomcat/trunk/webapps/docs/aio.xml

[fhanik]

Author: fhanik
Date: Fri Jun 15 14:31:45 2007
New Revision: 547792

URL: http://svn.apache.org/viewvc?view=rev&rev=547792
Log:
Added in AJAX with delayed response example

Modified:
tomcat/trunk/webapps/docs/aio.xml

Modified: tomcat/trunk/webapps/docs/aio.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?view=diff&rev=547792&r1=547791&r2=547792
==
--- tomcat/trunk/webapps/docs/aio.xml (original)
+++ tomcat/trunk/webapps/docs/aio.xml Fri Jun 15 14:31:45 2007
@@ -282,6 +282,133 @@
   
 
   
+  Let's start with a real world example of how you could use Comet to 
handle AJAX requests.
+ An AJAX request is a complete HTTP request, followed by a complete HTTP 
response.
+ The next request is a new HTTP request.
+ There are many AJAX frameworks, and they can be used with regular 
servlets, so why
+ would I want to do this using Comet?
+ The answer is simply, with Comet you can do the response asynchronously 
and therefor
+ release the Tomcat thread to handle other requests.
+  
+  
+  
+Non blocking read and writes 
+
+public class ExampleDelayedAjaxResponse implements CometProcessor {
+ ...
+ public class DelayedResponder extends Thread {
+   public void run() {
+ ...
+ Client[] clients = getClients();
+ for (int i=0; i

svn commit: r547794 - /tomcat/trunk/webapps/docs/aio.xml

[fhanik]

Author: fhanik
Date: Fri Jun 15 14:35:57 2007
New Revision: 547794

URL: http://svn.apache.org/viewvc?view=rev&rev=547794
Log:
fix formatting for latest added example

Modified:
tomcat/trunk/webapps/docs/aio.xml

Modified: tomcat/trunk/webapps/docs/aio.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?view=diff&rev=547794&r1=547793&r2=547794
==
--- tomcat/trunk/webapps/docs/aio.xml (original)
+++ tomcat/trunk/webapps/docs/aio.xml Fri Jun 15 14:35:57 2007
@@ -309,7 +309,8 @@
if (event.isWriteable()) { //did we write it all?
   event.close(); //close the event, in anticipation of the next 
request
   event.register(OP_CALLBACK); //triggers an END event
-   } else { //we didn't write it all, trigger a WRITE event when we 
are done with the write   event.register(OP_WRITE);
+   } else { //we didn't write it all, trigger a WRITE event when we 
are done with the write   
+ event.register(OP_WRITE);
}
  } else {
//we are not able to write, let us know when we can
@@ -329,7 +330,8 @@
if ( event.getEventType() == CometEvent.EventType.BEGIN ) {
  //configure non blocking
  event.configureBlocking(false);
- //deregister for READ since we want to enable pipe lining on the 
connection  //for the next HTTP request
+ //deregister for READ since we want to enable pipe lining on the 
connection  
+ //for the next HTTP request
  event.unregister(OP_READ);
  //add the client to the list
  clients.add(event);
@@ -349,7 +351,8 @@
event.close();
  }
} if ( event.getEventType() == CometEvent.EventType.END ) {
- clients.remove(event); } else if (...) {
+ clients.remove(event); 
+   } else if (...) {
  ...
}
...
@@ -383,7 +386,8 @@
if ( event.getEventType() == CometEvent.EventType.BEGIN ) {
  //configure blocking
  event.configureBlocking(true);
- //deregister for READ since we want to enable pipe lining on the 
connection  //for the next HTTP request
+ //deregister for READ since we want to enable pipe lining on the 
connection  
+ //for the next HTTP request
  event.unregister(OP_READ);
  //add the client to the list
  clients.add(event);
@@ -395,7 +399,8 @@
  //unregister from the write event
  event.unregister(OP_WRITE);
  //we can now write
- byte[] data = getDelayedResponse(event);   //note we don't have 
to check for null data here
+ byte[] data = getDelayedResponse(event);   
+ //note we don't have to check for null data here
  event.getHttpServletResponse().getOutputStream().write(data);
  event.close();
} if ( event.getEventType() == CometEvent.EventType.END ) {



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

DO NOT REPLY [Bug 42669] - Unhelpful error message when using zip installation on Mac OS X

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 14:45 ---
No one is trying to be an a**hole, especially not me :)
http://tomcat.apache.org/bugreport.html
This is obviously not a bug, one could have submitted the a bug saying  "I can't
install apache-tomcat-5.5.24.exe on MacOS", you've downloaded the wrong
distribution and ran into an error, hence the suggestion is invalid.

It would be unreasonable for us to improve error messages based on people
downloading the wrong distribution. If you think the download page should have
more text describing what to download, please submit a patch for it.

thanks

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

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

DO NOT REPLY [Bug 42678] New: - docBase ignored even if its not a subdir of appBase

[bugzilla]

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

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

   Summary: docBase ignored even if its not a subdir of appBase
   Product: Tomcat 6
   Version: unspecified
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: minor
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I use latest 6.0 SVN snapshot. I store deployable WARs in "webapps-dist" (aside
"webapps"). This is my setup:

bash-3.2$ ls $CATALINA_BASE 
conf  logs  temp  tomcat-dist  webapps  webapps-dist  work
bash-3.2$ ls  webapps-dist
sample.war
bash-3.2$ cat conf/Catalina/localhost/sample.xml


this ends up in: 

WARNUNG: A docBase /home/juergen/java/tomcat/webapps-dist/sample.war inside the
host appBase has been specified, and will be ignored

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

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

DO NOT REPLY [Bug 42678] - docBase ignored even if its not a subdir of appBase

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 15:09 ---
Created an attachment (id=20359)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20359&action=view)
fix docBase starting with same prefix as appBase


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

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

DO NOT REPLY [Bug 42497] - 304 response should consistently include ETag header

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 15:50 ---
Tested OK in 5.5.24 release candidate.

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

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

Re: Serious non-native AJP connector issue

[Jess Holle]

Rainer Jung wrote:

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.
Got that, but I've accounted for that via maxThreads of 51 and 
BalanceMember max of 50.


I'm left wondering why there's an off-by-one beyond this (and thus an 
off-by-2 overall).
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.

I don't think any of those should be involved in this short test.

3) Does it happen with mod_jk too?
I believe so.  I did some mod_jk testing to verify the overall nature of 
the issue remained the same, but I didn't go through all the same 
detailed tests.  I could redo this particular test if that's helpful.

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).
My Apache MaxClients is 300 and this is on Windows so I only have 1 
worker process.
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.
I believe I disproved this at some point by running 2 tests with -n 50 
and -c 50 manually back to back, but I'd have to re-test to be sure.  
[I'm wishing I'd taken better notes of various results...]


Apart from this weird edge condition (an off-by-2 isn't that devastating 
if it stays "2" in all cases), the thing that gets me overall is that 
the documentation really makes it sound like "acceptCount" works like a 
fair queue and that there's no harm in exceeding maxThreads except that 
requests will be queued.  As Bill suggested, I should come up with 
suggested patches to the documentation -- I'm just not yet confident 
enough in my understanding to propose such patches.  At this point all I 
can propose is strong warning verbage around maxThreads and acceptCount 
regarding their behavior for the Java AJP connector.


--
Jess Holle

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

DO NOT REPLY [Bug 42646] - Content-disposition on ia64 causes request to break

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-06-15 18:18 ---
That it works on one platform but not another suggests an issue with the
configuration of the platform. I suggest you follow up on the users list but
some things to check that might save you an e-mail:
- does it work if you do this in a simple servlet?
- anything in the logs?
- try proxying through Axis's TcpMon to see exactly what headers are going back
and forth

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

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