March 2017 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-575) Create a Load SPI module

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-575?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-575: -------------------------------------- Description: Currently implementers of a custom LoadMetric need to pull in entire core module. > Create a Load SPI module > ------------------------ > > Key: MODCLUSTER-575 > URL: https://issues.jboss.org/browse/MODCLUSTER-575 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.3.6.Final > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Fix For: 2.0.0.Alpha1 > > > Currently implementers of a custom LoadMetric need to pull in entire core module. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-570) Multiple invalid nodes created on graceful httpd restart

by Antoine Cotten (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-570?page=com.atlassian.jira.pl... ] Antoine Cotten edited comment on MODCLUSTER-570 at 3/30/17 9:13 AM: -------------------------------------------------------------------- I managed to reproduce on 1.3.6.Final. It's actually as simple as doing multiple graceful restarts in a row, no need for an application server. What I did: # Run httpd with mod_cluster {code}docker run --name mc -p 8080:80 -p 7777:6666 antoineco/httpd-mod_cluster:1.3.6-alpine{code} # Uncomment the mod_cluster modules in the config, and uncomment the very last line ({{Include}}) to enable the manager vhost {code}docker exec -it mc vi conf/httpd.conf{code} # Gracefully reload httpd: {code}docker exec mc apachectl -k graceful{code} # Repeat 3. two times The same error messages as described in the description will surface. was (Author: antoineco): I managed to reproduce on 1.3.6.Final. It's actually as simple as doing multiple graceful restarts in a row, no need for an application server. What I did: # Run httpd with mod_cluster {{docker run --name mc -p 8080:80 -p 7777:6666 antoineco/httpd-mod_cluster:1.3.6-alpine}} # Uncomment the mod_cluster modules in the config, and uncomment the very last line ({{Include}}) to enable the manager vhost {{docker exec -it mc vi conf/httpd.conf}} # Gracefully reload httpd: {{docker exec mc apachectl -k graceful}} # Repeat 3. two times The same error messages as described in the description will surface. > Multiple invalid nodes created on graceful httpd restart > -------------------------------------------------------- > > Key: MODCLUSTER-570 > URL: https://issues.jboss.org/browse/MODCLUSTER-570 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.5.Final, 1.3.6.Final > Environment: httpd 2.4.25 > Reporter: Antoine Cotten > Assignee: Jean-Frederic Clere > Priority: Minor > Attachments: mod_cluster_after_graceful.png, mod_cluster_before_graceful.png > > > mod_cluster creates a bunch of invalid nodes after a graceful restart of Apache httpd ({{SIGUSR1}}, {{SIGWINCH}}). The issue happens with or without backend servers in the pool. > httpd logs: > {code} > [mpm_event:notice] [pid 1:tid 140313388616520] AH00493: SIGUSR1 received. Doing graceful restart > [:notice] [pid 1:tid 140313388616520] Advertise initialized for process 1 > [mpm_event:notice] [pid 1:tid 140313388616520] AH00489: Apache/2.4.25 (Unix) mod_cluster/1.3.5.Final configured -- resuming normal operations > [core:notice] [pid 1:tid 140313388616520] AH00094: Command line: 'httpd -D FOREGROUND' > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > # ... trimmed 48 lines ... > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://:\x9d\x7f failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] add_balancer_node: balancer safe-name (balancer://4:6666\r\nX-Manager-Url: /c8dae916-7642-4deb-b841-2f3435613749\r\nX-Manager-Protocol: http\r\nX-Manager-Host: 172.17.0.4\r\n\r\n) too long > {code} > Application server logs (tomcat8): > {code} > Feb 01, 2017 11:34:25 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > ERROR: MODCLUSTER000042: Error MEM sending STATUS command to 172.17.0.4/172.17.0.4:6666, configuration will be reset: MEM: Can't read node with "java1-depl1-1234" JVMRoute > Feb 01, 2017 11:34:35 AM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.IllegalArgumentException: Node: [1],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [2],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [3],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > # ... trimmed lines ... > Node: [18],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [19],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Vhost: [0:0:1], Alias: > Vhost: [0:0:2], Alias: > Vhost: [0:0:3], Alias: > # ... trimmed lines ... > Vhost: [0:0:19], Alias: > Vhost: [0:0:20], Alias: > Context: [0:0:1], Context: , Status: REMOVED > Context: [0:0:2], Context: , Status: REMOVED > Context: [0:0:3], Context: , Status: REMOVED > # ... trimmed lines ... > Context: [0:0:97], Context: , Status: REMOVED > Context: [0:0:98], Context: , Status: REMOVED > Context: [0:0:99], Context: , Status: REMOVED > Context: [0:0:1], Context: , Status: REMOVED > at org.jboss.modcluster.mcmp.impl.DefaultMCMPResponseParser.parseInfoResponse(DefaultMCMPResponseParser.java:96) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:396) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:252) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524) > at java.lang.Thread.run(Thread.java:745) > Feb 01, 2017 11:35:05 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-575) Create a Load SPI module

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-575: ----------------------------------------- Summary: Create a Load SPI module Key: MODCLUSTER-575 URL: https://issues.jboss.org/browse/MODCLUSTER-575 Project: mod_cluster Issue Type: Feature Request Components: Core & Container Integration (Java) Reporter: Radoslav Husar Assignee: Jean-Frederic Clere -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-570) Multiple invalid nodes created on graceful httpd restart

by Antoine Cotten (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-570?page=com.atlassian.jira.pl... ] Antoine Cotten updated MODCLUSTER-570: -------------------------------------- Affects Version/s: 1.3.6.Final > Multiple invalid nodes created on graceful httpd restart > -------------------------------------------------------- > > Key: MODCLUSTER-570 > URL: https://issues.jboss.org/browse/MODCLUSTER-570 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.5.Final, 1.3.6.Final > Environment: httpd 2.4.25 > Reporter: Antoine Cotten > Assignee: Jean-Frederic Clere > Priority: Minor > Attachments: mod_cluster_after_graceful.png, mod_cluster_before_graceful.png > > > mod_cluster creates a bunch of invalid nodes after a graceful restart of Apache httpd ({{SIGUSR1}}, {{SIGWINCH}}). The issue happens with or without backend servers in the pool. > httpd logs: > {code} > [mpm_event:notice] [pid 1:tid 140313388616520] AH00493: SIGUSR1 received. Doing graceful restart > [:notice] [pid 1:tid 140313388616520] Advertise initialized for process 1 > [mpm_event:notice] [pid 1:tid 140313388616520] AH00489: Apache/2.4.25 (Unix) mod_cluster/1.3.5.Final configured -- resuming normal operations > [core:notice] [pid 1:tid 140313388616520] AH00094: Command line: 'httpd -D FOREGROUND' > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > # ... trimmed 48 lines ... > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://:\x9d\x7f failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] add_balancer_node: balancer safe-name (balancer://4:6666\r\nX-Manager-Url: /c8dae916-7642-4deb-b841-2f3435613749\r\nX-Manager-Protocol: http\r\nX-Manager-Host: 172.17.0.4\r\n\r\n) too long > {code} > Application server logs (tomcat8): > {code} > Feb 01, 2017 11:34:25 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > ERROR: MODCLUSTER000042: Error MEM sending STATUS command to 172.17.0.4/172.17.0.4:6666, configuration will be reset: MEM: Can't read node with "java1-depl1-1234" JVMRoute > Feb 01, 2017 11:34:35 AM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.IllegalArgumentException: Node: [1],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [2],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [3],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > # ... trimmed lines ... > Node: [18],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [19],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Vhost: [0:0:1], Alias: > Vhost: [0:0:2], Alias: > Vhost: [0:0:3], Alias: > # ... trimmed lines ... > Vhost: [0:0:19], Alias: > Vhost: [0:0:20], Alias: > Context: [0:0:1], Context: , Status: REMOVED > Context: [0:0:2], Context: , Status: REMOVED > Context: [0:0:3], Context: , Status: REMOVED > # ... trimmed lines ... > Context: [0:0:97], Context: , Status: REMOVED > Context: [0:0:98], Context: , Status: REMOVED > Context: [0:0:99], Context: , Status: REMOVED > Context: [0:0:1], Context: , Status: REMOVED > at org.jboss.modcluster.mcmp.impl.DefaultMCMPResponseParser.parseInfoResponse(DefaultMCMPResponseParser.java:96) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:396) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:252) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524) > at java.lang.Thread.run(Thread.java:745) > Feb 01, 2017 11:35:05 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-570) Multiple invalid nodes created on graceful httpd restart

by Antoine Cotten (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-570?page=com.atlassian.jira.pl... ] Antoine Cotten reopened MODCLUSTER-570: --------------------------------------- > Multiple invalid nodes created on graceful httpd restart > -------------------------------------------------------- > > Key: MODCLUSTER-570 > URL: https://issues.jboss.org/browse/MODCLUSTER-570 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.5.Final > Environment: httpd 2.4.25 > Reporter: Antoine Cotten > Assignee: Jean-Frederic Clere > Priority: Minor > Attachments: mod_cluster_after_graceful.png, mod_cluster_before_graceful.png > > > mod_cluster creates a bunch of invalid nodes after a graceful restart of Apache httpd ({{SIGUSR1}}, {{SIGWINCH}}). The issue happens with or without backend servers in the pool. > httpd logs: > {code} > [mpm_event:notice] [pid 1:tid 140313388616520] AH00493: SIGUSR1 received. Doing graceful restart > [:notice] [pid 1:tid 140313388616520] Advertise initialized for process 1 > [mpm_event:notice] [pid 1:tid 140313388616520] AH00489: Apache/2.4.25 (Unix) mod_cluster/1.3.5.Final configured -- resuming normal operations > [core:notice] [pid 1:tid 140313388616520] AH00094: Command line: 'httpd -D FOREGROUND' > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > # ... trimmed 48 lines ... > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://:\x9d\x7f failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] add_balancer_node: balancer safe-name (balancer://4:6666\r\nX-Manager-Url: /c8dae916-7642-4deb-b841-2f3435613749\r\nX-Manager-Protocol: http\r\nX-Manager-Host: 172.17.0.4\r\n\r\n) too long > {code} > Application server logs (tomcat8): > {code} > Feb 01, 2017 11:34:25 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > ERROR: MODCLUSTER000042: Error MEM sending STATUS command to 172.17.0.4/172.17.0.4:6666, configuration will be reset: MEM: Can't read node with "java1-depl1-1234" JVMRoute > Feb 01, 2017 11:34:35 AM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.IllegalArgumentException: Node: [1],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [2],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [3],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > # ... trimmed lines ... > Node: [18],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [19],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Vhost: [0:0:1], Alias: > Vhost: [0:0:2], Alias: > Vhost: [0:0:3], Alias: > # ... trimmed lines ... > Vhost: [0:0:19], Alias: > Vhost: [0:0:20], Alias: > Context: [0:0:1], Context: , Status: REMOVED > Context: [0:0:2], Context: , Status: REMOVED > Context: [0:0:3], Context: , Status: REMOVED > # ... trimmed lines ... > Context: [0:0:97], Context: , Status: REMOVED > Context: [0:0:98], Context: , Status: REMOVED > Context: [0:0:99], Context: , Status: REMOVED > Context: [0:0:1], Context: , Status: REMOVED > at org.jboss.modcluster.mcmp.impl.DefaultMCMPResponseParser.parseInfoResponse(DefaultMCMPResponseParser.java:96) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:396) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:252) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524) > at java.lang.Thread.run(Thread.java:745) > Feb 01, 2017 11:35:05 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-570) Multiple invalid nodes created on graceful httpd restart

by Antoine Cotten (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-570?page=com.atlassian.jira.pl... ] Antoine Cotten commented on MODCLUSTER-570: ------------------------------------------- I managed to reproduce on 1.3.6.Final. It's actually as simple as doing multiple graceful restarts in a row, no need for an application server. What I did: # Run httpd with mod_cluster {{docker run --name mc -p 8080:80 -p 7777:6666 antoineco/httpd-mod_cluster:1.3.6-alpine}} # Uncomment the mod_cluster modules in the config, and uncomment the very last line ({{Include}}) to enable the manager vhost {{docker exec -it mc vi conf/httpd.conf}} # Gracefully reload httpd: {{docker exec mc apachectl -k graceful}} # Repeat 3. two times The same error messages as described in the description will surface. > Multiple invalid nodes created on graceful httpd restart > -------------------------------------------------------- > > Key: MODCLUSTER-570 > URL: https://issues.jboss.org/browse/MODCLUSTER-570 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.5.Final > Environment: httpd 2.4.25 > Reporter: Antoine Cotten > Assignee: Jean-Frederic Clere > Priority: Minor > Attachments: mod_cluster_after_graceful.png, mod_cluster_before_graceful.png > > > mod_cluster creates a bunch of invalid nodes after a graceful restart of Apache httpd ({{SIGUSR1}}, {{SIGWINCH}}). The issue happens with or without backend servers in the pool. > httpd logs: > {code} > [mpm_event:notice] [pid 1:tid 140313388616520] AH00493: SIGUSR1 received. Doing graceful restart > [:notice] [pid 1:tid 140313388616520] Advertise initialized for process 1 > [mpm_event:notice] [pid 1:tid 140313388616520] AH00489: Apache/2.4.25 (Unix) mod_cluster/1.3.5.Final configured -- resuming normal operations > [core:notice] [pid 1:tid 140313388616520] AH00094: Command line: 'httpd -D FOREGROUND' > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 116:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > # ... trimmed 48 lines ... > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://: failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] Created: worker for ://:\x9d\x7f failed: Unable to parse URL > [:notice] [pid 145:tid 140313388616520] add_balancer_node: balancer safe-name (balancer://4:6666\r\nX-Manager-Url: /c8dae916-7642-4deb-b841-2f3435613749\r\nX-Manager-Protocol: http\r\nX-Manager-Host: 172.17.0.4\r\n\r\n) too long > {code} > Application server logs (tomcat8): > {code} > Feb 01, 2017 11:34:25 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > ERROR: MODCLUSTER000042: Error MEM sending STATUS command to 172.17.0.4/172.17.0.4:6666, configuration will be reset: MEM: Can't read node with "java1-depl1-1234" JVMRoute > Feb 01, 2017 11:34:35 AM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren > SEVERE: Exception invoking periodic operation: > java.lang.IllegalArgumentException: Node: [1],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [2],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [3],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > # ... trimmed lines ... > Node: [18],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Node: [19],Name: ,Balancer: ,LBGroup: ,Host: ,Port: ,Type: ,Flushpackets: Off,Flushwait: 0,Ping: 0,Smax: 0,Ttl: 0,Elected: 0,Read: 0,Transfered: 0,Connected: 0,Load: 0 > Vhost: [0:0:1], Alias: > Vhost: [0:0:2], Alias: > Vhost: [0:0:3], Alias: > # ... trimmed lines ... > Vhost: [0:0:19], Alias: > Vhost: [0:0:20], Alias: > Context: [0:0:1], Context: , Status: REMOVED > Context: [0:0:2], Context: , Status: REMOVED > Context: [0:0:3], Context: , Status: REMOVED > # ... trimmed lines ... > Context: [0:0:97], Context: , Status: REMOVED > Context: [0:0:98], Context: , Status: REMOVED > Context: [0:0:99], Context: , Status: REMOVED > Context: [0:0:1], Context: , Status: REMOVED > at org.jboss.modcluster.mcmp.impl.DefaultMCMPResponseParser.parseInfoResponse(DefaultMCMPResponseParser.java:96) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:396) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:457) > at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:252) > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1374) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546) > at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524) > at java.lang.Thread.run(Thread.java:745) > Feb 01, 2017 11:35:05 AM org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler sendRequest > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-574) Allow LoadMetric to put the node into error state

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-574?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-574 started by Radoslav Husar. ------------------------------------------------- > Allow LoadMetric to put the node into error state > ------------------------------------------------- > > Key: MODCLUSTER-574 > URL: https://issues.jboss.org/browse/MODCLUSTER-574 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.3.6.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 2.0.0.Alpha1 > > > This allows implementors of custom load metrics to put the node temporarily in the error state, e.g. when a connection to some sort of backend service is unavailable. > This has been requested multiple times, last time https://github.com/modcluster/mod_cluster/issues/244 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-574) Allow LoadMetric to put the node into error state

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-574?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-574: -------------------------------------- Description: This allows implementors of custom load metrics to put the node temporarily in the error state, e.g. when a connection to some sort of backend service is unavailable. This has been requested multiple times, last time https://github.com/modcluster/mod_cluster/issues/244 was: This allows implementors of custom load metrics to put the node temporarily in the error state. This has been requested multiple times, last time https://github.com/modcluster/mod_cluster/issues/244 > Allow LoadMetric to put the node into error state > ------------------------------------------------- > > Key: MODCLUSTER-574 > URL: https://issues.jboss.org/browse/MODCLUSTER-574 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.3.6.Final > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Critical > Fix For: 2.0.0.Alpha1 > > > This allows implementors of custom load metrics to put the node temporarily in the error state, e.g. when a connection to some sort of backend service is unavailable. > This has been requested multiple times, last time https://github.com/modcluster/mod_cluster/issues/244 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-574) Allow LoadMetric to put the node into error state

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-574: ----------------------------------------- Summary: Allow LoadMetric to put the node into error state Key: MODCLUSTER-574 URL: https://issues.jboss.org/browse/MODCLUSTER-574 Project: mod_cluster Issue Type: Feature Request Components: Core & Container Integration (Java) Affects Versions: 1.3.6.Final Reporter: Radoslav Husar Assignee: Jean-Frederic Clere Priority: Critical Fix For: 2.0.0.Alpha1 This allows implementors of custom load metrics to put the node temporarily in the error state. This has been requested multiple times, last time https://github.com/modcluster/mod_cluster/issues/244 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

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

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-526?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-526: -------------------------------------- Fix Version/s: 1.3.7.Final (was: 1.3.6.Final) > 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 mpm_event > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Blocker > Fix For: 1.3.7.Final > > > h3. Setup > * 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 > h3. 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} > h3. Behavior > {code} > 957 helper = (proxy_cluster_helper *) worker->context; > 961 if (helper) { > 962 i = helper->count_active; > 963 } > 968 if (i == 0) { > 971 proxy_worker_shared *stat = worker->s; > 972 proxy_cluster_helper *helper = (proxy_cluster_helper *) worker->context; > {code} > At this point, {{helper->shared}} points to a {{proxy_worker_shared}} structure that appears to be properly filled. > {code} > 999 if (worker->cp->pool) { > 1000 apr_pool_destroy(worker->cp->pool); > 1001 worker->cp->pool = NULL; > 1002 } > {code} > Regardless of the aforementioned block being there or nor (stuffed after 1010), > {{helper->shared}} suddenly points to {{NULL}}. > {code} > 1008 helper->index = 0; > 1009 worker->s = helper->shared; > {code} > Above assignment makes {{worker->s}} pointing to NULL. > {code} > 1010 memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > {code} > And here we go :( > IMHO, _other thread_ already cleared that memory and nulled the pointer, because it absolutely doesn't happen if > I run 1 process and 1 thread. > The [workaround that prevents the core|https://github.com/modcluster/mod_cluster/pull/207] looks like this: > {code} > if (helper->shared) { > worker->s = helper->shared; > memcpy(worker->s, stat, sizeof(proxy_worker_shared)); > } > {code} > h3. How do we fix it? > Any ideas? [~jfclere] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues March 2017