[
https://issues.apache.org/jira/browse/JAMES-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518028
]
Amichai Rothman commented on JAMES-799:
---------------------------------------
regarding the mysql jdbc drivers:
http://james.apache.org/server/2.3.1/using_database.html says:
"Please note that a MySQL driver is included as part of the James distribution
and so there is no need to add such a driver to the lib directory."
The two driver versions I've tried are 3.1.7 (which is the version that was
running in my webapps), and 5.0.7 which is the latest stable recommended
version on the MySQL site. In any case, since switching to mordred solved the
problem, it seems less likely that the MySQL drivers are the problem.
I didn't see any 'no connections available' or any other exceptions in the logs
- only the ones whose root cause was "Address already in use: connect", and a
'giving up' message after 3 such attempts - and this happened in all the
attempts I made with various configuration changes (about 5-10 attempts). In
contrast, after switching to mordred, I managed to transfer all the
repositories without a single error, including one with ~80K messages (the spam
repository - I'm saving it as a spam corpus for statistical data).
Note that I tried monitoring both the logs and the tables as they were filling
up during the repository transfer, and the errors always came after a short
while of inactivity where it looked like the processing is stuck - I suppose
this was some sort of db reconnect timeout before the exception was thrown.
The default values were indeed configured: 10 spool threads and 20 in the db
configuration "max" element. I've also tried setting them both to 8 (iirc) in
my previous attempts, as well as lowering the threads in the default thread
pool in the thread-manager configuration section. This ruled out the issue of
WinXP having a maximum of 10 half-open sockets issue (though there's no reason
for that to be related - but I tried anyway).
I know nothing of the implementation details of neither mordred nor dbcp, but
obviously they're doing something differently - with the rest of the
configuration remaining unchanged, one failed on all attempts and the other
always succeeded.
Since the file repositories are gone by now (except the users one, for which I
could not yet find a way to migrate to a db repository without having to
recreate all accounts manually), and there's considerable downtime involved to
the SMTP server, I'm afraid I probably won't have a chance to recreate this
scenario again with 1 spool thread. If there's any additional info that might
help, I'd be happy to provide it. I'm adding below the spoolmanager log excerpt
in case it helps.
04/08/07 14:39:31 ERROR spoolmanager.migratedb: Exception calling ToRepository:
Exception caught while storing mail Container:
javax.mail.MessagingException: Exception caught while storing mail Container: ;
nested exception is:
java.sql.SQLException: Server connection failure during transaction.
Due to underlying exception: 'java.net.SocketException: java.net.BindException:
Address already in use: connect'.
** BEGIN NESTED EXCEPTION **
java.net.SocketException
MESSAGE: java.net.BindException: Address already in use: connect
STACKTRACE:
java.net.SocketException: java.net.BindException: Address already in use:
connect
at
com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:151)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:280)
at com.mysql.jdbc.Connection.createNewIO(Connection.java:1886)
at com.mysql.jdbc.Connection.<init>(Connection.java:430)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:268)
at
org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:37)
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
at
org.apache.james.util.dbcp.JdbcDataSource.getConnection(JdbcDataSource.java:220)
at
org.apache.james.mailrepository.JDBCMailRepository.store(JDBCMailRepository.java:555)
at
org.apache.james.transport.mailets.ToRepository.service(ToRepository.java:98)
at
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:424)
at
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:405)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:309)
at java.lang.Thread.run(Unknown Source)
** END NESTED EXCEPTION **
Attempted reconnect 3 times. Giving up.
at
org.apache.james.mailrepository.JDBCMailRepository.store(JDBCMailRepository.java:764)
at
org.apache.james.transport.mailets.ToRepository.service(ToRepository.java:98)
at
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:424)
at
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:405)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:309)
at java.lang.Thread.run(Unknown Source)
Caused by: java.sql.SQLException: Server connection failure during transaction.
Due to underlying exception: 'java.net.SocketException: java.net.BindException:
Address already in use: connect'.
...
> 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]
