james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: project-schema.xml
Date Thu, 08 Mar 2007 06:31:47 GMT
Steve Brewin schrieb:
> robert burrell donkin wrote:
>   
>> On 3/6/07, Stefano Bagnara <apache@bago.org> wrote:
>>     
>>> robert burrell donkin ha scritto:
>>>       
>>>> i'm a torque expert so here are a couple of questions
>>>>         
>> about the schema...
>>     
>>> That's cool ;-)
>>> Well, Joachim is the man for your answers, but I try with
>>>       
>> my knowledge
>>     
>>> about...
>>>
>>>       
>>>> 1. there don't seem to be any indexes. is this intentional? does
>>>> torque automatically add indexes?
>>>>         
>>> It is not intentional: it was the first easy step to make
>>>       
>> it working.
>>
>> i'll try some indexes locally and see if they make a
>> noticeable difference
>>
>>     
>>>> 2. the header is a VARCHAR length 1024. this seems a
>>>>         
>> little short to
>>     
>>>> me. is there a good reason for this choice?
>>>>         
>>> 1024 == A random number for the first tests
>>> The rationale is: IIRC the RFC does not require limits on the header
>>> size, so we are stuck to a arbitrary number that will not
>>>       
>> fit any message.
>>     
>>> Maybe 1024 will fit 99% of messages, but maybe 2-3K will
>>>       
>> work better:
>>
>> those figures accord with my experience
>>
>>     
>>> messages with 1MB headers will need a special handling anyway
>>>       
>> true
>>
>> ATM a message with a header that is too big is simply rejected. even
>> if only 1% are effected then perhaps we shouldn't be just rejecting
>> these mail since they are RFC compliant. any ideas about better ways
>> to handle this case?
>>
>> - robert
>>     
>
> Why not use the maximum VARCHAR size supported by the underlying DBMS as an
> overridable default limit? When the limit is exceeded I cannot see a better
> alternative than rejecting the message with "452 Requested action not taken:
> insufficient system storage". The "bounce" seems perfectly reasonable
> behaviour as every system ultimately has hard limits.
>
> We do need to validate that we can withstand a flood of such huge headers.
>
> Cheers
>
> -- Steve
>   

Good points. Sounds like an easy and good solution :-)

bye
Norman

-- 
Mit freundlichen Grüßen 

i.A. Norman Maurer 
Systemadministrator

ByteAction GmbH
Auf der Beune 83-85
64839 Münster

Phone:   +49 (0) 60 71 92 16 - 21
Fax:       +49 (0) 60 71 92 16 - 20
E-mail:    nm@byteaction.de
Internet: www.byteaction.de
AG Darmstadt, HRB 33271
Ust-Id: DE206997247
GF: Thomas Volkert
------------------------------------------------------ 
Diese E-Mail enthält vertrauliche Informationen und ist nur für den in der E-Mail genannten
Adressaten bestimmt. Für den Fall, dass der Empfänger dieser E-Mail nicht der in der E-Mail
benannte Adressat ist, weisen wir darauf hin, dass das Lesen, Kopieren, die Wiedergabe, Verbreitung,
Vervielfältigung, Bekanntmachung, Veränderung, Verteilung und/oder Veröffentlichung der
E-Mail strengstens untersagt ist. Bitte verständigen Sie den Absender dieser E-Mail unter
folgender Rufnummer +49 (0) 6071 / 9216-0, falls Sie irrtümlich diese E-Mail erhalten haben
und löschen Sie diese E-Mail. Der Inhalt dieser E-Mail ist nur rechtsverbindlich, wenn er
von unserer Seite schriftlich durch Brief oder Telefax bestätigt wird. Die Versendung von
E-Mails an uns hat keine fristwahrende Wirkung. 

This e-mail contains information which is privileged and is intended only for the Addressee
named in the e-mail. In case that the recipient of this e-mail is not the named addressee,
we would like to inform you that it is strictly prohibited to read, to reproduce, to disseminate,
to copy, to disclose, to modify, to distribute and/or to publish this e-mail. If you have
received this e-mail in error, please call the sender under following telephone number +49
(0) 6071 / 9216-0 and delete this e-mail. The content of this e-mail is not legally binding
unless confirmed by letter or telefax. E-mails which are sent to us do not constitute compliance
with any time limits or deadlines.
------------------------------------------------------ 



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


Mime
View raw message