I will start working on this today, and given all the input on potential
pitfalls (thanks) I will go for a close match to Noels mail below, if my itch
is to great I might go for the msec/sec/... thingy
--Søren
On Friday 03 October 2003 17:52, Noel J. Bergman wrote:
> > You could work around thi
Noel J. Bergman wrote:
> An reasonable approach, but wrong execution. Whenever you
> have multiple
> entries, the resulting value provided by the Mailet API
> is going to be
> a CSV (comma separated value) String whose order reflects the
> order of the
> elements. Therefore using a comma to del
> You could work around this by optionally comma delimiting an attempts
> value in the tag...
An reasonable approach, but wrong execution. Whenever you have multiple
entries, the resulting value provided by the Mailet API is going to be
a CSV (comma separated value) String whose order reflects
Soeren Hilmer wrote:
I do not really know how this process works, who has the final word on which
of the proposed ways to do this, we go for?
The person who does the work gets by far the most say. The community
can suggest designs and may in special cases veto it.
I like Serge's "attempts" vers
Regarding the timing of subsequent tries to overcome network failures,
I have seen the phrase "exponential backoff strategy" used. I thought
I had seen that in RFC 2821. But if it were there I expect Noel would
have reported it.
As I understand it, the delays in an exponential backoff strateg
Soeren Hilmer wrote:
> I like Serge's "attempts" version best,
But as Noel noted in his reponse to Serge, the Mailet API does not support
it. You could work around this by optionally comma delimiting an attempts
value in the tag...
msecs [, attempts]
60
60, 3
> but in this case ar
t to redeliver?
>
> -Original Message-
> From: Soeren Hilmer [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 03, 2003 3:40 AM
> To: James Developers List
> Subject: Re: RemoteDelivery progressively increasing delay-time
>
>
> Hi,
>
> I do not really know how this proc
Noel J. Bergman wrote:
>
> This is not exposed to Mailet API components. We only get
> [name,value]. As
> noted in RemoteDelivery.init(), the resulting value is an
> ordered CSV (which
> answers a question Steve just asked).
As noted in org.apache.james.transport.mailets.RemoteDelivery.init()? I
40 AM
To: James Developers List
Subject: Re: RemoteDelivery progressively increasing delay-time
Hi,
I do not really know how this process works, who has the final word on which
of the proposed ways to do this, we go for?
I like Serge's "attempts" version best, but in this case
Hi,
I do not really know how this process works, who has the final word on which
of the proposed ways to do this, we go for?
I like Serge's "attempts" version best, but in this case are maxRetries then
to be disregarded? Or is it to be used on the last delaytime entry, if the
attempts attribu
> I like this, but would suggest an attribute named "attempts" to each
> element. For example, 600 would
> try 3 times at 600ms delays before moving to the next delayTime element.
This is not exposed to Mailet API components. We only get [name,value]. As
noted in RemoteDelivery.init(), the re
Soeren Hilmer wrote:
I have been thinking about extending RemoteDelivery to take a list of
delaytimes.
Something like:
600
160
2160
2160
I like this, but would suggest an attribute named "attempts" to each
element. For example, 600 would
try 3 times at 600ms delays before
> Still, I would retain tag and use the last of the
> tags as the time to use where maxRetrys > number
> of delayTime tags.
Agreed, as I noted in my response to Soren.
> As I am unsure that same named tags are returned in the sequence they
> are entered, I might enforce successively longer dela
Noel J. Bergman wrote:
>
> > Personally, if the change was to be made, I would prefer
> something like...
>
> I understand why, but it would require a change to the data
> model we expose
> via the Mailet API. The current API supports neither child
> elements nor
> attributes. The proposed change
> Personally, if the change was to be made, I would prefer something like...
I understand why, but it would require a change to the data model we expose
via the Mailet API. The current API supports neither child elements nor
attributes. The proposed change is compatible with the current data mod
Søren,
It has been discussed before, but no one ever implemented it. RFC 2821
section 4.5.4.1 discusses a similar strategy:
Experience suggests that failures are typically transient (the target
system or its connection has crashed), favoring a policy of two
connection attempts in the fi
Soeren Hilmer wrote:
>
> I have been thinking about extending RemoteDelivery to take a list of
> delaytimes.
Seems like a fair idea.
> Something like:
> 600
> 160
> 2160
> 2160
Personally, if the change was to be made, I would prefer something like...
600
Hi,
I have been thinking about extending RemoteDelivery to take a list of
delaytimes.
Something like:
600
160
2160
2160
The purpose being that I have often observed that when a server does not reply
it often replys just after (probably due to some timeout on the first
requ
18 matches
Mail list logo
