July 2016 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-447) ProxyInfo not available in Tomcat

by Jean-Frederic Clere (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-447?page=com.atlassian.jira.pl... ] Jean-Frederic Clere resolved MODCLUSTER-447. -------------------------------------------- Resolution: Done > ProxyInfo not available in Tomcat > --------------------------------- > > Key: MODCLUSTER-447 > URL: https://issues.jboss.org/browse/MODCLUSTER-447 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.2.10.Final > Environment: mod_cluster 1.2.10, Tomcat 7.0.57 > Reporter: Alexander Schulz > Assignee: Radoslav Husar > Fix For: 1.2.10.Final > > > I'm looking for a way to read proxy informations from within an application deployed on a Tomcat 7. > > With the jboss cli I can read the proxies info like this: > /host=xyz/server=abc/subsystem=modcluster:read-proxies-info() > > I looked for the ModClusterListener MBean methods and properties in Tomcat 7. I found this method in ModClusterListener: > /** > * {@inhericDoc} > * > * @see org.jboss.modcluster.ModClusterServiceMBean#getProxyInfo() > */ > @Override > public Map<InetSocketAddress, String> getProxyInfo() { > return this.service.getProxyInfo(); > } > > The problem is that I found no proxyInfo method or attribute at the ModClusterListener MBean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-505) ProxyErrorOverride=On causes workers in error state after 500 errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-505: ---------------------------------------------------- George Zaronikas <gzaronik(a)redhat.com> changed the Status of [bug 1338664|https://bugzilla.redhat.com/show_bug.cgi?id=1338664] from ASSIGNED to MODIFIED > ProxyErrorOverride=On causes workers in error state after 500 errors > --------------------------------------------------------------------- > > Key: MODCLUSTER-505 > URL: https://issues.jboss.org/browse/MODCLUSTER-505 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.12.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.3.Final, 1.2.14.Final > > > When a VirtualHost uses ProxyPass to proxy traffic to the backend and uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-505) ProxyErrorOverride=On causes workers in error state after 500 errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-505: ---------------------------------------------------- George Zaronikas <gzaronik(a)redhat.com> changed the Status of [bug 1309598|https://bugzilla.redhat.com/show_bug.cgi?id=1309598] from NEW to MODIFIED > ProxyErrorOverride=On causes workers in error state after 500 errors > --------------------------------------------------------------------- > > Key: MODCLUSTER-505 > URL: https://issues.jboss.org/browse/MODCLUSTER-505 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.2.Final, 1.2.12.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.3.Final, 1.2.14.Final > > > When a VirtualHost uses ProxyPass to proxy traffic to the backend and uses ProxyErrorOverride to host custom error pages on Apache httpd side, when the backend replies with a 50x error code mod_proxy/mod_cluster marks that worker as down, breaking session stickiness. This behaviour is quite similar to have failonstatus=500 for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-522) Memory leak in processing MCMP, wrong apr pool used for allocation

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Michal Karm Babacek commented on MODCLUSTER-522: ------------------------------------------------ Gonna try setting {{status-interval}} attribute of the mod_cluster subsystem element in Wildfly and setting {{org.jboss.modcluster.container.catalina.status-frequency}} for Tomcat to something higher than 1 (means 10 seconds). If it helps, it's {{STATUS}} message; if it doesn't it's probably {{CONFIG}} or {{*-APP}} logic. > Memory leak in processing MCMP, wrong apr pool used for allocation > ------------------------------------------------------------------ > > Key: MODCLUSTER-522 > URL: https://issues.jboss.org/browse/MODCLUSTER-522 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final, 2.0.0.Alpha1 > Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Critical > Attachments: mod_cluster-mem.jpg, mod_cluster-mem1.jpg > > > There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. > TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. > Originally discovered by: [~j_sykora] and [~jmsantuci] > Illustrative memory overview - with constant number of Tomcats: > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-522) Memory leak in processing MCMP, wrong apr pool used for allocation

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-522: ------------------------------------------- Forum Reference: https://developer.jboss.org/message/960119 > Memory leak in processing MCMP, wrong apr pool used for allocation > ------------------------------------------------------------------ > > Key: MODCLUSTER-522 > URL: https://issues.jboss.org/browse/MODCLUSTER-522 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final, 2.0.0.Alpha1 > Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Critical > Attachments: mod_cluster-mem.jpg, mod_cluster-mem1.jpg > > > There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. > TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. > Originally discovered by: [~j_sykora] and [~jmsantuci] > Illustrative memory overview - with constant number of Tomcats: > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-522) Memory leak in processing MCMP, wrong apr pool used for allocation

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-522: ------------------------------------------- Description: There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. Originally discovered by: [~j_sykora] and [~jmsantuci] Illustrative memory overview - with constant number of Tomcats: was: There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. Illustrative memory overview - with constant number of Tomcats: > Memory leak in processing MCMP, wrong apr pool used for allocation > ------------------------------------------------------------------ > > Key: MODCLUSTER-522 > URL: https://issues.jboss.org/browse/MODCLUSTER-522 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final, 2.0.0.Alpha1 > Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Critical > Attachments: mod_cluster-mem.jpg, mod_cluster-mem1.jpg > > > There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. > TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. > Originally discovered by: [~j_sykora] and [~jmsantuci] > Illustrative memory overview - with constant number of Tomcats: > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-522) Memory leak in processing MCMP, wrong apr pool used for allocation

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-522?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-522 started by Michal Karm Babacek. ------------------------------------------------------ > Memory leak in processing MCMP, wrong apr pool used for allocation > ------------------------------------------------------------------ > > Key: MODCLUSTER-522 > URL: https://issues.jboss.org/browse/MODCLUSTER-522 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Affects Versions: 1.3.1.Final, 2.0.0.Alpha1 > Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20 > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Critical > Attachments: mod_cluster-mem.jpg, mod_cluster-mem1.jpg > > > There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. > TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. > Illustrative memory overview - with constant number of Tomcats: > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

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

by Bogdan Sikora (JIRA)

Bogdan Sikora created MODCLUSTER-525: ---------------------------------------- Summary: Failed to start advertise listener: java.net.BindException: Address already in use Key: MODCLUSTER-525 URL: https://issues.jboss.org/browse/MODCLUSTER-525 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)

8 years, 5 months

1
0
0 / 0

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

by Bogdan Sikora (JIRA)

Bogdan Sikora created MODCLUSTER-524: ---------------------------------------- Summary: 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)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-523) Memory leak in processing MCMP, wrong apr pool used for allocation

by Michal Karm Babacek (JIRA)

Michal Karm Babacek created MODCLUSTER-523: ---------------------------------------------- Summary: Memory leak in processing MCMP, wrong apr pool used for allocation Key: MODCLUSTER-523 URL: https://issues.jboss.org/browse/MODCLUSTER-523 Project: mod_cluster Issue Type: Bug Components: Native (httpd modules) Affects Versions: 1.3.1.Final, 2.0.0.Alpha1 Environment: Solaris 10 x86_64, RHEL 6, Fedora 24, httpd 2.4.6, httpd 2.4.20 Reporter: Michal Karm Babacek Assignee: Michal Karm Babacek Priority: Critical There seems to be a wrong apr pool used for processing certain MCMP commands. We should use short life span pools for immediate processing and server-lifetime pools only for really persistent configuration. In the current state, with 20+ tomcat workers (1 alias and 1 context each) and virtually no client requests, we could see slow, but steady growth of heap allocated memory. TODO: Investigate the offending logic, make sure we ain't using long-lived pools for immediate processing. Illustrative memory overview - with constant number of Tomcats: -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 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