May 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-405) Make the testsuite a little more portable

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-405?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-405: ------------------------------------------- The problem was introduced by: https://github.com/rhusar/mod_cluster/commit/fe696391e9a887fe8cefd9628775... > Make the testsuite a little more portable > ----------------------------------------- > > Key: MODCLUSTER-405 > URL: https://issues.jboss.org/browse/MODCLUSTER-405 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > One thing would be making the multicast addresses configurable and not needing the linux workaround: > {code}sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev lo{code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-405) Make the testsuite a little more portable

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-405?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-405: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/75 > Make the testsuite a little more portable > ----------------------------------------- > > Key: MODCLUSTER-405 > URL: https://issues.jboss.org/browse/MODCLUSTER-405 > Project: mod_cluster > Issue Type: Feature Request > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > One thing would be making the multicast addresses configurable and not needing the linux workaround: > {code}sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev lo{code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-405) Make the testsuite a little more portable

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-405: ----------------------------------------- Summary: Make the testsuite a little more portable Key: MODCLUSTER-405 URL: https://issues.jboss.org/browse/MODCLUSTER-405 Project: mod_cluster Issue Type: Feature Request Affects Versions: 1.2.8.Final, 1.3.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 1.3.1.Final One thing would be making the multicast addresses configurable and not needing the linux workaround: {code}sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev lo{code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

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

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-404?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-404: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/74 > ModClusterService stop commands are always draining sessions > ------------------------------------------------------------ > > Key: MODCLUSTER-404 > URL: https://issues.jboss.org/browse/MODCLUSTER-404 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > 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.3#6260)

10 years, 7 months

1
0
0 / 0

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

by Aaron Ogburn (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-404?page=com.atlassian.jira.pl... ] Aaron Ogburn updated MODCLUSTER-404: ------------------------------------ > ModClusterService stop commands are always draining sessions > ------------------------------------------------------------ > > Key: MODCLUSTER-404 > URL: https://issues.jboss.org/browse/MODCLUSTER-404 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Aaron Ogburn > Assignee: Jean-Frederic Clere > > 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.3#6260)

10 years, 7 months

1
0
0 / 0

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

by Aaron Ogburn (JIRA)

Aaron Ogburn created MODCLUSTER-404: --------------------------------------- Summary: ModClusterService stop commands are always draining sessions Key: MODCLUSTER-404 URL: https://issues.jboss.org/browse/MODCLUSTER-404 Project: mod_cluster Issue Type: Bug Affects Versions: 1.2.8.Final, 1.3.0.Final Reporter: Aaron Ogburn Assignee: Jean-Frederic Clere 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.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-398) mod_cluster deadlock in a jboss/windows environment

by Michal Babacek (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-398?page=com.atlassian.jira.pl... ] Michal Babacek commented on MODCLUSTER-398: ------------------------------------------- Relevant code in context: * [pull/69|https://github.com/modcluster/mod_cluster/pull/69] * [commit/df8af31d|https://github.com/modcluster/mod_cluster/commit/df8af31d...] * [pull/72|https://github.com/modcluster/mod_cluster/pull/72] > mod_cluster deadlock in a jboss/windows environment > --------------------------------------------------- > > Key: MODCLUSTER-398 > URL: https://issues.jboss.org/browse/MODCLUSTER-398 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.6.Final > Environment: Windows 2008, EAP6 and EWS2.0.1 > Reporter: Marc Maurer > Assignee: Jean-Frederic Clere > > Under load Apache stops serving pages, with all threads are stuck in "W : Sending reply" state. With the windows Process Explorer we then got a stacktrace from a hanging thread. We don't have debug symbols, but it's easy enough to see what's happening: > ntoskrnl.exe!KeWaitForMultipleObjects+0xc0a > ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel+0x732 > ntoskrnl.exe!KeWaitForMutexObject+0x19f > ntoskrnl.exe!NtDeleteFile+0x3c4 > ntoskrnl.exe!PsDereferenceKernelStack+0x35358 > ntoskrnl.exe!KeSynchronizeExecution+0x3a23 > ntdll.dll!ZwLockFile+0xa > KERNELBASE.dll!LockFileEx+0xb2 > kernel32.dll!LockFileEx+0x1b > libapr-1.dll!apr_file_lock+0x69 <-- here > mod_slotmem.so+0x1318 <-- here > mod_manager.so+0x2a11 <-- here > mod_proxy_cluster.so+0x679e > mod_proxy.so!proxy_run_post_request+0x4e > mod_proxy.so!proxy_run_request_status+0x924 > libhttpd.dll!ap_run_handler+0x35 > libhttpd.dll!ap_invoke_handler+0x114 > libhttpd.dll!ap_die+0x2ea > libhttpd.dll!ap_psignature+0x1ae8 > libhttpd.dll!ap_run_process_connection+0x35 > libhttpd.dll!ap_process_connection+0x3b > libhttpd.dll!ap_regkey_value_remove+0x136e > msvcrt.dll!srand+0x93 > msvcrt.dll!ftime64_s+0x1dd > kernel32.dll!BaseThreadInitThunk+0xd > ntdll.dll!RtlUserThreadStart+0x21 > So mod_manager is requesting a filelock on one of the lockfiles in in the MemManagerFile path. In this case it was the "manager.sessionid.sessionid.lock" file. Removing the lockfile fixed the problem. > When bisecting the mod_cluster code, I think commit "74eeb9c026380deb8d833be53b09b3d808e02d10 - Lock in insert-update" in version 1.2.2 is the culprit. This would also explain why mod_cluster 1.2.1 is the last known working version. > What we don't know, is which process is already holding the lock when all Apache threads start blocking on it. We are trying to figure that out. There are no obviously wrong lock/unlock slotmem call pairs in the mod_manager module, and no locks are requested within other locks as far as we can see. Therefor our best guess would be a deadlock on a thread already holding the globalmutex_lock in combination with the slotmem file locks, but that's just a guess without debugging it. > More context can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1080047 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-403) UseAlias should use flag, interprets any On/Off/on/off as 0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-403?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-403: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/71 > UseAlias should use flag, interprets any On/Off/on/off as 0 > ----------------------------------------------------------- > > Key: MODCLUSTER-403 > URL: https://issues.jboss.org/browse/MODCLUSTER-403 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > Not very pretty. The function is using atoi which is not doing any error handling. > That means, if its integer, it will be checked fine, but if its any string it is always going to be translated as 0! > It should use AP_FLAG so its all done by httpd automatically. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-403) UseAlias should use flag, interprets any On/Off/on/off as 0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-403?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-403: ------------------------------------------- Oh snap, AP_INIT_FLAG doesn't take 0/1 as values so that would also break compatibility. I ll add our own logic... > UseAlias should use flag, interprets any On/Off/on/off as 0 > ----------------------------------------------------------- > > Key: MODCLUSTER-403 > URL: https://issues.jboss.org/browse/MODCLUSTER-403 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > Not very pretty. The function is using atoi which is not doing any error handling. > That means, if its integer, it will be checked fine, but if its any string it is always going to be translated as 0! > It should use AP_FLAG so its all done by httpd automatically. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-403) UseAlias should use flag, interprets any On/Off/on/off as 0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-403?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-403: -------------------------------------- Summary: UseAlias should use flag, interprets any On/Off/on/off as 0 (was: UseAlias should use flag, interprets both On/Off/on/off as 0) > UseAlias should use flag, interprets any On/Off/on/off as 0 > ----------------------------------------------------------- > > Key: MODCLUSTER-403 > URL: https://issues.jboss.org/browse/MODCLUSTER-403 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.3.0.Final, 1.2.8.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > Not very pretty. The function is using atoi which is not doing any error handling. > That means, if its integer, it will be checked fine, but if its any string it is always going to be translated as 0! > It should use AP_FLAG so its all done by httpd automatically. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues May 2014