Mailing List Archive

Understanding parallelism and queues
Hi,
this is my 1st time reaching out to the public community - so pls advise if
am doing something wrong.
My question is related to ruleset queues and parallelism. After reviewing
all the documentation on queues and reading them multiple times - the whole
idea behind the queue with a fixed or linked list was to introduce
asynchronous processing of actions within the ruleset which also helps with
handling costly filter logic.

In order to test the benefits of queues - i created a simple ruleset
without a queue 1st:
ruleset(name="test") {
action(type="omfile" file="/var/log/mtu3.log")
action(type="omfile" file="/var/log/mtu4.log")
}

As per the documentation - my expectation was - because i didn't define any
queues - the action would be processed synchronously - or - it will be
processed 1 after another. Meaning - all the syslog packets will be stored
in the main queue - which then will invoke the 1st action and once the 1st
action is complete - it will then invoke the 2nd action.

To my surprise - the data was written in parallel to both these files. And
now i am totally confused - if the data is being written in parallel - how
exactly is the cpu thread working:
is it writing to both files at once? If yes - then what really is the
benefit of a dedicated queue?
In the documentation - the biggest benefit seems to be avoiding a slow
output - and also helping provide parallel threads to do work while
increasing performance.

Yes - I understand that the slow output will eventually cause a backlog in
the main queue causing the entire rsyslog to hang - but is that the only
benefit of a queue? Performance doesnt really seem to be a benefit if the
main queue can already do things in parallel - till rsyslog eventually
hangs due to backlog.

Your team has done an awesome job helping out with an open source solution.
Pls keep it up.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Understanding parallelism and queues [ In reply to ]
Hello!

I'd say it should work as you expected.
First, a log message is written into the mtu3.log. Then it's written into
the mtu4.log. I don't think you should expect any visible timestamp
differences in your local logs as rsyslog and linux filesystems are pretty
quick.

It might be a bit easier to check with `omprog` or any other "slow" action.

Thank you!

On Wed, 7 Apr 2021 at 11:03, siddhartha dewan via rsyslog <
rsyslog@lists.adiscon.com> wrote:

> Hi,
> this is my 1st time reaching out to the public community - so pls advise if
> am doing something wrong.
> My question is related to ruleset queues and parallelism. After reviewing
> all the documentation on queues and reading them multiple times - the whole
> idea behind the queue with a fixed or linked list was to introduce
> asynchronous processing of actions within the ruleset which also helps with
> handling costly filter logic.
>
> In order to test the benefits of queues - i created a simple ruleset
> without a queue 1st:
> ruleset(name="test") {
> action(type="omfile" file="/var/log/mtu3.log")
> action(type="omfile" file="/var/log/mtu4.log")
> }
>
> As per the documentation - my expectation was - because i didn't define any
> queues - the action would be processed synchronously - or - it will be
> processed 1 after another. Meaning - all the syslog packets will be stored
> in the main queue - which then will invoke the 1st action and once the 1st
> action is complete - it will then invoke the 2nd action.
>
> To my surprise - the data was written in parallel to both these files. And
> now i am totally confused - if the data is being written in parallel - how
> exactly is the cpu thread working:
> is it writing to both files at once? If yes - then what really is the
> benefit of a dedicated queue?
> In the documentation - the biggest benefit seems to be avoiding a slow
> output - and also helping provide parallel threads to do work while
> increasing performance.
>
> Yes - I understand that the slow output will eventually cause a backlog in
> the main queue causing the entire rsyslog to hang - but is that the only
> benefit of a queue? Performance doesnt really seem to be a benefit if the
> main queue can already do things in parallel - till rsyslog eventually
> hangs due to backlog.
>
> Your team has done an awesome job helping out with an open source solution.
> Pls keep it up.
> _______________________________________________
> rsyslog mailing list
> https://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>


--
Yury Bushmelev
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Understanding parallelism and queues [ In reply to ]
Apart from that, you have to remember that file writes are buffered so
even with default 4KiB buffer you might have no "real" time difference
between the writes because they get written to the buffer first and then
get flushed more or less asynchronously.

And if you want to check synchronicity of processing you might try to
set up some rules using actions that can fail and then checking for
previous_action_suspended().

On 07.04.2021 08:45, Yuri Bushmelev via rsyslog wrote:
> Hello!
>
> I'd say it should work as you expected.
> First, a log message is written into the mtu3.log. Then it's written into
> the mtu4.log. I don't think you should expect any visible timestamp
> differences in your local logs as rsyslog and linux filesystems are pretty
> quick.
>
> It might be a bit easier to check with `omprog` or any other "slow" action.
>
> Thank you!
>
> On Wed, 7 Apr 2021 at 11:03, siddhartha dewan via rsyslog <
> rsyslog@lists.adiscon.com> wrote:
>
>> Hi,
>> this is my 1st time reaching out to the public community - so pls advise if
>> am doing something wrong.
>> My question is related to ruleset queues and parallelism. After reviewing
>> all the documentation on queues and reading them multiple times - the whole
>> idea behind the queue with a fixed or linked list was to introduce
>> asynchronous processing of actions within the ruleset which also helps with
>> handling costly filter logic.
>>
>> In order to test the benefits of queues - i created a simple ruleset
>> without a queue 1st:
>> ruleset(name="test") {
>> action(type="omfile" file="/var/log/mtu3.log")
>> action(type="omfile" file="/var/log/mtu4.log")
>> }
>>
>> As per the documentation - my expectation was - because i didn't define any
>> queues - the action would be processed synchronously - or - it will be
>> processed 1 after another. Meaning - all the syslog packets will be stored
>> in the main queue - which then will invoke the 1st action and once the 1st
>> action is complete - it will then invoke the 2nd action.
>>
>> To my surprise - the data was written in parallel to both these files. And
>> now i am totally confused - if the data is being written in parallel - how
>> exactly is the cpu thread working:
>> is it writing to both files at once? If yes - then what really is the
>> benefit of a dedicated queue?
>> In the documentation - the biggest benefit seems to be avoiding a slow
>> output - and also helping provide parallel threads to do work while
>> increasing performance.
>>
>> Yes - I understand that the slow output will eventually cause a backlog in
>> the main queue causing the entire rsyslog to hang - but is that the only
>> benefit of a queue? Performance doesnt really seem to be a benefit if the
>> main queue can already do things in parallel - till rsyslog eventually
>> hangs due to backlog.
>>
>> Your team has done an awesome job helping out with an open source solution.
>> Pls keep it up.
>> _______________________________________________
>> rsyslog mailing list
>> https://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com/professional-services/
>> What's up with rsyslog? Follow https://twitter.com/rgerhards
>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
>> DON'T LIKE THAT.
>>
>
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Understanding parallelism and queues [ In reply to ]
The actions are simply far too fast to see any difference. For that
case, a queue would just add overhead. It's not for actions that fast.

HTH
Rainer

El mié, 7 abr 2021 a las 5:02, siddhartha dewan via rsyslog
(<rsyslog@lists.adiscon.com>) escribió:
>
> Hi,
> this is my 1st time reaching out to the public community - so pls advise if
> am doing something wrong.
> My question is related to ruleset queues and parallelism. After reviewing
> all the documentation on queues and reading them multiple times - the whole
> idea behind the queue with a fixed or linked list was to introduce
> asynchronous processing of actions within the ruleset which also helps with
> handling costly filter logic.
>
> In order to test the benefits of queues - i created a simple ruleset
> without a queue 1st:
> ruleset(name="test") {
> action(type="omfile" file="/var/log/mtu3.log")
> action(type="omfile" file="/var/log/mtu4.log")
> }
>
> As per the documentation - my expectation was - because i didn't define any
> queues - the action would be processed synchronously - or - it will be
> processed 1 after another. Meaning - all the syslog packets will be stored
> in the main queue - which then will invoke the 1st action and once the 1st
> action is complete - it will then invoke the 2nd action.
>
> To my surprise - the data was written in parallel to both these files. And
> now i am totally confused - if the data is being written in parallel - how
> exactly is the cpu thread working:
> is it writing to both files at once? If yes - then what really is the
> benefit of a dedicated queue?
> In the documentation - the biggest benefit seems to be avoiding a slow
> output - and also helping provide parallel threads to do work while
> increasing performance.
>
> Yes - I understand that the slow output will eventually cause a backlog in
> the main queue causing the entire rsyslog to hang - but is that the only
> benefit of a queue? Performance doesnt really seem to be a benefit if the
> main queue can already do things in parallel - till rsyslog eventually
> hangs due to backlog.
>
> Your team has done an awesome job helping out with an open source solution.
> Pls keep it up.
> _______________________________________________
> rsyslog mailing list
> https://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Understanding parallelism and queues [ In reply to ]
Thank you for getting back. Makes sense. One more question related to this.
If we dont need logs in the order they were received, then what is
beneficial - multiple threads in ruleset queue vs multiple threads in
action queue. I read your blog but still have some doubts.
Assume we don’t need any filtering. And there are 2 omfwd actions sending
logs to tcp destinations within the ruleset.
In this scenario - should i create a ruleset queue with 4 threads(example)
or create the actions each with 2 threads(example).
Or is there a benefit to having both. Of course am assuming large mps like
500k.

Regards,
Sid

On Wed, Apr 7, 2021 at 12:51 AM Rainer Gerhards <rgerhards@hq.adiscon.com>
wrote:

> The actions are simply far too fast to see any difference. For that
> case, a queue would just add overhead. It's not for actions that fast.
>
> HTH
> Rainer
>
> El mié, 7 abr 2021 a las 5:02, siddhartha dewan via rsyslog
> (<rsyslog@lists.adiscon.com>) escribió:
> >
> > Hi,
> > this is my 1st time reaching out to the public community - so pls advise
> if
> > am doing something wrong.
> > My question is related to ruleset queues and parallelism. After reviewing
> > all the documentation on queues and reading them multiple times - the
> whole
> > idea behind the queue with a fixed or linked list was to introduce
> > asynchronous processing of actions within the ruleset which also helps
> with
> > handling costly filter logic.
> >
> > In order to test the benefits of queues - i created a simple ruleset
> > without a queue 1st:
> > ruleset(name="test") {
> > action(type="omfile" file="/var/log/mtu3.log")
> > action(type="omfile" file="/var/log/mtu4.log")
> > }
> >
> > As per the documentation - my expectation was - because i didn't define
> any
> > queues - the action would be processed synchronously - or - it will be
> > processed 1 after another. Meaning - all the syslog packets will be
> stored
> > in the main queue - which then will invoke the 1st action and once the
> 1st
> > action is complete - it will then invoke the 2nd action.
> >
> > To my surprise - the data was written in parallel to both these files.
> And
> > now i am totally confused - if the data is being written in parallel -
> how
> > exactly is the cpu thread working:
> > is it writing to both files at once? If yes - then what really is the
> > benefit of a dedicated queue?
> > In the documentation - the biggest benefit seems to be avoiding a slow
> > output - and also helping provide parallel threads to do work while
> > increasing performance.
> >
> > Yes - I understand that the slow output will eventually cause a backlog
> in
> > the main queue causing the entire rsyslog to hang - but is that the only
> > benefit of a queue? Performance doesnt really seem to be a benefit if the
> > main queue can already do things in parallel - till rsyslog eventually
> > hangs due to backlog.
> >
> > Your team has done an awesome job helping out with an open source
> solution.
> > Pls keep it up.
> > _______________________________________________
> > rsyslog mailing list
> > https://lists.adiscon.net/mailman/listinfo/rsyslog
> > http://www.rsyslog.com/professional-services/
> > What's up with rsyslog? Follow https://twitter.com/rgerhards
> > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Understanding parallelism and queues [ In reply to ]
with omfwd you need queues only when the file system is remote and
either unreliable or slow. Multiple threads never make sense with
omfwd - we have sequential writes, and so omfwd serializes them in
order to avoid incomplete lines (which could happen by multiple
non-serialized writes).

in short: do not use queues with omfwd

HTH
Rainer

El mié, 7 abr 2021 a las 10:44, siddhartha dewan
(<dewansiddhartha@gmail.com>) escribió:
>
> Thank you for getting back. Makes sense. One more question related to this. If we dont need logs in the order they were received, then what is beneficial - multiple threads in ruleset queue vs multiple threads in action queue. I read your blog but still have some doubts.
> Assume we don’t need any filtering. And there are 2 omfwd actions sending logs to tcp destinations within the ruleset.
> In this scenario - should i create a ruleset queue with 4 threads(example) or create the actions each with 2 threads(example).
> Or is there a benefit to having both. Of course am assuming large mps like 500k.
>
> Regards,
> Sid
>
> On Wed, Apr 7, 2021 at 12:51 AM Rainer Gerhards <rgerhards@hq.adiscon.com> wrote:
>>
>> The actions are simply far too fast to see any difference. For that
>> case, a queue would just add overhead. It's not for actions that fast.
>>
>> HTH
>> Rainer
>>
>> El mié, 7 abr 2021 a las 5:02, siddhartha dewan via rsyslog
>> (<rsyslog@lists.adiscon.com>) escribió:
>> >
>> > Hi,
>> > this is my 1st time reaching out to the public community - so pls advise if
>> > am doing something wrong.
>> > My question is related to ruleset queues and parallelism. After reviewing
>> > all the documentation on queues and reading them multiple times - the whole
>> > idea behind the queue with a fixed or linked list was to introduce
>> > asynchronous processing of actions within the ruleset which also helps with
>> > handling costly filter logic.
>> >
>> > In order to test the benefits of queues - i created a simple ruleset
>> > without a queue 1st:
>> > ruleset(name="test") {
>> > action(type="omfile" file="/var/log/mtu3.log")
>> > action(type="omfile" file="/var/log/mtu4.log")
>> > }
>> >
>> > As per the documentation - my expectation was - because i didn't define any
>> > queues - the action would be processed synchronously - or - it will be
>> > processed 1 after another. Meaning - all the syslog packets will be stored
>> > in the main queue - which then will invoke the 1st action and once the 1st
>> > action is complete - it will then invoke the 2nd action.
>> >
>> > To my surprise - the data was written in parallel to both these files. And
>> > now i am totally confused - if the data is being written in parallel - how
>> > exactly is the cpu thread working:
>> > is it writing to both files at once? If yes - then what really is the
>> > benefit of a dedicated queue?
>> > In the documentation - the biggest benefit seems to be avoiding a slow
>> > output - and also helping provide parallel threads to do work while
>> > increasing performance.
>> >
>> > Yes - I understand that the slow output will eventually cause a backlog in
>> > the main queue causing the entire rsyslog to hang - but is that the only
>> > benefit of a queue? Performance doesnt really seem to be a benefit if the
>> > main queue can already do things in parallel - till rsyslog eventually
>> > hangs due to backlog.
>> >
>> > Your team has done an awesome job helping out with an open source solution.
>> > Pls keep it up.
>> > _______________________________________________
>> > rsyslog mailing list
>> > https://lists.adiscon.net/mailman/listinfo/rsyslog
>> > http://www.rsyslog.com/professional-services/
>> > What's up with rsyslog? Follow https://twitter.com/rgerhards
>> > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Understanding parallelism and queues [ In reply to ]
Got it and thank you. 1 strange thing - when i use a queue in a ruleset -
impstats shows name for the queue - but it never ever shows any message
count increment.
It always shows increments only in mainQ and "imtcp(514)"; for example - i
have named the queue of my ruleset "tcp_mainq" - i see the DA queue and the
linkedlist queue - but its values never change - is that expected? I would
expect the worker threads to pick up all the messages;
Here is an example:
2021-04-11T20:13:18.082666-07:00 sidlogtest001 rsyslogd-pstats: { "name": "
*imtcp(514)*", "origin": "imtcp", "submitted": *1000000* }
2021-04-11T20:13:18.082675-07:00 sidlogtest001 rsyslogd-pstats: { "name":
"resource-usage", "origin": "impstats", "utime": 5525642, "stime": 2356213,
"maxrss": 7236, "minflt": 80055, "majflt": 0, "inblock": 0, "oublock":
1249592, "nvcsw": 21744, "nivcsw": 6 }
2021-04-11T20:13:18.082682-07:00 sidlogtest001 rsyslogd-pstats: { "name":
"impstats_001[DA]", "origin": "core.queue", "size": 0, "enqueued": 0,
"full": 0, "discarded.full": 0, "discarded.nf": 0, "maxqsize": 0 }
2021-04-11T20:13:18.082687-07:00 sidlogtest001 rsyslogd-pstats: { "name":
"impstats_001", "origin": "core.queue", "size": 9, "enqueued": 15, "full":
0, "discarded.full": 0, "discarded.nf": 0, "maxqsize": 15 }
2021-04-11T20:13:18.082692-07:00 sidlogtest001 rsyslogd-pstats: { "name":
"tcp_mainq[DA]", "origin": "core.queue", "size": 0, "enqueued": 0, "full":
0, "discarded.full": 0, "discarded.nf": 0, "maxqsize": 0 }
2021-04-11T20:13:18.082697-07:00 sidlogtest001 rsyslogd-pstats: {
"name": *"tcp_mainq",
"origin": "core.queue", "size": 0, "enqueued": 0, "full": 0,
"discarded.full": 0, "discarded.nf <http://discarded.nf>": 0, "maxqsize": 0*
}
2021-04-11T20:13:18.082702-07:00 sidlogtest001 rsyslogd-pstats: {
"name": "*main
Q*", "origin": "core.queue", "size": 0, *"enqueued": 1000000*, "full": 0,
"discarded.full": 0, "discarded.nf": 0, "maxqsize": 1348 }
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
Re: Understanding parallelism and queues [ In reply to ]
Please ignore my request above - i found the problem with my configuration.
My mistake.

On Sun, Apr 11, 2021 at 8:18 PM siddhartha dewan <dewansiddhartha@gmail.com>
wrote:

> Got it and thank you. 1 strange thing - when i use a queue in a ruleset -
> impstats shows name for the queue - but it never ever shows any message
> count increment.
> It always shows increments only in mainQ and "imtcp(514)"; for example -
> i have named the queue of my ruleset "tcp_mainq" - i see the DA queue and
> the linkedlist queue - but its values never change - is that expected? I
> would expect the worker threads to pick up all the messages;
> Here is an example:
> 2021-04-11T20:13:18.082666-07:00 sidlogtest001 rsyslogd-pstats: { "name": "
> *imtcp(514)*", "origin": "imtcp", "submitted": *1000000* }
> 2021-04-11T20:13:18.082675-07:00 sidlogtest001 rsyslogd-pstats: { "name":
> "resource-usage", "origin": "impstats", "utime": 5525642, "stime": 2356213,
> "maxrss": 7236, "minflt": 80055, "majflt": 0, "inblock": 0, "oublock":
> 1249592, "nvcsw": 21744, "nivcsw": 6 }
> 2021-04-11T20:13:18.082682-07:00 sidlogtest001 rsyslogd-pstats: { "name":
> "impstats_001[DA]", "origin": "core.queue", "size": 0, "enqueued": 0,
> "full": 0, "discarded.full": 0, "discarded.nf": 0, "maxqsize": 0 }
> 2021-04-11T20:13:18.082687-07:00 sidlogtest001 rsyslogd-pstats: { "name":
> "impstats_001", "origin": "core.queue", "size": 9, "enqueued": 15, "full":
> 0, "discarded.full": 0, "discarded.nf": 0, "maxqsize": 15 }
> 2021-04-11T20:13:18.082692-07:00 sidlogtest001 rsyslogd-pstats: { "name":
> "tcp_mainq[DA]", "origin": "core.queue", "size": 0, "enqueued": 0, "full":
> 0, "discarded.full": 0, "discarded.nf": 0, "maxqsize": 0 }
> 2021-04-11T20:13:18.082697-07:00 sidlogtest001 rsyslogd-pstats: { "name": *"tcp_mainq",
> "origin": "core.queue", "size": 0, "enqueued": 0, "full": 0,
> "discarded.full": 0, "discarded.nf <http://discarded.nf>": 0, "maxqsize": 0*
> }
> 2021-04-11T20:13:18.082702-07:00 sidlogtest001 rsyslogd-pstats: { "name": "*main
> Q*", "origin": "core.queue", "size": 0, *"enqueued": 1000000*, "full": 0,
> "discarded.full": 0, "discarded.nf": 0, "maxqsize": 1348 }
>
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.