robert burrell donkin wrote:
On 1/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
<snip>
>> About the command pattern applied to our services we are already
working
>> on a common infrastructure to reuse part of our network layer between
>> services and prepare for asynchronous handling: you can look at the
>> smtphandler in james 2.3 for the first implementation, you can look at
>> the handlerapi-experiment for a more advanced solution we're
working on
>> as an experiment.
>
> the best plan would be to use SEDA
>
> this requires use of messaging APIs
The architecture now in handlerapi-experiment supports SEDA
(specifically it has been wrote with MINA in mind).
And there is a command pattern.
what approach are you using to the scheduling architecture?
There is no scheduling but java synchronization and programmatic Locks
on MailRepository access in main James. (this exclude IMAP that I don't
know well and I currently don't remember).
master thread pool with mailboxes pushing tasks onto a queue? per
mailbox thread pools? something more sophisticated?
approach to the scheduling algorithms?
are you using a library to manage the concurrency?
- robert
no, no, no, AFAIK.
Unfortunately there is no much documentation but (once learned
Avalon/Phoenix) I learned james internals in few weeks. It is not too
complex as a project.
To make it simple every connection get a thread and that thread provide
everything is needed to satisfy the client. Then there are spool threads
that take care to read messages queued by the smtp server for processing
them and eventually put them in the inboxes to be read by pop3 (imap).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
