Thank for clarification
1) in unix if we do not update lb_mult of worker then push it to shm
storage and indicate other processes to pull it from shm storage then
how other processes know that the balancer was changed and act
accordingly ?
Looking at static void commit_all_members(), there is clear that the
update_mult is performed correctly before jk_lb_push
3657 else if (rc == 2)
3658 /* Recalculate the load multiplicators wrt. lb_factor */
3659 update_mult(lb, l);
3660 if (rc) {
3661 lb->sequence++;
3662 jk_lb_push(lb, JK_TRUE, l);
3663 }
2) As I understand there are jk_lb_pull which sync mem from shm to
heap and jk_lb_push which sync from mem to shm. So when we need to
update shm we will increase sequence of mem of one process by doing
this sequence of mem is ahead of shm then call jk_lb_push to copy mem
including its sequence to shm.
Other process has mem's sequence behind shm's sequence thus will call
jk_lb_pull to copy data from shm to its heap.
Finally all processes will have sequence of their mem same as shm.
On Mon, Mar 26, 2012 at 12:49 PM, Mladen Turk <mt...@apache.org> wrote:
> On 03/25/2012 11:00 PM, Le Huy wrote:
>>
>> Hi
>>
>> I am facing problem in using jkstatus to update subworker lb_factor,
>> it seems that after changing it, the mod_jk balancer does not change
>> anything
>>
>> Looking at source code in trunk, I think that there is bug , I
>> include herewith the 2 changes that I think will fix the problem,
>>
>
> It won't fix the problems.
> It'll cause IIS to crash on recycle.
>
> Think that the entire jkstatus needs to get reviewed
> cause the current code is unnecessary complex.
>
>>
>> for (i = 0; i< p->num_of_workers; i++) {
>> lb_sub_worker_t *w =&p->lb_workers[i];
>> - if (w->sequence< w->s->h.sequence) {
>> + if (w->sequence> w->s->h.sequence) {
>
>
> That's not correct.
> The shared memory needs to get incremented on change
> and heap memory updated when its sequence is behind
> the shared memory. It is illegal to have heap memory
> 'newer' then the content of shared memory.
>
>
>
> Regards
> --
> ^TM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
