April 2018 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-654) Documentation: move outside of the main repository

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-654: ----------------------------------------- Summary: Documentation: move outside of the main repository Key: MODCLUSTER-654 URL: https://issues.jboss.org/browse/MODCLUSTER-654 Project: mod_cluster Issue Type: Task Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-652) Documentation 2.0: living docs

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-652?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-652: -------------------------------------- Summary: Documentation 2.0: living docs (was: Documentation 2.0) > Documentation 2.0: living docs > ------------------------------ > > Key: MODCLUSTER-652 > URL: https://issues.jboss.org/browse/MODCLUSTER-652 > Project: mod_cluster > Issue Type: Bug > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Update of the original effort for choosing documentation platform [1]. > Problem: > * Documentation is out of date because its painful to edit. > * Too many obstacles to contribute to documentation (difficult format, unclear where, need accounts, doesn't render immediately) > Additional/updated requirements: > * standardized on AsciiDocs > * readers/users are provided with a link to update the documentation on github, submit PR, merge > * automatically built and automatically deployed -- live within 1-2 minutes > [1] https://developer.jboss.org/wiki/ChoosingDocumentationPlatformForModcluster -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-499) tarballs or git submodules for: openssl, httpd and apr in mod_proxy_cluster repo

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-499?page=com.atlassian.jira.pl... ] Michal Karm Babacek closed MODCLUSTER-499. ------------------------------------------ > tarballs or git submodules for: openssl, httpd and apr in mod_proxy_cluster repo > -------------------------------------------------------------------------------- > > Key: MODCLUSTER-499 > URL: https://issues.jboss.org/browse/MODCLUSTER-499 > Project: mod_cluster > Issue Type: Enhancement > Components: Native (httpd modules) > Affects Versions: 2.0.0.Alpha1 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > > h3. Task at hand > * we are gradually getting rid of [the old build system|http://anonsvn.jboss.org/repos/jbossnative/trunk/], moving towards CMake > * we don't want any auxiliary "util" or "helper" scripts hanging around, we want a pure CMake driven project > * mod_proxy_cluster depends on: > ** httpd > *** apr > *** apr-util > *** openssl > *** pcre > *** iconv > * we need to build these from sources > h3. Solutions > h4. Parent CMakeLists downloads tarballs > * we keep openssl and httpd CMakeLists files in the directory structure > * parent CMakeLists downlaods tarballs before children resolution > h4. We use git submodules > * we add the dependencies as git submodules > * parent CMakeLists does not downlaod anything, it merely checkouts into the desired versions of our dependencies > * we need to keep our:{noformat}mod_proxy_cluster/openssl/CMakeLists{noformat}, {noformat}mod_proxy_cluster/openssl/crypto/CMakeLists{noformat} etc. *and* submodules; perhaps needs something like {{openssl_build}} (our CMakeLists files) and {{openssl}} (git submodule) directories and {{mod_proxy_cluster/CMakeLists}} taking care of copying prior to children resolution > Gonna prototype and see what works the best. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-595) https://ci.modcluster.io windows httpd binaries depend on Debug vcruntime140d.dll

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-595?page=com.atlassian.jira.pl... ] Michal Karm Babacek resolved MODCLUSTER-595. -------------------------------------------- Resolution: Done Current builds are O.K. https://ci.modcluster.io/job/mod_proxy_cluster-2.x-windows/ > https://ci.modcluster.io windows httpd binaries depend on Debug vcruntime140d.dll > --------------------------------------------------------------------------------- > > Key: MODCLUSTER-595 > URL: https://issues.jboss.org/browse/MODCLUSTER-595 > Project: mod_cluster > Issue Type: Bug > Components: CI & Packaging > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > > Both httpd-2.4.25-win.\*.zip and httpd-2.4.25-win.*-devel.zip distributions depend on Debug Visual Studio runtime dll that is packaged in these zips. We should rewire the linking so as the production zip could be smaller, without vcruntime140d.dll and without ucrtbased.dll, just with vc_redist installer. Devel zip can contain these, doesn't matter there. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-499) tarballs or git submodules for: openssl, httpd and apr in mod_proxy_cluster repo

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-499?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-499 started by Michal Karm Babacek. ------------------------------------------------------ > tarballs or git submodules for: openssl, httpd and apr in mod_proxy_cluster repo > -------------------------------------------------------------------------------- > > Key: MODCLUSTER-499 > URL: https://issues.jboss.org/browse/MODCLUSTER-499 > Project: mod_cluster > Issue Type: Enhancement > Components: Native (httpd modules) > Affects Versions: 2.0.0.Alpha1 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > > h3. Task at hand > * we are gradually getting rid of [the old build system|http://anonsvn.jboss.org/repos/jbossnative/trunk/], moving towards CMake > * we don't want any auxiliary "util" or "helper" scripts hanging around, we want a pure CMake driven project > * mod_proxy_cluster depends on: > ** httpd > *** apr > *** apr-util > *** openssl > *** pcre > *** iconv > * we need to build these from sources > h3. Solutions > h4. Parent CMakeLists downloads tarballs > * we keep openssl and httpd CMakeLists files in the directory structure > * parent CMakeLists downlaods tarballs before children resolution > h4. We use git submodules > * we add the dependencies as git submodules > * parent CMakeLists does not downlaod anything, it merely checkouts into the desired versions of our dependencies > * we need to keep our:{noformat}mod_proxy_cluster/openssl/CMakeLists{noformat}, {noformat}mod_proxy_cluster/openssl/crypto/CMakeLists{noformat} etc. *and* submodules; perhaps needs something like {{openssl_build}} (our CMakeLists files) and {{openssl}} (git submodule) directories and {{mod_proxy_cluster/CMakeLists}} taking care of copying prior to children resolution > Gonna prototype and see what works the best. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-499) tarballs or git submodules for: openssl, httpd and apr in mod_proxy_cluster repo

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-499?page=com.atlassian.jira.pl... ] Michal Karm Babacek resolved MODCLUSTER-499. -------------------------------------------- Resolution: Done Done. https://ci.modcluster.io/job/mod_proxy_cluster-2.x-windows/ https://github.com/modcluster/ci.modcluster.io/tree/master/windows > tarballs or git submodules for: openssl, httpd and apr in mod_proxy_cluster repo > -------------------------------------------------------------------------------- > > Key: MODCLUSTER-499 > URL: https://issues.jboss.org/browse/MODCLUSTER-499 > Project: mod_cluster > Issue Type: Enhancement > Components: Native (httpd modules) > Affects Versions: 2.0.0.Alpha1 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > > h3. Task at hand > * we are gradually getting rid of [the old build system|http://anonsvn.jboss.org/repos/jbossnative/trunk/], moving towards CMake > * we don't want any auxiliary "util" or "helper" scripts hanging around, we want a pure CMake driven project > * mod_proxy_cluster depends on: > ** httpd > *** apr > *** apr-util > *** openssl > *** pcre > *** iconv > * we need to build these from sources > h3. Solutions > h4. Parent CMakeLists downloads tarballs > * we keep openssl and httpd CMakeLists files in the directory structure > * parent CMakeLists downlaods tarballs before children resolution > h4. We use git submodules > * we add the dependencies as git submodules > * parent CMakeLists does not downlaod anything, it merely checkouts into the desired versions of our dependencies > * we need to keep our:{noformat}mod_proxy_cluster/openssl/CMakeLists{noformat}, {noformat}mod_proxy_cluster/openssl/crypto/CMakeLists{noformat} etc. *and* submodules; perhaps needs something like {{openssl_build}} (our CMakeLists files) and {{openssl}} (git submodule) directories and {{mod_proxy_cluster/CMakeLists}} taking care of copying prior to children resolution > Gonna prototype and see what works the best. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-595) https://ci.modcluster.io windows httpd binaries depend on Debug vcruntime140d.dll

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-595?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-595 started by Michal Karm Babacek. ------------------------------------------------------ > https://ci.modcluster.io windows httpd binaries depend on Debug vcruntime140d.dll > --------------------------------------------------------------------------------- > > Key: MODCLUSTER-595 > URL: https://issues.jboss.org/browse/MODCLUSTER-595 > Project: mod_cluster > Issue Type: Bug > Components: CI & Packaging > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > > Both httpd-2.4.25-win.\*.zip and httpd-2.4.25-win.*-devel.zip distributions depend on Debug Visual Studio runtime dll that is packaged in these zips. We should rewire the linking so as the production zip could be smaller, without vcruntime140d.dll and without ucrtbased.dll, just with vc_redist installer. Devel zip can contain these, doesn't matter there. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-653) mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-653?page=com.atlassian.jira.pl... ] Masafumi Miura updated MODCLUSTER-653: -------------------------------------- Description: mod_cluster {{DefaultMCMPHandler#sendRequest()}} does not close a connection when Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}" response header. (As {{KeepAlive Off}} is set by default, Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}".) Therefore, CLOSE_WAIT connection remains every MCMP STATUS command. This CLOSE_WAIT connection will be cleaned when trying to send the next MCMP STATUS request, so there's no functional impact. And this is not a critical issue as neither connection leak nor file descriptor leak happens. However, it's better that mod_cluster handles the "{{Connection: close}}" response header and close a connection. was: mod_cluster {{DefaultMCMPHandler#sendRequest()}} does not close a connection when Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}" response header. (As {{KeepAlive Off}} is set by default, Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}".) Therefore, CLOSE_WAIT connection remains every MCMP STATUS command. This CLOSE_WAIT connection will be cleaned when trying to send the next MCMP STATUS request, so this is not a critical issue as neither connection leak nor file descriptor leak happens. However, it's better that mod_cluster handles the "{{Connection: close}}" response header and close a connection. > mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection > ------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-653 > URL: https://issues.jboss.org/browse/MODCLUSTER-653 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.7.Final > Reporter: Masafumi Miura > Assignee: Radoslav Husar > > mod_cluster {{DefaultMCMPHandler#sendRequest()}} does not close a connection when Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}" response header. (As {{KeepAlive Off}} is set by default, Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}".) Therefore, CLOSE_WAIT connection remains every MCMP STATUS command. > This CLOSE_WAIT connection will be cleaned when trying to send the next MCMP STATUS request, so there's no functional impact. And this is not a critical issue as neither connection leak nor file descriptor leak happens. However, it's better that mod_cluster handles the "{{Connection: close}}" response header and close a connection. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-653) mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-653?page=com.atlassian.jira.pl... ] Masafumi Miura commented on MODCLUSTER-653: ------------------------------------------- A possible proposed fix: https://github.com/modcluster/mod_cluster/compare/1.3.x...msfm:1.3.x_MODC... > mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection > ------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-653 > URL: https://issues.jboss.org/browse/MODCLUSTER-653 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.7.Final > Reporter: Masafumi Miura > Assignee: Radoslav Husar > > mod_cluster {{DefaultMCMPHandler#sendRequest()}} does not close a connection when Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}" response header. (As {{KeepAlive Off}} is set by default, Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}".) Therefore, CLOSE_WAIT connection remains every MCMP STATUS command. > This CLOSE_WAIT connection will be cleaned when trying to send the next MCMP STATUS request, so this is not a critical issue as neither connection leak nor file descriptor leak happens. However, it's better that mod_cluster handles the "{{Connection: close}}" response header and close a connection. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-653) mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-653?page=com.atlassian.jira.pl... ] Masafumi Miura moved JBEAP-14531 to MODCLUSTER-653: --------------------------------------------------- Project: mod_cluster (was: JBoss Enterprise Application Platform) Key: MODCLUSTER-653 (was: JBEAP-14531) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Core & Container Integration (Java) (was: mod_cluster) Affects Version/s: 1.3.7.Final (was: 7.1.1.GA) > mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection > ------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-653 > URL: https://issues.jboss.org/browse/MODCLUSTER-653 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.7.Final > Reporter: Masafumi Miura > Assignee: Radoslav Husar > > mod_cluster {{DefaultMCMPHandler#sendRequest()}} does not close a connection when Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}" response header. (As {{KeepAlive Off}} is set by default, Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}".) Therefore, CLOSE_WAIT connection remains every MCMP STATUS command. > This CLOSE_WAIT connection will be cleaned when trying to send the next MCMP STATUS request, so this is not a critical issue as neither connection leak nor file descriptor leak happens. However, it's better that mod_cluster handles the "{{Connection: close}}" response header and close a connection. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues April 2018