1:32 p.m.
[
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)