james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: Proposal: new approach to spooling
Date Tue, 06 Jun 2006 20:59:42 GMT
Noel J. Bergman 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 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.

We should define an interface that meets our requirements for dispatching
work, most likely a subset of the JMS APIs. Implementations of which may use
any SOA style service, be it JMS, WebServices, whatever.

One thing we can't be assured off is that the service can always consume the
work, so we have to have a clear contract for this. Probably no more than a
set of specialized Exceptions?

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

So the queue entry would be a kind of James Queue object. The queuing system
will neither know or care if its a concrete object or a proxy. In a closed
system where access to the proxied objects is assured, proxies are often the
most performant as it avoids pumping heavy weight objects around the system.
In an open system we don't have this luxury. The API shoould cater for both
>   - 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'ld suggest using javax transactions. If we were to expose the processors
to an MDB as suggested below this is the game we would have to play, and why
reinvent the wheel?

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

Lost me here. I'm not sure why we can't define interfaces for the things
that we talk to and why we wouldn't want to. Perhaps you can elaborate?


-- Steve

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

View raw message