[jira] Created: (JAMES-254) Connections not always recovered when idle timeout

2004-04-14 Thread jira
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/JAMES-254 Here is an overview of the issue: -

Re: keeping a JDBC connection active

2004-04-14 Thread Richard O. Hammer
Serge Knystautas wrote: ... permanently holding a single database connection open is a Bad Idea(tm). Some downsides: - your code is inherently single-threaded. I have not noticed any single-thread limitation. I have a singleton (only one instance) database class. It has the one Connection as a

RE: [jira] Updated: (JAMES-99) RFC1894 format notification

2004-04-14 Thread Steve Brewin
Steve Brewin wrote: > Soren and All, > > In support of MDN, as per RFC 2298, this weekend I was > planning to commit... I guess I should have explained that along with its general utility, MDN support is required in James in support of jSieve, our implementation of Sieve - RFC 3028. The Sieve rej

RE: [jira] Updated: (JAMES-99) RFC1894 format notification

2004-04-14 Thread Steve Brewin
Soren and All, In support of MDN, as per RFC 2298, this weekend I was planning to commit... - org.apache.james.util.mail.MimeMultipartReport - org.apache.james.util.mail.handlers.message_disposition_notification - org.apache.james.util.mail.handlers.multipart_report ... to support the Mime types

Re: keeping a JDBC connection active

2004-04-14 Thread Joe Cheng
I generally don't critique design patterns (let he who is without bad design patterns cast the first stone), but permanently holding a single database connection open is a Bad Idea(tm). Some downsides: - your code is inherently single-threaded. - if you change to make it 1 thread = 1 db connect

RE: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Noel J. Bergman
> > > I am about to commit a patch to CVS. Would you please check it? > > > did you send it to me? Can't find it! > > Was testing before posting. Should be there now. > Looks fine to me. This patch surely stops the JAMES being brought down. Actually, I didn't test enough. Just fixed again. The

cvs commit: james-server/src/java/org/apache/james/util/mordred JdbcDataSource.java

2004-04-14 Thread noel
noel2004/04/14 11:10:49 Modified:src/java/org/apache/james/util/mordred Tag: branch_2_1_fcs JdbcDataSource.java Log: Fix JAMES-253. Correction to move Thread.sleep(5000L) out of the synchronized block. Revision ChangesPath No

AW: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Labib Iskander, Marcus
Hi, > > > I am about to commit a patch to CVS. Would you please check it? > > did you send it to me? Can't find it! > Was testing before posting. Should be there now. Looks fine to me. This patch surely stops the JAMES being brought down. Only that a hard limit of 2 minutes seems very short to

Re: keeping a JDBC connection active

2004-04-14 Thread Serge Knystautas
Richard O. Hammer wrote: In my mailserver (a cousin of James) I use one java.sql.Connection throughout the life of the server. I call java.sql.DriverManager.getConnection() once at server startup. I've never suspected there was anything wrong with this, but I guess there might be. If this is

Re: AW: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Serge Knystautas
Labib Iskander, Marcus wrote: As long you trust the SQL queries and JDBC drivers, what you really should be able to, I don't see much sense in killing the connection even after a very long time. But maybe the original programmers had some misbehaved drivers in mind? Originally this database connect

keeping a JDBC connection active

2004-04-14 Thread Richard O. Hammer
In my mailserver (a cousin of James) I use one java.sql.Connection throughout the life of the server. I call java.sql.DriverManager.getConnection() once at server startup. I've never suspected there was anything wrong with this, but I guess there might be. If this is of interest to anybody,

RE: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Noel J. Bergman
> > I am about to commit a patch to CVS. Would you please check it? > did you send it to me? Can't find it! Was testing before posting. Should be there now. > > And it appears to me that there is a bug in your code. > yes. I was a little fast on that on as it seems :( No worries. > In the fi

cvs commit: james-server/src/java/org/apache/james/util/mordred JdbcDataSource.java

2004-04-14 Thread noel
noel2004/04/14 10:33:28 Modified:src/java/org/apache/james/util/mordred Tag: branch_2_1_fcs JdbcDataSource.java Log: Fix JAMES-253 Patch applied based upon Marcus Labib's contribution. Enforces synchronized access to the pool. Also added code ba

AW: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Labib Iskander, Marcus
> > Do you have any reason to believe that there are legitimate reasons > > for a JDBC connection to be active for several minutes, > much less an > > hour? > > I ran grep against the logs in my production environment. > There have been 32 timeouts since August 2002. Getting them > tends to

AW: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Labib Iskander, Marcus
Hi Noel, > I am about to commit a patch to CVS. Would you please check it? did you send it to me? Can't find it! > And it appears to me that there is a bug in your code. yes. I was a little fast on that on as it seems :( > Apparently, you want to log when a connection is older than > ACTIVE

RE: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Noel J. Bergman
> Do you have any reason to believe that there are legitimate > reasons for a JDBC connection to be active for several > minutes, much less an hour? I ran grep against the logs in my production environment. There have been 32 timeouts since August 2002. Getting them tends to indicate a need to r

[jira] Resolved: (JAMES-253) deadlock in mordred connection pool

2004-04-14 Thread jira
Message: The following issue has been resolved as FIXED. Resolver: Noel J. Bergman Date: Wed, 14 Apr 2004 9:41 AM Patch applied based upon Marcus Labib's contribution. Enforces synchronized access to the pool. Also added code based upon his patch to first just log overly long-liv

RE: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Noel J. Bergman
Marcus, I am about to commit a patch to CVS. Would you please check it? And it appears to me that there is a bug in your code. > The attached patch goes a little further than just fixing the bug. > I don't think it is wise to kill a connection after a minute > execution time. Judge for yoursel

RE: james 2.1.3: deadlock in mordred code

2004-04-14 Thread Noel J. Bergman
> I would not like to switch because I reckon you had a > reason not to call it 2.1.4 ;) Lots of major feature improvements. 2.1.4 would be just bug fixes. > I don't have time to do much testing myself. Thus I would not > upgrade before a release. Fair enough. > And then only if it had been ar

RE: [PATCH] Fix Issue 247 Oracle DB and add support for DB2

2004-04-14 Thread Steve Short
Looks good. Steve > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 13, 2004 11:43 PM > To: James Developers List > Subject: RE: [PATCH] Fix Issue 247 Oracle DB and add support for DB2 > > > Steve, > > Committed to CVS. Please review the ch

[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

2004-04-14 Thread jira
The following comment has been added to this issue: Author: Noel J. Bergman Created: Wed, 14 Apr 2004 6:46 AM Body: The Mail object is held in the userInbox for the duration of the session. When streaming is possible (there is an issue to be fixed with db protocol, but not file o

[jira] Commented: (JAMES-248) memory management - finalize/nullify after successful delivery of retrieved MailImpl

2004-04-14 Thread jira
The following comment has been added to this issue: Author: Ralf Hauser Created: Wed, 14 Apr 2004 3:07 AM Body: Noel, thx for the insight. But wouldn't the finalizer immediately be called if the MailImpl object the MailRepository.java's retrieve() mehtod returns would be actively