My lack of time and some bad and good news

[Serge Knystautas <se...@lokitech.com>]

I'm sorry I haven't been responsive to any of the lists.  I'm very busy with
work and a book project at the moment, but hopefully I'll have some time
later this week to at least respond.  I do have a few items of news:

Bad news:
1. File repositories will not be upward compatible from 1.2.1 to 2.0
While the James code kept the file formats the same between versions, we
upgraded Avalon and that code changed naming conventions for files. :(  If
you copy the file-pair in a 1.2.1 repository into a 2.0 repository, Avalon
never sees that file because it's not named correctly.

I would hope it shouldn't be very hard to write a mail repository migration
tool (to move from old avalon file to new avalon file or DB or whatever) if
anybody wanted to write that and contribute, that'd be great.

2. Avalon DB connection pooling not ready
Unfortunately Avalon's excalibur db pooling code isn't ready for heavy use.
A minor problem is that it automatically kills a connection every 15 uses
(not configurable), but more importantly, it doesn't support blocking.  When
you hit the max number of connections, it throws RuntimeExceptions each
connection request, until there's one available again.  In the DB mail
repository and the mailets that use the db conn pool, I've wrapped calls to
the excalibur db pool in a very crude loop to get a connection, but it's
kind of a showstopper.

3. Avalon file (stream-based) repository still not quite stable
Even with my code to make sure both files exist, I've found I still
occasionally get 0-byte files created on occasion.  This has particularly
nasty effects because the spool seems unable to delete the file in these
cases, and throttles the server retrying the same bogus file.  I guess I'll
add code to catch this situation, but I perhaps I need to create a timer
block that will prevent a message being unlocked until delete operations are
complete.  This will hurt performance, although in theory you can just boost
the number of threads to compensate.

Like I said, I'll try to respond to each person's emails to the list later
this week.

Good news is:
1. We've got classloader plans set, so I'll be able to create a
app/james/classes directory where you can stick mailets and matchers, so you
don't need to rebuild your James dist to use custom mailets/matcher.  Might
even go ahead and detect .java files and try to compile them, although
there's not an easy way to output compilation problems.  Also it will make
it much easier to support reloading.  In fact, I'm thinking about moving the
mailet/matcher part of the code into a separate .xml file (since it's rather
independent of the other system-level configuration), and then I can check
for changes to that file or the .java/.class files.

2. The code is mostly stable. :)  Aside from the fact that neither file nor
db mail repository works 100%. :)

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>