[JBoss JIRA] (MODCLUSTER-531) Eliminate automagic
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-531:
--------------------------------------
Description:
I am proposing we abandon automagic as much as possible.
h1. Problem
The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are:
# insecure (listening on all interfaces, allow from all, default security key "changeme!")
# difficult to debug (not clear what is the actual configuration)
# unstable installations (seemingly unrelated aspects like adding an interface or connector break the previously working configuration)
h1. Areas
There are several areas where automagic happens.
h5. Advertised address of the proxy
There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed.
h5. Advertise interfaces
The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly.
h5. Connector address
If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface.
h5. Connector selection
-This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit.- DONE MODCLUSTER-457
h5. Route generation
Remove setJvmRoute from the SPI.
was:
I am proposing we abandon automagic as much as possible.
h1. Problem
The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are:
# insecure (listening on all interfaces, allow from all, default security key "changeme!")
# difficult to debug (not clear what is the actual configuration)
# unstable installations (seemingly unrelated aspects like adding an interface or connector break the config)
h1. Areas
There are several areas where automagic happens.
h5. Advertised address of the proxy
There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed.
h5. Advertise interfaces
The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly.
h5. Connector address
If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface.
h5. Connector selection
-This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit.- DONE MODCLUSTER-457
h5. Route generation
Remove setJvmRoute from the SPI.
> Eliminate automagic
> -------------------
>
> Key: MODCLUSTER-531
> URL: https://issues.jboss.org/browse/MODCLUSTER-531
> Project: mod_cluster
> Issue Type: Enhancement
> Components: Core & Container Integration (Java), Documentation & Demos, Native (httpd modules)
> Affects Versions: 1.2.0.Final, 1.3.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 2.0.0.Alpha1
>
>
> I am proposing we abandon automagic as much as possible.
> h1. Problem
> The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are:
> # insecure (listening on all interfaces, allow from all, default security key "changeme!")
> # difficult to debug (not clear what is the actual configuration)
> # unstable installations (seemingly unrelated aspects like adding an interface or connector break the previously working configuration)
> h1. Areas
> There are several areas where automagic happens.
> h5. Advertised address of the proxy
> There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed.
> h5. Advertise interfaces
> The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly.
> h5. Connector address
> If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface.
> h5. Connector selection
> -This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit.- DONE MODCLUSTER-457
> h5. Route generation
> Remove setJvmRoute from the SPI.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[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 commented on MODCLUSTER-449:
-------------------------------------------
The configuration option is {{initialLoad="50"}} to start with load of 50 which will decay acording to decay configuration.
> 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: Blocker
> Fix For: 1.4.0.Alpha1, 2.0.0.Alpha1
>
> Attachments: httpdRamp-up.jpg, undertowRamp-up.jpg
>
>
> 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
(v7.2.3#72005)
7 years
[JBoss JIRA] (MODCLUSTER-469) Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-469?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-469:
--------------------------------------
Fix Version/s: 1.4.0.Alpha2
> Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-469
> URL: https://issues.jboss.org/browse/MODCLUSTER-469
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.1.Final, 1.4.0.Alpha1
> Environment: Apache 2.4, ModCluster 1.3.1, Tomcat 8.0 standalone
> Reporter: Eric Vernier
> Assignee: Radoslav Husar
> Fix For: 1.4.0.Alpha2
>
>
> If jvmRoute attribute is not set in server.xml on engine element, ModClusterService generates a jvmRoute (UUID). This UUID is not added in the value of the cookie "jsessionid", so the sticky session doesn't work. When the jvmRoute is defined in the server.xml all works fine.
> I known no much about lifecyle in Catalina, but my feeling is that ModClusterService generates the jvmRoute (with JvmRouteFactory)
> after the creation of SessionIdGenerator by the org.apache.catalina.Manager. When ModClusterService injects the generated jvmRoute it's too, the SessionIdGenerator is already created.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (MODCLUSTER-469) Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-469?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-469:
--------------------------------------
Affects Version/s: 1.4.0.Alpha1
> Tomcat8 standalone : jvmRoute not added to jessionid cookie when generated as UUID by JvmRouteFactory
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-469
> URL: https://issues.jboss.org/browse/MODCLUSTER-469
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.1.Final, 1.4.0.Alpha1
> Environment: Apache 2.4, ModCluster 1.3.1, Tomcat 8.0 standalone
> Reporter: Eric Vernier
> Assignee: Radoslav Husar
> Fix For: 1.4.0.Alpha2
>
>
> If jvmRoute attribute is not set in server.xml on engine element, ModClusterService generates a jvmRoute (UUID). This UUID is not added in the value of the cookie "jsessionid", so the sticky session doesn't work. When the jvmRoute is defined in the server.xml all works fine.
> I known no much about lifecyle in Catalina, but my feeling is that ModClusterService generates the jvmRoute (with JvmRouteFactory)
> after the creation of SessionIdGenerator by the org.apache.catalina.Manager. When ModClusterService injects the generated jvmRoute it's too, the SessionIdGenerator is already created.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (MODCLUSTER-531) Eliminate automagic
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-531?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-531:
--------------------------------------
Description:
I am proposing we abandon automagic as much as possible.
h1. Problem
The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are:
# insecure (listening on all interfaces, allow from all, default security key "changeme!")
# difficult to debug (not clear what is the actual configuration)
# unstable installations (seemingly unrelated aspects like adding an interface or connector break the config)
h1. Areas
There are several areas where automagic happens.
h5. Advertised address of the proxy
There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed.
h5. Advertise interfaces
The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly.
h5. Connector address
If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface.
h5. Connector selection
-This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit.- DONE MODCLUSTER-457
h5. Route generation
Remove setJvmRoute from the SPI.
was:
I am proposing we abandon automagic as much as possible.
h1. Problem
The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are:
# insecure (listening on all interfaces, allow from all, default security key "changeme!")
# difficult to debug (not clear what is the actual configuration)
# unstable installations (seemingly unrelated aspects like adding an interface or connector break the config)
h1. Areas
There are several areas where automagic happens.
h5. Advertised address of the proxy
There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed.
h5. Advertise interfaces
The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly.
h5. Connector address
If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface.
h5. Connector selection
This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit.
h5. Route generation
Remove setJvmRoute from the SPI.
> Eliminate automagic
> -------------------
>
> Key: MODCLUSTER-531
> URL: https://issues.jboss.org/browse/MODCLUSTER-531
> Project: mod_cluster
> Issue Type: Enhancement
> Components: Core & Container Integration (Java), Documentation & Demos, Native (httpd modules)
> Affects Versions: 1.2.0.Final, 1.3.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 2.0.0.Alpha1
>
>
> I am proposing we abandon automagic as much as possible.
> h1. Problem
> The main idea for automagic is to make deployment simple and easy to migrate/transfer and provide great user experience out of box. Unfortunately, this IMHO often backfires quite significantly resulting in configurations that are:
> # insecure (listening on all interfaces, allow from all, default security key "changeme!")
> # difficult to debug (not clear what is the actual configuration)
> # unstable installations (seemingly unrelated aspects like adding an interface or connector break the config)
> h1. Areas
> There are several areas where automagic happens.
> h5. Advertised address of the proxy
> There were multiple bugs in the past, where 0.0.0.0 would be sent in the advertise mesages, now if its not explcit in the VirtualHost or passed in to ServerAdvertise, it automagically picks a non-local interface. Such configurations should be disallowed.
> h5. Advertise interfaces
> The interfaces are not explicit and advertise messages could be sent/received on more interfaces (related MODCLUSTER-487). This is also problematic when trying to move to DatagramChannel interface, which requires interfaces to be defined explicitly (MODCLUSTER-502). We can require this explicitly.
> h5. Connector address
> If bound to any-address, the address is inferred from the proxy connection as the local address. This is solved in the default WildFly configuration as its explicitly bound to a interface.
> h5. Connector selection
> -This is solved in WildFly where selection is explicit. In tomcat this causes problems like MODCLUSTER-457 when WS requires http yet ajp is automatically selected by default. We can make this explicit.- DONE MODCLUSTER-457
> h5. Route generation
> Remove setJvmRoute from the SPI.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (MODCLUSTER-607) Support floating-point numerals for decay factor
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-607?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-607:
--------------------------------------
Priority: Critical (was: Major)
> Support floating-point numerals for decay factor
> ------------------------------------------------
>
> Key: MODCLUSTER-607
> URL: https://issues.jboss.org/browse/MODCLUSTER-607
> Project: mod_cluster
> Issue Type: Feature Request
> Components: Core & Container Integration (Java)
> Affects Versions: 1.2.13.Final, 1.3.7.Final
> Reporter: Leandro Quiroga
> Assignee: Radoslav Husar
> Priority: Critical
> Labels: decay
> Fix For: 1.4.0.Alpha1, 2.0.0.Alpha1
>
>
> The int type is too restrictive for specifying the decay factor.
> Using a decay factor of 1 means no decay.
> Next value is 2, and the importance of loads decreases too fast:
> ||Instant||Importance||
> |0|100%|
> |1|50%|
> |2|25%|
> |3|12.5%|
> |4|6.3%|
> |5|3.1%|
> |6|1.6%|
> |7|0.8%|
> |8|0.4%|
> |9|0.2%|
> Next value is 3, and the importance of loads decreases even faster:
> ||Instant||Importance||
> |0|100%|
> |1|33%|
> |2|11%|
> |3|3.7%|
> |4|1.2%|
> |5|0.4%|
> |6|0.1%|
> |7|0.0%|
> |8|0.0%|
> |9|0.0%|
>
> Using a double for decay factor isn't complex and allows much more precision.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years