You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Søren Hilmer <sh...@itplus.dk> on 2003/10/22 21:13:42 UTC
Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Hi,
During my implementation the multiple delay times in RemoteDelivery, I have
run into a little problem.
My idea was to always do an outgoing.accept(0) and set the Mails lastUpdated
to currentTimeMillis+the next delay for that mail-
But alas in 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?
Does it actually make sense to have a setLastUpdated method, when the effect
of it is changed behind your back?
-Søren
--
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
Re: Rationale behind explicit setLastUpdated in MailImpl writeobject
sought.
Posted by Serge Knystautas <se...@lokitech.com>.
Søren Hilmer wrote:
> Does it actually make sense to have a setLastUpdated method, when the effect
> of it is changed behind your back?
I'm happy with removing Mail.setLastUpdated and just having
MailImpl.setLastUpdated. I think the behavior makes sense, but can see
how exposing the setter method could create confusion.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Posted by Søren Hilmer <sh...@itplus.dk>.
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
Re: Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Posted by Søren Hilmer <sh...@itplus.dk>.
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
RE: Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 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
Re: Rationale behind explicit setLastUpdated in MailImpl writeobject
sought.
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>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.
I don't think he's suggesting removing this... just preventing mailets
from modifying it.
> 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.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Rationale behind explicit setLastUpdated in MailImpl writeobject sought.
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org