Kai,
It probably was the activation.jar, but I just made some changes to avoid
rendering the content with data handlers unless we really must. The same
changes should also address Danny's issue with volatile Message-ID. These
changes are not in HEAD, yet, but will be in 2.1.1a7, which I'll be
uploading shortly.
Please test it to make sure that I haven't accidently introduced a
regression. So far it looks good in my tests, but my tests do more in terms
of load testing than functional verification.
I'm not seeing problems with myisamchk, but I'll check again.
We would be happy to have you contribute to James. Our plans for James v3
further expand it into a "unified messaging" server. You may have noticed
comments regarding a Jabber service, for example, and both IMAP and NNTP
need attention.
CVS access for writes is earned (and voted upon). CVS access for reads is
easy. I just posted a message with instructions, since the question has
come up before. I'd thought I had sent that message on Thursday, but
apparently it had still been pending.
--- Noel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 09, 2003 8:52
To: [EMAIL PROTECTED]
Subject: RE: Critical bug in James 2.1 and 2.1.1
Hello,
In the meantime I upgraded to James 2.1.1a6.
In this version, the Exception did not occur.
I guess this is due to the fact that JavaMail 1.3 along with a current
activation.jar are used in this version. I've written a few Applications
using JavaMail myself, and I've always had problems with JavaMail 1.2 -
Version 1.3 is much more robust.
I can only recommend to release 2.1.1 - Put in the latest bug fixes (note my
SMTP Auth incompatibility report :)) and release it as a Milestone Release
at least.
When it comes to the MySQL Corruption, obviuously it wasn't James fault,
since even when the Exception happened, it released every resource
gracefully, and even
finished the Insert.
With the Exception being gone in 2.1.1a6, everything works fine - until I
use MySQL Front to view the table, that is.
As it turned out, somehow my MySQL Client seems to be responsible for the
problem. It accessed the data, and it seems as if it wasn't able to cope
with the stored data and locked up. So maybe there is a bug in the libraries
it uses to access MySQL.
PHPMyAdmin on the other hand is capable of dealing with the contents of the
tables.
Another coincidence seems to be that myisamchk reports errors on perfectly
working tables, even on empty ones.
I don't know why - maybe myisamchk doesn't know how to handle primary keys
of varchar type, and/or spanning two columns. Or the Table structure is
somehow working, but invalid.
Maybe those of you who also use MySQL should try myisamchk on their own
tables, and see if they get error-reports as well.
>The fact that I cannot reproduce your results
>notwithstanding, I have several observations.
>First, thank you for the report. Looking over the stack trace has given me
>ideas regarding optimizing future versions of James. We should be able to
>speed up performance of the message stores.
>In the meantime, I see what enables the potential problem, and I
>don't believe that we need to do it that way.
>We just want to stream the raw data (minus the headers) to the output
stream.
>Will see if I can bypass that portion of JavaMail entirely.
>Should have a test build for that this weekend.
By the way:
I'd like to contribute to James as a developer.
I am propably going to use James as the underlying Mail-Server in a Unified
Messaging Portal. (See http://www.my-vwclub.de and http://www.zoomie.de -
both in German)
As an experienced Java developer, I guess that I'll go ahead and fix bugs
and implement new features out of sheer necessity. And why shouldn't I
contribute those additions back to the official James distribution ?
What do I need to do to get CVS Access ?
with best regards,
Kai Londenberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
