Re: HttpCore / HttpClient development proposal
On 2023/08/11 17:11:46 Oleg Kalnichevski wrote: > On Fri, 2023-08-11 at 17:08 +0200, Michael Osipov wrote: > > Am 2023-08-10 um 20:08 schrieb Oleg Kalnichevski: > > > Folks > > > > > > I would like to propose the following course of action. Please let > > > me > > > know what think. > > > > > > Features in scope for HttpClient 5.4 > > > -- > > > > > > * RFC 9110 conformance > > > * RFC 9111 conformance > > > * Refctoring of synchronized sections to use lock primitives > > > > Why in 5.4? 5.3 is in alpha stage, those refactorings can easily go > > into > > 5.3, no? > > > > And than what? This will likely delay the 5.3 release by a year or so. > No feature release for another year. No Bearer authentication for > another year, no NTLM deprecation for another year. Does this make > sense? I see, you are right. Let's go ahead with your proposal. - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: HttpCore / HttpClient development proposal
On Fri, 2023-08-11 at 17:08 +0200, Michael Osipov wrote: > Am 2023-08-10 um 20:08 schrieb Oleg Kalnichevski: > > Folks > > > > I would like to propose the following course of action. Please let > > me > > know what think. > > > > Features in scope for HttpClient 5.4 > > -- > > > > * RFC 9110 conformance > > * RFC 9111 conformance > > * Refctoring of synchronized sections to use lock primitives > > Why in 5.4? 5.3 is in alpha stage, those refactorings can easily go > into > 5.3, no? > And than what? This will likely delay the 5.3 release by a year or so. No feature release for another year. No Bearer authentication for another year, no NTLM deprecation for another year. Does this make sense? > We should not maintain more than 1+2 (4.x and 5.x) branches at the > same > time. > This is going to be a merely another development branch with a version in its name. We are not going to start cutting releases from it until 5.3 goes GA. If you do not like the 5.4.x name, we can call the branch far-far-in-the-future or some such. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Comment Edited] (HTTPCORE-746) Deadlock with Java Virtual Threads
[ https://issues.apache.org/jira/browse/HTTPCORE-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753286#comment-17753286 ] Arturo Bernal edited comment on HTTPCORE-746 at 8/11/23 5:09 PM: - Merge in [5.3|https://github.com/apache/httpcomponents-core/tree/5.3.x] Please [~marsqing] check [https://github.com/apache/httpcomponents-core/pull/412] was (Author: abernal): Merge in 5.3 Please [~marsqing] check [https://github.com/apache/httpcomponents-core/pull/412] > Deadlock with Java Virtual Threads > -- > > Key: HTTPCORE-746 > URL: https://issues.apache.org/jira/browse/HTTPCORE-746 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore >Affects Versions: 4.4.16 > Environment: openjdk version "20.0.1" 2023-04-18 > archlinux >Reporter: marsqing >Priority: Minor > Labels: volunteers-wanted > Fix For: Stuck > > Attachments: LoomWithApacheHttpClientTest.java > > Time Spent: 2.5h > Remaining Estimate: 0h > > [Virtual Threads|https://openjdk.org/jeps/444] is expected to be released in > JDK21 soon. Contrast to traditional 'platform threads', virtual threads will > usually unmount from platform threads when doing blocking operations. But > accoring to the doc above, when doing blocking operations in synchronized > block/method, the carrying platform thread will be pinned and can not carry > other virtual threads. > > This limitation will make the sample in the attachment deadlocked. Because > all the platform threads add pinned in > [await|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#LL391C30-L391C30] > because it is in a [synchronized > block|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#L244] > and no connection is available in the pool. The only virtual thread which > can release the connection to the pool is waiting for some platform threads > to carry it. That is the platform thread is waiting for a connection while > the connection is waiting the platform thread to carry its virtual thread and > return the connection. Thus a deadlock. > > If we replace the synchronized above with a ReentrantLock, no thead will be > pinned and no deadlock will occur. Accoring to the doc above, the limitation > may be removed in future JDK versions. But before that, we may need to > replace synchronized with some locks. Do we have any related plan? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-746) Deadlock with Java Virtual Threads
[ https://issues.apache.org/jira/browse/HTTPCORE-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753286#comment-17753286 ] Arturo Bernal commented on HTTPCORE-746: Merge in 5.3 Please [~marsqing] check [https://github.com/apache/httpcomponents-core/pull/412] > Deadlock with Java Virtual Threads > -- > > Key: HTTPCORE-746 > URL: https://issues.apache.org/jira/browse/HTTPCORE-746 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore >Affects Versions: 4.4.16 > Environment: openjdk version "20.0.1" 2023-04-18 > archlinux >Reporter: marsqing >Priority: Minor > Labels: volunteers-wanted > Fix For: Stuck > > Attachments: LoomWithApacheHttpClientTest.java > > Time Spent: 2.5h > Remaining Estimate: 0h > > [Virtual Threads|https://openjdk.org/jeps/444] is expected to be released in > JDK21 soon. Contrast to traditional 'platform threads', virtual threads will > usually unmount from platform threads when doing blocking operations. But > accoring to the doc above, when doing blocking operations in synchronized > block/method, the carrying platform thread will be pinned and can not carry > other virtual threads. > > This limitation will make the sample in the attachment deadlocked. Because > all the platform threads add pinned in > [await|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#LL391C30-L391C30] > because it is in a [synchronized > block|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#L244] > and no connection is available in the pool. The only virtual thread which > can release the connection to the pool is waiting for some platform threads > to carry it. That is the platform thread is waiting for a connection while > the connection is waiting the platform thread to carry its virtual thread and > return the connection. Thus a deadlock. > > If we replace the synchronized above with a ReentrantLock, no thead will be > pinned and no deadlock will occur. Accoring to the doc above, the limitation > may be removed in future JDK versions. But before that, we may need to > replace synchronized with some locks. Do we have any related plan? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Resolved] (HTTPCORE-746) Deadlock with Java Virtual Threads
[ https://issues.apache.org/jira/browse/HTTPCORE-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal resolved HTTPCORE-746. Resolution: Fixed > Deadlock with Java Virtual Threads > -- > > Key: HTTPCORE-746 > URL: https://issues.apache.org/jira/browse/HTTPCORE-746 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore >Affects Versions: 4.4.16 > Environment: openjdk version "20.0.1" 2023-04-18 > archlinux >Reporter: marsqing >Priority: Minor > Labels: volunteers-wanted > Fix For: Stuck > > Attachments: LoomWithApacheHttpClientTest.java > > Time Spent: 2.5h > Remaining Estimate: 0h > > [Virtual Threads|https://openjdk.org/jeps/444] is expected to be released in > JDK21 soon. Contrast to traditional 'platform threads', virtual threads will > usually unmount from platform threads when doing blocking operations. But > accoring to the doc above, when doing blocking operations in synchronized > block/method, the carrying platform thread will be pinned and can not carry > other virtual threads. > > This limitation will make the sample in the attachment deadlocked. Because > all the platform threads add pinned in > [await|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#LL391C30-L391C30] > because it is in a [synchronized > block|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#L244] > and no connection is available in the pool. The only virtual thread which > can release the connection to the pool is waiting for some platform threads > to carry it. That is the platform thread is waiting for a connection while > the connection is waiting the platform thread to carry its virtual thread and > return the connection. Thus a deadlock. > > If we replace the synchronized above with a ReentrantLock, no thead will be > pinned and no deadlock will occur. Accoring to the doc above, the limitation > may be removed in future JDK versions. But before that, we may need to > replace synchronized with some locks. Do we have any related plan? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCLIENT-2290) Refactoring of synchronized sections to use lock primitives in light of virtual threads
Arturo Bernal created HTTPCLIENT-2290:
-
Summary: Refactoring of synchronized sections to use lock
primitives in light of virtual threads
Key: HTTPCLIENT-2290
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2290
Project: HttpComponents HttpClient
Issue Type: Improvement
Reporter: Arturo Bernal
With the upcoming inclusion of virtual threads in JDK 21, we need to review and
refactor sections of the HttpClient codebase that use the {{synchronized}}
keyword.
As virtual threads might introduce performance and deadlock issues with the
current {{synchronized}} sections, we'll move towards using explicit lock
primitives provided by the {{java.util.concurrent.locks}} package, such as
{{{}ReentrantLock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] arturobernalg merged pull request #412: HTTPCORE-746 - Refactor Synchronized Blocks to Use ReentrantLock.
arturobernalg merged PR #412: URL: https://github.com/apache/httpcomponents-core/pull/412 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: HttpCore / HttpClient development proposal
Yeah, I still have legacy 4.x code I need to port! Gary On Fri, Aug 11, 2023, 11:21 AM Michael Osipov wrote: > Am 2023-08-11 um 17:16 schrieb Gary Gregory: > > For my money, 4.x is no longer maintained, perhaps only for emergency > > security fixes. > > so be it, I also meant those. But two branches in 5.x is more than enough. > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: HttpCore / HttpClient development proposal
Am 2023-08-11 um 17:16 schrieb Gary Gregory: For my money, 4.x is no longer maintained, perhaps only for emergency security fixes. so be it, I also meant those. But two branches in 5.x is more than enough. - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: HttpCore / HttpClient development proposal
For my money, 4.x is no longer maintained, perhaps only for emergency security fixes. Gary On Fri, Aug 11, 2023, 11:08 AM Michael Osipov wrote: > Am 2023-08-10 um 20:08 schrieb Oleg Kalnichevski: > > Folks > > > > I would like to propose the following course of action. Please let me > > know what think. > > > > Features in scope for HttpClient 5.4 > > -- > > > > * RFC 9110 conformance > > * RFC 9111 conformance > > * Refctoring of synchronized sections to use lock primitives > > Why in 5.4? 5.3 is in alpha stage, those refactorings can easily go into > 5.3, no? > > We should not maintain more than 1+2 (4.x and 5.x) branches at the same > time. > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: HttpCore / HttpClient development proposal
Am 2023-08-10 um 20:08 schrieb Oleg Kalnichevski: Folks I would like to propose the following course of action. Please let me know what think. Features in scope for HttpClient 5.4 -- * RFC 9110 conformance * RFC 9111 conformance * Refctoring of synchronized sections to use lock primitives Why in 5.4? 5.3 is in alpha stage, those refactorings can easily go into 5.3, no? We should not maintain more than 1+2 (4.x and 5.x) branches at the same time. - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] garydgregory commented on pull request #412: HTTPCORE-746 - Refactor Synchronized Blocks to Use ReentrantLock.
garydgregory commented on PR #412: URL: https://github.com/apache/httpcomponents-core/pull/412#issuecomment-1674618499 Ok, sounds good. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[GitHub] [httpcomponents-core] ok2c commented on pull request #412: HTTPCORE-746 - Refactor Synchronized Blocks to Use ReentrantLock.
ok2c commented on PR #412: URL: https://github.com/apache/httpcomponents-core/pull/412#issuecomment-1674557972 @arturobernalg Please go ahead and merge this PR. @garydgregory I hope your concerns have been addressed by extending the 5.3 development cycle. It should give us ample of time to test out the changes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
