james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: Proposal: new approach to spooling
Date Sat, 03 Jun 2006 18:59:52 GMT
Am Samstag, den 03.06.2006, 14:18 -0400 schrieb Noel J. Bergman:
> 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 if
>     the underlying queue manager uses JMS.  But the
>     approach should NOT be JSM/MQ specific.  It
>     should work just fine with JDBC-based queues.
Not can say much about this. Not have a closer look at JSM!

>   - 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.

This sounds nice. Anyway i don't line control Messages at all. I prever
to implement administrativ commands on RemoteManager.

>   - 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.
Not sure i understand this point..

>   - Each processor is associated with a queue manager
>     and, optionally, a retry schedule.
So im right that if a user made 5 costums processors he use a queue for
each of them ? Or only for the "core" processors ?

>   - 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.

This is what i did in the FLUSHSPOOL cmd in RemoteManager. Isnt it ?
>   - 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.

What the RETRY Mail state will do ? just reset the timestamp ? or reset
the retry count ?

>   - 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.
> There are all sorts of ways to express this in XML, one of which might be:
>   <processor name="<queue-name>"
>              [onException="..."]
>              [fallthrough="<message-state>" def: RETRY]
>              [class="<class>" def: LinearProcessor] >
>     <queue [queueManager="<class>"> def: DefaultQueueManager] >
>       <!-- queue configuration -->
>     </queue>
>     <schedule [class="<class>" def: DefaultScheduler]>
>       <!-- see RemoteDelivery -->
>     </schedule>
>     <mailet ...>
>   </processor>
> 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.

Nice idea..

> 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.  The processor is responsible for workflow
> within the transaction, and for bridging between the queue manager and the
> mailet API.
> For this reason, I would not define interfaces for the queue manager and
> processor, but rather define semantics and responsibilities.  The Mailet API
> is the inviolate API that all processors would be expected to support.  A
> processor would accept the queue entry from the queue manager, invoke the
> mailet pipeline, handle any exceptions, etc.  A queue manager would handle
> acquisition of appropriate entries from the queue queue, threading, calling
> the processor, etc.  I envision enhancements to the ToProcessor mailet, and
> related calls, and am still debating how queue aliases might be handled,
> which can be quite powerful.
> 	--- Noel


View raw message