June 2014 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-413) Log superfluous stack traces onto DEBUG instead of ERROR level

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-413?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-413: -------------------------------------- Affects Version/s: 1.3.0.Final > Log superfluous stack traces onto DEBUG instead of ERROR level > -------------------------------------------------------------- > > Key: MODCLUSTER-413 > URL: https://issues.jboss.org/browse/MODCLUSTER-413 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged > (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace > (18:18:07) rhusar: pferraro: some projects solve this by > (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); > (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); > (18:18:18) rhusar: pferraro: would you be in favor of such change? > (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace > (18:19:31) rhusar: pferraro: just an error. > (18:20:15) pferraro: rhusar: that makes sense > (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-413) Log superfluous stack traces onto DEBUG instead of ERROR level

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-413?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-413: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/modcluster/mod_cluster/pull/87 > Log superfluous stack traces onto DEBUG instead of ERROR level > -------------------------------------------------------------- > > Key: MODCLUSTER-413 > URL: https://issues.jboss.org/browse/MODCLUSTER-413 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Affects Versions: 1.3.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged > (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace > (18:18:07) rhusar: pferraro: some projects solve this by > (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); > (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); > (18:18:18) rhusar: pferraro: would you be in favor of such change? > (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace > (18:19:31) rhusar: pferraro: just an error. > (18:20:15) pferraro: rhusar: that makes sense > (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-413) Log superfluous stack traces onto DEBUG instead of ERROR level

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-413?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-413: -------------------------------------- Summary: Log superfluous stack traces onto DEBUG instead of ERROR level (was: Log superfluous stack traces onto debug instead of error) > Log superfluous stack traces onto DEBUG instead of ERROR level > -------------------------------------------------------------- > > Key: MODCLUSTER-413 > URL: https://issues.jboss.org/browse/MODCLUSTER-413 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged > (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace > (18:18:07) rhusar: pferraro: some projects solve this by > (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); > (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); > (18:18:18) rhusar: pferraro: would you be in favor of such change? > (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace > (18:19:31) rhusar: pferraro: just an error. > (18:20:15) pferraro: rhusar: that makes sense > (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-413) Log superfluous stack traces onto debug instead of error

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-413?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-413: -------------------------------------- Summary: Log superfluous stack traces onto debug instead of error (was: Log useless stack traces onto debug instead of error) > Log superfluous stack traces onto debug instead of error > -------------------------------------------------------- > > Key: MODCLUSTER-413 > URL: https://issues.jboss.org/browse/MODCLUSTER-413 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged > (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace > (18:18:07) rhusar: pferraro: some projects solve this by > (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); > (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); > (18:18:18) rhusar: pferraro: would you be in favor of such change? > (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace > (18:19:31) rhusar: pferraro: just an error. > (18:20:15) pferraro: rhusar: that makes sense > (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-413) Log useless stack traces onto debug instead of error

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-413?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-413: ------------------------------------------- I am only converting IO which all have similar and unncessary stack trace logs. > Log useless stack traces onto debug instead of error > ---------------------------------------------------- > > Key: MODCLUSTER-413 > URL: https://issues.jboss.org/browse/MODCLUSTER-413 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged > (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace > (18:18:07) rhusar: pferraro: some projects solve this by > (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); > (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); > (18:18:18) rhusar: pferraro: would you be in favor of such change? > (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace > (18:19:31) rhusar: pferraro: just an error. > (18:20:15) pferraro: rhusar: that makes sense > (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-413) Log useless stack traces onto debug instead of error

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-413?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-413: ------------------------------------------- Now MODCLUSTER000043 it would look like (with debug on): {noformat} 2014-06-13 13:29:51,156 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000043: Failed to send INFO command to localhost/127.0.0.1:9090: Connection refused 2014-06-13 13:29:51,157 DEBUG [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) Catching: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_60] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_60] at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_60] at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_60] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [rt.jar:1.7.0_60] at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_60] at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:836) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:859) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:499) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:600) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:372) at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350) at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:459) at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:160) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_60] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [rt.jar:1.7.0_60] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_60] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] {noformat} > Log useless stack traces onto debug instead of error > ---------------------------------------------------- > > Key: MODCLUSTER-413 > URL: https://issues.jboss.org/browse/MODCLUSTER-413 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged > (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace > (18:18:07) rhusar: pferraro: some projects solve this by > (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); > (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); > (18:18:18) rhusar: pferraro: would you be in favor of such change? > (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace > (18:19:31) rhusar: pferraro: just an error. > (18:20:15) pferraro: rhusar: that makes sense > (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-413) Log useless stack traces onto debug instead of error

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-413?page=com.atlassian.jira.pl... ] Radoslav Husar updated MODCLUSTER-413: -------------------------------------- Component/s: Container Integration (Java) > Log useless stack traces onto debug instead of error > ---------------------------------------------------- > > Key: MODCLUSTER-413 > URL: https://issues.jboss.org/browse/MODCLUSTER-413 > Project: mod_cluster > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 1.3.1.Final > > > (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged > (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace > (18:18:07) rhusar: pferraro: some projects solve this by > (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); > (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); > (18:18:18) rhusar: pferraro: would you be in favor of such change? > (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace > (18:19:31) rhusar: pferraro: just an error. > (18:20:15) pferraro: rhusar: that makes sense > (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-413) Log useless stack traces onto debug instead of error

by Radoslav Husar (JIRA)

Radoslav Husar created MODCLUSTER-413: ----------------------------------------- Summary: Log useless stack traces onto debug instead of error Key: MODCLUSTER-413 URL: https://issues.jboss.org/browse/MODCLUSTER-413 Project: mod_cluster Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 1.3.1.Final (18:17:45) rhusar: pferraro: i would like to refactor this: when modcluster fails certain calls on the proxy, the whole stack trace is logged (18:17:59) rhusar: pferraro: and i think its really useless to log Connection failed stack trace (18:18:07) rhusar: pferraro: some projects solve this by (18:18:08) rhusar: pferraro: ContextLogger.LOG.unableToClearBeanStore(getBeanStore()); (18:18:08) rhusar: ContextLogger.LOG.catchingDebug(e); (18:18:18) rhusar: pferraro: would you be in favor of such change? (18:19:27) rhusar: pferraro: so you can still access the stack traces if you switch to debug. otherwise things like restarting the proxy doesnt print a horrific stack trace (18:19:31) rhusar: pferraro: just an error. (18:20:15) pferraro: rhusar: that makes sense (18:20:40) rhusar: pferraro: ie get rid of https://gist.githubusercontent.com/rhusar/6ddc5b3b0ce51d4f6f67/raw/137d12... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-178) Domains: non sticky requests should be contained within a given domain

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-178?page=com.atlassian.jira.pl... ] Radoslav Husar commented on MODCLUSTER-178: ------------------------------------------- Both are possible. My take would be introducing boolean sticky-domain as it is easiest for backward compatibility (when you think about the AS work that needs to be done or the docs, etc). > Domains: non sticky requests should be contained within a given domain > ---------------------------------------------------------------------- > > Key: MODCLUSTER-178 > URL: https://issues.jboss.org/browse/MODCLUSTER-178 > Project: mod_cluster > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Jean-Frederic Clere > Attachments: cluster-small.png, cluster.jpg > > > If we have a couple of domains, then non-sticky requests can go to *any* server in *any* domain. > It would be nice if we could at least make the domain sticky, so e.g. non-sticky requests always pick the same domain, as long as there are servers in that domain. > Maybe this should be a new flag, e.g. stickyDomain. If stickySession is false, then we'd check stickyDomain. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-339) "proxy: DNS lookup failure" with IPv6 on Solaris

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/MODCLUSTER-339?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on MODCLUSTER-339: ---------------------------------------------------- Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 963723|https://bugzilla.redhat.com/show_bug.cgi?id=963723] from ON_QA to VERIFIED > "proxy: DNS lookup failure" with IPv6 on Solaris > ------------------------------------------------ > > Key: MODCLUSTER-339 > URL: https://issues.jboss.org/browse/MODCLUSTER-339 > Project: mod_cluster > Issue Type: Bug > Affects Versions: 1.2.3.Final, 1.2.4.Final > Environment: Solaris 10 x86, Solaris 11 x86, Solaris 11 SPARC > Reporter: Michal Babacek > Assignee: Jean-Frederic Clere > Priority: Critical > Labels: ipv6 > Fix For: 1.2.5.Final > > Attachments: access_log-mod_cluster, error_log-mod_cluster, error_log-mod_cluster-RHEL, error_log-proxypass, error_log_pull20, http.conf, mod_manager.so, sockaddr.lo_fedora18_x86_64, sockaddr.lo_solaris11_sparc64 > > > h2. Failure with mod_cluster > Having the following setting: > {code:title=mod_cluster.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule slotmem_module modules/mod_slotmem.so > LoadModule manager_module modules/mod_manager.so > LoadModule proxy_cluster_module modules/mod_proxy_cluster.so > LoadModule advertise_module modules/mod_advertise.so > MemManagerFile "/tmp/mod_cluster-eap6/jboss-ews-2.0/var/cache/mod_cluster" > ServerName [2620:52:0:105f::ffff:50]:2080 > <IfModule manager_module> > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > KeepAliveTimeout 60 > MaxKeepAliveRequests 0 > ServerAdvertise on > AdvertiseFrequency 5 > ManagerBalancerName qacluster > AdvertiseGroup [ff01::7]:23964 > EnableMCPMReceive > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Deny from all > Allow from all > </Location> > </VirtualHost> > </IfModule> > {code} > I get a weird {{proxy: DNS lookup failure}} as soon as worker sends {{CONFIGURE}}}: > {code:title=access_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "INFO / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "CONFIG / HTTP/1.1" 200 - "-" "ClusterListener/1.0" > 2620:52:0:105f::ffff:50 - - [16/May/2013:08:37:24 -0400] "STATUS / HTTP/1.1" 200 64 "-" "ClusterListener/1.0" > ... > {code} > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans INFO (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler INFO (/) processing: "" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler INFO OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans CONFIG (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler CONFIG (/) processing: "JVMRoute=jboss-eap-6.1&Host=%5B2620%3A52%3A0%3A105f%3A0%3A0%3Affff%3A50%252%5D&Maxattempts=1&Port=8009&StickySessionForce=No&Type=ajp&ping=10" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2647): manager_handler CONFIG OK > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1923): manager_trans STATUS (/) > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(2598): manager_handler STATUS (/) processing: "JVMRoute=jboss-eap-6.1&Load=100" > [Thu May 16 08:37:24 2013] [debug] mod_manager.c(1638): Processing STATUS > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(655): add_balancer_node: Create balancer balancer://qacluster > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(426): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(532): proxy: initialized worker 1 in child 16847 for (2620:52:0:105f:0:0:ffff:50%2) min=0 max=25 smax=25 > [Thu May 16 08:37:24 2013] [debug] mod_proxy_cluster.c(601): Created: worker for ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009 1 (status): 1 > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (2620:52:0:105f:0:0:ffff:50%2) > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009/ to 2620:52:0:105f:0:0:ffff:50%2:8009 > [Thu May 16 08:37:24 2013] [error] [client 2620:52:0:105f::ffff:50] proxy: DNS lookup failure for: 2620:52:0:105f:0:0:ffff:50%2 returned by / > [Thu May 16 08:37:24 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (2620:52:0:105f:0:0:ffff:50%2) > ... > {code} > An attempt to access the mod_cluster manager console yields an unpleasant {{NOTOK}} (obviously, we have All workers are in error state...): > {code} > curl -g [2620:52:0:105f::ffff:50]:6666/mcm > ... > <h1> Node jboss-eap-6.1 (ajp://[2620:52:0:105f:0:0:ffff:50%2]:8009): </h1> > <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=ENABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Enable Contexts</a> <a href="/mcm?nonce=1bddeeea-f9d5-eeea-ee5b-e3a5e3c0a965&Cmd=DISABLE-APP&Range=NODE&JVMRoute=jboss-eap-6.1">Disable Contexts</a><br/> > Balancer: qacluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: NOTOK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: -1 > {code} > You might take a look at the logs: [^error_log-mod_cluster], [^access_log-mod_cluster]. > h2. ProxyPass itself works just fine > On the other hand, when I had tried this: > {code:title=proxypass.conf|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > LoadModule proxy_ajp_module modules/mod_proxy_ajp.so > ServerName [2620:52:0:105f::ffff:50]:2080 > Listen [2620:52:0:105f::ffff:50]:6666 > LogLevel debug > <VirtualHost [2620:52:0:105f::ffff:50]:6666> > ServerName [2620:52:0:105f::ffff:50]:6666 > ProxyPass / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > ProxyPassReverse / ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > <Directory /> > Order deny,allow > Deny from all > Allow from all > </Directory> > </VirtualHost> > {code} > I received: > {code:title=error_log|borderStyle=solid|borderColor=#ccc| titleBGColor=#F7D6C1} > ... > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(45): proxy: AJP: canonicalising URL //[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(1506): [client 2620:52:0:105f::ffff:50] proxy: ajp: found worker ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ for ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy.c(1020): Running scheme ajp handler (attempt 0) > [Thu May 16 08:29:00 2013] [debug] mod_proxy_http.c(1963): proxy: HTTP: declining URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] mod_proxy_ajp.c(681): proxy: AJP: serving URL ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2011): proxy: AJP: has acquired connection for (2620:52:0:105f:0:0:ffff:50) > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://[2620:52:0:105f:0:0:ffff:50]:8009/ to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2193): proxy: connected / to 2620:52:0:105f:0:0:ffff:50:8009 > [Thu May 16 08:29:00 2013] [debug] proxy_util.c(2444): proxy: AJP: fam 26 socket created to connect to 2620:52:0:105f:0:0:ffff:50 > ... > {code} > And from the client's side, it worked: > {{curl -g [2620:52:0:105f::ffff:50]:6666/}} brought me the worker's home page (EAP's welcome in this case). > Take a look at the whole log [^error_log-proxypass]. > *Note:* The [^http.conf] was the same both for mod_cluster and for proxypass test. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues June 2014