A project generated by Jhipster and deployed on weblogic server. Everythings works fine on weblogic server except constranits exceptions handling.
On tomcat when happen constraints exception is returned status error code 409 correctly but on weblogic return status error code 500, as below, so we cant detect what error has happened
with cause = 'weblogic.transaction.RollbackException: setRollbackOnly called on transaction' and exception = 'JTA transaction unexpectedly rolled back (maybe due to a timeout); nested exception is weblogic.transaction.RollbackException: setRollbackOnly called on transaction'
Related
Application: Java spring boot + mysql
Story:
application log showed "Could not open JDBC Connecton for transaction; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure"
Recovery of the DB instance has been triggered since hardware problem occurred in RDS instance
After 10 mins, the recovery is done.
application log showed "Could not commit JDBC transaction; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed." instead of previous exception.
After 45 mins, application resumed normal without manual operations.
Questions:
Will restarting the application solve the problem instantly?
Manual operation might not be the best to resolve such problem. But if I want it be auto resumed shortly, anything I can do to the setting datasource properties? i.e. set spring.datasource.justswap.time-between-eviction-runs-millis shorter?
Current datasource setting:
spring.datasource.xxx.maxActive=700
spring.datasource.xxx.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.xxx.test-on-borrow=false
spring.datasource.xxx.test-while-idle=true
spring.datasource.xxx.time-between-eviction-runs-millis=3600000
spring.datasource.druid.stat-view-servlet.enabled=false
The following is the error I'm getting in the server logs.
04:42:53.259 [41] [http-nio-8080-exec-8] ERROR org.springframework.web.socket.server.support.DefaultHandshakeHandler - Handshake failed due to invalid Upgrade header: null
I have gone through almost all questions out there regarding the similar issue but none seems to solve the issue. For me the issue is occurring intermittently, not every requests fails. There is also no proxy involved.
The application is deployed in kubernetes. Is there any other reason other that proxies that this issue can occur?
I downloaded bpm-installer-full-7.39.0.Final.zip from here https://download.jboss.org/jbpm/release/7.39.0.Final/
and trying to install it.
In contrast to 7.33 there's no ddl-scripts folder under /db path.
Then, when I made run
ant install.demo.noeclipse
ant start.demo.noeclipse
I kept seeing lots of similar traces:
2020-08-10 12:26:58,268 WARN [org.kie.server.services.impl.controller.DefaultRestControllerImpl] (KieServer-ControllerConnect) Exception encountered while syncing with controller at http://localhost:8080/jbpm-console/rest/controller/server/default-kieserver error Error while sending PUT request to http://localhost:8080/jbpm-console/rest/controller/server/default-kieserver response code 500
2020-08-10 12:27:08,284 INFO [org.kie.server.controller.websocket.client.WebSocketKieServerControllerImpl] (KieServer-ControllerConnect) Kie Server points to non Web Socket controller 'http://localhost:8080/jbpm-console/rest/controller', using default REST mechanism
2020-08-10 12:27:08,299 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /jbpm-console/rest/controller/server/default-kieserver: org.jboss.resteasy.spi.UnhandledException: java.lang.NoSuchMethodError: org.kie.server.api.marshalling.json.JSONMarshaller$2.verifyBaseTypeValidity(Lcom/fasterxml/jackson/databind/cfg/MapperConfig;Lcom/fasterxml/jackson/databind/JavaType;)Lcom/fasterxml/jackson/databind/jsontype/PolymorphicTypeValidator;
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:82)
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:346)
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:193)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:456)
However, PUT http://localhost:8080/jbpm-console/rest/controller/server/default-kieserver works fine and returns 201 status. Client-side cannot handle the response? then why is server response 500 according to the logs?
And GUI (process management) says:
Attention
Execution Server Unavailable
There is currently no server connected.
Does anyone have a guess what I am doing wrong?
PS I installed jbpm v 7.33 on the same PC a couple of months ago without a headache.
Thanks.
I made it work(at least traces are gone and GUI is not throwing warnings).
I went into jbpm-installer-7.39.0.Final\wildfly-18.0.1.Final\modules\system\layers\base\com\fasterxml\jackson
and upgraded
jackson-annotations
jackson-core
jackson-databind
up to 2.10.4 version as exactly this version is used for jbpm .war packages.
I am wondering how they delivered such untested and raw version!
We have an EJB application deployed on WebSphere 8.5, We are getting the following exception on console,
java.rmi.Exception:CORBA NO_RESPONSE 0x4942fb01 Maybe: nested exception is:
RESPONSE: Request 221370 timed out vmcid: IBM minor code: B01 Completed maybe
I can also see the root cause of exception as below:
caused by: org.omg.CORBA.NO_RESPONSE: Request timed out vmcid: B01 Completed maybe
at com.ibm.rmi.iiop.Connection.getCallStream(Connection.java:2493)
The effect of it is end user is unable to connect to the application.
Upon doing some analysis: I found out that main reason could be the connection pool settings.
So Can someone please help me on following:
possible root causes of above exception
possible way to fix this exception
Request timed out means that the EJB request timed out (default 180 seconds): https://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/uorb_rsetg.html
This may have many causes, but in general, it's best to analyze the performance of the EJB backend service (e.g. garbage collection, long response times due to a database, etc.). Here is a place to start on investigating general WAS performance problems: https://publib.boulder.ibm.com/httpserv/cookbook/Recipes-WAS_Traditional_Recipes-General_WAS_Traditional_Performance_Problem.html
A key item is step 8 which gathers thread dumps and basic OS statistics during the problem. If you are stuck analyzing that data, you may open an IBM support request with that MustGather data.
I have a transaction which runs for many hours in the Java Layer and the when Hibernate tries persist collated data, Exception Stack trace shown below is thrown.
Note: I have also tried the configurations specified at..
http://forums.mysql.com/read.php?39,52805,205216#msg-205216 and http://forums.mysql.com/read.php?39,52805,273371#msg-273371
++++++
ERROR org.hibernate.transaction.JDBCTransaction (JDBCTransaction.java:232) - Could not toggle autocommit
java.sql.SQLException: No operations allowed after connection closed.Connection was implicitly closed due to underlying exception/error:
** BEGIN NESTED EXCEPTION **
com.mysql.jdbc.CommunicationsException
MESSAGE: Communications link failure due to underlying exception:
** BEGIN NESTED EXCEPTION **
java.io.EOFException
STACKTRACE:
java.io.EOFException
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1903)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2349)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2860)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1666)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2972)
at com.mysql.jdbc.Connection.commit(Connection.java:2147)
at org.apache.commons.dbcp.DelegatingConnection.commit(DelegatingConnection.java:301)
at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:200)
at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:170)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:146)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:656)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:754)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:723)
at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:394)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:117)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)
MySQL has a default timeout period after which it terminates idle connections. By default the period is 8 hrs.
The DBCP however is unaware of when the connections are terminated by the MySQL server and so these stale connections are still handed out on demand to the application. Hence you get an Exception.
A fix is to add the following properties to your dbcp config:
validationQuery=”SELECT 1″
testOnBorrow=”true”
This tells DBCP to validate the connection with that query.
The connection was most likely dropped by the database. Specify a validation query on DBCP to ensure that the connections in the pool are still alive.
http://commons.apache.org/dbcp/configuration.html
We were having a very similar stacktrace at work when trying to index data, using Lucene, from our Spring application. The problem was the wait_timeout setting in my.cnf. We had just upgraded our MySQL installation and our DBA had forgotten to change wait_timeout from the default setting to what it was previously, 3600.