james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Søren Hilmer ...@itplus.dk>
Subject Re: Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Date Thu, 23 Oct 2003 06:42:28 GMT
I can see, why you wish to keep lastUpdated as the time the mail was actually 
put in the spool for diagnostic purposes.

I was hoping to keep the changes local to RemoteDelivery, but this boils down 
to that not being possible.

So I will start working on Spool.Filter and Spool.TimeFilter. and 
accept (Filter);

But let be just be sure this is what you mean:

Spool.accept(TimeFilter) will consult the supplied TimeFilter with the mail as 
input, which in turn uses the lastUpdated time of the Mail and its current 
retrycount (which exists in the errormessage), and based on these it 
determines if the Mail is ready for retry.

This is quite elegant IMO as the concrete TimeFilter implementation can reside 
in RemoteDelivery, so the "misuse" of the errormessage for the retrycount is 
localized in RemoteDelivery. And it requires minimal changes to Spool.


On Thursday 23 October 2003 00:19, Noel J. Bergman wrote:
> > > 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.
> >
> > Agreed.
> >
> > But to address the fundamental challenge, I would say this is a good use
> > of mail attributes.  Sounds like we would need to provide a query
> > interface on the repository for this, but really you want to set a date
> > on the mail that is not last updated, but independent of any data we
> > store right now.
> I had thought of that, but it would mean that:
>   (a) scheduling would only work on systems with attributes enabled
>   (b) scheduling would require reading the attributes, too.
> We already have the lastUpdate time.  We can easily add the retry count to
> the same query, which we'll want, anyway.  From that, we can compute the
> delivery time.
> What we could do is establish something like:
>    Spool.accept(Filter filter)
> Spool.Filter would be an static inner interface of the Spool interface, so
> we tie the concepts.  If we have a Spool.TimeFilter interface, we could
> check for that interface, which just tells us that all we need are the time
> and retry count.  Then we can call it, perhaps TimeFilter.accept(long time,
> int retries) to see if the current pending message is suitable.  I dislike
> the lack of polymorphism, but the JDBC Spool uses a very lightweight object
> that isn't a full MailImpl.
> Anyhow, that's an idea.  Seems like something useful (and reusable) there
> if we tweak it.
> 	--- Noel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

Søren Hilmer, M.Sc.
R&D manager		Phone:	+45 70 27 64 00
TietoEnator IT+		Fax:	+45 70 27 64 40
Ved Lunden 12		Direct:	+45 87 46 64 57
DK-8230 Åbyhøj		Email:	soren.hilmer@tietoenator.com

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

View raw message