james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Proposal: new approach to spooling
Date Wed, 14 Jun 2006 08:45:44 GMT
You remember right: currently I'm using multiple spoolmanagers and I 
also use a remoteSpoolManager instead of the RemoteDelivery "worker 
thread hack" (http://issues.apache.org/jira/browse/JAMES-520)
I have 4 queue (SpoolRepositories) and 4 spoolmanagers.

Imho a processor should not be aware that there is a mail queue 
associated to it, but only process a given input mail and return output 

That's why I don't understand the advantages of binding the queue inside 
the processor and not viceversa.

I think that it should be:
   <queue binding="...">
     ... scheduling options... (each queue could support different 
scheduling schemes)

Btw I don't think that the queue<->processor relation is much important 
now: as I always say it is much better to work on something and the 
right path will be much more clear when you see the code you have to change.


Noel J. Bergman wrote:
> I am a bit surprised that this is an area that Stefano asked about, because
> one of the earliest messages from him that I recall was about wanting
> multiple spoolers because he wanted finer grained control over threads
> available to specific processors.  Perhaps he is wondering why I didn't
> express things as:
>   <spoolmanager>
>     <processor>
>       ...
>     </processor>
>   </spoolmanager>
> For one thing, the processor is more the mental focus for an administrator.
> But in addition, the spoolmanager, at this level of discourse, would not
> have multiple queues (and thus not multiple processors), unless we did
> something like:
>   <spoolmanager>
>     <processor name="myprocessor">
>       <queue binding="..."/>
>       ...
>     </processor>
>     <processor name="anotherprocessor">
>       <queue binding="..."/>
>       ...
>     </processor>
>   </spoolmanager>
> Which gets us back to what I expressed.  Recalling that processors are the
> named targets, and therefore are what is logically attached to a queue, and
> that the queue manager is the entity bridging the processor and the queue,
> it seems to make the most sense to describe it as I have in the proposal.
> But that's why we post these things for discussion.
> And, yes, the queue manager would continue to be responsible for calling the
> processor to handle each message.  Each queue manager would be registered
> with the MailetContext, which would be provided to the processor in order to
> allow it to put messages set to a new processor (if we keep the currently
> Mailet API).  We might provide a suitable error or exception on the
> Mail.setState call if we try to address a queue (processor) that does not
> exist.

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

View raw message