December 2015 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-318) make connector address user configurable

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-318?page=com.atlassian.jira.pl... ] James Livingston commented on MODCLUSTER-318: --------------------------------------------- This would also be useful to handle the case when there is a NAT between httpd and the backend, in which case the connector binding address is not the address that httpd can reach it on. That has been brought up a few times in the forum such as https://developer.jboss.org/thread/249888 > make connector address user configurable > ---------------------------------------- > > Key: MODCLUSTER-318 > URL: https://issues.jboss.org/browse/MODCLUSTER-318 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.2.1.Final > Reporter: Aleksandar Kostadinov > Assignee: Paul Ferraro > > MODCLUSTER-168 introduced a change that broke some existing working configurations relying on using IP instead of a hostname. Also it is likely to be the cause of MODCLUSTER-91. > To have everybody happy, this needs to be made configurable, perhaps a system property that user can set to force a particular IP or hostname. It would also be very useful if there is a special value that makes the behavior same as before the changes in MODCLUSTER-168. For example setting the value to -1 would return the original behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-472) wildfly-mod_cluster integration should load-balance requests on more than one ports

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-472?page=com.atlassian.jira.pl... ] Radoslav Husar reassigned MODCLUSTER-472: ----------------------------------------- Assignee: Radoslav Husar (was: Jean-Frederic Clere) > wildfly-mod_cluster integration should load-balance requests on more than one ports > ----------------------------------------------------------------------------------- > > Key: MODCLUSTER-472 > URL: https://issues.jboss.org/browse/MODCLUSTER-472 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final > Environment: httpd 2.2 > modcluster 1.3.0 > wildfly 8.2.0.Final > Reporter: kostd kostd > Assignee: Radoslav Husar > Priority: Trivial > Labels: connector, listener, load-balancing, mod_cluster, port, undertow, wildfly > Attachments: load-balancer-question-scheme.png > > > Earlier I asked on forums https://developer.jboss.org/message/946476#946476 > {quote} > on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area. > > we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304. > > In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section: > > {code:title=jboss-as-mod-cluster_1_2.xsd} > <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/> > {code} > > alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304. > But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both. > > Seems that mod_cluster absolutely not supports more than one connector balancing: > > {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf} > Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to > which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not > confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector > can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml, > mod_cluster uses the following algorithm to choose between them: > 1. If an native (APR) AJP connector is available, use it. > 2. If an AJP connector is available, use it. > 3. Otherwise, choose the HTTP connector with the highest max threads. > {code} > > is this true? > > what is the best way to solve our problem? > {quote} > During more than 100 views no one answer :'( > Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-472) wildfly-mod_cluster integration should load-balance requests on more than one ports

by kostd kostd (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-472?page=com.atlassian.jira.pl... ] kostd kostd updated MODCLUSTER-472: ----------------------------------- Priority: Trivial (was: Minor) > wildfly-mod_cluster integration should load-balance requests on more than one ports > ----------------------------------------------------------------------------------- > > Key: MODCLUSTER-472 > URL: https://issues.jboss.org/browse/MODCLUSTER-472 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final > Environment: httpd 2.2 > modcluster 1.3.0 > wildfly 8.2.0.Final > Reporter: kostd kostd > Assignee: Jean-Frederic Clere > Priority: Trivial > Labels: connector, listener, load-balancing, mod_cluster, port, undertow, wildfly > Attachments: load-balancer-question-scheme.png > > > Earlier I asked on forums https://developer.jboss.org/message/946476#946476 > {quote} > on our wf8.2 server the web-app have two http endpoints: on port 8080 to regular http requests; and on port 37304 to "special" user requests in protected area. > > we want use mod_cluster as load-balancer that balances user requests on both ports. For example(see the pic), lets requests on balancer`s port 7801 will be balance between node1 and node2 on port 8080, and requests on balancer`s port 7802 will be balance on port 37304. > > In modcluster-subsystem configuration in standalone.xml we can set only one connector for mod-cluster config. And cannot set more than one mod-cluster-config section: > > {code:title=jboss-as-mod-cluster_1_2.xsd} > <xs:element name="mod-cluster-config" type="mod-cluster-configType" minOccurs="0" maxOccurs="1"/> > {code} > > alternatively, we can use mod_cluster + mod_proxy_balancer or mod_cluster + mod_jk so that mod_cluster balances on 8080 and other tech(mod_proxy_balancer or mod_jk) balances on other port 37304. > But this decision obviously not good: reverse loopback from servers(mgmt info with loadfactor of server) to balancer will manage balancing only for one port, not for both. > > Seems that mod_cluster absolutely not supports more than one connector balancing: > > {code:title=http://docs.jboss.org/mod_cluster/1.3.0/pdf/Mod_cluster-UserGuide.pdf} > Like mod_jk and mod_proxy_balancer, mod_cluster requires a connector in your server.xml to > which to forward web requests. Unlike mod_jk and mod_proxy_balancer, mod_cluster is not > confined to AJP, but can use HTTP as well. While AJP is generally faster, an HTTP connector > can optionally be secured via SSL. If multiple possible connectors are defined in your server.xml, > mod_cluster uses the following algorithm to choose between them: > 1. If an native (APR) AJP connector is available, use it. > 2. If an AJP connector is available, use it. > 3. Otherwise, choose the HTTP connector with the highest max threads. > {code} > > is this true? > > what is the best way to solve our problem? > {quote} > During more than 100 views no one answer :'( > Now we have made a decision to use mod_proxy_balancer, but if it possible to refine mod_cluster subsystem, this will be greate. When it happens, we will jump to mod_cluster again :) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-460) Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-460?page=com.atlassian.jira.pl... ] Radoslav Husar edited comment on MODCLUSTER-460 at 12/7/15 10:24 AM: --------------------------------------------------------------------- Had to revert the original fix, the fix would be stop using old IO altogether. was (Author: rhusar): Had to revert the original fix, the fix would be stop using old IO. > Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-460 > URL: https://issues.jboss.org/browse/MODCLUSTER-460 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 1.3.2.Alpha1 > > > This seems to be caused by the legacy code in mod_cluster, which could instead make use of interruptible channels introduced since JDK 1.4. Simpler option would be log this message onto debug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-460) Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-460?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-460: ------------------------------------------- Had to revert the original fix, the fix would be stop using old IO. > Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-460 > URL: https://issues.jboss.org/browse/MODCLUSTER-460 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 1.3.2.Alpha1 > > > This seems to be caused by the legacy code in mod_cluster, which could instead make use of interruptible channels introduced since JDK 1.4. Simpler option would be log this message onto debug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-460) Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-460?page=com.atlassian.jira.pl... ] Work on MODCLUSTER-460 stopped by Radoslav Husar. ------------------------------------------------- > Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown > --------------------------------------------------------------------------------------- > > Key: MODCLUSTER-460 > URL: https://issues.jboss.org/browse/MODCLUSTER-460 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 1.3.2.Alpha1 > > > This seems to be caused by the legacy code in mod_cluster, which could instead make use of interruptible channels introduced since JDK 1.4. Simpler option would be log this message onto debug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-473) Describe Context#getPath contract when dealing with the root context

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-473?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-473: -------------------------------------- Issue Type: Enhancement (was: Bug) > Describe Context#getPath contract when dealing with the root context > -------------------------------------------------------------------- > > Key: MODCLUSTER-473 > URL: https://issues.jboss.org/browse/MODCLUSTER-473 > Project: mod_cluster > Issue Type: Enhancement > Components: Documentation & Demos > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Optional > Fix For: 1.3.2.Alpha1 > > > Tomcat used "" to represent root context path, yet with undertow, the path is represented as "/". This is not handled well by modcluster. The container SPI could encapsulate the details of how the root context is treated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-473) Describe Context#getPath contract when dealing with the root context

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-473?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-473: -------------------------------------- Priority: Optional (was: Major) > Describe Context#getPath contract when dealing with the root context > -------------------------------------------------------------------- > > Key: MODCLUSTER-473 > URL: https://issues.jboss.org/browse/MODCLUSTER-473 > Project: mod_cluster > Issue Type: Bug > Components: Documentation & Demos > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Optional > Fix For: 1.3.2.Alpha1 > > > Tomcat used "" to represent root context path, yet with undertow, the path is represented as "/". This is not handled well by modcluster. The container SPI could encapsulate the details of how the root context is treated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-473) Describe Context#getPath contract when dealing with the root context

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-473?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-473: -------------------------------------- Component/s: Documentation & Demos (was: Core & Container Integration (Java)) > Describe Context#getPath contract when dealing with the root context > -------------------------------------------------------------------- > > Key: MODCLUSTER-473 > URL: https://issues.jboss.org/browse/MODCLUSTER-473 > Project: mod_cluster > Issue Type: Bug > Components: Documentation & Demos > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.2.Alpha1 > > > Tomcat used "" to represent root context path, yet with undertow, the path is represented as "/". This is not handled well by modcluster. The container SPI could encapsulate the details of how the root context is treated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-473) Describe Context#getPath contract when dealing with the root context

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-473?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-473: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 1.3.2.Alpha1 Resolution: Done > Describe Context#getPath contract when dealing with the root context > -------------------------------------------------------------------- > > Key: MODCLUSTER-473 > URL: https://issues.jboss.org/browse/MODCLUSTER-473 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.2.Alpha1 > > > Tomcat used "" to represent root context path, yet with undertow, the path is represented as "/". This is not handled well by modcluster. The container SPI could encapsulate the details of how the root context is treated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues December 2015