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.
PLEASE report this problem to MySQL, because there is no reason why an
aborted insert should ever corrupt a database server.
--- Noel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 07, 2003 18:48
To: [EMAIL PROTECTED]
Subject: Critical bug in James 2.1 and 2.1.1
I've found a pretty critical bug in the core JAMES
Distribution. It appears in 2.1, and reviewing the 2.1.1a6
Source-Code, it doesn't seem to be fixed by now.
I've set up James 2.1 to use a MySQL Database for everything.
When I try to send a mail with an Attachment,
the Mailserver, *and* MySQL hang, and crash. Worse even, the MySQL
Database gets corrupted.
I get the following Exception on the console where I started james:
James 2.1
Remote Manager Service started plain:4555
POP3 Service started plain:110
SMTP Service started plain:25
NNTP Service Disabled
Fetch POP Disabled
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
application/octet-stream;
name=Borland_JBuilder_8_Enterprise_Trial_InstallLog.log
at
javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:851)
at javax.activation.DataHandler.writeTo(DataHandler.java:305)
at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:635)
at javax.mail.internet.MimeMultipart.writeTo(MimeMultipart.java:233)
at
com.sun.mail.handlers.multipart_mixed.writeTo(multipart_mixed.java:68)
at
javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:849)
at javax.activation.DataHandler.writeTo(DataHandler.java:305)
at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1089)
at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1527)
at
org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:268
)
at
org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:235
)
at
org.apache.james.mailrepository.JDBCMailRepository.store(JDBCMailRepository.
java:575)
at
org.apache.james.mailrepository.JDBCSpoolRepository.store(JDBCSpoolRepositor
y.java:190)
at org.apache.james.James.sendMail(James.java:444)
at org.apache.james.James.sendMail(James.java:407)
at org.apache.james.James.sendMail(James.java:389)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I wouldn't call this bug serious, but not critical, if that was all that
happened.
But since that Exception happened *during* a Database insert, which did not
complete,
the table that has been written to was corrupted. myisamcheck reported some
errors, but
also the indices were corrupted, so not even myisamcheck could recover it.
First time that I have problems with the data integrity of MySQL. Anyway ...
There wasn't anything valuable in it, so I dropped the database and tried
again.
I could re-produce the problem nicely. Even the MySQL crash, and the table
corruption
could be reproduced.
The results of this bug could be desastrous in a production environment,
since it can
lock up the entire MySQL Database, and even it's clients. (I had MySQL Front
locking
up when it tried to access the corrupted tables), and could lead to the loss
of data.
My software setup:
Sun JDK 1.4.1_01
James 2.1 (including the jdbc driver for mysql)
MySQL 3.23.55
Linux - Debian 3.0 - sid (unstable) with 2.4.20 Kernel
The problem lies in the way the MimeMessage.writeTo() Method works. It
parses the entire
Message, and invokes DataHandlers for each MimePart. If it doesn't find an
appropriate one
(and the javax.activation Framework doesn't provide a DataHandler for every
possible
MimeType), the above Exception occurs.
To fix the most serious consequences: the Exception should be dealt with
gracefully,
and in such a way that MySQL does not lock up.
There are two ways I could imagine to solve the problem, so that the
Exception doesn't
happen at all ..
1.) Don't use MimeMessage.writeTo()
I don't know exactly if there's a way to get to the raw data without having
it parsed and
re-generated like MimeMessage.writeTo() does. Maybe
MimeMessage.getRawInputStream()
could work.
2.) Write and register a catch-all DataHandler, so that there is always a
valid
DataHandler.
I'll go ahead and try to fix it myself. But I've never done anything to the
James
Source-Code, so maybe it would be a better idea if an active developer from
this list
- who is much more likely to know the consequences of any changes made -
fixed it as well, and submitted the fix to the CVS Repository.
with best regards,
Kai Londenberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
