[Mailman-Users] Messages got stuck in "in" queue due to one"bad"message

[Xueshan Feng]

Quoting Mark Sapiro <msapiro at value.net>:

> Xueshan Feng wrote:
> 
> >Quoting Mark Sapiro <msapiro at value.net>:
> >
> >>> All four of them?
> >
> >Only 3:
> >
> >mailman:/var/lib/mailman/qfiles# ps -ef | grep Inco
> >list     21394 21383  0 18:45 ?        00:00:17 /usr/bin/python
> >/var/lib/mailman/bin/qrunner --runner=IncomingRunner:0:4 -s
> >list     21395 21383  0 18:45 ?        00:00:13 /usr/bin/python
> >/var/lib/mailman/bin/qrunner --runner=IncomingRunner:1:4 -s
> >list     21396 21383  0 18:45 ?        00:00:15 /usr/bin/python
> >/var/lib/mailman/bin/qrunner --runner=IncomingRunner:2:4 -s
> >
> >A these 3 remaining ones would not do the work?
> 
> 
> You are processing the 'in' queue in 4 slices with 4 IncomingRunner
> instances.
> 
> You do this by redefining or modifying the QRUNNERS list in mm_cfg.py.
> The entry in the list for IncomingRunner is
> 
>     ('IncomingRunner', 4),

That's exactly I have in our mm_cfg.py.
> 
> meaning that there will be four IncomingRunner instances processing
> slices 0:4, 1:4, 2:4 and 3:4 (the 3:4 runner is missing above).

> 
> Slicing works by dividing the queue entry hash space into slices (2^n
> in general, 4 in this case. Each slice has its own runner. A portion
> of each queue entry's name (the part between '+' and '.pck') is a 20
> byte hash of a pickle of the message + the list name + the time of
> enqueueing expressed as 40 hex digits. In this case, the first quarter
> of the hash space is processed by the 0:4 runner, the second quarter
> by the 1:4 runner, etc. If one of the four runners isn't running, its
> portion of the hash space will not be processed.

Wow, that's interesting. I was wondering how the long file name was
generated in the queue. For effective monitoring, I should check total
qrunner instances to match up what's configured in mm_cfg.

Thanks for the explanation!

Xueshan