August 2013 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-332) Add Engine.getExecutor() to container SPI

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-332?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-332. -------------------------------------------- Resolution: Done In fact there are requests to make less STATUS so it is more easy to just count the events and trigger a STATUS every n events. I have added a system-property to use like: +++ <system-properties> <property name="org.jboss.modcluster.container.catalina.WAITSTATUS" value="60"/> </system-properties> +++ In fact the value is rounded to the nearest 10 seconds value (upper). > Add Engine.getExecutor() to container SPI > ----------------------------------------- > > Key: MODCLUSTER-332 > URL: https://issues.jboss.org/browse/MODCLUSTER-332 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.3.Final > Reporter: Paul Ferraro > Assignee: Jean-Frederic Clere > Fix For: 1.2.5.Final > > > This is required to expose some mechanism to configure the STATUS interval. Currently, the web subsystem in AS7 has no mechanism to configure the background process period of the Engine. An Engine.getExecutor() container SPI method would allow the mod_cluster subsystem to configure its own executor to control this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-168) mod_cluster should use hostname provided in address instead a IP address

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-168?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-168: ------------------------------------------------ It seems the corresponding code is gone in 1.2.x and master. > mod_cluster should use hostname provided in address instead a IP address > ------------------------------------------------------------------------ > > Key: MODCLUSTER-168 > URL: https://issues.jboss.org/browse/MODCLUSTER-168 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.1.0.CR3 > Environment: any > Reporter: Jean-Frederic Clere > Assignee: Paul Ferraro > Fix For: 1.2.5.Final > > > The CONFIG message contains something like: > JVMRoute=51ec121e-2976-3d75-bfd9-9e662bbb4bcd&Host=10.33.144.3&Port=8009&Type=ajp > Even if the Connector is defined like: > <Connector port="8009" address= "jfcpc" protocol="AJP/1.3" redirectPort="8443" /> > There are 2 ways to fix: > - Use the String (Change the Connector.java in mod_cluster). > - Use parameters.put("Host", connector.getAddress().getHostName()); when building the CONFIG message. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-339) "proxy: DNS lookup failure" with IPv6 on Solaris

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-339?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-339. -------------------------------------------- Resolution: Done > "proxy: DNS lookup failure" with IPv6 on Solaris > ------------------------------------------------ > > Key: MODCLUSTER-339 > URL: https://issues.jboss.org/browse/MODCLUSTER-339 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.3.Final, 1.2.4.Final > Environment: Solaris 10 x86, Solaris 11 x86, Solaris 11 SPARC > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Priority: Critical > Labels: ipv6 > Fix For: 1.2.5.Final > > Attachments: access_log-mod_cluster, error_log-mod_cluster, error_log-mod_cluster-RHEL, error_log-proxypass, error_log_pull20, http.conf, mod_manager.so, sockaddr.lo_fedora18_x86_64, sockaddr.lo_solaris11_sparc64 > > > h2. Failure with mod_cluster > Having the following setting: > {code:title=mod_cluster.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule slotmem_module modules/mod_slotmem.so > LoadModule manager_module modules/mod_manager.so > LoadModule proxy_cluster_module modules/mod_proxy_cluster.so > LoadModule advertise_module modules/mod_advertise.so > MemManagerFile "/tmp/mod_cluster-eap6/jboss-ews-2.0/var/cache/mod_cluster" > ServerName [2620:52:0:105f::ffff:50]:2080 > <IfModule manager_module> > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup [ff01::7]:23964 > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > I get a weird {{proxy: DNS lookup failure}} as soon as worker sends {{CONFIGURE}}}: > {code:title=access_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "STATUS / HTTP/1.1" 200 64 "-" "ClusterListener/1.0" > ... > {code} > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans INFO (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler INFO (/) processing: "" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler INFO OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans CONFIG (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler CONFIG (/) processing: "JVMRoute=jboss-eap-6.1&Host=%5B2620%3A52%3A0%3A105f%3A0%3A0%3Affff%3A50%252%5D&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler CONFIG OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans STATUS (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler STATUS (/) processing: "JVMRoute=jboss-eap-6.1&Load=100" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1638): Processing STATUS > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(655): add_balancer_node: Create balancer balancer://qacluster > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(426): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(532): proxy: initialized worker 1 in child 16847 for (2620:52:0:105f:0:0:ffff:50%2) min=0 max=25 smax=25 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(601): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 1 (status): 1 > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (2620:52:0:105f:0:0:ffff:50%2) > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009/ to 2620:52:0:105f:0:0:ffff:50%2:8009 > [Thu May 16 08:37:24 2013] [error] [client 2620:52:0:105f::ffff:50] proxy: DNS lookup failure for: 2620:52:0:105f:0:0:ffff:50%2 returned by / > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (2620:52:0:105f:0:0:ffff:50%2) > ... > {code} > An attempt to access the mod_cluster manager console yields an unpleasant {{NOTOK}} (obviously, we have All workers are in error state...): > {code} > curl -g [2620:52:0:105f::ffff:50]:6666/mcm > ... > <h1> Node jboss-eap-6.1 (ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009): </h1> > <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=ENABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Enable Contexts</a> <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=DISABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Disable Contexts</a><br/> > Balancer: qacluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: NOTOK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: -1 > {code} > You might take a look at the logs: [^error_log-mod_cluster], [^access_log-mod_cluster]. > h2. ProxyPass itself works just fine > On the other hand, when I had tried this: > {code:title=proxypass.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule proxy_ajp_module modules/mod_proxy_ajp.so > ServerName [2620:52:0:105f::ffff:50]:2080 > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > ProxyPass / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > ProxyPassReverse / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > </VirtualHost> > {code} > I received: > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(1506): [client 2620:52:0:105f::ffff:50] proxy: ajp: found worker ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ for ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy.c(1020): Running scheme ajp handler (attempt 0) > [Thu May 16 08:29:00 2013] [debug] mod_proxy_http.c(1963): proxy: HTTP: declining URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(681): proxy: AJP: serving URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2011): proxy: AJP: has acquired connection for (2620:52:0:105f:0:0:ffff:50) > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2193): proxy: connected / to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2444): proxy: AJP: fam 26 socket created to connect to 2620:52:0:105f:0:0:ffff:50 > ... > {code} > And from the client's side, it worked: > {{curl -g [2620:52:0:105f::ffff:50]:6666/}} brought me the worker's home page (EAP's welcome in this case). > Take a look at the whole log [^error_log-proxypass]. > *Note:* The [^http.conf] was the same both for mod_cluster and for proxypass test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-356) BalancerMember directives cause httpd crash when using mod_cluster 1.2.x

by Marco Danti (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-356?page=com.atlassian.jira.pl... ] Marco Danti updated MODCLUSTER-356: ----------------------------------- Environment: SLES-11-SP1 x86_64 running httpd 2.2.24 or 2.4.6 with any mod_cluster-1.2.x version and JBoss-AS-7.2.0.Final (was: SLES-11-SP1 x86_64 running httpd-2.4.6 with any mod_cluster-1.2.x version and JBoss-AS-7.2.0.Final) Steps to Reproduce: Easiest way to reproduce is using httpd-2.2.24/mod_cluster-1.2.3.Final configured as a reverse proxy and load balancer for two or more JBoss-AS-7.2.0 instances configured to work in HA. If the httpd.conf file contains one or more BalancerMember directive as in <Proxy balancer://mycluster> BalancerMember ......... BalancerMember ......... </Proxy> then the httpd server crashes just by running it. All the details and configuration files can be found in the forum reference thread was: Easiest way to reproduce is using httpd-2.2.24/mod_cluster-1.2.3.Final configured as a reverse proxy and load balancer for two or more JBoss-AS-7.2.0 instances configured to work in HA. If the httpd.conf file contains one or more BalancerMember directive as in <Proxy balancer://mycluster> BalancerMember ......... BalancerMember ......... ProxySet lbmethod=byrequests # ProxySet stickysession=JSESSIONID|jsessionid </Proxy> then the httpd server crashes just by running it. All the details and configuration files can be found in the forum reference thread > BalancerMember directives cause httpd crash when using mod_cluster 1.2.x > ------------------------------------------------------------------------ > > Key: MODCLUSTER-356 > URL: https://issues.jboss.org/browse/MODCLUSTER-356 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.4.Final > Environment: SLES-11-SP1 x86_64 running httpd 2.2.24 or 2.4.6 with any mod_cluster-1.2.x version and JBoss-AS-7.2.0.Final > Reporter: Marco Danti > Assignee: Jean-Frederic Clere > Labels: balancerMember, crash, httpd, mod_cluster > > httpd dumps core in mod_proxy_cluster.c if the httpd.conf file contains BalancerMember directives. > this happens at least with the following two setups: > 1) httpd-2.4.6 and mod_cluster-1.2.x > 2) httpd-2.2.24 and mod_cluster-1.2.3.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-356) BalancerMember directives cause httpd crash when using mod_cluster 1.2.x

by Marco Danti (JIRA)

Marco Danti created MODCLUSTER-356: -------------------------------------- Summary: BalancerMember directives cause httpd crash when using mod_cluster 1.2.x Key: MODCLUSTER-356 URL: https://issues.jboss.org/browse/MODCLUSTER-356 Project: mod_cluster Issue Type: Bug Affects Versions: 1.2.4.Final Environment: SLES-11-SP1 x86_64 running httpd-2.4.6 with any mod_cluster-1.2.x version and JBoss-AS-7.2.0.Final Reporter: Marco Danti Assignee: Jean-Frederic Clere httpd dumps core in mod_proxy_cluster.c if the httpd.conf file contains BalancerMember directives. this happens at least with the following two setups: 1) httpd-2.4.6 and mod_cluster-1.2.x 2) httpd-2.2.24 and mod_cluster-1.2.3.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-331) Add mod_cluster container SPI implementation for undertow

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-331?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-331: -------------------------------------- Fix Version/s: 1.3.0.Alpha1 (was: 1.2.5.Final) We decided the implementation is going to reside entirely in WildFly repo. Moreover, this also encompasses integration with standalone Undertow, since that is going to be bundled as minimal WildFly instance. See WFLY-1888. > Add mod_cluster container SPI implementation for undertow > --------------------------------------------------------- > > Key: MODCLUSTER-331 > URL: https://issues.jboss.org/browse/MODCLUSTER-331 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.3.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-303) Discovery protocol based on mod-cluster

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-303?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-303: ------------------------------------------- BTW the target is now WildFly 9, but lets see if I can get this earlier. > Discovery protocol based on mod-cluster > --------------------------------------- > > Key: MODCLUSTER-303 > URL: https://issues.jboss.org/browse/MODCLUSTER-303 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Vladimir Blagojevic > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > In it previous life used to be https://issues.jboss.org/browse/JGRP-1322 > It would be nice to have a discovery protocol that can use mod-cluster as the source of the node information. > Mod-cluster already knows the list of participating nodes and provides this information in a well known format, so it could be simple to implement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-355) Allow connector to not define maximum capacity (e.g. Undertow listener)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-355?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-355: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/39 > Allow connector to not define maximum capacity (e.g. Undertow listener) > ----------------------------------------------------------------------- > > Key: MODCLUSTER-355 > URL: https://issues.jboss.org/browse/MODCLUSTER-355 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > See WFLY-1888. > In WF we are wrapping Undertow listener with Connector interface. However, with all the async processing the maximum capacity does not represent busyness correctly. > I am going to add support for the connector to return "-1" that indicates to mod_cluster that this connector does not define maximum number of threads and leave the load calculation to capacity instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-335) Regression in ProxyPass integration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-335?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-335: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> made a comment on [bug 960243|https://bugzilla.redhat.com/show_bug.cgi?id=960243] It is fixed in m_c 1.2.5. > Regression in ProxyPass integration > ----------------------------------- > > Key: MODCLUSTER-335 > URL: https://issues.jboss.org/browse/MODCLUSTER-335 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.4.Final > Environment: RHEL6 x86_64, the rest is to be confirmed... > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Fix For: 1.2.5.Final > > Attachments: logs-and-configs-m_c-1.2.3.zip, logs-and-configs-m_c-1.2.4.zip, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.3.log, test-run-modProxyOnlyPartOfUrlSpaceTest-mod_cluster-1.2.4.log > > > This configuration & test worked just fine with 1.2.3.Final and it is broken in 1.2.4.Final, so we have a *regression* here, I guess. > {code} > ProxyPassMatch ^/app/static/ ! > ProxyPass /app balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on > ProxyPass / ! > ProxyPassReverse /app balancer://qacluster > ProxyPassReverseCookieDomain / /app/ > ProxyPassReverseCookiePath / /app/ > ProxyPreserveHost on > {code} > Accessing e.g. {{/app/clusterbench/requestinfo/}} returns HTTP 503. *requestinfo* comes from the famous [CommonRequestInfoServlet.java|https://github.com/Karm/clusterbench/blob/s...]. > h3. mod_cluster 1.2.3 ProxyPass test: > *Failed tests* > * modProxyOnlyPartOfUrlSpaceTest: Known fail: [JBQA-7899] Assert #10 Session ID must always be the same. > * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available... > h3. mod_cluster 1.2.4 ProxyPass test: > *Failed tests* > * modProxyOnlyPartOfUrlSpaceTest: Assert #1, fail, http://10.16.45.160:2080/app/clusterbench/requestinfo/ should have been available... > * modProxyWithoutSessionId: Assert #1, fail, known as [MODCLUSTER-334], http://10.16.45.160:2080/clusterbench/requestinfo/ should have been available... > What the test does is it accesses various URLs, getting either static content from httpd or a dynamic one from application server. > Browse the attached files for complete configs, debug logs and test results. Ping me, if the zipped file structure does not make sense to you... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-303) Discovery protocol based on mod-cluster

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-303?page=com.atlassian.jira.pl... ] Jean-Frederic Clere commented on MODCLUSTER-303: ------------------------------------------------ Correct a fix is needed in the native part or in the tests. > Discovery protocol based on mod-cluster > --------------------------------------- > > Key: MODCLUSTER-303 > URL: https://issues.jboss.org/browse/MODCLUSTER-303 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Vladimir Blagojevic > Assignee: Radoslav Husar > Fix For: 1.3.0.Alpha1 > > > In it previous life used to be https://issues.jboss.org/browse/JGRP-1322 > It would be nice to have a discovery protocol that can use mod-cluster as the source of the node information. > Mod-cluster already knows the list of participating nodes and provides this information in a well known format, so it could be simple to implement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues August 2013