OS: Uduntu 16.04 64-bit LTS
SonarQube: 6.7.1
PostgreSql: 9.5
Java: 1.8.0_144
Default SonarQube has JDBC 42.1.4 and the following error in web.log:
ERROR web[][o.postgresql.Driver] Connection error:
org.postgresql.util.PSQLException: The connection attempt failed.
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:275)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:194)
at org.postgresql.Driver.makeConnection(Driver.java:450)
at org.postgresql.Driver.connect(Driver.java:252)
at org.apache.commons.dbcp.DriverConnectionFactory.createConnection(DriverConnectionFactory.java:38)
at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582)
at org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:1617)
at org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:1575)
at org.apache.commons.pool.impl.GenericObjectPool.access$700(GenericObjectPool.java:190)
at org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1709)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: java.net.UnknownHostException: localhost
but when i update to JDBC 4.2 Driver, 42.2.1 work well.
Maybe someone from sonarqube see and fix it.
Indeed the version of PostgreSQL driver packaged in SonarQube 6.7.1 has some bugs. Driver is upgraded in SonarQube 6.7.2, not released at the time of writing.
See a related ticket: https://jira.sonarsource.com/browse/SONAR-10296
Related
I am trying to run liquibase to create DB schema and tables in GCP.
Below error is coming any idea ?
Class [org.hibernate.boot.jaxb.hbm.spi.package-info] could not be found.
Processing bindings will probably fail.
java.lang.ClassNotFoundException: org.hibernate.boot.jaxb.hbm.spi.package-info
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass (SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass (ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass (ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass (ClassRealm.java:239)
at java.lang.Class.forName0 (Native Method)
at java.lang.Class.forName (Class.java:315)
I had to downgrade my Liquibase version to 3.6.3 (as suggested by #Jens). Now I am not getting the error.
Stack I use: Ubuntu 18.04 / OpenJDK 11
We had the same issue but it was only warning and it was not a stopper for us. To remove the warning, we upgraded the Liquibase version into version - 4.7.1 and the warning is gone.
I'm trying to run slf4j with log4j 2.8 on openJDK 8 (latest version on Ubuntu 8u131-b11-0ubuntu1.17.04.1).
When running simple java class via maven openjdk is unable to resolve local hostname:
Exception in thread "AWT-EventQueue-0" java.lang.NoSuchFieldError: preferIPv6Address
at java.base/java.net.InetAddress.init(Native Method)
at java.base/java.net.InetAddress.init(Native Method)
at java.base/java.net.InetAddress.<clinit>(InetAddress.java:333)
at org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:53)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:539)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:617)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:634)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:229)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:122)
at org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
at org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
at org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
looks like the method
public static InetAddress getLocalHost() throws UnknownHostException
is implemented differently than in Oracle java.
/etc/hosts contains ipv6 record:
::1 ip6-localhost ip6-loopback
The problem was caused by JDK9 installed on the system. Log4j 2.8 is not compatible with Java 9 yet.
Either removing JDK9 or setting preference to JDK8 should solve the issue. On Debian:
sudo update-alternatives --config java
When a .wlapp file is deployed in MobileFirst Console, we get the following error in the logs. This happened after we upgraded MobileFirst Server from 6.3 to 7, but don't know if this is related to the version of MobileFirst.
000001c6 BaseTransacti E RuntimeMBeanCallable.call() exception
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy166.deployApplication(Unknown Source)
at com.ibm.worklight.admin.actions.ApplicationDeploymentTransaction.prepareMBean(ApplicationDeploymentTransaction.java:919)
at com.ibm.worklight.admin.actions.util.RuntimeMBeanWorkerThreadCaller$RuntimeMBeanCallable.call(RuntimeMBeanWorkerThreadCaller.java:76)
at com.ibm.worklight.admin.actions.util.RuntimeMBeanWorkerThreadCaller.callSynchronously(RuntimeMBeanWorkerThreadCaller.java:183)
at com.ibm.worklight.admin.actions.util.RuntimeMBeanPoolCaller.callRuntimeMBeans(RuntimeMBeanPoolCaller.java:91)
at com.ibm.worklight.admin.actions.BaseTransaction.prepare(BaseTransaction.java:450)
at com.ibm.worklight.admin.actions.BaseTransaction.internalRun(BaseTransaction.java:348)
at com.ibm.worklight.admin.actions.BaseTransaction$1.run(BaseTransaction.java:235)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:790)
Caused by: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: The system failed to make the SOAP RPC call: invoke
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:894)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:689)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:679)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:665)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:487)
at com.sun.proxy.$Proxy121.invoke(Unknown Source)
at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
at com.worklight.common.util.jmx.WASRuntimeMBeanHandler$AdminClientMBeanServerConnection.invoke(WASRuntimeMBeanHandler.java:521)
at com.sun.jmx.mbeanserver.MXBeanProxy$InvokeHandler.invoke(MXBeanProxy.java:146)
at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:160)
at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:246)
... 11 more
Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Read timed out; targetException=java.net.SocketTimeoutException: Read timed out]
at org.apache.soap.transport.http.SOAPHTTPConnection.send(SOAPHTTPConnection.java:479)
at org.apache.soap.rpc.Call.WASinvoke(Call.java:510)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient$8.run(SOAPConnectorClient.java:852)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:845)
... 21 more
MobileFirst version 7
WAS server version 8.5.5.5
JRE version 1.6
Re-deploying the MobileFirst artifacts to the application server should normally not be required as inspecting the logs and configuration usually will lead to the root cause of the problem. However in some cases starting over to get things right will work.
As mentioned in the comments, re-deployment of the server artifacts nullified the issue that was experienced.
Gradle throws exception with message "Unable to establish loopback connection". The following is the stack trace thrown at the console.
java.io.IOException: Unable to establish loopback connection
org.gradle.internal.UncheckedException: java.io.IOException: Unable to establish loopback connection
at org.gradle.internal.UncheckedException.throwAsUncheckedException(UncheckedException.java:39)
at org.gradle.messaging.remote.internal.inet.SocketConnection.<init>(SocketConnection.java:58)
at org.gradle.messaging.remote.internal.inet.SocketConnectCompletion.create(SocketConnectCompletion.java:43)
at org.gradle.messaging.remote.internal.hub.MessageHubBackedObjectConnection.connect(MessageHubBackedObjectConnection.java:92)
at org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcessor.forkProcess(ForkingTestClassProcessor.java:78)
at org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcessor.processTestClass(ForkingTestClassProcessor.java:56)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestClassProcessor.processTestClass(RestartEveryNTestClassProcessor.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.dispatch.FailureHandlingDispatch.dispatch(FailureHandlingDispatch.java:29)
at org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDispatch.java:132)
at org.gradle.messaging.dispatch.AsyncDispatch.access$000(AsyncDispatch.java:33)
at org.gradle.messaging.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:72)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
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:744)
Gradle version :
Gradle 1.12
Build time: 2014-04-29 09:24:31 UTC
Build number: none
Revision: a831fa866d46cbee94e61a09af15f9dd95987421
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
Ivy: 2.2.0
JVM: 1.7.0_45 (Oracle Corporation 24.45-b08)
OS: Windows 7 6.1 x86
Jdk is 1.7.45.
Is there any help? I tried stopping the anti virus assuming the connection are getting terminated by AV. However, the issue re-occurred when the AV was turned off.
I assume this is a problem where Gradle cannot connect to the gradle Daemon. Your machine probably has an issue with its networking config, which needs to be worked out.
A possible workaround would be to run without the Daemon, using the --no-daemon option. If that still doesn't work, there is some other reason why it tries to establish a connection, probably due to a custom plugin or build script.
I was using JDK v1.7.0_45 and I now use 1.7.0_79. Ever since the upgrade I am not observing this issue. I switched back to v1.7.0_45 this morning and I am already noticed "Unable to establish loopback connection" twice out of six iterations.
I have sonarqube 3.5.1, and sonar-runner 2.2.1 on a RHEL6.2 server, sonar-runner works fine against the sample data I've downloaded.
However, I've deployed sonar-runner to a windows client, and its failing to connect to the H2 database.
INFO: Sonar Server 3.5.1
11:58:19.960 INFO - Load batch settings
11:58:20.116 INFO - User cache: C:\Users\e01942082\.sonar\cache
11:58:20.132 INFO - Install plugins
11:58:21.739 INFO - ------------- Executing Project Scan
11:58:22.113 INFO - Install JDBC driver
11:58:22.129 INFO - Apply project exclusions
11:58:22.129 WARN - H2 database should be used for evaluation purpose only
11:58:22.129 INFO - Create JDBC datasource for jdbc:h2:tcp://localhost/sonar
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 8.393s
Final Memory: 2M/15M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: Fail to connect to database
ERROR: Caused by: Cannot create PoolableConnectionFactory (Connection is broken: "java.net.ConnectException: Connection refused: connect: localhost" [90067-167])
ERROR: Caused by: Connection is broken: "java.net.ConnectException: Connection refused: connect: localhost" [90067-167]
ERROR: Caused by: Connection refused: connect
So, I've updated the sonar-properties in sonarqube
# Comment the following line to deactivate the default embedded database.
sonar.jdbc.url: jdbc:h2:tcp://gbrpsr000000711.xxxxxxxxx.xxxxxxxxxxx.com:9092/sonar
sonar.jdbc.driverClassName: org.h2.Driver
and sonar-runner conencts to the server with the
sonar.host.url=http://gbrpsr000000711.xxxxxxx.xxxxxxxx.com:9000/sonar
its not clear why its picking up the localhost rather than the full url of the server. Am I missing somehting/ or has this been embedded when I started the service prior to making the config changes????
thanks for you assistance
dD