james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject Proposal: new approach to spooling
Date Sat, 03 Jun 2006 18:18:56 GMT

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

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

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

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

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

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

  - 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>"
             [fallthrough="<message-state>" def: RETRY]
             [class="<class>" def: LinearProcessor] >

    <queue [queueManager="<class>"> def: DefaultQueueManager] >
      <!-- queue configuration -->

    <schedule [class="<class>" def: DefaultScheduler]>
      <!-- see RemoteDelivery -->

    <mailet ...>


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.

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

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message