July 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-526) SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-526: ------------------------------------------- Description: * 3 tomcats * 2 load balancing groups * 1 request every 3 seconds (no load at all) * shutdown and kill of various nodes * no later than third kill/start iteration causes SIGSEGV {code} #if AP_MODULE_MAGIC_AT_LEAST(20101223,1) /* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */ helper->index = 0; /* mark it removed */ worker->s = helper->shared; crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared)); #else worker->id = 0; /* mark it removed */ #endif {code} was: * 3 tomcats * 2 load balancing groups * 1 request every 3 seconds (no load at all) * shutdown and kill of various nodes * no later than third kill/start iteration causes SIGSEGV {code} h==9005== Thread 5: ==9005== Source and destination overlap in memcpy(0x4021068, 0x4021068, 304) ==9005== at 0x4C2B403: memcpy@(a)GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9005== by 0xB28ECA1: insert_update (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB07BCC2: ap_slotmem_do (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_cluster_slotmem.so) ==9005== by 0xB28ED6B: insert_update_node (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB28666D: process_node_cmd (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB286AA7: process_appl_cmd (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB28745A: process_remove (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB28B619: manager_handler (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0x44CEEF: ap_run_handler (config.c:170) ==9005== by 0x44D438: ap_invoke_handler (config.c:434) ==9005== by 0x461D89: ap_process_async_request (http_request.c:410) ==9005== by 0x45E4AF: ap_process_http_connection (http_core.c:154) ==9005== ==9005== Thread 3: ==9005== Invalid write of size 8 ==9005== at 0x4C2B473: memcpy@(a)GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9005== by 0xB499EE5: remove_workers_node (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) ==9005== by 0xB49E165: remove_workers_nodes (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) ==9005== by 0xB49E353: proxy_cluster_watchdog_func (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) ==9005== by 0x5B5FEE4: start_thread (pthread_create.c:309) ==9005== by 0x606DD1C: clone (clone.S:111) ==9005== Address 0x0 is not stack'd, malloc'd or (recently) free'd {code} > SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup > ----------------------------------------------------------------------------------- > > Key: MODCLUSTER-526 > URL: https://issues.jboss.org/browse/MODCLUSTER-526 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.3.Final > Environment: Fedora 20, x86_64, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Blocker > Fix For: 1.3.4.Final > > > * 3 tomcats > * 2 load balancing groups > * 1 request every 3 seconds (no load at all) > * shutdown and kill of various nodes > * no later than third kill/start iteration causes SIGSEGV > {code} > #if AP_MODULE_MAGIC_AT_LEAST(20101223,1) > /* Here that is tricky the worker needs shared memory but we don't and CONFIG will reset it */ > helper->index = 0; /* mark it removed */ > worker->s = helper->shared; > crash---> memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > #else > worker->id = 0; /* mark it removed */ > #endif > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-526) SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-526: ------------------------------------------- Description: * 3 tomcats * 2 load balancing groups * 1 request every 3 seconds (no load at all) * shutdown and kill of various nodes * no later than third kill/start iteration causes SIGSEGV {code} h==9005== Thread 5: ==9005== Source and destination overlap in memcpy(0x4021068, 0x4021068, 304) ==9005== at 0x4C2B403: memcpy@(a)GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9005== by 0xB28ECA1: insert_update (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB07BCC2: ap_slotmem_do (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_cluster_slotmem.so) ==9005== by 0xB28ED6B: insert_update_node (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB28666D: process_node_cmd (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB286AA7: process_appl_cmd (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB28745A: process_remove (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0xB28B619: manager_handler (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) ==9005== by 0x44CEEF: ap_run_handler (config.c:170) ==9005== by 0x44D438: ap_invoke_handler (config.c:434) ==9005== by 0x461D89: ap_process_async_request (http_request.c:410) ==9005== by 0x45E4AF: ap_process_http_connection (http_core.c:154) ==9005== ==9005== Thread 3: ==9005== Invalid write of size 8 ==9005== at 0x4C2B473: memcpy@(a)GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9005== by 0xB499EE5: remove_workers_node (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) ==9005== by 0xB49E165: remove_workers_nodes (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) ==9005== by 0xB49E353: proxy_cluster_watchdog_func (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) ==9005== by 0x5B5FEE4: start_thread (pthread_create.c:309) ==9005== by 0x606DD1C: clone (clone.S:111) ==9005== Address 0x0 is not stack'd, malloc'd or (recently) free'd {code} was: * 3 tomcats * 2 load balancing groups * 1 request every 3 seconds (no load at all) * shutdown and kill of various nodes * no later than third kill/start iteration causes SIGSEGV > SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup > ----------------------------------------------------------------------------------- > > Key: MODCLUSTER-526 > URL: https://issues.jboss.org/browse/MODCLUSTER-526 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.3.Final > Environment: Fedora 20, x86_64, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Blocker > Fix For: 1.3.4.Final > > > * 3 tomcats > * 2 load balancing groups > * 1 request every 3 seconds (no load at all) > * shutdown and kill of various nodes > * no later than third kill/start iteration causes SIGSEGV > {code} > h==9005== Thread 5: > ==9005== Source and destination overlap in memcpy(0x4021068, 0x4021068, 304) > ==9005== at 0x4C2B403: memcpy@(a)GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==9005== by 0xB28ECA1: insert_update (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) > ==9005== by 0xB07BCC2: ap_slotmem_do (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_cluster_slotmem.so) > ==9005== by 0xB28ED6B: insert_update_node (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) > ==9005== by 0xB28666D: process_node_cmd (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) > ==9005== by 0xB286AA7: process_appl_cmd (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) > ==9005== by 0xB28745A: process_remove (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) > ==9005== by 0xB28B619: manager_handler (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_manager.so) > ==9005== by 0x44CEEF: ap_run_handler (config.c:170) > ==9005== by 0x44D438: ap_invoke_handler (config.c:434) > ==9005== by 0x461D89: ap_process_async_request (http_request.c:410) > ==9005== by 0x45E4AF: ap_process_http_connection (http_core.c:154) > ==9005== > ==9005== Thread 3: > ==9005== Invalid write of size 8 > ==9005== at 0x4C2B473: memcpy@(a)GLIBC_2.14 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==9005== by 0xB499EE5: remove_workers_node (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) > ==9005== by 0xB49E165: remove_workers_nodes (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) > ==9005== by 0xB49E353: proxy_cluster_watchdog_func (in /home/karm/Projects/MOD_CLUSTER/httpd-2.4.20-build/modules/mod_proxy_cluster.so) > ==9005== by 0x5B5FEE4: start_thread (pthread_create.c:309) > ==9005== by 0x606DD1C: clone (clone.S:111) > ==9005== Address 0x0 is not stack'd, malloc'd or (recently) free'd > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-526) SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup

by Michal Karm Babacek (JIRA)

Michal Karm Babacek created MODCLUSTER-526: ---------------------------------------------- Summary: SIGSEGV in remove_workers_node (mod_proxy_cluster.so) when using LoadBalancingGroup Key: MODCLUSTER-526 URL: https://issues.jboss.org/browse/MODCLUSTER-526 Project: mod_cluster Issue Type: Bug Components: Native (httpd modules) Affects Versions: 1.3.3.Final Environment: Fedora 20, x86_64, httpd 2.4.20 Reporter: Michal Karm Babacek Assignee: Michal Karm Babacek Priority: Blocker Fix For: 1.3.4.Final * 3 tomcats * 2 load balancing groups * 1 request every 3 seconds (no load at all) * shutdown and kill of various nodes * no later than third kill/start iteration causes SIGSEGV -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-524) Failed to start advertise listener: java.net.BindException: Address already in use

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-524?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-524: ------------------------------------------- Component/s: Core & Container Integration (Java) > Failed to start advertise listener: java.net.BindException: Address already in use > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-524 > URL: https://issues.jboss.org/browse/MODCLUSTER-524 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.2.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > > {noformat} > 2016-07-15 04:26:41,229 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.2.Final-redhat-1 > 2016-07-15 04:26:41,247 ERROR [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000034: Failed to start advertise listener: java.net.BindException: Address already in use: Cannot bind > at java.net.TwoStacksPlainDatagramSocketImpl.bind0(Native Method) > at java.net.TwoStacksPlainDatagramSocketImpl.bind0(TwoStacksPlainDatagramSocketImpl.java:107) > at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:93) > at java.net.TwoStacksPlainDatagramSocketImpl.bind(TwoStacksPlainDatagramSocketImpl.java:97) > at java.net.DatagramSocket.bind(DatagramSocket.java:392) > at java.net.MulticastSocket.<init>(MulticastSocket.java:172) > at java.net.MulticastSocket.<init>(MulticastSocket.java:136) > at org.jboss.modcluster.advertise.impl.MulticastSocketFactoryImpl.createMulticastSocket(MulticastSocketFactoryImpl.java:74) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.init(AdvertiseListenerImpl.java:145) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.start(AdvertiseListenerImpl.java:165) > at org.jboss.modcluster.ModClusterService.init(ModClusterService.java:181) > at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.start(UndertowEventHandlerAdapter.java:100) > at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-524) Failed to start advertise listener: java.net.BindException: Address already in use

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-524?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-524: ------------------------------------------- Steps to reproduce? > Failed to start advertise listener: java.net.BindException: Address already in use > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-524 > URL: https://issues.jboss.org/browse/MODCLUSTER-524 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.2.Final > Reporter: Bogdan Sikora > Assignee: Radoslav Husar > > {noformat} > 2016-07-15 04:26:41,229 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000001: Initializing mod_cluster version 1.3.2.Final-redhat-1 > 2016-07-15 04:26:41,247 ERROR [org.jboss.modcluster] (ServerService Thread Pool -- 64) MODCLUSTER000034: Failed to start advertise listener: java.net.BindException: Address already in use: Cannot bind > at java.net.TwoStacksPlainDatagramSocketImpl.bind0(Native Method) > at java.net.TwoStacksPlainDatagramSocketImpl.bind0(TwoStacksPlainDatagramSocketImpl.java:107) > at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:93) > at java.net.TwoStacksPlainDatagramSocketImpl.bind(TwoStacksPlainDatagramSocketImpl.java:97) > at java.net.DatagramSocket.bind(DatagramSocket.java:392) > at java.net.MulticastSocket.<init>(MulticastSocket.java:172) > at java.net.MulticastSocket.<init>(MulticastSocket.java:136) > at org.jboss.modcluster.advertise.impl.MulticastSocketFactoryImpl.createMulticastSocket(MulticastSocketFactoryImpl.java:74) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.init(AdvertiseListenerImpl.java:145) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.start(AdvertiseListenerImpl.java:165) > at org.jboss.modcluster.ModClusterService.init(ModClusterService.java:181) > at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.start(UndertowEventHandlerAdapter.java:100) > at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-449) Implement ramp-up when starting new nodes

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-449?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-449: -------------------------------------- Affects Version/s: 1.3.0.Final 1.2.0.Final > Implement ramp-up when starting new nodes > ----------------------------------------- > > Key: MODCLUSTER-449 > URL: https://issues.jboss.org/browse/MODCLUSTER-449 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.2.0.Final, 1.3.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 2.0.0.Alpha1 > > > IIUC this has been a problem since inception. The problem is that the initial load stays in effect for performing load-balancing decisions until a new stat interval kicks in. > This effect is mitigated by load decay over time, but for the time a new node joins in, it can get overloaded upon startup. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-449) Implement ramp-up when starting new nodes

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-449?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-449: -------------------------------------- Fix Version/s: 2.0.0.Alpha1 (was: 1.3.4.Final) > Implement ramp-up when starting new nodes > ----------------------------------------- > > Key: MODCLUSTER-449 > URL: https://issues.jboss.org/browse/MODCLUSTER-449 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.2.0.Final, 1.3.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 2.0.0.Alpha1 > > > IIUC this has been a problem since inception. The problem is that the initial load stays in effect for performing load-balancing decisions until a new stat interval kicks in. > This effect is mitigated by load decay over time, but for the time a new node joins in, it can get overloaded upon startup. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-429) Some problems were encountered while building the effective model for org.jboss:User-Guide-en:jdocbook:1.3.1.Alpha3-SNAPSHOT

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-429?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-429. ------------------------------------- Fix Version/s: (was: 1.3.4.Final) Resolution: Out of Date We want to move to a better documentation platform in near future. > Some problems were encountered while building the effective model for org.jboss:User-Guide-en:jdocbook:1.3.1.Alpha3-SNAPSHOT > ---------------------------------------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-429 > URL: https://issues.jboss.org/browse/MODCLUSTER-429 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > [WARNING] > [WARNING] Some problems were encountered while building the effective model for org.jboss:User-Guide-en:jdocbook:1.3.1.Alpha3-SNAPSHOT > [WARNING] 'artifactId' contains an expression but should be a constant. @ org.jboss:User-Guide-${translation}:1.3.1.Alpha3-SNAPSHOT, /home/rhusar/git/mod_cluster/docs/userguide/pom.xml, line 31, column 17 > [WARNING] 'parent.relativePath' points at org.jboss.mod_cluster:org.jboss.mod_cluster-docs instead of org.jboss:jboss-parent, please verify your project structure @ org.jboss:User-Guide-${translation}:1.3.1.Alpha3-SNAPSHOT, /home/rhusar/git/mod_cluster/docs/userguide/pom.xml, line 24, column 13 > [WARNING] > [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. > [WARNING] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-440) Release 1.3.x binaries to mod-cluster.jboss.org/downloads

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-440?page=com.atlassian.jira.pl... ] Radoslav Husar closed MODCLUSTER-440. ------------------------------------- Fix Version/s: (was: 1.3.4.Final) Resolution: Out of Date > Release 1.3.x binaries to mod-cluster.jboss.org/downloads > --------------------------------------------------------- > > Key: MODCLUSTER-440 > URL: https://issues.jboss.org/browse/MODCLUSTER-440 > Project: mod_cluster > Issue Type: Task > Components: Documentation & Demos > Affects Versions: 1.3.0.Final > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > > We should really do this and at least we should release the JARs so people get Tomcat 8 support. People using AS7 or WildFly get their modcluster jars out of box. > ..and blog/tweet about it :-) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 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 updated MODCLUSTER-303: -------------------------------------- Fix Version/s: 2.0.0.Alpha1 (was: 1.3.4.Final) > 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: 2.0.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 was sent by Atlassian JIRA (v6.4.11#64026)

7 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 July 2016