Re: Filters with multiple copies of pine running

On Mon, 5 Feb 2007, Ross wrote:
> On Sun, 4 Feb 2007, Ryan Barrett wrote:
>> On Sun, 4 Feb 2007, Ross wrote:
>>> Please clarify "running two pines". Do you mean the program 
>>> Pine is loaded twice?  For two separate servers - two 
>>> separate account INBOXes?

>> matt's explanation made sense to me. what's more, i've seen 
>> the same behavior as him. in my case, it's two different 
>> machines running pine, with configs pointing to the same 
>> account and INBOX.

> As long as the INBOX contains the message, though it may be 
> marked as deleted or in any fashion, both copies of Pine will 
> read (& probably cache) the message. Any filter will then 
> process the message accordingly. So if both copies of Pine 
> process the message with the same designed filter, two copies 
> of the message will be processed accordingly, & the receiving 
> folder will end up with two copies of the same message.

To followup, I doubt the "recent" or "new" tags, or any others, 
get set as the filter is designed to move the message, not update 
status. Anotherwords save a copy to the destination folder, then 
expunge the message from the INBOX. It seems it would be a waste 
of time to set message status in INBOX for a split second, but a 
Pine programmer would know. So both Pine filter processes see a 
recent & new message in realtime. Only some kind of a delay in 
one of the dual Pine filter applications could offset the 
simultaneous function in this design. Yes, it is a race problem.

I suggest altering the filters, make one filter process for one 
criteria & the other filter process another criteria. For 
example: assign one filter to process any "Received from pattern" 
for "[1, [3, [5, [7, [9" IP's, & the other filter to process any 
"Received from pattern" for "[2, [4, [6, [8" IP's. In case of an 
imbalanced workload, shift one of the IP prefixes to the other 
filter.

If this is a high volume system, I would also suggest two 
different destination folders to avoid the bottleneck of 
file/record sharing & locking there.

--
RossARR
[email protected]
mrossarr.nixsyspaus.org/
nixsyspaus.org=208.64.38.250
---end-of-message---
_______________________________________________
Pine-info mailing list
[email protected]
http://mailman1.u.washington.edu/mailman/listinfo/pine-info