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 12:55:30 GMT
Ahh, now I fully understand Noels comments. 

I started doing accept(Filter) in JDBCSpoolRepository and we do not have 
complete MaiImpl's in there and even the misused errormessage is not in 
PendingMessage. But as it is in the underlying db I will just change the sql 
query and PendingMessage.

I am beginning to understand why this hasn't been done before.

--Søren


On Thursday 23 October 2003 08:42, Søren Hilmer wrote:
> 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.
>
> --Søren
>
> 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


Mime
View raw message