https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
Eiji Takahashi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #16 from Rainer Jung 2009-03-10 01:13:06
PST ---
Doh!
Fixed (r752016 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=752016 ).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- Y
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #15 from Eiji Takahashi 2009-03-09 23:59:56
PST ---
Created an attachment (id=23364)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23364)
patch for jk_util.c
Thank you for dealing with this problem.
I will ex
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #14 from Rainer Jung 2009-03-09 20:01:13
PST ---
I discussed with Mladen and we both committed a few changes.
But let's first express our expectation to what should happen.
We don't want the system to behave overly nervo
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #13 from Eiji Takahashi 2009-03-09 00:35:03
PST ---
> Nope this is completely valid. The node is retried in a conservative maner.
> Before pulling out the cable you should mark the node a Disabled, and
> when all sessions
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
Mladen Turk changed:
What|Removed |Added
Component|Common |mod_jk
--- Comment #12 from Mlad
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #11 from Eiji Takahashi 2009-03-07 07:49:16
PST ---
Oops! I'm sorry. The log file was too large. I divided the log file.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are re
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #10 from Eiji Takahashi 2009-03-07 07:47:10
PST ---
Created an attachment (id=23352)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23352)
log file 4 of 4
--
Configure bugmail: https://issues.apache.org/bugzi
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #9 from Eiji Takahashi 2009-03-07 07:45:38
PST ---
Created an attachment (id=23351)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23351)
log file 3 of 4
--
Configure bugmail: https://issues.apache.org/bugzil
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #8 from Eiji Takahashi 2009-03-07 07:44:52
PST ---
Created an attachment (id=23350)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23350)
log file 2 of 4
--
Configure bugmail: https://issues.apache.org/bugzil
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #7 from Eiji Takahashi 2009-03-07 07:43:57
PST ---
Created an attachment (id=23349)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23349)
log file 1 of 4
--
Configure bugmail: https://issues.apache.org/bugzil
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #6 from Eiji Takahashi 2009-03-07 07:28:41
PST ---
Hi.
I'm sorry that the explanation is insufficient.
I used the roughly following settings.
-
worker.list=wlb
# not use socket_connect_timeout
worker.ap00.socket_t
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #5 from Rainer Jung 2009-03-06 03:56:54
PST ---
Did you actually use prepose cping/cpong and socket_connect_timeout to keep
latency of error detection low for the two cases "already connected" and "new
connection"? If so,
I'll bring that to dev list ...
bugzi...@apache.org wrote:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #4 from Rainer Jung 2009-03-06 00:13:55
PST ---
So having the "new" busy in shm is on purpose, and we have three of those:
a) one for the lb in total
b) one fo
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #4 from Rainer Jung 2009-03-06 00:13:55
PST ---
So having the "new" busy in shm is on purpose, and we have three of those:
a) one for the lb in total
b) one for each lb sub
c) one for each ajp worker
b) and c) are very l
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #3 from Mladen Turk 2009-03-06 00:06:07 PST ---
Right the problem here is that we don't know weather
the failed connection to backend was caused by Tomcat
rejecting the connection because too busy or someone pulled
the cabl
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #2 from Rainer Jung 2009-03-05 23:51:05
PST ---
I'm also investigating this and try to fully understand all implications of
r647085 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=647085 )
One first question (to Mladen)
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
--- Comment #1 from Mladen Turk 2009-03-05 23:38:00 PST ---
Your patch breaks other things that are more important.
The check fof busy is deliberate because athough one connection can be
rejected others might still work. This would mea
18 matches
Mail list logo
