Rainer Jung wrote:
Hi Mladen,
I checked out jk trunk today and built mod_jk
Can you double check the trunk?
Think I've fixed the CRLF issue.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
Hi all,
The next version of mod_jk is approaching its release. A code snapshot is
available at:
http://people.apache.org/~mturk/jk-1.2.22-dev/
It is in the same format as a release download, so easy to build.
It would be nice, if we could get some testing feedback from the community.
Feel free
William L. Thomson Jr. wrote:
The next version of mod_jk is approaching its release. A code snapshot is
available at:
http://people.apache.org/~mturk/jk-1.2.22-dev/
Little version funkiness?
1.1.22 ?
LOL, my bad, but you already know what I meant (1.2.22)
Cheers,
Mladen.
-
Rainer Jung wrote:
Hi Mladen,
did you delete setting owner and group by accident from the release script?
No, I did it by purpose. I don't have user or group named asf, so the tar
fails. What would be a purpose of it anyhow, and how would you ensure
that the same user will exist on the users
Rainer Jung wrote:
OK, I forgot, that I actually had a user and group named asf (I thought
tar would ignore their non-existance).
All in all I would suggest root:bin to.
I used root:users instead.
Think the users group exists on all *nixes.
Regards,
Mladen.
All in all I would suggest root:bin to.
I used root:users instead.
Think the users group exists on all *nixes.
Hmm, it doesn't after all :(
Switching to suggested root/bin
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL
Hi,
Few months ago Filip added something like
Now, that simply doeasn't work because SSL.initialize(null) is always called,
and my perception was that this would allow having SSL.initialize(someengine)
or not calling SSL.initialize at all if off is entered.
Now, additional param would be neede
Filip Hanik - Dev Lists wrote:
That should be pretty straight forward, no mbean or anything needed.
I'll take a look at it tonight
Cool, otherwise if we have a native compiled without SSL,
it throws exception instead not initializing SSL at all.
Regards,
Mladen.
-
Hi,
The quality check release was out few days ago.
I plan to tag the mod_jk tomorrow morning Europe time.
Any objections?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PR
Jim Jagielski wrote:
The quality check release was out few days ago.
I plan to tag the mod_jk tomorrow morning Europe time.
Any objections?
This is a "holiday" weekend, so maybe afterwards?
OK, so the schedule is then for Tuesday May 10th.
Regards,
Mladen.
Coffman, Steven wrote:
Hi,
I have a question for 42038. I only recently figured out exactly what
was causing it, so I'm sorry for the bugzilla spam as I zeroed in on it.
I already explain that in the bz case.
Please do not steal threads!
Regards,
Mladen.
-
Rainer Jung wrote:
1) Things to add to the changelog
=
I added few. Some of them are waste of resource IMHO ;)
I found the following changes, which are missing in the change log. Not
all of them need to go there, but maybe Mladen, Jean-Frederic, Guenter
and
Mladen Turk wrote:
Hi,
The quality check release was out few days ago.
Hi there is new quality check release available from:
http://people.apache.org/~mturk/jk-1.2.22-dev/
It contains few minor fixes mostly for documentation
and release script (owner/group for .tar)
I'll give it 24
Hi,
Mod_jk 1.2.22 has been available for testing for some days.
No new bugs have been reported so far, so it is time to proceed with the
release vote.
The source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.22/
or
http://www.apache.org
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
The source distribution can be downloaded from:
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.22/
or
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.22/
May I ask -why-?
It's not released (quit
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Don't understand your question.
It was more then a week available for a developers review.
The official stable is still 1.2.21 until 1.2.22 gets votes or not,
in which case we'll go for 1.2.23.
So what's the problem?
How many time
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
I suggest you revoke my commit privileges to the
www.apache.org/dist/ so it won't happen again and you
won't need to repeat this again.
I'm sure infra would be happy to if you would prefer this.
LOL. Man, you really don
Jim Jagielski wrote:
On Apr 13, 2007, at 7:20 AM, Yoav Shapira wrote:
Let's try to chill out, please ;) I'm sure putting the candidate
binaries on the official mirrors before the vote was an honest
mistake.
++1 (especially on the chill out part ;) ) !!
I think the issue is that, especially
William A. Rowe, Jr. wrote:
So, can we agree I made an mistake?
Hey, I make 'em all the time...
No - I don't dislike you Mladen :) Nor Redhat - work with Marc and Joe
all the time on httpd-stuff.
Cool, let's move forward. I'll make sure I don't upload files
on random places any more :)
Ch
Guenter Knauf wrote:
Hi,
Therefore I would like to suggest another approach: let us import ap_snprintf.c
from Apache 1.3.x into the mod_jk project.
comments welcome!
Just commit if you think it's more portable.
Regards,
Mladen.
---
Henri Gomez wrote:
Still on mod_jk and this kind of stuff.
We switch our dev servers from i5/OS v5R4 and many changes occurs in
IBM HTTP Server powered by Apache, and for instance this one :
If I could'nt fix/adapt for i5/OS, we may have to remove the whole
AS400 support in next release of mod_
Henri Gomez wrote:
2007/4/16, Mladen Turk <[EMAIL PROTECTED]>:
You mean the support for the IBM HTTP Server.
I suppose the AS400 is still able to have genuine Apache Httpd
and mod_jk compiled and running.
Nope on AS400, there is an IBM HTTP Server (powered by Apache), so
it's no
Henri Gomez wrote:
Right, but one can compile Apache Httpd from the ASF thought
and run it on AS400. I suppose all the EBCDIC we added to
mod_jk will allow it compile with standard httpd like before.
On AS400, it will be more than difficult and not supported by IBM.
But it will be supported
Hi,
The results of the vote are:
Stable: 5 votes (Rainer, Guenter, Jim, Peter and mine implicit)
Beta, Alpha: None.
According to the vote, I'll put the releases
from tomcat.apacheorg/dev/dist to apache.org/dist,
wait for few hours and make an Announce
Regards,
Mladen.
---
Hi,
Some files on /x1/www/tomcat.apache.org
have 0644, instead 0664 and are owned by markt.
Mark can you change those the files to a correct permission?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additiona
The Apache Tomcat team is pleased to announce the immediate availability
of version 1.2.22 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 ver
[EMAIL PROTECTED] wrote:
Author: hgomez
-#ifdef AS400
+#if defined(AS400) && !defined(AS400_UTF8)
So, seems that UTF8 is now default for AS400
I wonder why are you maintain AS400 since you said
it doesn't work anyhow.
Also, UTF8 in mod_jk does not exist. All we have
is < 127, so there is no
Henri Gomez wrote:
2007/4/20, Mladen Turk <[EMAIL PROTECTED]>:
[EMAIL PROTECTED] wrote:
> Author: hgomez
>
> -#ifdef AS400
> +#if defined(AS400) && !defined(AS400_UTF8)
So, seems that UTF8 is now default for AS400
On i5/OS V5R4 (not on previous release)
But
Remy Maucherat wrote:
The candidates binaries in which I suppose a horrible bug will be found
in about 5 minutes are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.12/
Tested on all windows versions and linux.
Works fine. Will you propose a vote?
Regards,
Mladen.
-
Martin Goldhahn wrote:
Hi!
I did some modifications to the Jakarta ISAPI filter in
connectors/trunk/jk/native. It would be nice to see most of them
included the distribution.
Like explained in the bz..
This connector is unsupported!
Use native/iis instead for using iside Microsoft IIS.
Other on
Markus Schönhaber wrote:
Could you please explain the reason for this change?
Sure :)
Using APR_UNSPEC was introduced to make the APR Connector also listen on
IPv6 addresses if no specific address is configured - this way
resembling the behaviour of the Base Connector.
http://issues.apache.
Markus Schönhaber wrote:
You might also want to change
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
I will. Just needed a second confirmation if it's working as expected.
Regards,
Mladen.
-
To
David Rees wrote:
OK, I see that mladen has recently checked in some jk changes. As soon
as he gives the word, I'll check out the latest from SVN and do some
testing.
Think I'm done with all the patches I had on my schedule.
Feel free to check the HEAD.
Regards,
Mladen.
Costin Manolache wrote:
are quite different,
I want to have it simpler and smaller than the apr model. I think old-style
connector
should be deprecated, since JDK1.5 is now required there is no point in
having it.
Sorry for stealing the thread ;)
What about old jk2 connectors found again in t
Costin Manolache wrote:
What about finally creating tomcat-modules or tomcat-addons ( or any other
name ),
for stuff that is (more or less) tomcat version independent, or at least
works for
multiple recent versions, and can be released independently ?
This way the cluster stuff would have a bet
Costin Manolache wrote:
Maybe create a modules/ under tomcat6 - with the definition 'stuff that can
be
released independently, and may support older versions of tomcat as well'
Or just 'can be released independently'.
Hmm, I'm not very much in favor of that.
If the 'module' is mature enough it
Costin Manolache wrote:
By modules/ I mean mostly release units - so maybe a build.xml to create
build and package the module, some readme, manifest, etc. Tomcat normal
release wouldn't include the module, but it can be released independently,
maybe
for multiple versions of tomcat.
Look, if
Costin Manolache wrote:
I don't see the benefit of having things like cluster support in the tomcat
release -
if someone does want a cluster, they can easily download an additional
jar -
setting
up a cluster involves a lot of work, we won't make it much simpler by
bundling the jar with
tomcat.
Costin Manolache wrote:
Of course - all stuff must compile at least - but I don't think it's a
reasonable
requirement to have all modules or other things that are not part of tomcat
tested in order to do a release.
But in that case, they could not be the part of the Tomcat code.
If you think
Costin Manolache wrote:
On 6/19/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
I agree - it's good to have a single codebase !
But I strongly disagree that we should have one big bloated release that
includes
everything in the codebase.
Look, all that I'm saying is that the cod
William A. Rowe, Jr. wrote:
Mladen, maybe you aught to have deleted the @author tag while you were
at it :)
Right. It seems so :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi all,
IMO this is mostly Costin related, because he has something
inside the sandbox :)
Now my question is, could the current sandbox content be
moved to the /sandbox/abc so I (or someone else)
can create a /sandbox/xyz ?
Right now the sandbox is not the 'sandbox' but rather
the Tomcat6Sanbox
Rainer Jung wrote:
Hi Mladen,
Costins README.txt inside the sandbox already suggested:
I know, I read the README, but the content inside does
not follow the README. That's the point :)
Regards,
Mladen.
-
To unsubscribe, e-m
Rainer Jung wrote:
-static int JK_METHOD maintain_workers(jk_worker_t *p, jk_logger_t *l)
+static int JK_METHOD maintain_workers(jk_worker_t *p, time_t now,
jk_logger_t *l)
{
unsigned int i = 0;
jk_uint64_t curmax = 0;
long delta;
-time_t now = time(NULL);
-JK_TRACE_ENT
[EMAIL PROTECTED] wrote:
I'm not seeing the windows problems, I used to have many problems on
windows using jdk1.4, but since 1.5 I have no problems at all. I do have a
brand new machine, so maybe there is some windows patch on it that I
didn't have before, other than that I can't think of anythi
Costin Manolache wrote:
You mean to remove the 'single tree', and only have components ? I can live
with this,
but I don't think it's the best idea - and I haven't seen any reasons for
that.
The idea of the sandbox is that you can try things in it - including the
single source tree :-)
Right.
Rainer Jung wrote:
Hi,
I would like to start releasing mod_jk 1.2.16 this week.
Any comments?
+1
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
David Rees wrote:
On 6/27/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
- take the role as RM for mod_jk 1.2.16
- tag mod_jk soon as 1.2.16-rc1
Why not do releases like tomcat/httpd do it? Go ahead and
rollup/release 1.2.16, then vote on the stability. If there are
problems, roll up another relea
William A. Rowe, Jr. wrote:
Someone might want to review the 2nd to last paragraph here;
http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/
He he :)
Seems like old copy/paste policy is in place for years :)
Regards,
Mladen.
--
Rainer Jung wrote:
Hi,
As a result of 1) I propose to roll 1.2.17 as soon, as Mladen has done
4) (assuming it's just minor stuff).
Like said, lets postpone that for Monday.
The changes I made are mostly cosmetic, since I reverted
the reties patch. I need to make some testings
during the weeke
You see how desperate I am when writing this on Sunday :)
Anyhow, we are pretty close to the new JK release that I
hope will be the most usable and stable whatsoever.
The things we agreed so many times before, but having
obviously too little resources to actually create are
the 1.3 branch (aka J
Costin Manolache wrote:
What's the status with mod_proxy ?
It seems this kind of change would break backward compatibility, and if
this
happens - maybe it's better to fix the protocol marshalling limitations or
change it completely.
I hate the idea of patching an old and mostly broken marshall
Jean-frederic Clere wrote:
Rainer Jung wrote:
It's called once a minute (at least if a request comes in) to be able to
clean up things not directly related to the actual request, like closing
idle connections.
Something to add to mod_proxy probably.
If you finish your maintenance module
Jean-frederic Clere wrote:
If you finish your maintenance module then it'll
be his responsibility to make a heartbeat independent
of the request, on the regular intervals.
Sure I need an extra program to make a real heartbeat but I still still
don't see how I could close a socket in a httpd s
Filip Hanik - Dev Lists wrote:
This is a question for the user list, it might be better for you to take
the inquiries there, and you shouldn't need to hack tomcat for something
like this.
Simply create a filter, that wraps your HttpServletRequest in a
HttpServletRequestWrapper,
worst case you
Henri Gomez wrote:
What the status of mod_jk 1.2.17 ?
It would be usefull to get some binaries to help users check against
their platform, for instance win32.
http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/
Wait for a while until synced.
Regards,
Mladen.
-
Rainer Jung wrote:
Hi Mladen,
would you mind putting it on
http://tomcat.apache.org/dev/dist/
first?
Nope. There is no version/platform directory
structure inside.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTE
William A. Rowe, Jr. wrote:
IF 1.2.17 sources aren't at www. then, well, the binaries don't belong
there either.
Simply used the current method.
Was not aware of the new repo inside tomcat.
Should I delete them or what?
Regards,
Mladen.
--
Henri Gomez wrote:
jk 1.2.17 build failed on iSeries v5R3.
/home/apache/jk/native/common/jk_connect.c, 198.38: CZM0280(30) Function
argument assignment between types "int*" and "unsigned int*" is not
allowed.
Henri, can you commit the working version?
Seems that the 'unsigned int' is presen
Rainer Jung wrote:
Be careful:
I understand Henri problem report as getsockopt complaining about the
*last* argument. So it has been introduced between 1.2.15 and 1.2.16:
r386629 | pero | 2006-03-17 13:36:04 +0100 (Fri,
Henri Gomez wrote:
Well on iSeries the C compiler is very strict about these kind of
typecast so the socklen_t should be used (and the build works with
it).
Can you check the current head?
I committed the fix.
--
Mladen.
-
T
Rainer Jung wrote:
Then let Peter try it on Mac OS X, if he only gets a warning or a real
error.
Sure, but since
http://www.hmug.org/man/2/getsockopt.php
says that the OS/X uses socklen_t as well, we should be fine.
--
Mladen.
Henri Gomez wrote:
Good, so we're ready for a 1.2.18 release ?
Sure if the Rainer still has the energy
for another run :)
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL P
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Tue Jul 18 08:38:14 2006
New Revision: 423119
URL: http://svn.apache.org/viewvc?rev=423119&view=rev
Log:
Add svn:eol-style:native.
We'll probably need to do that for the entire repository.
-1. This will screw up diffs, which w
Rainer Jung wrote:
Maybe we need to set everything to native, checkout, convert those that
have the wrong endings and commit?
No need for co/commit.
svn propset will convert current line endings to the virtual
one I suppose, and then each client depending on the platform
will have correct E
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Why it would be?
JK 1.2.18 is still not tagged.
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Henri Gomez wrote:
Well a new show stopper for 1.2.18 ;(
Committed a fix that allows to have a
worker.name.recover_time lower then 60 seconds.
Previously the minimum value was 60 seconds, and
now is 1 second.
The default is still the same (60 seconds)
Regards,
Mladen.
---
Rainer Jung wrote:
6) We could make the interval configurable, but there is a real danger
of users thinking, that a low recovery interval, like 10 seconds would
make things better, whereas it is very likely, that it would make there
whole system kind of oscillate.
Well, I don't wish to li
Rainer Jung wrote:
No, I think it's not:
1) This is not a regression, it was always implemented like that.
Right, and the reason it was never changed was because
no one gave any reason to change it.
Like said, 60 seconds recover timeout was probably used
since someone thought it should be 'fi
Rainer Jung wrote:
Mladen Turk wrote:
Anyhow, why would 60 second be optimal value?
It could as well be 90, 100, 180, etc...
Increasing is something totally different. I just want to avoid people
ending with a system that changes error/ok states with a high frequency,
so that the whole
Rainer Jung wrote:
I'm OK with your change.
I think we should try to educate the users via doc, that they need to be
careful when lowering these values to very small numbers. I don't know,
if that's the right term, but the system needs some damping to keep it
from switching very frequently be
Hi,
I have created a branch that shows the difference between
current trunk and the new one wit correctly set
svn:eol-style and svn:executable
For example the
java/org/apache/catalina/Context.java when checked
out on linux has DOS line endings with those ugly ^M.
The same file with svn:eol-style
Rainer Jung wrote:
Hi,
http://tomcat.apache.org/dev/dist/
The .zip files have Unix line endings.
At least all .dsp and .dsw files *needs* to
have the DOS line endings, because VStudio
complains about corrupted project files.
This is only needed for .zip files.
Also,
http://tomcat.apache.or
Rainer Jung wrote:
To find out, why this is so: did you get the same VStudio complains for
1.2.16 or 17? I tought you built those?
I would suggest to just repack the zip, since there is no change in
repository and no official release yet.
Well, it's just packing, and its RM responsibility :)
Rainer Jung wrote:
To find out, why this is so: did you get the same VStudio complains for
1.2.16 or 17? I tought you built those?
I would suggest to just repack the zip, since there is no change in
repository and no official release yet.
OK.
I have used your zip file and simply run
the perl
Hi,
Anyone has a working copy of InstallShield
and is able to build the the .msi?
Inside iis/installer/bin one needs to put
the isapi_redirect.dll and run the
isapi-redirector-win32-msi.ism
Bill, IIRC you have one for building
httpd? Any chance you create this build?
I had mine IS 10, but the
If anyone wonders what all those SVN commit messages are about,
they are about moving the /sandbox to the /sandbox/tomcat-lite
I choose the name, but I suppose Costing might have other ideas,
so a simple 'svn mv tomcat-lite what-ever-name' should do the trick.
The problems was because the /path/*
Hi,
First of all I wish to nominate myself as a greatest spamer.
A simple SVN lock/unlock happens to send couple of thousand
emails before I realized that the email is send for each
file in the trunk.
Sorry if that made problems with you mail boxes.
Anyhow, hope no one will in the future make
th
Jim Jagielski wrote:
I'm assuming this the the reason for the slew of svn lock messages :)
Right :(
Any chance to suppress that in future?
If someone else accidentally hits the svn lock
on the trunk the same will happen again.
Regards,
Mladen.
Cesar wrote:
LA PUTA QUE TE PARIO HIJO DE PUTA, DEJATE DE ENVIAR BASURAA
At least try to swear on English :)
- Original Message - From: <[EMAIL PROTECTED]>
To:
Sent: Thursday, July 20, 2006 10:03 AM
Subject: svn unlock:
/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Lo
Yoav Shapira wrote:
Hi,
On 7/20/06, Costin Manolache <[EMAIL PROTECTED]> wrote:
The svn messages are quite horrible IMO. Is there any way to suppress
them
in future ?
So all in all, let's treat today as the unusual event it was in terms
of volume of SVN messages, and keep things the same un
Costin Manolache wrote:
I'm pretty sure Mladen didn't intentionally do a 'svn lock/unlock' on each
file. Maybe his IDE did - he can
comment on what commands he used to perform the operation.
$> svn lock trunk
$> svn propset ...
$> svn unlock trunk
Changing a property on all files in a repos
Paul Querna wrote:
If you think svn is correct in sending lock/unlock/proppatch mails for
each individual file ( without at least agreggating them ) - then
It was done separately BECAUSE it was not done in a SINGLE ATOMIC COMMIT.
THIS IS CAUSED BY USER ERROR, AND NOT BY A PROBLEM WITH SUBVER
Mladen Turk wrote:
Paul Querna wrote:
THIS IS CAUSED BY USER ERROR, AND NOT BY A PROBLEM WITH SUBVERSION OR
OUR CONFIGURATION.
Then you might put that somewhere inside www.apache.org/dev
One note:
Sorry, seems it was caused by the Tortoise SVN client.
It has an option to 'Get Loc
Trent Nelson wrote:
Mladen Turk wrote:
Just out of interest, is there any motivation to switch to Nullsoft's
Installer for future mod_jk/isapi_redirect releases? Given that
tomcat's win32 installer uses this, and it's free, I would think that
would be a better option than Inst
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Nullsoft lacks advanced IIS virtual directory
creation/deletion. I suppose it can be done with
multiple .vbs scripts.
EWWW - no :) They are keys.
No, they are not. Neither are filters :)
--
Mladen
Rainer Jung wrote:
Apache Tomcat Connectors 1.2.18 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
BTW, excellent job Rainer!
--
Mladen.
-
Hi all,
Here is the config that IMHO each committer using
TortoiseSVN should set up.
It will resolve the things that were needed to be done for
the TC6 because they were added to the svn repo without
proper default properties.
So:
1. Right click on any Windows folder
2. Select TortoiseSVN->Setti
Mladen Turk wrote:
Hi all,
Here is the config that IMHO each committer using
TortoiseSVN should set up.
It will resolve the things that were needed to be done for
the TC6 because they were added to the svn repo without
proper default properties.
So:
1. Right click on any Windows folder
2
Mark Thomas wrote:
Here is the config that IMHO each committer using
TortoiseSVN should set up.
There is already an Apache wide recommendation that would appear to be
more comprehensive.
http://www.apache.org/dev/svn-eol-style.txt
Great!
I just wish something like that were mentioned
insid
Jean-frederic Clere wrote:
Hi,
Does it make sense we register the AJP port to IANA?
No.
It has numerous limitations that makes it almost
unusable in anything but webserver->servlet-engine
communication. And even that is limited by the
8K message. We should persuade a next generation
binary ht
Jim Jagielski wrote:
I and other have run into issues where the socket
between Apache and Tomcat (due to a in-between firewall)
isn't closed as it should be... I'm digging further into
this as far as why the timeout isn't being honored, but
it got me thinking that a "no reuse" option might be
nic
Remy Maucherat wrote:
Maybe JIRA should be used for TC 6 ?
++1
Further more, I would like to have that
all across tomcat.apache.org, not only
for TC6.
--
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional c
Filip Hanik - Dev Lists wrote:
I was gonna suggest a
worker..reuse=True|False
This is a very minor, non intrusive change since jk_ajp_*.c already has
a struct that has a reuse flag, and it respects it, the code currently
hard codes it to true.
It (or at least it should) favors this flag acc
Jim Jagielski wrote:
Makes no sense to me.
Yeah, the recommendation for people who are
hit by this is either (1) avoid AJP or (2)
set MaxRequestsPerChild (in httpd) to 1
See my reply about AJP13_END_RESPONSE reuse flag.
The Tomcat should be responsible for deciding
if the connection will
Filip Hanik - Dev Lists wrote:
cool, I will cut the release
Can you hold that up till Monday?
I would like to test and cut the tcnative
in front so that installer uses new binaries.
Regards,
Mladen.
-
To unsubscribe, e-mail:
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
See my reply about AJP13_END_RESPONSE reuse flag.
it works fine, connections close
So, is it working or not?
You've send two contradictory posts to this thread :)
Regards,
M
Jim Jagielski wrote:
On Aug 18, 2006, at 12:40 PM, Mladen Turk wrote:
The Tomcat should be responsible for deciding
if the connection will be reused or not.
This doesn't match, iirc, how the whole cache_timeout
(or connection_pool_timeout) is done within mod_jk...
Basically, what
Peter Rossbach wrote:
+1, and we can move the other parts later. Give new source a chance with
a better bug system :-)
I agree. The transition of other components if ever done
would be a great thing to have, but its not mandatory for
having TC6 in JIRA.
If someone has a knowledge and itch fo
Rainer Jung wrote:
I still don't have a consistent idea what happened around the firewall:
It is a very simple:
1. There are firewalls that will cut the connection
between mod_jk and Tomcat without sending FIN.
You can not do anything with that, cause they
simply exist, and I don't ca
301 - 400 of 1263 matches
Mail list logo
