> My idea was to always do an outgoing.accept(0) and set the Mails
lastUpdated
> to currentTimeMillis+the next delay for that mail-
> MailImpl.writeObject always does a lastUpdated=new Date() prior to
> the actual storing of the object, which effectly prevents me from
> dating the mail into the future.
> What is the rationale behind this?
lastUpdated is also a useful diagnostic that I would not want to lose.
In terms of the spooler, lastUpdated is the past, not the future. The calls
is a bit odd in that for spool.accept(time), the parameter means that you
want only objects that had been in the spool for at least that long.
Consider, too, that this feature works only if STATE is "ERROR". It only
works in a dedicated spool like the one for RemoteDelivery, and it prevents
us from doing scheduling elsewhere in the pipeline.
There is a benefit to handling the time in the spooler because we don't have
to load the message until we know that we have a suitable one. We could
figure out a message's next try time by using lastUpdated *and* the retry
count, if we knew the retry schedule.
Mind you, I'd also like to see Spool.accept() return the message, not the
key. There are exactly two calls to Spool.accept()/accept(long) in James.
In both cases, we immediately follow up by retrieving the message, but we
have a much more complex synchronization process because of the two stage
access method.
> Does it actually make sense to have a setLastUpdated method, when the
effect
> of it is changed behind your back?
Within the standard pipeline, changes made to the message won't be put into
the spool unless the STATE has changed, so within a processor, only
setLastUpdated would be visible. Not that anyone seems to use it that way.
And it isn't well-documented that saving the message has that side-effect.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
