May 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-501) mod_proxy_cluster crash when using BalancerMember

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-501?page=com.atlassian.jira.pl... ] Michal Karm Babacek commented on MODCLUSTER-501: ------------------------------------------------ [~paololutterotti], could you attach the actual config you used in your Apache HTTP Server? (sanitized from sensitive hostnames and IP addresses) It seems your attached log mixes httpd 2.2/2.4 configs, unless I'm looking at a wrong file. I've failed to reproduce it so far. It would hep if you elaborate on what you've actually wanted to do. Do you want to use mod_proxy_cluster automatic, dynamic configuration for your Tomcat webapps and ProxyPass mod_proxy BalancerMember config for your PHP Drupal servers...? Thanks for info. Help me help you :) > mod_proxy_cluster crash when using BalancerMember > ------------------------------------------------- > > Key: MODCLUSTER-501 > URL: https://issues.jboss.org/browse/MODCLUSTER-501 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final > Environment: o.s.:: CentOS Linux release 7.2.1511 > httpd 2.4.6 > mod cluster 1.3.1 final > Reporter: Paolo Lutterotti > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final > > Attachments: vhost.conf > > > Hello, > I'm experiencing an issue very similar to https://issues.jboss.org/browse/MODCLUSTER-356 > When I try to use a BalancerMember directive, I get a segmentation fault, caused at line https://github.com/modcluster/mod_cluster/blob/1.3.1.Final/native/mod_pro... > I tried to remove directives from the virtual host, but the issue persists until there is at least one ProxyPass using a balancer defined with BalancerMember. I attach a .conf file where I put all of the configurations involved in the issue and which is causing the crash. > If I put a check at line 2223, there are no more segmentations, but a 503 caused by mod_proxy_cluster.c(2332): proxy: byrequests balancer FAILED > Thanks, > Paolo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-501) mod_proxy_cluster crash when using BalancerMember

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-501?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-501 stopped by Michal Karm Babacek. ------------------------------------------------------ > mod_proxy_cluster crash when using BalancerMember > ------------------------------------------------- > > Key: MODCLUSTER-501 > URL: https://issues.jboss.org/browse/MODCLUSTER-501 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final > Environment: o.s.:: CentOS Linux release 7.2.1511 > httpd 2.4.6 > mod cluster 1.3.1 final > Reporter: Paolo Lutterotti > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final > > Attachments: vhost.conf > > > Hello, > I'm experiencing an issue very similar to https://issues.jboss.org/browse/MODCLUSTER-356 > When I try to use a BalancerMember directive, I get a segmentation fault, caused at line https://github.com/modcluster/mod_cluster/blob/1.3.1.Final/native/mod_pro... > I tried to remove directives from the virtual host, but the issue persists until there is at least one ProxyPass using a balancer defined with BalancerMember. I attach a .conf file where I put all of the configurations involved in the issue and which is causing the crash. > If I put a check at line 2223, there are no more segmentations, but a 503 caused by mod_proxy_cluster.c(2332): proxy: byrequests balancer FAILED > Thanks, > Paolo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-458) Add JVMRoute or node identifier to httpd/mod_cluster errors

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-458?page=com.atlassian.jira.pl... ] Michal Karm Babacek closed MODCLUSTER-458. ------------------------------------------ Resolution: Done > Add JVMRoute or node identifier to httpd/mod_cluster errors > ----------------------------------------------------------- > > Key: MODCLUSTER-458 > URL: https://issues.jboss.org/browse/MODCLUSTER-458 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Coty Sutherland > Assignee: Michal Karm Babacek > Fix For: 1.2.12.Final, 1.3.2.Final > > > Messages such as: > [Tue Apr 14 10:38:56 2015] [warn] manager_handler STATUS error: MEM: Can't read node > are very difficult to troubleshoot given the limited context provided. It would be great if we could add some sort of node identifier or the JVMRoute of the node to the message above. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-458) Add JVMRoute or node identifier to httpd/mod_cluster errors

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-458?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-458: ------------------------------------------- Issue Type: Bug (was: Feature Request) > Add JVMRoute or node identifier to httpd/mod_cluster errors > ----------------------------------------------------------- > > Key: MODCLUSTER-458 > URL: https://issues.jboss.org/browse/MODCLUSTER-458 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Coty Sutherland > Assignee: Michal Karm Babacek > Fix For: 1.3.2.Final, 1.2.12.Final > > > Messages such as: > [Tue Apr 14 10:38:56 2015] [warn] manager_handler STATUS error: MEM: Can't read node > are very difficult to troubleshoot given the limited context provided. It would be great if we could add some sort of node identifier or the JVMRoute of the node to the message above. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-458) Add JVMRoute or node identifier to httpd/mod_cluster errors

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-458?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-458: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1258396, https://bugzilla.redhat.com/show_bug.cgi?id=1338644 > Add JVMRoute or node identifier to httpd/mod_cluster errors > ----------------------------------------------------------- > > Key: MODCLUSTER-458 > URL: https://issues.jboss.org/browse/MODCLUSTER-458 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Coty Sutherland > Assignee: Michal Karm Babacek > Fix For: 1.3.2.Final, 1.2.12.Final > > > Messages such as: > [Tue Apr 14 10:38:56 2015] [warn] manager_handler STATUS error: MEM: Can't read node > are very difficult to troubleshoot given the limited context provided. It would be great if we could add some sort of node identifier or the JVMRoute of the node to the message above. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-458) Add JVMRoute or node identifier to httpd/mod_cluster errors

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-458?page=com.atlassian.jira.pl... ] Michal Karm Babacek reopened MODCLUSTER-458: -------------------------------------------- > Add JVMRoute or node identifier to httpd/mod_cluster errors > ----------------------------------------------------------- > > Key: MODCLUSTER-458 > URL: https://issues.jboss.org/browse/MODCLUSTER-458 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Reporter: Coty Sutherland > Assignee: Michal Karm Babacek > Fix For: 1.3.2.Final, 1.2.12.Final > > > Messages such as: > [Tue Apr 14 10:38:56 2015] [warn] manager_handler STATUS error: MEM: Can't read node > are very difficult to troubleshoot given the limited context provided. It would be great if we could add some sort of node identifier or the JVMRoute of the node to the message above. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-250) bad interaction with ProxyPassReverse when redirection.

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-250?page=com.atlassian.jira.pl... ] Michal Karm Babacek reassigned MODCLUSTER-250: ---------------------------------------------- Assignee: Michal Karm Babacek (was: Jean-Frederic Clere) > bad interaction with ProxyPassReverse when redirection. > ------------------------------------------------------- > > Key: MODCLUSTER-250 > URL: https://issues.jboss.org/browse/MODCLUSTER-250 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.1.3.Final > Environment: Mixing ProxyPass/ProxyPassReverse and mod_cluster > Reporter: Jean-Frederic Clere > Assignee: Michal Karm Babacek > Priority: Minor > Fix For: 1.1.4.Final > > > Using: > ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On > ProxyPassReverse / balancer://mycluster/ > or > ProxyPass / balancer://mycluster stickysession=JSESSIONID|jsessionid nofailover=On > ProxyPassReverse / balancer://mycluster > (note that this one won't work with mod_proxy_balancer). > You get stuff like: > curl -v http://jfcpc:8000/myapp > +++ > < HTTP/1.1 302 Moved Temporarily > < Date: Thu, 25 Aug 2011 09:40:17 GMT > < Server: Apache-Coyote/1.1 > < Location: http://jfcpc:8000//myapp/ > < Content-Length: 0 > < Content-Type: text/plain > +++ > Or > curl -v http://jfcpc:8000/myapp/TestRedirect?location=/toto.html > +++ > < HTTP/1.1 302 Moved Temporarily > < Date: Thu, 25 Aug 2011 09:42:59 GMT > < Server: Apache-Coyote/1.1 > < Location: http://jfcpc:8000//toto.html;jsessionid=OYeoix8WaRh6VEtlSrfzIS7Q.498bb1f0... > < Content-Length: 0 > < Set-Cookie: JSESSIONID=OYeoix8WaRh6VEtlSrfzIS7Q.498bb1f0-00d9-3436-a341-7f012bc2e7ec; Path=/myapp > < Content-Type: text/plain > +++ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-250) bad interaction with ProxyPassReverse when redirection.

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-250?page=com.atlassian.jira.pl... ] Michal Karm Babacek commented on MODCLUSTER-250: ------------------------------------------------ Assigning to myself to investigate and presumably close -- it's supposed to be cool on recent httpd releases. > bad interaction with ProxyPassReverse when redirection. > ------------------------------------------------------- > > Key: MODCLUSTER-250 > URL: https://issues.jboss.org/browse/MODCLUSTER-250 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.1.3.Final > Environment: Mixing ProxyPass/ProxyPassReverse and mod_cluster > Reporter: Jean-Frederic Clere > Assignee: Michal Karm Babacek > Priority: Minor > Fix For: 1.1.4.Final > > > Using: > ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On > ProxyPassReverse / balancer://mycluster/ > or > ProxyPass / balancer://mycluster stickysession=JSESSIONID|jsessionid nofailover=On > ProxyPassReverse / balancer://mycluster > (note that this one won't work with mod_proxy_balancer). > You get stuff like: > curl -v http://jfcpc:8000/myapp > +++ > < HTTP/1.1 302 Moved Temporarily > < Date: Thu, 25 Aug 2011 09:40:17 GMT > < Server: Apache-Coyote/1.1 > < Location: http://jfcpc:8000//myapp/ > < Content-Length: 0 > < Content-Type: text/plain > +++ > Or > curl -v http://jfcpc:8000/myapp/TestRedirect?location=/toto.html > +++ > < HTTP/1.1 302 Moved Temporarily > < Date: Thu, 25 Aug 2011 09:42:59 GMT > < Server: Apache-Coyote/1.1 > < Location: http://jfcpc:8000//toto.html;jsessionid=OYeoix8WaRh6VEtlSrfzIS7Q.498bb1f0... > < Content-Length: 0 > < Set-Cookie: JSESSIONID=OYeoix8WaRh6VEtlSrfzIS7Q.498bb1f0-00d9-3436-a341-7f012bc2e7ec; Path=/myapp > < Content-Type: text/plain > +++ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-463) UpperCase Alias never matches any context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-463?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated MODCLUSTER-463: ----------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1340957, https://bugzilla.redhat.com/show_bug.cgi?id=1340958 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1340957) > UpperCase Alias never matches any context > ----------------------------------------- > > Key: MODCLUSTER-463 > URL: https://issues.jboss.org/browse/MODCLUSTER-463 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.11.Final, 1.3.1.Final > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final, 1.2.13.Final > > Attachments: simplecontext-examples.zip > > > h3. Problem > h4. JBossWeb > Regardless the upper/lower case of an Alias one configured in _JBossWeb (EAP 6.4.3, mod_cluster subsystem 1.2.11.Final)_, it has always been reported to Apache HTTP Server in lower case. For example, the following configuration:{code:xml} > <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="workerXXX" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> > <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > <virtual-server name="web1" default-web-module="simplecontext-web1"> > <alias name="web1.rhel7GAx86-64"/> > </virtual-server> > <virtual-server name="web2" default-web-module="simplecontext-web2"> > <alias name="web2.rhel7GAx86-64"/> > </virtual-server> > </subsystem> > {code}sends this message with aliases actually being reported in lower case: {{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7gax86-64&Context=%2F}}. Having {{aliases}} stored in lower case on the Apache HTTP Server side enables both these URLs to work perfectly:{noformat}curl http://web2.rhel7GAx86-64:6666/ > curl http://web2.rhel7gax86-64:6666/{noformat}. The balancer configuration is just a simple [UseAlias 1|http://fpaste.org/251417/86985831/]. > h4. Undertow > _Undertow (JBossWeb's successor in EAP 7.0.0.DR7, mod_cluster subsystem 1.3.1.Final)_ behaves differently; it reports verbatim what one sets as an alias, so with the following configuration:{code:xml}<subsystem xmlns="urn:jboss:domain:undertow:3.0" instance-id="workerXXX"> > <buffer-cache name="default"/> > <server name="default-server"> > <ajp-listener name="ajp" socket-binding="ajp"/> > <http-listener name="default" redirect-socket="https" socket-binding="http"/> > <host name="default-host" alias="localhost"> > <location name="/" handler="welcome-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web1" alias="web1.rhel7GAx86-64"> > <location name="/" handler="web1-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web2" alias="web2.rhel7GAx86-64"> > <location name="/" handler="web2-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > <websockets/> > </servlet-container> > <handlers> > <file name="web1-content" path="${jboss.home.dir}/simplecontext-web1"/> > <file name="web2-content" path="${jboss.home.dir}/simplecontext-web2"/> > <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> > </handlers> > <filters> > <response-header name="server-header" header-value="WildFly/10" header-name="Server"/> > <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/> > </filters> > </subsystem>{code}, the message reported to Apache HTTP Server actually is:{{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7GAx86-64&Context=%2F}}. Due to the fact that aliases are being compared byte-by-byte for equality (because pumping of slash characters takes place) and the accessed domain is always in lower case and alias is stored as it was received, there is never match between these. > The result is that while these work:{{http://web2:6666/}}, {{http://web1:6666/}}, one of the upper case containing ones work at all: {{http://web1.rhel7GAx86-64:6666}} and {{http://web2.rhel7gax86-64:6666/}} neither. By not working I actually mean they return the root of Apache HTTP Server Welcome page instead of correctly forwarding to one of the Application server's virtual host contexts. > Last but not least, while EAP 6.4.3 with JBossWeb itself treats aliases as case-insensitive, EAP 7.0.0.DR7 with Undertow does not; i.e. {{web1.rhel7GAx86-64:8080/}} returns correctly web application content whereas {{web1.rhel7gax86-64:8080/}} returns EAP7 Welcome page. > While the aforementioned is clearly a bug (or a weird feature :)) in Undertow, we must make the Apache HTTP Server code resilient to such behaviour. > h3. Solution > I suggest converting aliases to lower case in mod_manager on ENABLE-APP arrival. According to my preliminary tests, this approach works for both JBossWeb and Undertow equipped workers. I think it's cool to do that: [RFC 1035|https://tools.ietf.org/html/rfc1035#section-2.3.3]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-463) UpperCase Alias never matches any context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-463?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated MODCLUSTER-463: ----------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1340957 Bugzilla Update: Perform > UpperCase Alias never matches any context > ----------------------------------------- > > Key: MODCLUSTER-463 > URL: https://issues.jboss.org/browse/MODCLUSTER-463 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.2.11.Final, 1.3.1.Final > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Fix For: 1.3.3.Final, 1.2.13.Final > > Attachments: simplecontext-examples.zip > > > h3. Problem > h4. JBossWeb > Regardless the upper/lower case of an Alias one configured in _JBossWeb (EAP 6.4.3, mod_cluster subsystem 1.2.11.Final)_, it has always been reported to Apache HTTP Server in lower case. For example, the following configuration:{code:xml} > <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" instance-id="workerXXX" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> > <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > <virtual-server name="web1" default-web-module="simplecontext-web1"> > <alias name="web1.rhel7GAx86-64"/> > </virtual-server> > <virtual-server name="web2" default-web-module="simplecontext-web2"> > <alias name="web2.rhel7GAx86-64"/> > </virtual-server> > </subsystem> > {code}sends this message with aliases actually being reported in lower case: {{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7gax86-64&Context=%2F}}. Having {{aliases}} stored in lower case on the Apache HTTP Server side enables both these URLs to work perfectly:{noformat}curl http://web2.rhel7GAx86-64:6666/ > curl http://web2.rhel7gax86-64:6666/{noformat}. The balancer configuration is just a simple [UseAlias 1|http://fpaste.org/251417/86985831/]. > h4. Undertow > _Undertow (JBossWeb's successor in EAP 7.0.0.DR7, mod_cluster subsystem 1.3.1.Final)_ behaves differently; it reports verbatim what one sets as an alias, so with the following configuration:{code:xml}<subsystem xmlns="urn:jboss:domain:undertow:3.0" instance-id="workerXXX"> > <buffer-cache name="default"/> > <server name="default-server"> > <ajp-listener name="ajp" socket-binding="ajp"/> > <http-listener name="default" redirect-socket="https" socket-binding="http"/> > <host name="default-host" alias="localhost"> > <location name="/" handler="welcome-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web1" alias="web1.rhel7GAx86-64"> > <location name="/" handler="web1-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > <host name="web2" alias="web2.rhel7GAx86-64"> > <location name="/" handler="web2-content"/> > <filter-ref name="server-header"/> > <filter-ref name="x-powered-by-header"/> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > <websockets/> > </servlet-container> > <handlers> > <file name="web1-content" path="${jboss.home.dir}/simplecontext-web1"/> > <file name="web2-content" path="${jboss.home.dir}/simplecontext-web2"/> > <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> > </handlers> > <filters> > <response-header name="server-header" header-value="WildFly/10" header-name="Server"/> > <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/> > </filters> > </subsystem>{code}, the message reported to Apache HTTP Server actually is:{{JVMRoute=workerXXX&Alias=web2%2Cweb2.rhel7GAx86-64&Context=%2F}}. Due to the fact that aliases are being compared byte-by-byte for equality (because pumping of slash characters takes place) and the accessed domain is always in lower case and alias is stored as it was received, there is never match between these. > The result is that while these work:{{http://web2:6666/}}, {{http://web1:6666/}}, one of the upper case containing ones work at all: {{http://web1.rhel7GAx86-64:6666}} and {{http://web2.rhel7gax86-64:6666/}} neither. By not working I actually mean they return the root of Apache HTTP Server Welcome page instead of correctly forwarding to one of the Application server's virtual host contexts. > Last but not least, while EAP 6.4.3 with JBossWeb itself treats aliases as case-insensitive, EAP 7.0.0.DR7 with Undertow does not; i.e. {{web1.rhel7GAx86-64:8080/}} returns correctly web application content whereas {{web1.rhel7gax86-64:8080/}} returns EAP7 Welcome page. > While the aforementioned is clearly a bug (or a weird feature :)) in Undertow, we must make the Apache HTTP Server code resilient to such behaviour. > h3. Solution > I suggest converting aliases to lower case in mod_manager on ENABLE-APP arrival. According to my preliminary tests, this approach works for both JBossWeb and Undertow equipped workers. I think it's cool to do that: [RFC 1035|https://tools.ietf.org/html/rfc1035#section-2.3.3]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues May 2016