[ 
https://issues.apache.org/jira/browse/JAMES-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518038
 ] 

Stefano Bagnara commented on JAMES-799:
---------------------------------------

Thank you for the website documentation errata pointer. We'll try to fix it 
soon.

For the other problem I guess the max_wait parameter would have fixed your 
issue.
AFAICT you get that exception on windows if you try to get connections too fast 
and the OS has yet to free up that resource. So I guess the pool is not working 
fine because it doesn't keep the connection opened for a while, waiting for new 
"clients".

Maybe this explains why I keep updating that parameters in every of my server.

Can any other use confirm this? Is anyone using dbcp with the max_idle and 
max_wait parameters like me to fix similar issues?

> 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]

Reply via email to