December 2016 - mod_cluster-issues

[JBoss JIRA] (MODCLUSTER-557) Standby workers should be excluded from the deterministic failover candidate list

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-557?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-557: -------------------------------------- Summary: Standby workers should be excluded from the deterministic failover candidate list (was: Stand-by workers should be excluded from the deterministic failover candidate list) > Standby workers should be excluded from the deterministic failover candidate list > --------------------------------------------------------------------------------- > > Key: MODCLUSTER-557 > URL: https://issues.jboss.org/browse/MODCLUSTER-557 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.6.Final > > > We need to consider standby nodes, when there are only standby nodes in cluster and exclude from the initial candidate list. > No affected version, its master/1.3.6.Final-SNAPSHOT. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-557) Stand-by workers should be excluded from the deterministic failover candidate list

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-557?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-557: -------------------------------------- Description: We need to consider standby nodes, when there are only standby nodes in cluster and exclude from the initial candidate list. No affected version, its master/1.3.6.Final-SNAPSHOT. was:We need to consider standby nodes, when there are only standby nodes in cluster and exclude from the initial candidate list. > Stand-by workers should be excluded from the deterministic failover candidate list > ---------------------------------------------------------------------------------- > > Key: MODCLUSTER-557 > URL: https://issues.jboss.org/browse/MODCLUSTER-557 > Project: mod_cluster > Issue Type: Bug > Components: Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.6.Final > > > We need to consider standby nodes, when there are only standby nodes in cluster and exclude from the initial candidate list. > No affected version, its master/1.3.6.Final-SNAPSHOT. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-557) Stand-by workers should be excluded from the deterministic failover candidate list

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-557: ----------------------------------------- Summary: Stand-by workers should be excluded from the deterministic failover candidate list Key: MODCLUSTER-557 URL: https://issues.jboss.org/browse/MODCLUSTER-557 Project: mod_cluster Issue Type: Bug Components: Native (httpd modules) Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 1.3.6.Final We need to consider standby nodes, when there are only standby nodes in cluster and exclude from the initial candidate list. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-556) Consider protobuf-c (plain C Google Protocol Buffers) to replace shm slotmem and allow multiple httpd instances state sharing

by Michal Karm Babacek (JIRA)

Michal Karm Babacek created MODCLUSTER-556: ---------------------------------------------- Summary: Consider protobuf-c (plain C Google Protocol Buffers) to replace shm slotmem and allow multiple httpd instances state sharing Key: MODCLUSTER-556 URL: https://issues.jboss.org/browse/MODCLUSTER-556 Project: mod_cluster Issue Type: Feature Request Components: Native (httpd modules) Reporter: Michal Karm Babacek Assignee: Michal Karm Babacek Lemme leave it here for future coding spree: * shm is PITA, any update of data model is very scary * the only description of data is in code, our structures and additional meta data like timestamps * adding and removing records from shm causes leftover artifacts that are not cleaned up * meticulous locking on shm access is a bottleneck, it is making httpd slower than Java Undertow implementation when it comes to huge concurrency * storing and loading data structures as Google Protocol Buffers would allow for httpd processes to behave as actors, sending and receiving messages and thus achieve much higher level of concurrency than locking a single shared mem file * furthermore, it would actually allow multiple httpd instances to share mod_proxy_cluster state, blurring the difference between httpd child processes and separate httpd instances * Google Protocol Buffers https://developers.google.com/protocol-buffers/ * protobuf-c (plain C) https://github.com/protobuf-c/protobuf-c -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-556) Consider protobuf-c to replace shm slotmem and allow multiple httpd instances state sharing

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-556?page=com.atlassian.jira.pl... ] Michal Karm Babacek updated MODCLUSTER-556: ------------------------------------------- Summary: Consider protobuf-c to replace shm slotmem and allow multiple httpd instances state sharing (was: Consider protobuf-c (plain C Google Protocol Buffers) to replace shm slotmem and allow multiple httpd instances state sharing) > Consider protobuf-c to replace shm slotmem and allow multiple httpd instances state sharing > ------------------------------------------------------------------------------------------- > > Key: MODCLUSTER-556 > URL: https://issues.jboss.org/browse/MODCLUSTER-556 > Project: mod_cluster > Issue Type: Feature Request > Components: Native (httpd modules) > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > > Lemme leave it here for future coding spree: > * shm is PITA, any update of data model is very scary > * the only description of data is in code, our structures and additional meta data like timestamps > * adding and removing records from shm causes leftover artifacts that are not cleaned up > * meticulous locking on shm access is a bottleneck, it is making httpd slower than Java Undertow implementation when it comes to huge concurrency > * storing and loading data structures as Google Protocol Buffers would allow for httpd processes to behave as actors, sending and receiving messages and thus achieve much higher level of concurrency than locking a single shared mem file > * furthermore, it would actually allow multiple httpd instances to share mod_proxy_cluster state, blurring the difference between httpd child processes and separate httpd instances > * Google Protocol Buffers https://developers.google.com/protocol-buffers/ > * protobuf-c (plain C) https://github.com/protobuf-c/protobuf-c -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues December 2016