[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:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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: Radoslav Husar
> Fix For: 2.0.0.Alpha1
>
>
> Currently, implementers of a custom LoadMetric need to pull in entire core module. A load spi module could be created, which then along with the container spi module is sufficient for metric implementers to import.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 9 months
[JBoss JIRA] (MODCLUSTER-596) mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-596?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-596:
--------------------------------------
Affects Version/s: 1.3.6.Final
(was: 2.0.0.Alpha1)
(was: 1.3.7.Final)
> mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-596
> URL: https://issues.jboss.org/browse/MODCLUSTER-596
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.6.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 2.0.0.Alpha1, 1.3.7.Final
>
>
> CLI operation description
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "stop",
> "description" => "Tell reverse proxies that all contexts on the node can't process requests.",
> "request-properties" => {"waittime" => {
> "type" => INT,
> "description" => "Timeout to wait for all contexts to stop.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => 10,
> "unit" => "SECONDS"
> }},
> "reply-properties" => {},
> "read-only" => false,
> "runtime-only" => true
> }
> }
> {noformat}
> With default and non-distributable context or draining strategy set to ALWAYS.
> * stop() or stop-context is called
> * Disable creating any new session by sending DISABLE-APP command to balancer
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
> * Session drain
> {noformat}
> 2017-05-10 09:19:09,956 INFO [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/clusterbench in 10 seconds.
> {noformat}
> * Session timeout is 5 minutes so it fails
> {noformat}
> 2017-05-10 09:26:05,081 WARN [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000025: Failed to drain 1 remaining active sessions from default-host:/clusterbench within 10.0 seconds
> {noformat}
> *_+{color:red}Issue{color}+_*
> * Stop-app should be sent to balancer to stop context/node, but node/context stays disabled. This happens even if session drain is successful.
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 9 months
[JBoss JIRA] (MODCLUSTER-596) mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-596?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-596:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 2.0.0.Alpha1
1.3.7.Final
Resolution: Done
> mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-596
> URL: https://issues.jboss.org/browse/MODCLUSTER-596
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.6.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 2.0.0.Alpha1, 1.3.7.Final
>
>
> CLI operation description
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "stop",
> "description" => "Tell reverse proxies that all contexts on the node can't process requests.",
> "request-properties" => {"waittime" => {
> "type" => INT,
> "description" => "Timeout to wait for all contexts to stop.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => 10,
> "unit" => "SECONDS"
> }},
> "reply-properties" => {},
> "read-only" => false,
> "runtime-only" => true
> }
> }
> {noformat}
> With default and non-distributable context or draining strategy set to ALWAYS.
> * stop() or stop-context is called
> * Disable creating any new session by sending DISABLE-APP command to balancer
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
> * Session drain
> {noformat}
> 2017-05-10 09:19:09,956 INFO [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/clusterbench in 10 seconds.
> {noformat}
> * Session timeout is 5 minutes so it fails
> {noformat}
> 2017-05-10 09:26:05,081 WARN [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000025: Failed to drain 1 remaining active sessions from default-host:/clusterbench within 10.0 seconds
> {noformat}
> *_+{color:red}Issue{color}+_*
> * Stop-app should be sent to balancer to stop context/node, but node/context stays disabled. This happens even if session drain is successful.
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 9 months
[JBoss JIRA] (MODCLUSTER-383) Session draining broken: requests counting broken on load-balancer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-383?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on MODCLUSTER-383:
----------------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1018705|https://bugzilla.redhat.com/show_bug.cgi?id=1018705] from ASSIGNED to CLOSED
> Session draining broken: requests counting broken on load-balancer
> ------------------------------------------------------------------
>
> Key: MODCLUSTER-383
> URL: https://issues.jboss.org/browse/MODCLUSTER-383
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.0.Alpha1
> Environment: Fedora 20, 64 bit, httpd 2.4.6 + mod_cluster master (21ceed3c219fc3ad743b361cafd1097ebac19dfe)
> Reporter: Radoslav Husar
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.3.0.Final
>
>
> The request counting is broken. Looks like synchronization problem with dirty cached reads.
> Steps to reproduce:
> # start AS with some context
> # start LB
> # start 2 or more load driver threads
> # number of requests on that context goes to higher values than 2, eventually and slowly increasing
> On the AS it manifests as:
> {noformat}
> 19:44:14,160 WARN [org.jboss.modcluster] (MSC service thread 1-7) MODCLUSTER000022: Failed to drain 57 remaining pending requests from default-host:/clusterbench within 10.0 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 9 months
[JBoss JIRA] (MODCLUSTER-596) mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-596?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-596:
--------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/modcluster/mod_cluster/pull/264, https://github.com/modcluster/mod_cluster/pull/265
> mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-596
> URL: https://issues.jboss.org/browse/MODCLUSTER-596
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 2.0.0.Alpha1, 1.3.7.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> CLI operation description
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "stop",
> "description" => "Tell reverse proxies that all contexts on the node can't process requests.",
> "request-properties" => {"waittime" => {
> "type" => INT,
> "description" => "Timeout to wait for all contexts to stop.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => 10,
> "unit" => "SECONDS"
> }},
> "reply-properties" => {},
> "read-only" => false,
> "runtime-only" => true
> }
> }
> {noformat}
> With default and non-distributable context or draining strategy set to ALWAYS.
> * stop() or stop-context is called
> * Disable creating any new session by sending DISABLE-APP command to balancer
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
> * Session drain
> {noformat}
> 2017-05-10 09:19:09,956 INFO [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/clusterbench in 10 seconds.
> {noformat}
> * Session timeout is 5 minutes so it fails
> {noformat}
> 2017-05-10 09:26:05,081 WARN [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000025: Failed to drain 1 remaining active sessions from default-host:/clusterbench within 10.0 seconds
> {noformat}
> *_+{color:red}Issue{color}+_*
> * Stop-app should be sent to balancer to stop context/node, but node/context stays disabled. This happens even if session drain is successful.
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 9 months
[JBoss JIRA] (MODCLUSTER-596) mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-596?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-596:
--------------------------------------
Due Date: 28/Jun/17
> mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-596
> URL: https://issues.jboss.org/browse/MODCLUSTER-596
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 2.0.0.Alpha1, 1.3.7.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> CLI operation description
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "stop",
> "description" => "Tell reverse proxies that all contexts on the node can't process requests.",
> "request-properties" => {"waittime" => {
> "type" => INT,
> "description" => "Timeout to wait for all contexts to stop.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => 10,
> "unit" => "SECONDS"
> }},
> "reply-properties" => {},
> "read-only" => false,
> "runtime-only" => true
> }
> }
> {noformat}
> With default and non-distributable context or draining strategy set to ALWAYS.
> * stop() or stop-context is called
> * Disable creating any new session by sending DISABLE-APP command to balancer
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
> * Session drain
> {noformat}
> 2017-05-10 09:19:09,956 INFO [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/clusterbench in 10 seconds.
> {noformat}
> * Session timeout is 5 minutes so it fails
> {noformat}
> 2017-05-10 09:26:05,081 WARN [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000025: Failed to drain 1 remaining active sessions from default-host:/clusterbench within 10.0 seconds
> {noformat}
> *_+{color:red}Issue{color}+_*
> * Stop-app should be sent to balancer to stop context/node, but node/context stays disabled. This happens even if session drain is successful.
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 9 months
[JBoss JIRA] (MODCLUSTER-596) mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-596?page=com.atlassian.jira.pl... ]
Radoslav Husar moved JBEAP-11793 to MODCLUSTER-596:
---------------------------------------------------
Project: mod_cluster (was: JBoss Enterprise Application Platform)
Key: MODCLUSTER-596 (was: JBEAP-11793)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Core & Container Integration (Java)
(was: mod_cluster)
Affects Version/s: 2.0.0.Alpha1
1.3.7.Final
(was: 7.1.0.DR16)
(was: 7.1.0.DR17)
> mod_cluster stop/stop-context operations do not send STOP-* in when session draining was unsuccessful
> -----------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-596
> URL: https://issues.jboss.org/browse/MODCLUSTER-596
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 2.0.0.Alpha1, 1.3.7.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> CLI operation description
> {noformat}
> [standalone@localhost:9990 /] /subsystem=modcluster/:read-operation-description(name=stop
> {
> "outcome" => "success",
> "result" => {
> "operation-name" => "stop",
> "description" => "Tell reverse proxies that all contexts on the node can't process requests.",
> "request-properties" => {"waittime" => {
> "type" => INT,
> "description" => "Timeout to wait for all contexts to stop.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => 10,
> "unit" => "SECONDS"
> }},
> "reply-properties" => {},
> "read-only" => false,
> "runtime-only" => true
> }
> }
> {noformat}
> With default and non-distributable context or draining strategy set to ALWAYS.
> * stop() or stop-context is called
> * Disable creating any new session by sending DISABLE-APP command to balancer
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
> * Session drain
> {noformat}
> 2017-05-10 09:19:09,956 INFO [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000046: Starting to drain 1 active sessions from default-host:/clusterbench in 10 seconds.
> {noformat}
> * Session timeout is 5 minutes so it fails
> {noformat}
> 2017-05-10 09:26:05,081 WARN [org.jboss.modcluster] (management-handler-thread - 1) MODCLUSTER000025: Failed to drain 1 remaining active sessions from default-host:/clusterbench within 10.0 seconds
> {noformat}
> *_+{color:red}Issue{color}+_*
> * Stop-app should be sent to balancer to stop context/node, but node/context stays disabled. This happens even if session drain is successful.
> {noformat}
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "disabled"
> }}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 9 months
[JBoss JIRA] (MODCLUSTER-430) CreateBalancers behave the same with option 0 or 2
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-430?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-430:
--------------------------------------
Fix Version/s: (was: 1.2.14.Final)
(was: 1.3.7.Final)
> CreateBalancers behave the same with option 0 or 2
> --------------------------------------------------
>
> Key: MODCLUSTER-430
> URL: https://issues.jboss.org/browse/MODCLUSTER-430
> Project: mod_cluster
> Issue Type: Bug
> Components: Native (httpd modules)
> Affects Versions: 1.3.0.Final, 1.2.9.Final
> Environment: RHEL 6.4.0
> Apache HTTPD 2.4.10
> JBoss 6.1.1
> Mod_cluster 1.3.0 Final
> Reporter: John Jerome
> Assignee: Michal Karm Babacek
>
> The directive CreateBalancers with directive 0 or 2 creates the balancers on all httpd vhosts.
> With option 2, the balancers should be created on the main server only, not in the vhosts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 10 months
[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: (was: 1.3.7.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
>
> 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)
6 years, 10 months