[EMAIL PROTECTED] wrote:
> On Thu, 2 May 2002, Amund Elstad wrote:
> 
> 
>>(1) all requests without a session are routed to a specific tomcat instance
>>(if that instance is working). 
> 
> 
> That has been added, and it should work in both jk1 and jk2 ( I don't 
> remember who sent the patch, but I remember adding it ). If it doesn't 
> work yet, is easy to fix.
> 

Sorry, may be I'm stupid, but how does it work? I looked at jk and jk2. My 
understanding is the following:

The worker which uses the jvm route is the lb_worker. The others don't use the 
SessionId extension. You could tweak this worker, but its buggy or I 
misunderstood it. After you said that my patch is included a had a closer look 
at mod_jk. I can't see anything of my code but I found the special meaning of 
the zero lb_factor/lb_value. It seems that I didn't understand it right at the 
first time. This could solve my problem but after a closer look and some testing 
I found another problem. When you set the lb_value in workers.properties to 1 
for the local tomcat and 0 for the others, you get the desired behavior. But if 
you switch off the local tomcat for a short time you come into trouble. The 
problem is the 0 for the other workers. The calculation of lb_worker transforms 
the 0 to _inf_. Because 1/0 for a double is _inf_. This is greater than any 
other lb_value and greater than the lb_value of the local tomcat. But after a 
failure of the local tomcat he is in error_state. After some time its set to 
recovering and if the local tomcat is back again the function jk(2)_get_max_lb 
gets the highest lb_value. This is _inf_ from one of the other workers. The 
addition of a value to _inf_ is meaningless. You end up with an lb_value of 
_inf_ for the local worker. If this worker isn't the first in the worker list, 
it will never be choosen again. Because his lb_value will never be less than 
another lb_value, because all the other workers have _inf_ as theire lb_values. 
So every request without a session will be routed to the first of the other 
tomcats.

The only way out is a restart of the local apache after tomcat is up and 
running. But I don't know when tomcat is finished with all his contexts and 
started the connectors.

I didn't looked very deep into jk2, but I found the same 
get_most_suitable_worker and get_max_lb functions. The jk2_get_max_lb function 
will always return _inf_. In your answer to some other mails you said, that 
workers could be removed. Do I understand it right, that if my local tomcat goes 
down his worker is removed from the list and after he is comming up again added 
to the worker list with reseted lb_value (only for mod_jk2)?

The next days I will look in the docu and code of jk2 and give it a try. May be 
all my problems gone away with the new module :).

Sorry if I ask stupid questions, but I want to make it working for our new cluster.

Thanks

Bernd

> This is essential for jk2's JNI worker, which fits perfectly this case
> ( you don't want to send via TCP when you have a tomcat instance in the 
> same process ).
> 
> 
> 
>>(2) Tomcat instances in standby or "soft shutdown" mode where they serve
>>requests bound by established sessions, and requests without a session only
>>if all non-standby instances have failed.
> 
> 
> That's what the SHM scoreboard is going to do ( among other things ). 
> You can register tomcat instances ( which will be added automatically ),
> or unregister - in which case no new requests ( except the old sessions )
> will go to the unregistered tomcat.
> 
> 
> Costin
> 
> 
>>[EMAIL PROTECTED] wrote:
>>
>>
>>>On Tue, 30 Apr 2002, Bernd Koecke wrote:
>>>
>>>
>>>>some weeks ago I send a patch for mod_jk for an only routing lb_worker. A
>>>
>>few 
>>
>>>>days later I sent the docu. Henry Gomez said, that it should be commited.
>>>
>>But it 
>>
>>>>I think it isn't in the repository. But its the same  with me here, to
>>>
>>mutch 
>>
>>>>work for to less time :).
>>>
>>>I think it is in mod_jk, I remember seeing the commit. 
>>>
>>>And I think I commited it in jk2 as well ( after some modifications ).
>>>
>>>
>>>>I need sticky sessions but no loadbalancing in the module. If a request
>>>
>>without 
>>
>>>>a session comes in, it should be routed to the _local_ tomcat.
>>>
>>>Well, there is another use-case with the exact same behavior - Apache2 
>>>with tomcat in JNI mode. All requests without session should be routed to 
>>>the _jni_ channel ( i.e. in-process, minimal overhead ).
>>>
>>>It's exacly the same - so be sure I do my best to handle this case :-)
>>>
>>>Apache2 acts like a 'natural' load-balancer/fail-over, with the parent
>>>process monitoring for crashes and it starts/stop childs based on 
>>>load.
>>>
>>>
>>>
>>>>I think this could be possible with the associated instance of a channel
>>>
>>(item 
>>
>>>>7). Then I have to configure all four nodes for the same group. Because
>>>
>>all 
>>
>>>>nodes will serve the same webapps and associate the channel with this
>>>
>>group. But 
>>
>>>>for this I need a non balancing group. I don't see if the default
>>>
>>behavior of a 
>>
>>>>group is balancing and if this can be switched off. Is this right or do I
>>>
>>miss 
>>
>>>>something?
>>>
>>>The default is balancing, but you can tune this using weithgs ( and I 
>>>think we use your code for making one instance 'top priority').
>>>
>>>Please check the code, take a look and send additional comments/patches.
>>>
>>>It's not yet completely done, of course.
>>>
>>>
>>>Thanks,
>>>Costin 
>>
>>
>>--
>>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>--
>>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 



-- 
Dipl.-Inform. Bernd Koecke
UNIX-Entwicklung
Schlund+Partner AG
Fon: +49-721-91374-0
E-Mail: [EMAIL PROTECTED]


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

Reply via email to