Am Montag, den 17.07.2006, 03:44 +0200 schrieb Zsombor:
> 2006. 07. 14, péntek keltezéssel 16.08-kor Joachim Draeger ezt írta:
> > I was looking for the maximal number of threads Java is able to run I
> > found the answer that it is only limited by memory...
> > I always try to challenge propositio
2006. 07. 14, péntek keltezéssel 16.08-kor Joachim Draeger ezt írta:
> I was looking for the maximal number of threads Java is able to run I
> found the answer that it is only limited by memory...
> I always try to challenge propositions. Is it even a problem to have a
> sleeping thread per connect
Joachim Draeger wrote:
IMAP is a perfect case for SEDA because often there are a lot of idle
collection and without SEDA you need to keep idle threads allocated.
How much does it cost to keep an idle thread allocated? Is it only using
memory or using a lot of memory or does the JVM need cpu tim
On Jul 14, 2006, at 10:08 AM, Joachim Draeger wrote:
How much does it cost to keep an idle thread allocated? Is it only
using
memory or using a lot of memory or does the JVM need cpu time to deal
with them?
Do you recommend using SEDA instead of MINA?
MINA would let you implement a SEDA-style
Am Freitag, den 14.07.2006, 15:40 +0200 schrieb Stefano Bagnara:
> >> The thread per connection model simply doesn't scale to the level that
> >> would be needed for a decent IMAP server.
> >
> > Why? There are reasons to limit the maximal number of simultaneously
> > running threads. But what
Joachim Draeger wrote:
The thread per connection model simply doesn't scale to the level that
would be needed for a decent IMAP server.
Why? There are reasons to limit the maximal number of simultaneously
running threads. But what are the drawbacks of having one thread per
connection?
I thi
Am Montag, den 10.07.2006, 21:05 -0600 schrieb Mike Heath:
> On Mon, 2006-07-10 at 14:57 +0200, Joachim Draeger wrote:
>
> > > Maybe such idle connections could be handled by a special thread and if
> > > any real work is starting on a connection, this one is handed over to a
> > > worker thread
Am Montag, den 10.07.2006, 21:05 -0600 schrieb Mike Heath:
> On Mon, 2006-07-10 at 14:57 +0200, Joachim Draeger wrote:
>
> > > Maybe such idle connections could be handled by a special thread and if
> > > any real work is starting on a connection, this one is handed over to a
> > > worker thread
On Mon, 2006-07-10 at 14:57 +0200, Joachim Draeger wrote:
> > Maybe such idle connections could be handled by a special thread and if
> > any real work is starting on a connection, this one is handed over to a
> > worker thread?
>
> To allow many idle connections but limit the maximal possible
Am Samstag, den 08.07.2006, 13:08 +0200 schrieb Bernd Fondermann:
> > Actually there is a inactivity limit of 30 minutes defined in the RFC
> > and clients should be able to deal with the fact that they might be
> > thrown out from time to time.
>
> But any command restarts this timeout. A simple
Am Samstag, den 08.07.2006, 12:56 +0200 schrieb Bernd Fondermann:
> > For accessing a DB cluster you don't need any specialization. Any
> > application that uses JDBC should be able to do it quite out of the box.
>
> Keeping the whole of James in mind, I think it is more worthwhile to
> think ab
Joachim Draeger wrote:
Hi Ahmed,
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?
Joachim Draeger wrote:
Hi Bernd,
Imap is quite resource intensive.
Is it? Why?
How does IMAP resource consumption compare to already existing James
parts like POP3 and UserRepositories?
The normal SMTP/POP life-cycle is 1. delivering a message 2. retrieve by
pop3, store on users hard-dis
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
Am Donnerstag, den 06.07.2006, 15:39 +0200 schrieb Ahmed Mohombe:
> > 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
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 awar
Hi Ahmed,
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 issu
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?
Also, doesn't this require too a totally different testing approach?
Clustering at DB level would mean t
Hi Bernd,
> > Imap is quite resource intensive.
>
> Is it? Why?
> How does IMAP resource consumption compare to already existing James
> parts like POP3 and UserRepositories?
The normal SMTP/POP life-cycle is 1. delivering a message 2. retrieve by
pop3, store on users hard-disk, delete from s
I am not going too much into the topic itself, just a few more general
questions at first.
Joachim Draeger wrote:
Cluster
Imap is quite resource intensive.
Is it? Why?
How does IMAP resource consumption compare to already existing James
parts like POP3 and UserRepositories?
I would have
Cluster
Imap is quite resource intensive. This requires to share the load
between multiple hosts. Another goal is being fault tolerant and to have
a fail-over strategy. This means not having 99.999% availability. This
could be done using a cluster capable RDBMS. At the best this would mean
that y
21 matches
Mail list logo
