james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <danny.an...@gmail.com>
Subject Re: Proposal: new approach to spooling
Date Wed, 14 Jun 2006 09:25:57 GMT
On 03/06/06, Noel J. Bergman <noel@devtech.com> wrote:
> Concepts:
>
>   - Each processor is a named queue entry.  This is
>     not a change from today, except that these may
>     be real queues in the JMS sense of the word

JMS +1

>
>   - A queue entry would normally contain a JAMES Mail
>     object.  JavaMail Message objects would be
>     contained, or more likely referenced, by a JAMES
>     Mail object.  I say "normally" just in case we
>     want to permit other message types, e.g., JAMES
>     control messages, to be posted, since JAMES
>     processors effectively become services.

Not refrenced, where is the referenced object going to live?
The JMS queue may have been populated by another system at another location.
In the JMS vision we can imagine a partial James running SMTP-inbound
and publishing to a queue,
that queue is then subscribed by another queue on another system the
partial James running on the other system will be dequeueing and
processing.
Outbound messages can be routed to other queues on yet more systems,
even just for regular old mail routing I can envisage an outbound
queue and a local delivery queue.

(see drawings for examples)

>   - Each processor is a transaction.  What this means
>     is that we can try to wrap a global transaction
>     around behavior within the processor.  This will
>     have some impact on Mailets, too.

I think we have to think a bit harder about transaction boundaries.


>   - Each processor is associated with a queue manager
>     and, optionally, a retry schedule.

I think there should be one queue with multiple topics.

>   - I believe that a queue implementation independent
>     scheduler that provides the next time at which a
>     message should be processed may be sufficient.
>     Each queue entry would carry a timestamp before
>     which it should not be processed.  "Restarting"
>     the queue would be as simple as changing that
>     timestamp entry.

Queue implementations should include this kind of detail.
Remember that we want to use queues, not invent them.

>   - A new RETRY Mail state can be set to rollback the
>     transaction and put the Mail back into the queue.
>     We should decide on commit and rollback semantics.

Use exceptions and jdbc transactions, if a mailet throws a recoverable
exception the dequeue is rolledback, if it throws an unrecoverable
exception the message is dequeued into the error queue.

>   - The processor acquires a new attribute that explicitly
>     sets the fall-through state.  The default shall be the
>     new RETRY state, except for messages that exhause the
>     retry schedule.

Me no like, no retry, and certainly not default. If a message can't be
processed an exception should rollback the dequeue (see above)

> There are all sorts of ways to express this in XML

Yes aren't there, remember that you will also need to allow the vendor
specific configuration of the JMS implementation, and message
selection,
multiple or single subscribers, and in-order or not-in-order delivery.

> Despite that this defines the queue manager as a child of the processor, we
> would invert that in code, with the queue manager calling the processor.  I
> believe that thread management is defined squarely on the queue manager.

It has to be that way, examine message driven beans for an example of
how to use JMS.
Imagine james deployed as MDB's

> The concept still needs fleshing out, but I wanted to air the thoughts.
> This gives a lot of flexibility in implementation.  For example, one might
> implement a processor as an MDB.

Exactly. and all the config you'd need would be the queue and or topic.

> The processor is responsible for workflow
> within the transaction, and for bridging between the queue manager and the
> mailet API.


d.


Mime
View raw message