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
mail/mails.
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:
<spoolmanager>
<queue binding="...">
... scheduling options... (each queue could support different
scheduling schemes)
</queue>
<processor>
</processor>
</spoolmanager>
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.
Stefano
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
