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 20:45:35 GMT
Am Samstag, den 03.06.2006, 16:32 -0400 schrieb Noel J. Bergman:
> 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.
if you see it so.. you are right. Maybe this make it a bit flexibler ;-)

> 
> > >   - 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
> processor.
> 
Now i understand. 
> > >   - 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.
ok.
> 
> > >   - 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

Yeah i see. Hopefully we find a good and flexible solution for this. 

bye
Norman


Mime
View raw message