[ https://issues.apache.org/jira/browse/QPID-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Wall updated QPID-7623: ----------------------------- Description: As reported in QPID-7311, a state change that throws an exception, may cause a warning like the following to be reported to stderr: {noformat} SEVERE: RuntimeException while executing runnable com.google.common.util.concurrent.Futures$6@5b83d60e with executor org.apache.qpid.server.configuration.updater.TaskExecutorImpl@2 c5a6012 org.apache.qpid.server.configuration.IllegalConfigurationException: Unable to get certificate for 'test' from 'https://google.com' at org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:339) at org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:302) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.net.ConnectException: Connection timed out: connect at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:625) at org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:316) ... 5 more {noformat} The problem is a general one rather than being specific to SSTS. The create exception handler involved code at lines AbstractConfiguredObject.java:1083 unconditionally re-raises the exception. The exception then goes uncaught and is logged by Guava at line ExecutionList.java:160. Guava's behaviour here is documented in ListenableFuture.java:103. Whilst ugly, this actually causes no functional harm. The child creation error is still reported to the end user, and the child is still deregistered from the parent. However, the appearance of the stack on stderr will cause alarm to end-users. The cause of the problem is AbstractConfiguredObject.java:1083. The {{FutureCallback#onFailure}} impl should not be rethrowing the exception. Setting returnValue's exception is sufficient. was: As reported in QPID-7311, a state change that throws an exception, may cause a warning like the following to be reported to stderr: {noformat} SEVERE: RuntimeException while executing runnable com.google.common.util.concurrent.Futures$6@5b83d60e with executor org.apache.qpid.server.configuration.updater.TaskExecutorImpl@2 c5a6012 org.apache.qpid.server.configuration.IllegalConfigurationException: Unable to get certificate for 'test' from 'https://google.com' at org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:339) at org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:302) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.net.ConnectException: Connection timed out: connect at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:625) at org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:316) ... 5 more {noformat} The problem is a general one rather than being specific to SSTS. The create exception handler involved code at lines AbstractConfiguredObject.java:1083 unconditional re-raises the exception. The exception then goes uncaught and is logged by Guava at line ExecutionList.java:160. Guava's behaviour here is documented in ListenableFuture.java:103. Whilst ugly, this actually causes no functional harm. The child creation error is still reported to the end user, and the child is still deregistered from the parent. However, the appearance of the stack on stderr will cause alarm to end-users. The cause of the problem is AbstractConfiguredObject.java:1083. The {{FutureCallback#onFailure}} impl should not be rethrowing the exception. Setting returnValue's exception is sufficient. > "SEVERE: RuntimeException while executing runnable" reported by Guava to > stderr if a state transition method throws exception > ----------------------------------------------------------------------------------------------------------------------------- > > Key: QPID-7623 > URL: https://issues.apache.org/jira/browse/QPID-7623 > Project: Qpid > Issue Type: Bug > Components: Java Broker > Affects Versions: qpid-java-6.0, qpid-java-6.1 > Reporter: Keith Wall > Assignee: Alex Rudyy > Priority: Minor > Fix For: qpid-java-7.0 > > > As reported in QPID-7311, a state change that throws an exception, may cause > a warning like the following to be reported to stderr: > {noformat} > SEVERE: RuntimeException while executing runnable > com.google.common.util.concurrent.Futures$6@5b83d60e with executor > org.apache.qpid.server.configuration.updater.TaskExecutorImpl@2 > c5a6012 > org.apache.qpid.server.configuration.IllegalConfigurationException: Unable to > get certificate for 'test' from 'https://google.com' > at > org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:339) > at > org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:302) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.ConnectException: Connection timed out: connect > at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) > at > java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:579) > at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:625) > at > org.apache.qpid.server.security.SiteSpecificTrustStoreImpl$2.call(SiteSpecificTrustStoreImpl.java:316) > ... 5 more > {noformat} > The problem is a general one rather than being specific to SSTS. > The create exception handler involved code at lines > AbstractConfiguredObject.java:1083 unconditionally re-raises the exception. > The exception then goes uncaught and is logged by Guava at line > ExecutionList.java:160. Guava's behaviour here is documented in > ListenableFuture.java:103. > Whilst ugly, this actually causes no functional harm. The child creation > error is still reported to the end user, and the child is still deregistered > from the parent. However, the appearance of the stack on stderr will cause > alarm to end-users. > The cause of the problem is AbstractConfiguredObject.java:1083. The > {{FutureCallback#onFailure}} impl should not be rethrowing the exception. > Setting returnValue's exception is sufficient. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org