Re: [dbcp][pool] Use abort instead of close for abandoned connections?
The two cases i seen the abort() helped, since it closes the socket without synchronize and the socket close will unblock the read. But you need to be careful not to call any other blocking method first (i remeber rollback, Statement close and even isOpen (if i recall correctly) have been problematic) Gruss Bernd -- http://bernd.eckenfels.net Von: Phil Steitz Gesendet: Friday, September 4, 2020 1:06:23 AM An: dev@commons.apache.org Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections? On 9/3/20 3:02 PM, Bernd Eckenfels wrote: > The issues I have seen are not a/b "deadlocks", they are "just" endless locks > - the close is waiting for a read to finish (since both synchronize on the > connection). If the asumption is a pool timer can in the background cancel a > read - it can't, at least on Oracle thin or jtds. > > The cause can be softened by using read timeouts and/or keepalive, but both > is not the default and can block the pool for minutes, still. The question is would using abort instead of close work better in some of the abandoned connection scenarios. IIUC the contract correctly, at least the pool thread will not be blocked in these scenarios if we move to this for that use case. Note that dbcp/pool can be configured to remove abandoned connections on borrow as well as maintenance, so blocking in the former case blocks the pool client. Phil > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > Von: Mark Thomas > Gesendet: Thursday, September 3, 2020 11:44:52 AM > An: dev@commons.apache.org > Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned > connections? > > On 31/08/2020 01:05, Phil Steitz wrote: > > > >> If others agree it is a good idea for dbcp, I can do it. I can see the >> argument that its better to stay with close() even for abandoned and I >> have not been able to get the deadlock to happen, so I would like to >> wait a bit and allow others to weigh in. Similarly for pool, I would >> like to get more community feedback before adding to the interface. > Hmm. > > On one hand if the driver deadlocks I don't see how that can be anything > other than a driver bug. If multiple code paths obtain multiple locks > then those code paths must always obtain those locks in the same order. > Anything else is a bug that is likely to result in a deadlock in a > multithreaded environment. > > On the other hand, it could be argued that the situation only arises > when an application doesn't correctly return connections to the pool > and/or keeps them for too long and/or doesn't configure the pool > correctly for their usage pattern. > > The approach of adding > > PooledObjectFactory.destroyObject(PooledObject,CloseMode) > > where CloseMode is an Enum with two values looks reasonable to me. > > I do agree that abort() should only be used in the case of abandoned > connections. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.3 RC1
On Fri, 4 Sep 2020 at 00:06, Gary Gregory wrote: > > On Thu, Sep 3, 2020 at 11:43 AM Mark Thomas wrote: > > > On 03/09/2020 15:37, Gary Gregory wrote: > > > On Thu, Sep 3, 2020 at 10:17 AM Mark Thomas wrote: > > > > > >> On 03/09/2020 14:06, Gary Gregory wrote: > > >>> Mark, > > >>> > > >>> The vote email must contain SHA256 or 512 hashes for the file bin and > > gz > > >>> files in https://dist.apache.org/repos/dist/dev/commons/daemon/ > > >>> > > >>> Per https://commons.apache.org/releases/prepare.html > > >>> > > >>> (There is no need to hash the files twice on > > >>> https://dist.apache.org/repos/dist/dev/commons/daemon/) > > >> > > >> See previous Commons Daemon release vote threads for why I won't be > > >> doing that. > > >> > > > > > > Based on the search: > > > > > > > > https://www.mail-archive.com/search?l=dev%40commons.apache.org=%5BVOTE%5D+Release+Apache+Commons+Daemon+=1 > > > > > > I see that the 1.1.0 RC provided SHA1's: > > > > > > https://www.mail-archive.com/dev@commons.apache.org/msg60676.html > > > > > > But I don't see 1.2.x VOTE threads so it must have happened with > > different > > > worlds in the subject. > > > > http://markmail.org/message/agt3f3etzdyt7qjv > > and > > http://commons.markmail.org/thread/6ivhavlovopqrt5z > > which expands on the topic of traceability. > > > > I've always seen as I've learnt it from Sebb: Hashes in the VOTE email > provides traceability *from *the email *to *what we are voting on. > > Sebb? Yes, I think it is vital that one can tie the vote email to the artifacts. That is easy to do if the email contains the hashes. > Gary > > > > Mark > > > > > > > > Gary > > > > > > > > >> Mark > > >> > > >> > > >>> > > >>> Thank you, > > >>> Gary > > >>> > > >>> On Tue, Sep 1, 2020 at 2:25 PM Mark Thomas wrote: > > >>> > > Apologies for the slight delay between the tag and the vote. There was > > an issue with the code signing service we use to sign the Windows > > >> binaries. > > > > It has been almost a year since the last Commons Daemon release. > > Notable > > changes since 1.2.2 include: > > - Improved debug logging for error conditions > > - Added support for Java's Native Memory Tracing > > - Added a procrun command to output the current configuration > > > > The full set of changes is in the changelog > > > > 1.2.3 RC1 can be obtained from (r41271) > > https://dist.apache.org/repos/dist/dev/commons/daemon/ > > > > The git tag is: > > Tag: COMMONS_DAEMON_1_2_3_RC1 > > URL: > > > > > > >> > > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > > Hash: f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > > > > The Maven Staging repo is: > > > > >> > > https://repository.apache.org/content/repositories/orgapachecommons-1525/ > > > > The Windows binaries have been signed by the DigiCert (formerly > > Symantec) code signing service. > > > > Files signed with my preferred key: > > http://people.apache.org/~markt/ > > KEYS file is standard Apache Commons keys file: > > http://www.apache.org/dist/commons/KEYS > > > > > > [ ] Approved - go ahead and release Commons Daemon 1.2.3 RC1 as 1.2.3 > > [ ] Broken - do not release because... > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > >>> > > >> > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp][pool] Use abort instead of close for abandoned connections?
On 9/3/20 3:02 PM, Bernd Eckenfels wrote: The issues I have seen are not a/b "deadlocks", they are "just" endless locks - the close is waiting for a read to finish (since both synchronize on the connection). If the asumption is a pool timer can in the background cancel a read - it can't, at least on Oracle thin or jtds. The cause can be softened by using read timeouts and/or keepalive, but both is not the default and can block the pool for minutes, still. The question is would using abort instead of close work better in some of the abandoned connection scenarios. IIUC the contract correctly, at least the pool thread will not be blocked in these scenarios if we move to this for that use case. Note that dbcp/pool can be configured to remove abandoned connections on borrow as well as maintenance, so blocking in the former case blocks the pool client. Phil Gruss Bernd -- http://bernd.eckenfels.net Von: Mark Thomas Gesendet: Thursday, September 3, 2020 11:44:52 AM An: dev@commons.apache.org Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections? On 31/08/2020 01:05, Phil Steitz wrote: If others agree it is a good idea for dbcp, I can do it. I can see the argument that its better to stay with close() even for abandoned and I have not been able to get the deadlock to happen, so I would like to wait a bit and allow others to weigh in. Similarly for pool, I would like to get more community feedback before adding to the interface. Hmm. On one hand if the driver deadlocks I don't see how that can be anything other than a driver bug. If multiple code paths obtain multiple locks then those code paths must always obtain those locks in the same order. Anything else is a bug that is likely to result in a deadlock in a multithreaded environment. On the other hand, it could be argued that the situation only arises when an application doesn't correctly return connections to the pool and/or keeps them for too long and/or doesn't configure the pool correctly for their usage pattern. The approach of adding PooledObjectFactory.destroyObject(PooledObject,CloseMode) where CloseMode is an Enum with two values looks reasonable to me. I do agree that abort() should only be used in the case of abandoned connections. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.3 RC1
On Thu, Sep 3, 2020 at 11:43 AM Mark Thomas wrote: > On 03/09/2020 15:37, Gary Gregory wrote: > > On Thu, Sep 3, 2020 at 10:17 AM Mark Thomas wrote: > > > >> On 03/09/2020 14:06, Gary Gregory wrote: > >>> Mark, > >>> > >>> The vote email must contain SHA256 or 512 hashes for the file bin and > gz > >>> files in https://dist.apache.org/repos/dist/dev/commons/daemon/ > >>> > >>> Per https://commons.apache.org/releases/prepare.html > >>> > >>> (There is no need to hash the files twice on > >>> https://dist.apache.org/repos/dist/dev/commons/daemon/) > >> > >> See previous Commons Daemon release vote threads for why I won't be > >> doing that. > >> > > > > Based on the search: > > > > > https://www.mail-archive.com/search?l=dev%40commons.apache.org=%5BVOTE%5D+Release+Apache+Commons+Daemon+=1 > > > > I see that the 1.1.0 RC provided SHA1's: > > > > https://www.mail-archive.com/dev@commons.apache.org/msg60676.html > > > > But I don't see 1.2.x VOTE threads so it must have happened with > different > > worlds in the subject. > > http://markmail.org/message/agt3f3etzdyt7qjv > and > http://commons.markmail.org/thread/6ivhavlovopqrt5z > which expands on the topic of traceability. > I've always seen as I've learnt it from Sebb: Hashes in the VOTE email provides traceability *from *the email *to *what we are voting on. Sebb? Gary > Mark > > > > > Gary > > > > > >> Mark > >> > >> > >>> > >>> Thank you, > >>> Gary > >>> > >>> On Tue, Sep 1, 2020 at 2:25 PM Mark Thomas wrote: > >>> > Apologies for the slight delay between the tag and the vote. There was > an issue with the code signing service we use to sign the Windows > >> binaries. > > It has been almost a year since the last Commons Daemon release. > Notable > changes since 1.2.2 include: > - Improved debug logging for error conditions > - Added support for Java's Native Memory Tracing > - Added a procrun command to output the current configuration > > The full set of changes is in the changelog > > 1.2.3 RC1 can be obtained from (r41271) > https://dist.apache.org/repos/dist/dev/commons/daemon/ > > The git tag is: > Tag: COMMONS_DAEMON_1_2_3_RC1 > URL: > > > >> > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > Hash: f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > > The Maven Staging repo is: > > >> > https://repository.apache.org/content/repositories/orgapachecommons-1525/ > > The Windows binaries have been signed by the DigiCert (formerly > Symantec) code signing service. > > Files signed with my preferred key: > http://people.apache.org/~markt/ > KEYS file is standard Apache Commons keys file: > http://www.apache.org/dist/commons/KEYS > > > [ ] Approved - go ahead and release Commons Daemon 1.2.3 RC1 as 1.2.3 > [ ] Broken - do not release because... > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > >>> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [dbcp][pool] Use abort instead of close for abandoned connections?
The issues I have seen are not a/b "deadlocks", they are "just" endless locks - the close is waiting for a read to finish (since both synchronize on the connection). If the asumption is a pool timer can in the background cancel a read - it can't, at least on Oracle thin or jtds. The cause can be softened by using read timeouts and/or keepalive, but both is not the default and can block the pool for minutes, still. Gruss Bernd -- http://bernd.eckenfels.net Von: Mark Thomas Gesendet: Thursday, September 3, 2020 11:44:52 AM An: dev@commons.apache.org Betreff: Re: [dbcp][pool] Use abort instead of close for abandoned connections? On 31/08/2020 01:05, Phil Steitz wrote: > If others agree it is a good idea for dbcp, I can do it. I can see the > argument that its better to stay with close() even for abandoned and I > have not been able to get the deadlock to happen, so I would like to > wait a bit and allow others to weigh in. Similarly for pool, I would > like to get more community feedback before adding to the interface. Hmm. On one hand if the driver deadlocks I don't see how that can be anything other than a driver bug. If multiple code paths obtain multiple locks then those code paths must always obtain those locks in the same order. Anything else is a bug that is likely to result in a deadlock in a multithreaded environment. On the other hand, it could be argued that the situation only arises when an application doesn't correctly return connections to the pool and/or keeps them for too long and/or doesn't configure the pool correctly for their usage pattern. The approach of adding PooledObjectFactory.destroyObject(PooledObject,CloseMode) where CloseMode is an Enum with two values looks reasonable to me. I do agree that abort() should only be used in the case of abandoned connections. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Commons-email with jakarta.mail?
Id just go with a shade+relocation as several geronimo or owb libs since javax will stay mainstream for years. Avoid yet another package change and 2 branches to maintain. Le jeu. 3 sept. 2020 à 18:33, Jean-Louis MONTEIRO a écrit : > Hi, > > Jakarta Mail is under vote at the minute and should go out hopefully in a > few days. > https://www.eclipse.org/lists/jakarta.ee-spec/msg00788.html > > Some work has been done on the Apache Geronimo side of things recently. Not > sure about the status though. > > Le jeu. 3 sept. 2020 à 17:52, Xeno Amess a écrit : > > > 5.0.0 means this : > > https://github.com/eclipse-ee4j/servlet-api/releases/tag/5.0.0-RELEASE > > And I believe that is the first release who introduced new namespaces for > > jakarta. > > And as you've already noticed, there even be no jakarta- > > mail 2.0 release to use now. > > I don't think it worthy to maintain a thread based on some rc > > dependencies... > > I'd rather take actions when they really release. > > After all they (means jakarta-mail here) even do not have a clear roadmap > > for the 2.0 release, as far as I know... > > > > David Goodenough 于2020年9月3日周四 > 下午11:17写道： > > > > > On Thursday, 3 September 2020 15:58:53 BST Xeno Amess wrote: > > > > > Is there a version of commons-email which uses > > > > > > > > > > the new jakarta-mail API rather than the old > > > > > javax.mail API? > > > > > > > > of course not. > > > > They just released 5.0.0, which use the new API, at just 4 days > ago... > > > I was not expecting a final version, just a snapshot, like the 2.0-RC6 > > > versions of jakarta- > > > mail currently on maven. Not quite sure what you mean by 5.0.0? > > > > > > > > > If not is one planned? > > > > > > > > No ideas. > > > > > > > > > > > > > > -- > Jean-Louis >
Re: [IO][LANG][POOL][OTHER]
Le jeu. 3 sept. 2020 à 17:01, Gary Gregory a écrit : > > On Thu, Sep 3, 2020 at 10:47 AM Gilles Sadowski > wrote: > > > Le jeu. 3 sept. 2020 à 14:49, Gary Gregory a > > écrit : > > > > > > Over on GH [1], Matt mentions retry APIs like retry4j which is a concept > > we > > > could reuse in Commons components like IO, Lang, Pool (and by extension > > > DBCP). > > > > > > While this might initially feel like a fit for Lang, I wonder what the > > > community thinks. > > > > > > > Of depending on that library? > > > > No, I said "a concept we could reuse", I did not say "a library we can > reuse". Too bad... :-P But still not clear IMHO. To ask that project's developers to bring their code into Commons, or to fork it? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Commons-email with jakarta.mail?
Hi, Jakarta Mail is under vote at the minute and should go out hopefully in a few days. https://www.eclipse.org/lists/jakarta.ee-spec/msg00788.html Some work has been done on the Apache Geronimo side of things recently. Not sure about the status though. Le jeu. 3 sept. 2020 à 17:52, Xeno Amess a écrit : > 5.0.0 means this : > https://github.com/eclipse-ee4j/servlet-api/releases/tag/5.0.0-RELEASE > And I believe that is the first release who introduced new namespaces for > jakarta. > And as you've already noticed, there even be no jakarta- > mail 2.0 release to use now. > I don't think it worthy to maintain a thread based on some rc > dependencies... > I'd rather take actions when they really release. > After all they (means jakarta-mail here) even do not have a clear roadmap > for the 2.0 release, as far as I know... > > David Goodenough 于2020年9月3日周四 下午11:17写道： > > > On Thursday, 3 September 2020 15:58:53 BST Xeno Amess wrote: > > > > Is there a version of commons-email which uses > > > > > > > > the new jakarta-mail API rather than the old > > > > javax.mail API? > > > > > > of course not. > > > They just released 5.0.0, which use the new API, at just 4 days ago... > > I was not expecting a final version, just a snapshot, like the 2.0-RC6 > > versions of jakarta- > > mail currently on maven. Not quite sure what you mean by 5.0.0? > > > > > > > If not is one planned? > > > > > > No ideas. > > > > > > > -- Jean-Louis
Re: Commons-email with jakarta.mail?
5.0.0 means this : https://github.com/eclipse-ee4j/servlet-api/releases/tag/5.0.0-RELEASE And I believe that is the first release who introduced new namespaces for jakarta. And as you've already noticed, there even be no jakarta- mail 2.0 release to use now. I don't think it worthy to maintain a thread based on some rc dependencies... I'd rather take actions when they really release. After all they (means jakarta-mail here) even do not have a clear roadmap for the 2.0 release, as far as I know... David Goodenough 于2020年9月3日周四 下午11:17写道： > On Thursday, 3 September 2020 15:58:53 BST Xeno Amess wrote: > > > Is there a version of commons-email which uses > > > > > > the new jakarta-mail API rather than the old > > > javax.mail API? > > > > of course not. > > They just released 5.0.0, which use the new API, at just 4 days ago... > I was not expecting a final version, just a snapshot, like the 2.0-RC6 > versions of jakarta- > mail currently on maven. Not quite sure what you mean by 5.0.0? > > > > > If not is one planned? > > > > No ideas. > > >
Re: [VOTE] Release Apache Commons Daemon 1.2.3 RC1
On 03/09/2020 15:37, Gary Gregory wrote: > On Thu, Sep 3, 2020 at 10:17 AM Mark Thomas wrote: > >> On 03/09/2020 14:06, Gary Gregory wrote: >>> Mark, >>> >>> The vote email must contain SHA256 or 512 hashes for the file bin and gz >>> files in https://dist.apache.org/repos/dist/dev/commons/daemon/ >>> >>> Per https://commons.apache.org/releases/prepare.html >>> >>> (There is no need to hash the files twice on >>> https://dist.apache.org/repos/dist/dev/commons/daemon/) >> >> See previous Commons Daemon release vote threads for why I won't be >> doing that. >> > > Based on the search: > > https://www.mail-archive.com/search?l=dev%40commons.apache.org=%5BVOTE%5D+Release+Apache+Commons+Daemon+=1 > > I see that the 1.1.0 RC provided SHA1's: > > https://www.mail-archive.com/dev@commons.apache.org/msg60676.html > > But I don't see 1.2.x VOTE threads so it must have happened with different > worlds in the subject. http://markmail.org/message/agt3f3etzdyt7qjv and http://commons.markmail.org/thread/6ivhavlovopqrt5z which expands on the topic of traceability. Mark > > Gary > > >> Mark >> >> >>> >>> Thank you, >>> Gary >>> >>> On Tue, Sep 1, 2020 at 2:25 PM Mark Thomas wrote: >>> Apologies for the slight delay between the tag and the vote. There was an issue with the code signing service we use to sign the Windows >> binaries. It has been almost a year since the last Commons Daemon release. Notable changes since 1.2.2 include: - Improved debug logging for error conditions - Added support for Java's Native Memory Tracing - Added a procrun command to output the current configuration The full set of changes is in the changelog 1.2.3 RC1 can be obtained from (r41271) https://dist.apache.org/repos/dist/dev/commons/daemon/ The git tag is: Tag: COMMONS_DAEMON_1_2_3_RC1 URL: >> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 Hash: f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 The Maven Staging repo is: >> https://repository.apache.org/content/repositories/orgapachecommons-1525/ The Windows binaries have been signed by the DigiCert (formerly Symantec) code signing service. Files signed with my preferred key: http://people.apache.org/~markt/ KEYS file is standard Apache Commons keys file: http://www.apache.org/dist/commons/KEYS [ ] Approved - go ahead and release Commons Daemon 1.2.3 RC1 as 1.2.3 [ ] Broken - do not release because... - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Commons-email with jakarta.mail?
On Thursday, 3 September 2020 15:58:53 BST Xeno Amess wrote: > > Is there a version of commons-email which uses > > > > the new jakarta-mail API rather than the old > > javax.mail API? > > of course not. > They just released 5.0.0, which use the new API, at just 4 days ago... I was not expecting a final version, just a snapshot, like the 2.0-RC6 versions of jakarta- mail currently on maven. Not quite sure what you mean by 5.0.0? > > > If not is one planned? > > No ideas.
Re: [IO][LANG][POOL][OTHER]
On Thu, Sep 3, 2020 at 10:47 AM Gilles Sadowski wrote: > Le jeu. 3 sept. 2020 à 14:49, Gary Gregory a > écrit : > > > > Over on GH [1], Matt mentions retry APIs like retry4j which is a concept > we > > could reuse in Commons components like IO, Lang, Pool (and by extension > > DBCP). > > > > While this might initially feel like a fit for Lang, I wonder what the > > community thinks. > > > > Of depending on that library? > No, I said "a concept we could reuse", I did not say "a library we can reuse". Gary > Gilles > > > Gary > > > > [1] https://github.com/apache/commons-io/pull/72 > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: Commons-email with jakarta.mail?
> Is there a version of commons-email which uses > the new jakarta-mail API rather than the old > javax.mail API? of course not. They just released 5.0.0, which use the new API, at just 4 days ago... > If not is one planned? No ideas.
Commons-email with jakarta.mail?
Is there a version of commons-email which uses the new jakarta-mail API rather than the old javax.mail API? If not is one planned?
Re: [IO][LANG][POOL][OTHER]
Le jeu. 3 sept. 2020 à 14:49, Gary Gregory a écrit : > > Over on GH [1], Matt mentions retry APIs like retry4j which is a concept we > could reuse in Commons components like IO, Lang, Pool (and by extension > DBCP). > > While this might initially feel like a fit for Lang, I wonder what the > community thinks. > Of depending on that library? Gilles > Gary > > [1] https://github.com/apache/commons-io/pull/72 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.3 RC1
On Thu, Sep 3, 2020 at 10:17 AM Mark Thomas wrote: > On 03/09/2020 14:06, Gary Gregory wrote: > > Mark, > > > > The vote email must contain SHA256 or 512 hashes for the file bin and gz > > files in https://dist.apache.org/repos/dist/dev/commons/daemon/ > > > > Per https://commons.apache.org/releases/prepare.html > > > > (There is no need to hash the files twice on > > https://dist.apache.org/repos/dist/dev/commons/daemon/) > > See previous Commons Daemon release vote threads for why I won't be > doing that. > Based on the search: https://www.mail-archive.com/search?l=dev%40commons.apache.org=%5BVOTE%5D+Release+Apache+Commons+Daemon+=1 I see that the 1.1.0 RC provided SHA1's: https://www.mail-archive.com/dev@commons.apache.org/msg60676.html But I don't see 1.2.x VOTE threads so it must have happened with different worlds in the subject. Gary > Mark > > > > > > Thank you, > > Gary > > > > On Tue, Sep 1, 2020 at 2:25 PM Mark Thomas wrote: > > > >> Apologies for the slight delay between the tag and the vote. There was > >> an issue with the code signing service we use to sign the Windows > binaries. > >> > >> It has been almost a year since the last Commons Daemon release. Notable > >> changes since 1.2.2 include: > >> - Improved debug logging for error conditions > >> - Added support for Java's Native Memory Tracing > >> - Added a procrun command to output the current configuration > >> > >> The full set of changes is in the changelog > >> > >> 1.2.3 RC1 can be obtained from (r41271) > >> https://dist.apache.org/repos/dist/dev/commons/daemon/ > >> > >> The git tag is: > >> Tag: COMMONS_DAEMON_1_2_3_RC1 > >> URL: > >> > >> > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > >> Hash: f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > >> > >> The Maven Staging repo is: > >> > https://repository.apache.org/content/repositories/orgapachecommons-1525/ > >> > >> The Windows binaries have been signed by the DigiCert (formerly > >> Symantec) code signing service. > >> > >> Files signed with my preferred key: > >> http://people.apache.org/~markt/ > >> KEYS file is standard Apache Commons keys file: > >> http://www.apache.org/dist/commons/KEYS > >> > >> > >> [ ] Approved - go ahead and release Commons Daemon 1.2.3 RC1 as 1.2.3 > >> [ ] Broken - do not release because... > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [VOTE] Release Apache Commons Daemon 1.2.3 RC1
On 03/09/2020 14:06, Gary Gregory wrote: > Mark, > > The vote email must contain SHA256 or 512 hashes for the file bin and gz > files in https://dist.apache.org/repos/dist/dev/commons/daemon/ > > Per https://commons.apache.org/releases/prepare.html > > (There is no need to hash the files twice on > https://dist.apache.org/repos/dist/dev/commons/daemon/) See previous Commons Daemon release vote threads for why I won't be doing that. Mark > > Thank you, > Gary > > On Tue, Sep 1, 2020 at 2:25 PM Mark Thomas wrote: > >> Apologies for the slight delay between the tag and the vote. There was >> an issue with the code signing service we use to sign the Windows binaries. >> >> It has been almost a year since the last Commons Daemon release. Notable >> changes since 1.2.2 include: >> - Improved debug logging for error conditions >> - Added support for Java's Native Memory Tracing >> - Added a procrun command to output the current configuration >> >> The full set of changes is in the changelog >> >> 1.2.3 RC1 can be obtained from (r41271) >> https://dist.apache.org/repos/dist/dev/commons/daemon/ >> >> The git tag is: >> Tag: COMMONS_DAEMON_1_2_3_RC1 >> URL: >> >> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 >> Hash: f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 >> >> The Maven Staging repo is: >> https://repository.apache.org/content/repositories/orgapachecommons-1525/ >> >> The Windows binaries have been signed by the DigiCert (formerly >> Symantec) code signing service. >> >> Files signed with my preferred key: >> http://people.apache.org/~markt/ >> KEYS file is standard Apache Commons keys file: >> http://www.apache.org/dist/commons/KEYS >> >> >> [ ] Approved - go ahead and release Commons Daemon 1.2.3 RC1 as 1.2.3 >> [ ] Broken - do not release because... >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Daemon 1.2.3 RC1
Mark, The vote email must contain SHA256 or 512 hashes for the file bin and gz files in https://dist.apache.org/repos/dist/dev/commons/daemon/ Per https://commons.apache.org/releases/prepare.html (There is no need to hash the files twice on https://dist.apache.org/repos/dist/dev/commons/daemon/) Thank you, Gary On Tue, Sep 1, 2020 at 2:25 PM Mark Thomas wrote: > Apologies for the slight delay between the tag and the vote. There was > an issue with the code signing service we use to sign the Windows binaries. > > It has been almost a year since the last Commons Daemon release. Notable > changes since 1.2.2 include: > - Improved debug logging for error conditions > - Added support for Java's Native Memory Tracing > - Added a procrun command to output the current configuration > > The full set of changes is in the changelog > > 1.2.3 RC1 can be obtained from (r41271) > https://dist.apache.org/repos/dist/dev/commons/daemon/ > > The git tag is: > Tag: COMMONS_DAEMON_1_2_3_RC1 > URL: > > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > Hash: f42d76aaa22df5f6bfa2f745ba2985bc47fe28d1 > > The Maven Staging repo is: > https://repository.apache.org/content/repositories/orgapachecommons-1525/ > > The Windows binaries have been signed by the DigiCert (formerly > Symantec) code signing service. > > Files signed with my preferred key: > http://people.apache.org/~markt/ > KEYS file is standard Apache Commons keys file: > http://www.apache.org/dist/commons/KEYS > > > [ ] Approved - go ahead and release Commons Daemon 1.2.3 RC1 as 1.2.3 > [ ] Broken - do not release because... > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [IO] release candidate soon
On Thu, 3 Sep 2020 at 13:07, Gilles Sadowski wrote: > > Le jeu. 3 sept. 2020 à 13:55, sebb a écrit : > > > > On Wed, 2 Sep 2020 at 20:54, Gary Gregory wrote: > > > > > > On Wed, Sep 2, 2020, 15:50 Xeno Amess wrote: > > > > > > > Why so hurry? > > > > > > > > > > I need to use new APIs now. Releases happen all the time, more releases > > > more often is better than big bang releases IMO, IOW RERO (Release Early, > > > Release Often). > > > > > > Is there any severe bug solved? > > > > > > > > > > See changes.xml, severity is relative to one's needs. > > > > > > > > > > And here goes another question. > > > > why is commons-io's group ID be commons-io but not com. apache. commons? > > > > > > > > > > Backward compatibility. We can change it if and when we break BC for 2.0. > > > > This is a bit old, but I think it still applies: > > > > https://cwiki.apache.org/confluence/display/COMMONS/MavenGroupIDChange > > Unfortunately, the crucial part (about whether a "relocation POM" would work) > is missing. > There wouldn't be any BC issue. *If* they worked as we would like. It could be a false hope. Last time I checked, it looked like a relocation POM was only checked if the Maven build attempted to access that particular version. However, I think relocation POMs can only be applied to the most recent version. That is inherently fragile. Since we have no proof that relocation POMs work, it is not safe to assume they can fix the issue. > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[IO][LANG][POOL][OTHER]
Over on GH [1], Matt mentions retry APIs like retry4j which is a concept we could reuse in Commons components like IO, Lang, Pool (and by extension DBCP). While this might initially feel like a fit for Lang, I wonder what the community thinks. Gary [1] https://github.com/apache/commons-io/pull/72
Re: [IO] release candidate soon
Le jeu. 3 sept. 2020 à 13:55, sebb a écrit : > > On Wed, 2 Sep 2020 at 20:54, Gary Gregory wrote: > > > > On Wed, Sep 2, 2020, 15:50 Xeno Amess wrote: > > > > > Why so hurry? > > > > > > > I need to use new APIs now. Releases happen all the time, more releases > > more often is better than big bang releases IMO, IOW RERO (Release Early, > > Release Often). > > > > Is there any severe bug solved? > > > > > > > See changes.xml, severity is relative to one's needs. > > > > > > > And here goes another question. > > > why is commons-io's group ID be commons-io but not com. apache. commons? > > > > > > > Backward compatibility. We can change it if and when we break BC for 2.0. > > This is a bit old, but I think it still applies: > > https://cwiki.apache.org/confluence/display/COMMONS/MavenGroupIDChange Unfortunately, the crucial part (about whether a "relocation POM" would work) is missing. There wouldn't be any BC issue. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] release candidate soon
On Wed, 2 Sep 2020 at 20:54, Gary Gregory wrote: > > On Wed, Sep 2, 2020, 15:50 Xeno Amess wrote: > > > Why so hurry? > > > > I need to use new APIs now. Releases happen all the time, more releases > more often is better than big bang releases IMO, IOW RERO (Release Early, > Release Often). > > Is there any severe bug solved? > > > > See changes.xml, severity is relative to one's needs. > > > > And here goes another question. > > why is commons-io's group ID be commons-io but not com. apache. commons? > > > > Backward compatibility. We can change it if and when we break BC for 2.0. This is a bit old, but I think it still applies: https://cwiki.apache.org/confluence/display/COMMONS/MavenGroupIDChange > Gary > > > > > > > Gary Gregory 于 2020年9月3日周四 上午1:57写道： > > > > > Hi all, > > > > > > I plan on cutting a release candidate very soon, probably tonight. > > > > > > Gary > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Apache Commons Codec 1.15 Released
Thanks very much for getting the release out :-) On Tue, 1 Sep 2020 at 16:52, Alex Herbert wrote: > > The Apache Commons Team is pleased to announce the availability of > version 1.15 of "Apache Commons Codec". > > The Apache Commons Codec package contains simple encoders and > decoders for various formats such as Base64 and Hexadecimal. In > addition to these widely used encoders and decoders, the codec > package also maintains a collection of phonetic encoding utilities. > > Changes in this version include: > > New features: > o CODEC-290: Base16Codec and Base16Input/OutputStream. > Thanks to Adam Retter. > o CODEC-291: Hex encode/decode with existing arrays. > Thanks to Adam Retter. > > Fixed Bugs: > o CODEC-264: MurmurHash3: Ensure hash128 maintains the sign extension > bug. Thanks to Andy Seaborne. > > Changes: > o CODEC-280: Base32/Base64/BCodec: Added strict decoding property to > control handling of trailing bits. Default lenient mode > discards them without error. Strict mode raise an > exception. > o CODEC-289: Base32/Base64 Input/OutputStream: Added strict decoding > property to control handling of trailing bits. Default > lenient mode discards them without error. Strict mode > raise an exception. > > > Historical list of changes: > https://commons.apache.org/proper/commons-codec/changes-report.html > > For complete information on Commons Codec, including instructions on > how to submit bug reports, patches, or suggestions for improvement, > see the Apache Commons Codec website: > https://commons.apache.org/proper/commons-codec/ > > Distribution packages can be downloaded from the following page: > https://commons.apache.org/proper/commons-codec/download_codec.cgi > > When downloading, please verify signatures using the KEYS file > available at > https://www.apache.org/dist/commons/KEYS > > Maven artifacts are also available in the central Maven repository: > https://repo.maven.apache.org/maven2/commons-codec/commons-codec > > commons-codec > commons-codec > 1.15 > > Alex Herbert, > On behalf of the Apache Commons Team -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp][pool] Use abort instead of close for abandoned connections?
On 31/08/2020 01:05, Phil Steitz wrote: > If others agree it is a good idea for dbcp, I can do it. I can see the > argument that its better to stay with close() even for abandoned and I > have not been able to get the deadlock to happen, so I would like to > wait a bit and allow others to weigh in. Similarly for pool, I would > like to get more community feedback before adding to the interface. Hmm. On one hand if the driver deadlocks I don't see how that can be anything other than a driver bug. If multiple code paths obtain multiple locks then those code paths must always obtain those locks in the same order. Anything else is a bug that is likely to result in a deadlock in a multithreaded environment. On the other hand, it could be argued that the situation only arises when an application doesn't correctly return connections to the pool and/or keeps them for too long and/or doesn't configure the pool correctly for their usage pattern. The approach of adding PooledObjectFactory.destroyObject(PooledObject,CloseMode) where CloseMode is an Enum with two values looks reasonable to me. I do agree that abort() should only be used in the case of abandoned connections. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
