james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amichai Rothman (JIRA)" <server-...@james.apache.org>
Subject [jira] Commented: (JAMES-799) dbcp causes "Address already in use: connect" exception and server fails
Date Sun, 05 Aug 2007 11:06:53 GMT

    [ 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 migratedb@localhost, 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="RecipientIs=migratedb@localhost" class="FromRepository">
    <processor> migratedb </processor>

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>

> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message