When james is configured with many processors then the spooling processing
is really slow.
It takes a minimum of 1 minute per processor to fully spool a single email.
JDBCSpoolRepository has a 60 seconds wait, and the spool threads only
complete 1 processor and return the mail to the spool.
Hi, I wanto to know if there is a manner to limit the quota of space for
each user.
like others mail server, everyone has a limit of capacity in the inbox
repository,
it is possible to configure james for that? where and how??
thanks
Daniel Rebolo
Have a look at the RecipientIsOverFixedQuota mailet.
Vincenzo
Daniel Rebolo wrote:
Hi, I wanto to know if there is a manner to limit the quota of space for
each user.
like others mail server, everyone has a limit of capacity in the inbox
repository,
it is possible to configure james for that?
JDBCSpoolRepository has a 60 seconds wait
Which should get terminated when notify is called().
ref:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#wait(long)
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#notify(
)
the spool threads only complete 1
One possible change, hinted at in comments I left in the code, would be for
the spool manager to become single threaded, dishing off messages to worker
threads. This would be quite similar to a common usage pattern with NIO,
should eliminate contention and synchronization issues, and improve
I don't really see us as that competitive. I rather thing we'll carve
out two different nitches in the market.
I've actually started moving most of the plan into JIRA. We're actually
going to try and cut a 1.0 release sooner rather than later and cut our
planned feature set (really just move
On Fri, 29 Apr 2005 12:21:29 -0400
[EMAIL PROTECTED] wrote:
Myself and the other committers are also discussing
offline what might be necessary to collaborate on Mailets
if there was interest from JAMES, but I don't really want
to go down that path until after 1.0.
I would be interested,
it would be easier to review if you send a diff -u there is a
reason why we like diffs compared to random blocks of code.
You can find the diff at the end of this email.
JDBCSpoolRepository has a 60 seconds wait
Which should get terminated when notify is called().
I know how notify()
1. refector the project
Already anticipated, which is why the path is server/. We just wanted to
wait until we had a reason to push mailet/ to a separate subproject.
a. email.apache.org/james
b. email.apache.org/mailet (associated lists)
Would be james.apache.org/server and
JDBCSpoolRepository has a 60 seconds wait
Which should get terminated when notify is called().
I know how notify() works but james does not call it.
Then we should fix that part.
the only notify is at the end of store() but there is no notify at
the unlock()
store() would be called
the only notify is at the end of store() but there is no
notify at the
unlock()
store() would be called elsewhere in the code to put it into
the next processor, and processor.service() doesn't return
until the processor has finished with the message.
Ok, I found the call to store()
Okay. I don't think its very important but could be to others. Since
JAMES is the server and it will be perceptually JAMES's mailets and not
just Apache Mailets it might kind of inhibit adoption. I don't really
care enough to be personally inhibited, just pointing out that it is an
--- [EMAIL PROTECTED] wrote:
the only notify is at the end of store() but
there is no
notify at the
unlock()
store() would be called elsewhere in the code to
put it into
the next processor, and processor.service()
doesn't return
until the processor has finished with the
Serge Knystautas wrote:
I would be interested, though we're also intending to
change the Mailet API. It's very servlet API-esque, which
is rather passe.
Being passé is no reason of itself to change the Mailet API. I'm sure I'm
being paranoid, but you don't mean drop the current Mailet API do
14 matches
Mail list logo
