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 RE: Proposal: new approach to spooling
Date Sat, 03 Jun 2006 20:32:15 GMT
Norman Maurer wrote:

> Noel J. Bergman:

> >   - Each processor is a named queue entry.
> Not can say much about this. Not have a closer look at [JMS]

The first line is the key idea.  The fact that it *might* be a JMS queue
should not really be a change, and we should support other implementations.
I believe that a JDBC implementation may be more performant in a LAN
environment than JMS or MQ.

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

> i don't line control Messages at all. I prever to implement
> administrativ commands on RemoteManager.

Which might, in turn, send control messages.  :-)  We can expose control
behavior as services.  WebSphere, for example, uses JMX, but there is an
exposed service that arbitrates between clients and JMX beans.

> >   - Each processor is a transaction.
> Not sure i understand this point.

Which part?  By declaring that message processing happens within a
transaction, we are saying that either the entire processor is executed
satisfactorily, or nothing happens.  If one mailet causes a failure, or if
the system crashes while a message is in the middle of the processor, the
entire transaction can be rolled-back.  The original message is returned to
the queue, and can be gotten again for processing, and other changes are not
committed, e.g., new messages are not generated, etc.

Believe it or not, this is supposed to be the semantic now, but we have no
real control over it, since we lack transactions.  There can be weird
side-effects if JAMES crashes when a message is in the middle of a

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

Yes, each processor would have a queue.  The queue might be virtual, e.g.,
it could be a selector against an underlying queue or a key in a table.  The
key is that we post to it by name, just as we do now.  Hence my comment that
we would likely need to enhance and change ToProcessor-related behavior.

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

I'm proposing a general and standard mechanism for all JAMES queues.

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

Actually, we might want to distinguish between (undesired) rollback and
(deliberate) reschedule.  The retry for exceptions could be different from
the reschedule for application level events, such as we have with
RemoteDelivery.  Perhaps RETRY should be supplimented with RESCHEDULE?  The
latter would change the timestamp to the next scheduled time for that
message; the former would just change the retry count --- and perhaps bump
the timestamp by a retry interval.  Similar, but not identical behavior,
because the schedule is different.

There are some interesting options that we could permit if we do it right.
For example, if an internal exception happens during RemoteDelivery a
message and we have multiple servers reading from the queue, the transaction
would be rolled back, another server could try it, rather than waiting for
the delivery schedule, and perhaps it has more available memory and
immediately succeeds.

As you can see, there is plenty of room for discussion to evaluate and
improve the idea.

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