August 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-3) Mod-Cluster event listener for JBossWeb lifecycle and deployment events

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-3?page=com.atlassian.jira.plug... ] Michal Babacek closed MODCLUSTER-3. ----------------------------------- Closing. Clean-up. > Mod-Cluster event listener for JBossWeb lifecycle and deployment events > ----------------------------------------------------------------------- > > Key: MODCLUSTER-3 > URL: https://issues.jboss.org/browse/MODCLUSTER-3 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Fix For: 1.0.0.Beta1 > > > Listen for lifecycle events in JBossWeb. That is, server start/stop, connector start/stop, deployment/undeployment of contexts. > Current plan is to use the existing ClusterListener the JBossWeb team has created for standalone JBossWeb. So, this task is mostly about deploying that listener as part of an aggregate solution. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-1) Could The Web Tier Tell JBoss About Itself Via HTTP?

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-1?page=com.atlassian.jira.plug... ] Michal Babacek closed MODCLUSTER-1. ----------------------------------- Resolution: Deferred Closing. Clean-up. > Could The Web Tier Tell JBoss About Itself Via HTTP? > ---------------------------------------------------- > > Key: MODCLUSTER-1 > URL: https://issues.jboss.org/browse/MODCLUSTER-1 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Jimmy Wilson > Assignee: Paul Ferraro > Priority: Minor > > In cases where there is a firewall between Apache and JBoss, could the web tier use multicast to either tell the other Apache servers about itself or to retrieve the names of the JBoss servers from another Apache instance so that it (or another Apache instance) could use an HTTP request to tell the JBoss nodes about itself gaining automatic configuration even in the firewall case? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-417) Obfuscating jvmRoute as to hide topology

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-417?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-417. ------------------------------------- Closing. Clean-up. > Obfuscating jvmRoute as to hide topology > ---------------------------------------- > > Key: MODCLUSTER-417 > URL: https://issues.jboss.org/browse/MODCLUSTER-417 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Native (httpd modules) > Affects Versions: 1.3.0.Final, 1.2.9.Final > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Priority: Minor > > Feature request from https://github.com/jmcabrera > Hello guys. > First of all, this is a feature request and not a bug. > I would like to "obfuscate" the jvmRoute so that an external attacker cannot "guess" the topology of my internal infrastructure. > The "strong" way would be to have a symmetrical cipher with a configurable key. > mod_cluster could then cipher the jsessionid before exposing it to the external world, and decipher it to recover the jvmRoute and properly redirect the request. > But I guess that this would have very undesirable consequences on performance. > The "weak" way would be just obfuscate, i.e. let's say that the jsessionid is alea + '.' + jvmRoute. We could take a part of the alea to alter the jvmroute in a reversible way (XORing for instance). > Anyhow, the expected effect would be that the jvmroute would be externally different for each and every request. > Unfortunately, I have close to no C skills, hence I cannot make this myself. > (as a side note, coming from mod_jk, I'm quite impressed by the features mod_cluster offers! Thanks for the good work :) ) -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-404) ModClusterService stop commands are always draining sessions

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-404?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-404. ------------------------------------- Closing. > ModClusterService stop commands are always draining sessions > ------------------------------------------------------------ > > Key: MODCLUSTER-404 > URL: https://issues.jboss.org/browse/MODCLUSTER-404 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > Using the ModClusterService stop or stopContext commands via CLI always fails to move a context to the STOPPED state after failing to drain the active sessions. So these commands then aren't very useful for quickly stopping the context when desired if you can't do it without draining. > I think it'd make sense for any draining done by manual stops to also follow the session draining strategy used by typical stops from undeploy events. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-407) worker-timeout can cause httpd thread stalls

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-407?page=com.atlassian.jira.pl... ] Michal Babacek closed MODCLUSTER-407. ------------------------------------- Closing. > worker-timeout can cause httpd thread stalls > -------------------------------------------- > > Key: MODCLUSTER-407 > URL: https://issues.jboss.org/browse/MODCLUSTER-407 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > Setting a modcluster worker-timeout can stall requests and threads on the httpd side when the requests are received with workers in a down state. A stack of the problem thread looks like the following (recursive loops through mod_proxy_cluster from #160 to #2): > #0 0x00007ff8eb547533 in select () from /lib64/libc.so.6 > #1 0x00007ff8eba39185 in apr_sleep () from /usr/lib64/libapr-1.so.0 > #2 0x00007ff8e84be0d1 in ?? () from /etc/httpd/modules/mod_proxy_cluster.so > ... > #160 0x00007ff8e84beb9f in ?? () from /etc/httpd/modules/mod_proxy_cluster.so > #161 0x00007ff8e88d2116 in proxy_run_pre_request () from /etc/httpd/modules/mod_proxy.so > #162 0x00007ff8e88d9186 in ap_proxy_pre_request () from /etc/httpd/modules/mod_proxy.so > #163 0x00007ff8e88d63c2 in ?? () from /etc/httpd/modules/mod_proxy.so -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-404) ModClusterService stop commands are always draining sessions

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-404?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-404: -------------------------------------- Bugzilla Update: (was: Perform) > ModClusterService stop commands are always draining sessions > ------------------------------------------------------------ > > Key: MODCLUSTER-404 > URL: https://issues.jboss.org/browse/MODCLUSTER-404 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final, 1.2.9.Final > > > Using the ModClusterService stop or stopContext commands via CLI always fails to move a context to the STOPPED state after failing to drain the active sessions. So these commands then aren't very useful for quickly stopping the context when desired if you can't do it without draining. > I think it'd make sense for any draining done by manual stops to also follow the session draining strategy used by typical stops from undeploy events. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-415) Drop support for HP-UX older than HP-UX 11v3 (Itanium 64)

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-415?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-415: ------------------------------------------- Happy to hear that. I'll exclude it from the current 1.2.10.dev build effort. > Drop support for HP-UX older than HP-UX 11v3 (Itanium 64) > --------------------------------------------------------- > > Key: MODCLUSTER-415 > URL: https://issues.jboss.org/browse/MODCLUSTER-415 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Documentation & Demos, Native (httpd modules) > Reporter: Radoslav Husar > Assignee: Jean-Frederic Clere > Fix For: 1.3.1.Final > > > As per https://access.redhat.com/site/articles/111663 we can drop support for HP-UX older than HP-UX 11v3 (Itanium 64). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-420) Consider dropping support for very old versions of httpd

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-420?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-420: ------------------------------------------- [~rhusar] Are you going to slaughter these ifdefs? I might quite enjoy it and run the full test suite after each block removal. > Consider dropping support for very old versions of httpd > -------------------------------------------------------- > > Key: MODCLUSTER-420 > URL: https://issues.jboss.org/browse/MODCLUSTER-420 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Native (httpd modules) > Affects Versions: 1.3.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > The EWS is built on 2.2.24 and further on when productizing modcluster, this version might even increase. Lets consider dropping older versions prior to this one. > If the decision is made, you can assign to me to remove the support. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-391: ------------------------------------------- Regarding MODCLUSTER-425, todo 4 mbabacek: Verify that the timeouts are really used as configured. > mod_cluster and mod_proxy integration > ------------------------------------- > > Key: MODCLUSTER-391 > URL: https://issues.jboss.org/browse/MODCLUSTER-391 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.6.Final > Environment: All platforms we build mod_cluster for. > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Labels: native_libraries > Fix For: 1.3.1.Final, 1.2.10.Final > > Attachments: error_log, mod_cluster.conf, mod_proxy.conf, standalone-ha.xml > > > This Jira encapsulates all concerns regarding mod_cluster - mod_proxy integration. For instance, while basic {{ProxyPass}} settings work just fine, e.g. serving some files on {{/static}} from the Apache HTTP itself: > {code} > ProxyPassMatch ^/static/ ! > ProxyPass / balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on > ProxyPassReverse / balancer://qacluster > ProxyPreserveHost on > {code} > there are more complex setups, involving {{BalancerMember}} configurations, that do not work as expected. In the following example, one wanted to have {{/clusterbench}} application managed by mod_cluster, dynamically, while at the same time, in a different VirtualHost, having {{/tses}} application handled by manually created mod_proxy balancer settings. > Attached [^mod_cluster.conf], [^mod_proxy.conf], [^standalone-ha.xml](modcluster subsystem element only) and [^error_log]. > The aforementioned setup resulted in: > |HTTP 200|(From worker)|http://10.16.88.19:8847/clusterbench/requestinfo/|OK|(/)| > |HTTP 404|(From httpd)|http://10.16.88.19:8847/tses/session.jsp|Expected fail|(/)| > |HTTP 503|(From httpd)|http://10.16.88.19:2182/tses/session.jsp|Unexpected fail|(x)| -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-391) mod_cluster and mod_proxy integration

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-391?page=com.atlassian.jira.pl... ] Michal Babacek updated MODCLUSTER-391: -------------------------------------- Comment: was deleted (was: Pavel Slavicek <pslavice(a)redhat.com> changed the Status of [bug 987259|https://bugzilla.redhat.com/show_bug.cgi?id=987259] from VERIFIED to CLOSED) > mod_cluster and mod_proxy integration > ------------------------------------- > > Key: MODCLUSTER-391 > URL: https://issues.jboss.org/browse/MODCLUSTER-391 > Project: mod_cluster > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.6.Final > Environment: All platforms we build mod_cluster for. > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Labels: native_libraries > Fix For: 1.3.1.Final, 1.2.10.Final > > Attachments: error_log, mod_cluster.conf, mod_proxy.conf, standalone-ha.xml > > > This Jira encapsulates all concerns regarding mod_cluster - mod_proxy integration. For instance, while basic {{ProxyPass}} settings work just fine, e.g. serving some files on {{/static}} from the Apache HTTP itself: > {code} > ProxyPassMatch ^/static/ ! > ProxyPass / balancer://qacluster stickysession=JSESSIONID|jsessionid nofailover=on > ProxyPassReverse / balancer://qacluster > ProxyPreserveHost on > {code} > there are more complex setups, involving {{BalancerMember}} configurations, that do not work as expected. In the following example, one wanted to have {{/clusterbench}} application managed by mod_cluster, dynamically, while at the same time, in a different VirtualHost, having {{/tses}} application handled by manually created mod_proxy balancer settings. > Attached [^mod_cluster.conf], [^mod_proxy.conf], [^standalone-ha.xml](modcluster subsystem element only) and [^error_log]. > The aforementioned setup resulted in: > |HTTP 200|(From worker)|http://10.16.88.19:8847/clusterbench/requestinfo/|OK|(/)| > |HTTP 404|(From httpd)|http://10.16.88.19:8847/tses/session.jsp|Expected fail|(/)| > |HTTP 503|(From httpd)|http://10.16.88.19:2182/tses/session.jsp|Unexpected fail|(x)| -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 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 August 2014