james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Serge Knystautas" <sknystau...@gmail.com>
Subject Re: Proposal: new approach to spooling
Date Tue, 13 Jun 2006 15:02:20 GMT
On 6/12/06, Noel J. Bergman <noel@devtech.com> wrote:
> This is a bit primative, albeit not dissimilar from MQSeries.  We can
> improve upon it, e.g., by looking up queue managers -- implementation and
> all -- from JNDI as shown, but I am trying to not assume that every
> implementation will have JNDI or JMS or JDBC pervasive throughout the
> system.

I would think it would be good to learn the patterns used by JMS
implementations, like MQSeries and emulate those (not that JMS is a
particularly well designed spec, but..).

To me this plan largely sounds like we are effectively a queuing
server.  Whether that's the goal or not, I just mean to point out that
there are very robust implementations that do this, and we could learn
from them as examples.

> And, yes, the queue manager would continue to be responsible for calling the
> processor to handle each message.  Each queue manager would be registered
> with the MailetContext, which would be provided to the processor in order to
> allow it to put messages set to a new processor (if we keep the currently
> Mailet API).  We might provide a suitable error or exception on the
> Mail.setState call if we try to address a queue (processor) that does not
> exist.

If I had to do any one thing about the mailet API over, it would be
Mail.setState.  I think it's very counterintuitive and just doesn't
make sense.  What it is simulating...

a) letting the mailet indicate that it has consumed the message.
b) injecting this mailet into another spool

We then do mailconfig.sendMail to simulate b) in another areas.  It's
just really messy... the constants make no sense and nevermind the
terrible name "Ghost" to say a message is consumed.

Anyway, so rather than checking on mail.setState, provide a way the
message into another spool and fail there, deprecating mail.setState
a.s.a.p.

-- 
Serge Knystautas
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


Mime
View raw message