Mailet vs Procmail on James Wiki

[Nitin Borwankar <ni...@borwankar.com>]

Hi all,

I was reading the Mailet vs Procmail page on the James Wiki
http://wiki.apache.org/james/MailetVsProcmail

and had the following question :-

When using procmail if you have to do anything other than header match + 
file/forward then you pipe to a custom script.
This spawns a copy of the script interpreter ( perl, python, ... ) per 
message.  So if you need to do anything useful it is
quite expensive.  But using Mailets each message is handled by a thread 
and so even if JavaMail is expensive it is probably less expensive than 
spawning an interpreter per message.  Is that correct or am I missing 
something ?

Nitin Borwankar
http://tagschema.com



---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: Mailet vs Procmail on James Wiki

[Nitin Borwankar <ni...@borwankar.com>]

Stefano Bagnara wrote:

> Nitin Borwankar wrote:
>
>> Hi all,
>>
>> I was reading the Mailet vs Procmail page on the James Wiki
>> http://wiki.apache.org/james/MailetVsProcmail
>>
>> and had the following question :-
>>
>> When using procmail if you have to do anything other than header 
>> match + file/forward then you pipe to a custom script.
>> This spawns a copy of the script interpreter ( perl, python, ... ) 
>> per message.  So if you need to do anything useful it is
>> quite expensive.  But using Mailets each message is handled by a 
>> thread and so even if JavaMail is expensive it is probably less 
>> expensive than spawning an interpreter per message.  Is that correct 
>> or am I missing something ?
>
>
> Yes, I believe this is an important difference in the approaches: and 
> this is why, in the procmail world, most "heavy weight" processing 
> (antivirus/antispam filters) nowadays have been moved to listening 
> daemons and the procmail filter simply connect to the service to 
> obtain the processing.


OK, thanks very much for that clarification ... however even if to 
"simply connect" we would have to spawn an interpreter if the connector 
was written in a scripting language.  So,  not only does the real work 
have to be done in a long running process, but also the connector code 
has to be written in C/C++ and compiled so no interpreter is spawned.

Aside from this issue I have a question about JavaMail - the wiki 
mentions that JavaMail is memory-intensive - does anyone have any rough 
numbers on the minimum memory footprint of JavaMail per Mailet thread ?

Thanks again for the help.

Nitin Borwankar,
http://tagschema.com

>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: Mailet vs Procmail on James Wiki

[Stefano Bagnara <ap...@bago.org>]

Nitin Borwankar wrote:
> Hi all,
> 
> I was reading the Mailet vs Procmail page on the James Wiki
> http://wiki.apache.org/james/MailetVsProcmail
> 
> and had the following question :-
> 
> When using procmail if you have to do anything other than header match + 
> file/forward then you pipe to a custom script.
> This spawns a copy of the script interpreter ( perl, python, ... ) per 
> message.  So if you need to do anything useful it is
> quite expensive.  But using Mailets each message is handled by a thread 
> and so even if JavaMail is expensive it is probably less expensive than 
> spawning an interpreter per message.  Is that correct or am I missing 
> something ?

Yes, I believe this is an important difference in the approaches: and 
this is why, in the procmail world, most "heavy weight" processing 
(antivirus/antispam filters) nowadays have been moved to listening 
daemons and the procmail filter simply connect to the service to obtain 
the processing.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org