james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmed Mohombe <amoho...@yahoo.com>
Subject Re: IMAP Draft: Cluster
Date Thu, 06 Jul 2006 13:39:06 GMT
> Am Donnerstag, den 06.07.2006, 10:47 +0200 schrieb Ahmed Mohombe:
>>> In a worst case, when nobody is ill or on holidays, you have at least
>>> one open connection per user all the time. 
>> How would one handle in the JVM and code these very long lasting connections?
> Why? Are there issues? 
> I'm not aware of any problems with many sockets treated by many threads
> running a long time apart from the not avoidable network, cpu and memory
> consumption. 
Well, if too many resources are for long time "occupied" and not released,
the JVM won't even get the change to do GC on those object trees.
The problem is also that those resources are limited (at least for most
of the people).

> We should try to keep the data hold by the sessions small. If there are
> really many users it should be possible to run an optimistic setup: not
> all connected users will start the most expensive operations at the same
> time. So maybe it is needed to have a strategy for the worst case:
> Before everything gets so slow that nobody can do anything activate a
> dynamic connection limit.
Exactly :).

> In this case the IMAP server should run on a separate machine not to
> influence smtp/spooling on high loads.
Having a second machine is already a too high system requirement. Many
small companies that have their server to an ISP would gladly use IMAP
but only on that one machine.
Many providers also do not allow messing with MX records or other things, so
many small companies get one machine, one IP address and  a few domain names.
Even if the loading is not too high, somehow all services on that machine should run on
that single one machine without consuming the resources totally from other
processes in case of higher loading pikes.

> Is that the direction of your question?
This would be the purpose: to guarantee somehow that at least those who
are in (or do not overpass a limit) get decent handing even if more
users try to access the service.

>>>> Clustering at DB level would mean to not support dbfile, file and other 
>>>>   types of repositories.
>>> Clustering at DB level would just mean following some rules in the
>>> implementation. DBMS are designed to be accessed simultaneously from
>>> multiple hosts.
>>> dbfile mmh, good point. I just made a few thoughts. There are also
>>> various solutions to access a network file-system without a single point
>>> of failure. 
>> What about JCR? (e.g. the Jackrabbit implementation). Could
>> it solve some of the problems, or it is too far away from making
>> it usable as a "file system" for IMAP?
> Well, I don't have any knowledge about JCR. I tried to quickly browse
> some docs/faqs. 
> But it seems to be able to use it reliable Jackrabbit uses a JDBC
> back-end, too. And I guess it wasn't made to store lots of emails. The
> overhead of implementing this might be greater than using JDBC directly.
> This gives us the ability to tune performance.
> How do you think JCR might help?
Well, JCR is a standard and can have many types of back-ends (not just JDBC).
It is used for CMSes and DMSes (e.g. Magnolia) and has all the features that require
reliability, scalability, etc.
I asked about JCR since IMAP from a user perspective looks more like a DMS. In fact,
many small companies use the Exchange server(and some Outlook plug-ins) with IMAP exactly
in this 
way: to access easily all the documents from everywhere and all the time.

>> What are the minimal performance requirements for  JAMES's first IMAP implementation?
> As i said above I can only make assumptions. But it is an important
> question. The first goal is to have something stable.
> I think the cpu/memory usage for pure protocol handling is not that
> higher than in POP3. The critical part is moving the data.
> Apart from directly accessing mime-parts or performing searches it
> should compare to a smtp/pop3 session.
This sounds good.


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

View raw message