[
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: [email protected]
For additional commands, e-mail: [email protected]
