[
https://issues.apache.org/jira/browse/JAMES-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517753
]
Amichai Rothman commented on JAMES-799:
---------------------------------------
The configuration I use is basically the default one, where I commented the
file repositories and uncommented the db ones, and added the appropriate db
username/password. In contrast to what the JAMES docs say, it seems that the
MySQL drivers were not installed by default (the server failed to start) so I
added them to the lib folder as the docs suggest - I tried both an older
version and the latest version (after adding the driver, the server came up
properly. I eventually left the newer version in place when I saw this doesn't
affect the reported error.)
I configured the FromRepository Mailet in order to convert a previous file
repository to the new db repository since I couldn't find any documented way to
do this (and spent quite a while searching). To correct what I wrote before -
the file repository contained 692 messages, which translate to twice as many
files on disk, from which I got the ~1.5K number I wrote before. After the
server was started, I sent the trigger message to [EMAIL PROTECTED], which
started the process. So in effect, this was a batch spooling of 692 messages,
which are immediately stored in the db. The process never made it to completion
(well it did, but always with some messages missing - never the full 692
messages converted, and I've deleted the db and retried several times). The
exceptions always occured somewhere in the middle, giving up and dropping some
of the spooled messages. Also note that the external routing of port 25 to this
server was turned off during the migration process, so there was no other
activity other than that triggered by the migratedb trigger email. Finally,
after many retries and researching the web, I made the single configuration
modification of specifying the mordred class rather than the dbcp class, and
restarted the process. From then on everything worked right, and I proceeded to
configure additional repositories to be migrated to the db, none of which
showed any errors.
The relevant configuration sections are:
<!-- configured as the first Mailet in the root processor for db migration -->
<mailet match="[EMAIL PROTECTED]" class="FromRepository">
<repositoryPath>file:///C:/James/error/</repositoryPath>
<processor> migratedb </processor>
<delete>false</delete>
</mailet>
and the corresponding processor:
<processor name="migratedb">
<!-- used with the FromRepository triggered mailet to perform migration
from file stores to db stores -->
<mailet match="All" class="ToRepository">
<repositoryPath> db://maildb/deadletter/error </repositoryPath>
</mailet>
</processor>
> dbcp causes "Address already in use: connect" exception and server fails
> ------------------------------------------------------------------------
>
> Key: JAMES-799
> URL: https://issues.apache.org/jira/browse/JAMES-799
> Project: James
> Issue Type: Bug
> Components: MailStore & MailRepository
> Affects Versions: 2.3.1
> Environment: Windows XP, MySQL 4.1.22
> Reporter: Amichai Rothman
>
> I've tried using FromRepository servlet (manual one-time configuration) to
> migrate a file store with ~1.5K messages to a database store. however afte a
> few hundred inserts, the logs started filling with exceptions, whose root
> cause is "Address already in use: connect". After much investigation, I found
> out using netstat that there are thousands of ports open (all local - both
> JAMES and MySQL are on the same server), and as some googled post suggested,
> the available TCP ports may have been exhausted. The result was that some of
> the message never made it through the conversion - the logs showed that after
> 3 db connection retries JAMES gave up on them.
> I tried lowering the number of threads in the db source configuration, spool
> configuration, and default thread pool configuration (all in config.xml) but
> nothing helped. Eventually, I reverted all my configuration attempts, and
> applied the single change of using mordred instead of dbcp, and now
> everything works fine. I don't know if this is a JAMES or a dbcp bug, but
> it's definitely unacceptible for db connections to fail when there is a bit
> of load on the system (a few hundred messages).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
