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(JDBCSpoolRepository.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]
