Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Henri, Dan,
There are some discussions below about the usage
of msg/rmsg. What did you guys finally decide
on that? Just reuse msg? I'm seeing the problem
Dan mentioned on message larger than the ajp13
buffer (8K).
thanks,
s
> 1) First off, I strongly believe that this work (which I think is an
>excellent feature, BTW), belongs in the 3.3 branch, and *not* in 3.2.
+1, there was a message about including latest mod_jk features/corrections
back to Tomcat 3.2.x but TC 3.2 Release Manager and others clairly
stated that
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
I proposed to [EMAIL PROTECTED] list some days
now
that we start a subproject called web-connector where
we could put mod_jk/mod_jserv/mod_webapp with
both
native (Apache, NES, IIS) and Java
(Modules/Interceptors for
TC 3.2.x, 3.3
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
> 1) First off, I strongly believe that this work (which I think is an
> excellent feature, BTW), belongs in the 3.3 branch, and *not* in 3.2.
> Although it feels like a bug that we need to restart Apache
> every time w
Henri,
I looked in the archives and found the patch which I hadn't seen (my ISP's
mail server needs a serious talking to!).
Okay, I think I see some fairly serious issues. I'll lay out here what I've
seen so far:
1) First off, I strongly believe that this work (which I think is an
excellent f
Henri,
I think you're right about not trying to clean out the cache of endpoints.
Too much work and not really necessary.
I'd be happy to check your code, but I don't think I've seen it -- did you
submit it to the list (I may have missed a few messages to the list)?
-Dan
GOMEZ Henri wrote:
>
>In the mean time, I have taken Henri's changes and back
>port it to 3.2.1 (because I need it on 3.2.1). Everything
>seems to work well. I've tested it in the normal scenarios
>(one Apache, one Tomcat) and in the load-balanced scenarios.
Thanks for using the patch and tested it under LoadBal
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Hi, Dan,
I may not understand all of the issues here. But I really
don't think we should close all connections when we
detect one ECONNRESET. In my opinion, it is not necessary
to close all connections, since the next ECONNRESET
a
> connaissance.
> -- Benjamin Disraeli
>
>
> >-Original Message-
> >From: Dan Milstein [mailto:[EMAIL PROTECTED]]
> >Sent: Friday, March 09, 2001 6:34 AM
> >To: [EMAIL PROTECTED]
> >Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
> >
>
La prise de conscience de votre propre ignorance est un grand pas vers la
connaissance.
-- Benjamin Disraeli
>-Original Message-
>From: Dan Milstein [mailto:[EMAIL PROTECTED]]
>Sent: Friday, March 09, 2001 6:34 AM
>To: [EMAIL PROTECTED]
>Subject: Re: FW: problem w/ aj
Here how we could do :
>Okay, I basically agree with you. I'll take out
>the check for errno and just have recv() == -1
>be considered a recoverable error (i.e: retry it).
>However, I disagree with making the retry in a
>loop for RETRIES times. This is because if one
>retry fails, this mean
Henri,
You say that checking errno isn't safe in a multithreaded env (which would
certainly makes sense to me, since it looks like a global var).
However, after searching online, and reading up in "Programming Threads", by
Kleiman, Shah and Smaalders, I find on p. 47:
"Each thread has its own i
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Okay, I basically agree with you. I'll take out
the check for errno and just have recv() == -1
be considered a recoverable error (i.e: retry it).
However, I disagree with making the retry in a
loop for RETRIES times. This is be
>Okay so this means, you would prefer my proposed solution #1?
>That was my inclination too.
Proposed solution #1 without the errno check.
My idea :
get the service code in a loop
for (i = 0; i < RETRIES; i++) {
if (send_request() < 0)
continue;
if (read_r
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
> I revue your patch and I notice :
>
> We could use select to determine if something happen to the
> connection, typically readfds will be set if something is to read.
> With ajp13 protocol where everything is consume
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
I revue your patch and I notice :
We could use select to determine if something happen to the
connection, typically readfds will be set if something is to read.
With ajp13 protocol where everything is consumed after reading the
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
> BTW we should redirect this to the tomcat-users list as I don't think
> its a development issue.
Sorry about that.
> I don't see anything wrong, and the only drastic difference from my
> previous setup w
unfortunately I do not remember what the strings were to fix
this, but
I'm sure their documented somewhere (and they're not intuitive)..
Hope this helps some.
-Andy
-Original Message-
From: Shinta Tjio
To: 'oliver2, andy'; '[EMAIL PROTECTED] '
Cc:
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Here's exactly what I did to reproduce the problem.
Again, I'm running this on a Solaris 2.8 SunOS machine,
using JDK1.2.2, Apache 1.3.14, Tomcat 3.2.1.
1. Start Apache
2. Start Tomcat
3. Start hitting Apache with multipl
:[EMAIL PROTECTED]>
]
> Sent: Tuesday, March 06, 2001 12:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
>
>
> What version of TC are you using? What version of Apache?
>
> I would look into the mod_jk docs -- I think t
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
I am using Tomcat 3.2.1, Apache 1.3.14, running on
Solaris 2.8, Sun machines.
After various attempts of debugging this, I have
more information.
1. Even though I'm setting the worker's property
cache_size to default (1), I
What version of TC are you using? What version of Apache?
I would look into the mod_jk docs -- I think this is the spec'd behavior
(which, admittedly, is not great, but that makes it more of a feature
request than a bug ;-). With ajp13, Apache opens up a persistent TCP/IP
connection TC -- if TC
22 matches
Mail list logo
