At 06:38 AM 4/25/2005, Mladen Turk wrote:
Peter Rossbach wrote:
that is a very shot time period for testing.
Well, some of the things are really critical, so that's the reason.
I think that 1.2.8/1.2.9 proved that haste creates this churn.
Once 1.2.11 is ready, isn't it sufficient to point
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34614.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project jakarta-tomcat-jk-native has an issue affecting its community
integration.
This
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34609.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34610.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hey Mladen,
Mladen Turk schrieb:
Peter Rossbach wrote:
Hey Mladen,
I used the tomcat at cluster mode, but your answer is a little bit to
easy.
Sticky session is the only way for the most applications to be
consistens.
Session replication is only a secondary feature when failure occured.
Why
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34615.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34615.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34616.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34616.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hey Mladen,
I have made successfull a test implementation to deactived a worker. I
works very fine for me at windows.
Now made a second test under apache 2.0.54 and Linux 9.3 with worker and
prefork MPM.
I think in two hour I am ready to checkin the change. :-)
Peter
Peter Rossbach schrieb:
Hey
Peter Rossbach wrote:
Are you sure this is absolute necessity?
But at cluster the session are replicated, and we must not wait. Please,
can we
add a flag active=false/true to test my idea. What do you thing I can start
a quick experiment and send you the diffs for reviewing?
Well I'm -0 on the
William A. Rowe, Jr. wrote:
We've burned the users with deprecating mod_jk2. Generating churn
in mod_jk (as opposed to solid, stable releases) will only continue
to lessen users' faith in jk as a production solution.
Well, I don't quite understand your question.
JK2 is past tense, so that's
Mladen Turk schrieb:
Peter Rossbach wrote:
Are you sure this is absolute necessity?
But at cluster the session are replicated, and we must not wait.
Please, can we
add a flag active=false/true to test my idea. What do you thing I can
start
a quick experiment and send you the diffs for reviewing?
Peter Rossbach wrote:
I name the flag deactived.
Look, can we prolong that to the next release?
I would really appreciate that, because the 1.2.11
should be a bug-fix release.
Changing that would break the current configurations,
and IMO we could think of something smarter in the future.
Adding
Hey Malden,
Mladen Turk schrieb:
Peter Rossbach wrote:
I name the flag deactived.
Look, can we prolong that to the next release?
I would really appreciate that, because the 1.2.11
should be a bug-fix release.
Changing that would break the current configurations,
and IMO we could think of
Thanks,
stopped is a very good name!
Peter
Georg v. Zezschwitz schrieb:
On Tue, Apr 26, 2005 at 01:10:13PM +0200, Peter Rossbach wrote:
I name the flag deactived.
Sorry for a lurkers comment from the background (and I am neither
a native speaker).
But I guess it should be named:
At 06:01 AM 4/26/2005, Mladen Turk wrote:
I wish to make the 1.2.11 as a bugfix release, so where's the
churn in that?
Nothing, 1.2.11 is wonderful.
You proposed releasing 1.2.12/stable a few days afterwards.
I don't know if calling 1.2.12/stable in a few days is really such
a hot idea.
William A. Rowe, Jr. wrote:
I wish to make the 1.2.11 as a bugfix release, so where's the
churn in that?
Nothing, 1.2.11 is wonderful.
You proposed releasing 1.2.12/stable a few days afterwards.
I don't know if calling 1.2.12/stable in a few days is really such
a hot idea.
Me neither. I see
On Tue, Apr 26, 2005 at 12:57:12AM -0500, William A. Rowe, Jr. wrote:
At 06:38 AM 4/25/2005, Mladen Turk wrote:
Peter Rossbach wrote:
that is a very shot time period for testing.
Well, some of the things are really critical, so that's the reason.
I think that 1.2.8/1.2.9 proved that haste
Well 1.2.11 will be the latest stable release, until we discover bugs
in it and release a 1.2.12.
:-)
2005/4/26, Mladen Turk [EMAIL PROTECTED]:
William A. Rowe, Jr. wrote:
I wish to make the 1.2.11 as a bugfix release, so where's the
churn in that?
Nothing, 1.2.11 is wonderful.
You
Glenn Nielsen wrote:
We may want to consider use of a 1.3 development branch for new
features. I have noticed that there have been significant new features
added between releases of mod_jk 1.2.
Well, I agree with you that we create a new branch.
I wish to deprecate ajp12, jni and ajp14 connectors,
At 09:35 AM 4/26/2005, Mladen Turk wrote:
Well, I agree with you that we create a new branch.
I wish to deprecate ajp12, jni and ajp14 connectors,
as well as isapi, domino and ntservice servers.
Reasons:
... ntservice: unmaintained for years.
I've used ntservice for years, never had an issue,
William A. Rowe, Jr. wrote:
Reasons:
... ntservice: unmaintained for years.
I've used ntservice for years, never had an issue, happy to
maintain it. Can you point to a specific issue?
Well, excellent. No reason to omit from the 1.2 branch then :)
The effort might better be spent after conversion
AJP14 remove in JK 1.2.x and also in JTC ?
So where will you put new AJP stuff ?
2005/4/26, Mladen Turk [EMAIL PROTECTED]:
Glenn Nielsen wrote:
We may want to consider use of a 1.3 development branch for new
features. I have noticed that there have been significant new features
added
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34549.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
At 09:48 AM 4/26/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote
The effort might better be spent after conversion to svn, since
you attain the ability to have versioned rmdir, without hacking
up the raw CVS tree and breaking historical checkouts.
Hmm, I would like to leave the CVS until the
The message contains Unicode characters and has been sent as a binary
attachment.
Norton AntiVirus Deleted1.txt
Description: plain/text
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Henri Gomez wrote:
AJP14 remove in JK 1.2.x and also in JTC ?
So where will you put new AJP stuff ?
Inside the new connector :).
Really if we wish to have a full dynamic config,
discovery, encryption and compression we should
stick to APR, Apache2/IIS.
IMO for that kind of things we need a modern
pero2005/04/26 08:28:18
Modified:jk/native/common jk_lb_worker.c jk_shm.h jk_status.c
jk_uri_worker_map.h jk_util.c jk_util.h
Log:
Add stopped flag for better cluster support to worker.
Many thanks to Mladen :-
Revision ChangesPath
1.79
pero2005/04/26 08:30:59
Modified:jk/xdocs changelog.xml
jk/xdocs/config workers.xml
Log:
Add stopped flag for better cluster support to worker.
Many thanks to Mladen :-
Revision ChangesPath
1.24 +5 -0
Ok, what's the plan for the new connector ?
2005/4/26, Mladen Turk [EMAIL PROTECTED]:
Henri Gomez wrote:
AJP14 remove in JK 1.2.x and also in JTC ?
So where will you put new AJP stuff ?
Inside the new connector :).
Really if we wish to have a full dynamic config,
discovery,
pero2005/04/26 10:42:16
Modified:catalina/src/share/org/apache/catalina/ant
JKStatusUpdateTask.java
Log:
Update for new stopped flag at jk 1.2.11
Revision ChangesPath
1.3 +39 -9
I have a jk native compilation problem at suse 9.3 with the current CVS
HEAD.
Can't compile jk_connect.c
jk_connect.c: In function 'jk_shutdown_socket' :
jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function)
jk_connect.c:485: error (Each unde ...
How can I find the missing
Peter Rossbach wrote:
I have a jk native compilation problem at suse 9.3 with the current CVS
HEAD.
According to posix:
If how is 0, further receives will be disallowed. If how
is 1, further sends will be disallowed. If how is 2, further
sends and receives will be disallowed.
So ...
#ifnedf
This works for me from a clean build with the following process:
1. Build using build.xml as per
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html
2. Then cd jakarta-tomcat-5
3. build dist
4. build installer
You will need to configure build.properties in both ${tomcat-source} and
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34637.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34637.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
grep -r SD_SEND /usr/include/*
grep -r SD_SEND /usr/local/include/*
?
Tell us where it's hidden and it's more likely we can come up with
an appropriate patch. Any ./configure output would also be helpful.
At 01:01 PM 4/26/2005, Peter Rossbach wrote:
I have a jk native compilation problem at
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34399.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34549.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Mark,
Thanks for replying.
First an update.
Couldn't get this to work with cygwin.
It would build, but the .exe created would fail on Service Install.
Did get it to work with cmd.exe (this is with the original
build.properties.default. The nsis installer gets downloaded into
Hello, mturk.
(B
(BYou changed implementation of jk_ajp_common.c from Revision 1.67 to Revision
(B1.68.
(BACL have been judged UNKNOWN_METHOD since its modification.
(BWhy ?
(B
(Bregards
(BTakahiro
(B
(B-
(BTo
Hey,
here the configure output
[EMAIL PROTECTED]:~/develop/tomcat/jakarta-tomcat-connectors/jk/native
./configure --with-apxs=/home/peter/server/apache2/bin/apxs
checking build system type... i686-suse-linux
checking host system type... i686-suse-linux
checking target system type...
Mail transaction failed. Partial message is available.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
45 matches
Mail list logo
