I have configured the max. connection pool size of my SpringBoot application to 1 by using the following command:
spring.datasource.hikari.maximum-pool-size=1
Is there any way to verify and confirm this change. I want to check that this is working for my application.
You can see the pool values in log, if you enable debug log for HikariCP.
HikariCP housekeeper thread logs pool information at fixed time interval.
Just set com.zaxxer.hikari logging level to debug.
In logback.xml you can do it like
<logger name="com.zaxxer.hikari" level="debug"/>
Or you can do it in application.properties
logging.level.com.zaxxer.hikari=debug
In your console of log file you will find something similar like this.
DEBUG [HikariPool-1 housekeeper] com.zaxxer.hikari.pool.HikariPool: HikariPool-1 - Pool stats (total=10, active=0, idle=10, waiting=0)
Total value should not exceed maximum-pool-size value.
Related
One of our JBoss Application Server version 7.1 is failing to deploy ear applications during the startup process. I have tried many different values for the default-timeout parameter (600secs, 1200secs, 2400secs) in the deployment scanner section of the standalone.xml file. It keeps on failing with the same message no matter the value set for the default-timeout.
It used to work just fine till yesterday with the default-timeout set at 300 secs. Please find the error message in the "Error Message" section below.
Along with trying out different default-timeout values, i have also tried removing cache such as renaming or removing tmp directory several times before restarting.
What can I try to fix this?
Error Message:
15:46:01,732 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015052: Did not receive a response to the deployment operation within the allowed timeout period [600 seconds]. Check the server configuration file and the server logs to find more about the status of the deployment.
15:46:01,734 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015052: Did not receive a response to the deployment operation within the allowed timeout period [600 seconds]. Check the server configuration file and the server logs to find more about the status of the deployment.
15:46:01,733 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015871: Deploy of deployment "ServerApps.ear" was rolled back with no failure message
15:46:01,736 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015052: Did not receive a response to the deployment operation within the allowed timeout period [600 seconds]. Check the server configuration file and the server logs to find more about the status of the deployment.
15:46:01,736 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015871: Deploy of deployment "bpm.ear" was rolled back with no failure message
15:46:01,776 INFO [javax.enterprise.resource.webservices.jaxws.servlet.http] (MSC service thread 1-1) WSSERVLET15: JAX-WS servlet destroyed
15:46:01,779 INFO [javax.enterprise.resource.webservices.jaxws.server.http] (MSC service thread 1-1) WSSERVLET13: JAX-WS context listener destroyed
The error may cause due to the init() method of Servlet or other EE component was calling System.exit() which triggers shutdown hook to run. The JBoss Modular Service Container or MSC registers a hook and when triggered it shuts down the container. The container shutdown operation needs to wait until the EAR deployment over so that it knows if the deployment succeeded or failed. This may cause the deadlock as the System.exit() call waits until the hooks finish its execution and deadlock will be broken when the deployment gets failed due to timeout and release the MSC and continue with the shutdown.
You can try to collect the thread dumps and see if there is
A "MSC service thread" which has called into System.exit() or Runtime.exit(), and is waiting until the shutdown hooks complete.
The "MSC Shutdown Hook" thread, which is waiting for a CountDownlatch
I'm using the following:
JBoss Wildfly 15.0.1.Final
MSSQL JDBC connector (i.e. mssql-jdbc-7.2.2.jre11.jar)
standalone-full.xml
I believe I have setup everything correctly. The MSSQL JDBC jar is in the modules directory with its associated module.xml. The datasource is correctly defined and functional. ActiveMQ Artemis has been setup (works fine using the file system). However when I attempt to have it use JDBC it fails trying to create the necessary tables with the following error:
SQLState: S0001 ErrorCode: 102 Message: Incorrect syntax near AUTO_INCREMENT'.
So I'm wondering what is wrong. ActiveMQ says it supports SQL Server, and it automatically figures out which SQL dialect to use based on the return value of the driver (I've checked that name with an 6.0 version of the driver and it is the same), also in the debug output it says
[org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl] ServerService Thread Pool -- 80) Detect database dialect as 'MSSQL'".
So that looks good. So I'm a bit confused on what is wrong and would like to get it to work. I'm providing the critical elements that I have in the standalone-full.xml. Is there any other setup I need or is this a bug?
Is this also a symptom of a problem? (i.e. see the log output...the broker is not initialized with correct driver/url that was specified by the datasource definition)
AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=false,jdbcDriverClassName=org.apache.derby.jdbc.EmbeddedDriver,jdbcConnectionUrl=null,messageTableName=AMQ_MESSAGES,bindingsTableName=AMQ_BINDINGS,largeMessageTableName=AMQ_LARGE_MESSAGES,pageStoreTableName=AMQ_PSTORE,)
excerpts from the standalone-full.xml settings
<extensions>
<extension module="org.wildfly.extension.messaging-activemq"/>
</extensions>
<datasources>
<datasource jndi-name="java:/RMBM-DEFAULT-DS" pool-name="RMBM-DEFAULT-DS" enabled="true">
<connection-url>jdbc:sqlserver://${rmbm.default.ds.host}:${rmbm.default.ds.port:1433};DatabaseName=${rmbm.default.ds.dbname}
</connection-url>
<driver>SQLSVR</driver>
</datasource>
<drivers>
<driver name="SQLSVR" module="com.microsoft.sqlserver.jdbc">
<driver-class>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver- class>
</driver>
</drivers>
<subsystem xmlns="urn:jboss:domain:messaging-activemq:5.0">
<server name="default">
<journal datasource="RMBM-DEFAULT-DS" messages-table="AMQ_MESSAGES" bindings-table="AMQ_BINDINGS"
jms-bindings-table="AMQ_JMS_BINDINGS" large-messages-table="AMQ_LARGE_MESSAGES" page-store-table="AMQ_PGSTORE"/>
</server>
</subsystem>
Here is a portion of the log output:
18:36:27,116 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-8) WFLYMSGAMQ0001: AIO wasn't located on this platform, it will fall back to using pure Java NIO.
18:36:27,665 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on 127.0.0.1:443
18:36:27,808 INFO [org.jboss.ws.common.management] (MSC service thread 1-7) JBWS022052: Starting JBossWS 5.2.4.Final (Apache CXF 3.2.5.jbossorg-1)
18:36:27,964 DEBUG [org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl] (MSC service thread 1-8) Detect database dialect as 'MSSQL'.
18:36:27,968 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-8) use JDBC store for Artemis server, bindingsTable:AMQ_BINDINGS
18:36:28,065 DEBUG [org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl] (ServerService Thread Pool -- 80) Starting server ActiveMQServerImpl::
18:36:28,069 DEBUG [org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl] (ServerService Thread Pool -- 80) Detected no Shared Store HA options on JDBC store
18:36:28,121 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 80) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=false,jdbcDriverClassName=org.apache.derby.jdbc.EmbeddedDriver,jdbcConnectionUrl=null,messageTableName=AMQ_MESSAGES,bindingsTableName=AMQ_BINDINGS,largeMessageTableName=AMQ_LARGE_MESSAGES,pageStoreTableName=AMQ_PSTORE,)
18:36:28,306 DEBUG [org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl] (ServerService Thread Pool -- 80) Detect database dialect as 'MSSQL'.
18:36:28,398 ERROR [org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver] (ServerService Thread Pool -- 80)
SQL STATEMENTS:
CREATE TABLE AMQ_LARGE_MESSAGES (ID BIGINT AUTO_INCREMENT, FILENAME VARCHAR(255), EXTENSION VARCHAR(10), DATA BLOB, PRIMARY KEY(ID))
SQL EXCEPTIONS:
SQLState: S0001 ErrorCode: 102 Message: Incorrect syntax near 'AUTO_INCREMENT'.
18:36:28,425 WARN [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 80) AMQ222010: Critical IO Error, shutting down the server. file=NULL, message=Unable to start database driver: com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near 'AUTO_INCREMENT'.
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:262)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1621)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:868)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:768)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7194)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2935)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:248)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:223)
at com.microsoft.sqlserver.jdbc//com.microsoft.sqlserver.jdbc.SQLServerStatement.executeUpdate(SQLServerStatement.java:711)
at org.jboss.ironjacamar.jdbcadapters#1.4.11.Final//org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.createTableIfNotExists(AbstractJDBCDriver.java:258)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.createTable(AbstractJDBCDriver.java:118)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactoryDriver.createSchema(JDBCSequentialFileFactoryDriver.java:69)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.start(AbstractJDBCDriver.java:83)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.jdbc.store.file.JDBCSequentialFileFactory.start(JDBCSequentialFileFactory.java:131)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager.init(JDBCJournalStorageManager.java:92)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.<init>(AbstractJournalStorageManager.java:229)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.<init>(JournalStorageManager.java:106)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager.<init>(JDBCJournalStorageManager.java:55)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2155)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2296)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:64)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:535)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:474)
at org.apache.activemq.artemis#2.6.3.jbossorg-00014//org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376)
at org.wildfly.extension.messaging-activemq//org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:206)
at org.wildfly.extension.messaging-activemq//org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:65)
at org.wildfly.extension.messaging-activemq//org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:100)
It appears that even though the dialect is correctly detected as MSSQL the broker doesn't have the corresponding SQL statements to properly support it. The SQL statements for MSSQL were added in ActiveMQ Artemis 2.6.4 via ARTEMIS-2202. You're using 2.6.3 so you don't have those.
Upgrading ActiveMQ Artemis in Wildfly can sometimes fail due to the tight coupling between the two so if you don't want to try upgrading you could theoretically crack open the artemis-jdbc-store jar file and add/replace these lines to journal-sql.properties
# MSSQL SQL statements
create-file-table.mssql=CREATE TABLE %s (ID BIGINT NOT NULL IDENTITY, FILENAME VARCHAR(255), EXTENSION VARCHAR(10), DATA VARBINARY(max), PRIMARY KEY(ID))
create-journal-table.mssql=CREATE TABLE %s(id BIGINT,recordType SMALLINT,compactCount SMALLINT,txId BIGINT,userRecordType SMALLINT,variableSize INTEGER,record VARBINARY(max),txDataSize INTEGER,txData VARBINARY(max),txCheckNoRecords INTEGER,seq BIGINT NOT NULL, PRIMARY KEY(seq))
max-blob-size.mssql=2147483647
Regarding the AMQ221000 log message that indicates there is an incorrect JDBC driver configuration...This is due to the fact that the ActiveMQ Artemis broker has its own JDBC driver configuration for when it's running standalone. When it's embedded in Wildfly and configured to use a datasource via JNDI then the standalone JDBC driver configuration isn't used. It will simply look up the specified datasource and use that.
My logs are getting hammered by below log message in JBOSS 7. Can you anyone suggest how to stop this log message.
2018-02-28 13:37:13,618 WARN [com.arjuna.ats.arjuna] (default-threads - 48) ARJUNA012141: Multiple last resources have been added to the current transaction. This is transactionally unsafe and should not be relied upon. Current resource is LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl#5d70439b[connectionListener=653eac5d connectionManager=7f6856e8 warned=false currentXid=null productName=MySQL productVersion=10.2.13-MariaDB-log jndiName=java:/jdbc/db_jndi]))
In your standalone.xml file, in the logging section, add something like this under the appropriate handler element:
<filter>
<not>
<match pattern="ARJUNA012141"/>
</not>
</filter>
Of course, you should add these lines using the jboss-cli utility. Did you know that changes to logging don't require a server restart, but will be picked up at the defined refresh interval?
I using springboot with HikariCP, but after a while my app crash and I got the error:
org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection
...
Caused by: org.hibernate.exception.JDBCConnectionException: Unable to acquire JDBC Connection
....
Caused by: java.sql.SQLTransientConnectionException: HikariPool-6 - Connection is not available, request timed out after 30000ms.
This is my aplication.properties
spring.datasource.type=com.zaxxer.hikari.HikariDataSource
spring.datasource.url=jdbc:postgresql://localhost:5432/db_dnaso
#spring.datasource.url=jdbc:postgresql://172.16.1.10:5432/db_dnaso
spring.datasource.username=postgres
spring.datasource.password=dna44100
spring.datasource.driver-class-name=org.postgresql.Driver
So I have a lot of save, find and anothers access to DB, how can I visualize how method are blocking my connection?
tks
It looks like your your database server is running out of connection. Default value for property maximumPoolSize in Hikari is 10. That means it will try to create 10 connection on server startup and it will not start if not able to acquire 10 connection or may fail if your db server pool size having less connection in the pool as you are creating using Hikari configuration.
If you are able to start Spring Boot server and then facing this issue then try enabling leakDetectionThreshold and check which connection is taking more time and not returning to Hikari pool .
spring:
datasource:
hikari:
leak-detection-threshold: 2000
Enable the leakDetectionThreshold, set to something like 1 minute (60000ms). It is likely that you have a connection leak somewhere ... a connection is borrowed but never closed (returned).
In springboot, you can set spring.datasource.hikari.leak-detection-threshold=10000 (in milliseconds) in application.properties.
And the default value for maximumPoolSize is 10. You can change it with spring.datasource.hikari.maximum-pool-size=xx.
I have a Play 2.0 app, ran play console from the command line. Somewhere in one of the libraries I use, it uses log4j and started to stream debug output for [crawler4j][1], I'm trying to figure out how to selectively disable that output in the play console. I have tried changing the following in application.conf and logger.xml without any luck
application.conf
logger.root=ERROR
logger.play=ERROR
logger.application=ERROR
logger.xml
<logger name="org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager" level="ERROR"/>
Here's a sample of the streaming debug log
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:10:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:10:18.819 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:11:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:11:18.818 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
13:11:18.819 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.c.t.ThreadSafeClientConnManager - Closing connections idle longer than 60 SECONDS
13:11:18.819 [java-sdk-http-connection-reaper] DEBUG o.a.h.i.conn.tsccm.ConnPoolByRoute - Closing connections idle longer than 60 SECONDS
Just to be clear, the log settings are enforced when I ran the Play app from command line, it's when I run it from within the play console that the settings are not enforced.
I don't think log4j is in use here actually. Apache HTTP client, which is the library producing the debug, logs via apache commons logging.
Play2 uses the SLF4J API with a logback backend.
There is a library on your classpath called jcl-over-slf4j that causes log messages going to apache commons logging to bridge through SLF4J and then to logback instead. (Convoluted I know, but an attempt to allow SLF4J to act as a facade to all the others, and its backend to be the "one logger to rule them all").
The play2 docs indicate logger.xml should allow you to totally customize logging settings, so I think that when there's a logger.xml file present, the application.conf settings have no effect.
logger.xml needs to be a full logback configuration file. I'm not sure if you've posted the full contents of logger.xml or just the changes.
To suppress output like that shown, you should be able to set the contents of logger.xml to something like this:
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<logger name="org.apache.http.impl.conn.tsccm" level="error" />
<root level="debug">
<appender-ref ref="STDOUT" />
</root>
</configuration>
If this doesn't work change the top line to be:
<configuration debug="true">
which will cause logback to log its attempt to configure itself. This might give more pointers.
Hope this helps.
This worked for me:
import org.slf4j.{Logger, LoggerFactory}
LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME).asInstanceOf[
ch.qos.logback.classic.Logger].setLevel(ch.qos.logback.classic.Level.INFO)