Has anyone also noticed an issue with queue browsing with 5.16.2?
It happens when using an XA connection and starting a session without a transaction context.
This always worked fine but no longer does. Instead one can see a exception, but only when debug logging is turned on:
javax.jms.JMSException: Session's XAResource has not been enlisted in a distributed transaction.
at org.apache.activemq.ActiveMQXASession.doStartTransaction(ActiveMQXASession.java:101) ~[?:?]
This was changed a few years back in 5.16.0 via AMQ-2659. You need to set xaAckMode=1 on your URL now, e.g.:
tcp://localhost:61616?jms.xaAckMode=1
Related
I'm new on Open Liberty and I need to maintain a legacy app
I have on this app logs the following error:
The ConnectionManager was unable to associate Connection com.ibm.ws.rsadapter.jdbc.WSJdbcConnection#3b05f444 with ManagedConnection
WSRdbManagedConnectionImpl#67538473 for resource jdbc/AppDs. Received exception: com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException:
DSRA9420E: Connection cannot be reassociated because child objects are still open.
I'm not sure from to start on this.
I have already searched here
But the code that is shown on logs is based on spring and it couldn't leak connections.
The app uses spring and ehcache.
Please, can someone to provide some guidance?
Looking at the Open Liberty source, that error is raised from a single place in the code, in response to the error condition that a JDBC Connection still has open child JDBC resources (such as Statement, PreparedStatement, ...) associated with it, at a point where it is being asked to reassociate the connection handle across transaction boundaries. Looking at the single caller of that code, it appears that the dissociate method (which closes these same JDBC resources) would have been invoked only a few lines earlier, suggesting that the only way for you to reach the state where the error occurs is if other code were simultaneously using the connection from another thread. To help confirm if this is the case, you could try enabling Liberty trace (via server.xml config) of
<logging traceSpecification="*=info:RRA=all"/>
while reproducing the error and post it somewhere accessible to look at.
I have a .NET Service which keeps polling Oracle Database to get records every 2 mins.
But service stops communicating with Oracle after few hours of run, and throws exception.
I verified at DB level and found there were 155 INACTIVE sessions. I restarted my service and then when I checked there were around 70 INACTIVE sessions for my service.
This process is causing an exception in my service and hence interrupting the work. Can anyone please help me in understanding where is the problem?
Why do not it closes the session or re-use the existing one.
I came to know that in my code Connections to database were not getting closed. I analysed again the whole thing, and closed the connection sin finally block. And it is working smoothly now. Thanks.
I am using Tomcat 7.0, Spring 4.0.2, Web Module 3.0 in eclipse for my web application.
And I configured my session timeout in app/web.xml as well as tomcat/conf/web.xml.
<session-config><session-timeout>10</session-timeout></session-config>
I am sending one request called captureLastActiveTimeForCurrentFile after every 5 mins.
I need to ignore one request (suppose, captureLastActiveTimeForCurrentFile) from updating lastAccessedTime of session.
According http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Sessions (org.apache.catalina.core.StandardHostValve.ACCESS_SESSION) default behavior of tomcat is : every request that is associated with a session will cause the session's last accessed time to be updated if the request explicitly accesses the session.
I am not accessing session explicitly from request (HttpServletRequest object) captureLastActiveTimeForCurrentFile. So According to my understanding tomcat should invalidate session after 10 min from any request done which is accessing session explicitly. But In my case tomcat never invalidate session because I am sending captureLastActiveTimeForCurrentFile after every 5 mins. But according to docs it should be. Can Anyone help me to understand what is happening here? Thanks in advance.
EDIT : I found some discussion regarding this topic here. But still I am not getting actual problem.
I decided to use DBCP mainly because I was getting timeouts on my database connections. In theory, once you define a "validation query", DBCP will by default run that query on the connection before using it, so you always know the connection is OK.
I set it up two weeks ago and it seemed to work. However, last night I got a timeout exception on a connection.
On my dev machine the code survives a MySQL restart without a problem, so I guess DBCP is doing something.
How should I proceed investigating this? Do you use DBCP for this purpose?
(Just deleted 50 lines or so of more detail, trying to keep the question readable. Let me know if some crucial info is missing).
EDIT: Guess I should have read this question before I started...
This is not always true. I experienced similar problems, but it turned out to be that DBCP has a default behavior that is not very well documented.
You must set the time between eviction runs to purge idle connections. This can be set on a SharedPoolDataSource object by calling setTimeBetweenEvictionRunsMillis. If this is never set, the default value is negative, and the thread never runs!
We randomly get warnings such as below on our WL server. We'd like to better understand what exactly these warnings are and what we should possibly do to avoid them.
Abandoning transaction after 86,606
seconds:
Xid=BEA1-52CE4A8A9B5CD2587CA9(14534444),
Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
since begin=86605, seconds
left=0,XAServerResourceInfo[JMS_goJDBCStore]=(ServerResourceInfo[JMS_goJDBCStore]= (state=committed,assigned=go_server),xar=JMS_goJDBCStore,re-Registered
= true),XAServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=
(ServerResourceInfo[weblogic.jdbc.wrapper.JTSXAResourceImpl]=(state=new,assigned=none),xar=
weblogic.jdbc.wrapper.JTSXAResourceImpl#1a8fb80,re-Registered
= true),SCInfo[go+go_server]= (state=committed),properties=({weblogic.jdbc=t3://10.6.202.37:18080}),local
properties=
({weblogic.transaction.recoveredTransaction=true}),OwnerTransactionManager=
ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=go_server+10.6.202.37:18080+go+t3+,
XAResources={JMS_goJDBCStore,
weblogic.jdbc.wrapper.JTSXAResourceImpl},NonXAResources=
{})],CoordinatorURL=go_server+10.6.202.37:18080+go+t3+)
I do understand the BEA explanation:
Error: Abandoning transaction after secs seconds: tx
Description: When a transaction is abandoned,
knowledge of the transaction is
removed from the transaction manager
that was attempting to drive the
transaction to completion. The JTA
configuration attribute
AbandonTimeoutSeconds determines how
long the transaction manager should
persist in trying to commit or
rollback the transaction.
Cause: A resource or participating server may
have been unavailable for the duration of the
AbandonTimeoutSeconds period.
Action: Check participating resources for heuristic
completions and correct any data inconsistencies.
We have observed that you can get rid of these warnings by deleting the *.tlog files but this doesn't seem like the right strategy to deal with the warnings.
The warnings refer to JMS and our JMS store. We do use JMS. We just don't understand why transactions are hanging out there and why they would be "abandoned"??
I know it's not very satisfying, but we do delete *.tlog files before startup in our app hosted on WLS 7.
Our app is an event-processing back-end, largely driven by JMS. We aren't interested in preserving transactions across WLS restarts. If it didn't complete before the shutdown, it tends not to complete after a restart. So doing this *.tlog cleanup just eliminates some warnings and potential flaky behavior.
I don't think JMS is fundamental to any of this, by the way. At least not that I know.
By the way, we moved from JDBC JMS store to local files. That was said to be better performing and we didn't need the location independence we'd get from using JDBC. If that describes your situation also, maybe moving to local files would eliminate the root cause for you?