Recently I had chance to work with MQ Adapter, and it was pretty nice experience and I pretty much tried all different types of settings supported by MQAdapter. Here I would like to share something.
If you religiously follow the document: http://download.oracle.com/docs/cd/B32110_01/web.1013/b28956.pdf then there is not much value I will be adding, but still you might find something useful and accumulated information.
1) Different Settings
-
Scheme: Three types of scheme
-
dynamic : use max connections, if all are in use, then give new one and don't worry about maxConnections limit
-
fixed: use max connections, if all are in use, then throw exception for new request
-
fixed_wait: use max connections, if all are in use, then do fixed amount of wait for newly requested connection
-
-
Best practice is to use fixed_wait with higher timeout so that we can restrict the number of connection
- minConnections/maxConnections/initial-capacity: Decided number of connections and initial connections during start up.
- waitTimeout : This is the timeout used during fixed_wait scheme for new requests
- inactivity-timeout-check: When to check for expired or inactive connections. Supported values are "never","periodic","piggyback" (when a new connection is fetched), and "all" (periodically and when a new connection is fetched).
- We kept it “all” as we don’t want to keep connections idle longer than certain time period.
- inactivity-timeout: The desired connection timeout, in seconds, as a positive integer, or 0 for connections to never expire. Negative values are disallowed.
- We have kept it 60 seconds.
2) "Garbage Collector" - clean up routine
Basically three parameters are used to configure for releasing the idle connection held by OC4J connection pool.
- inactivity-timeout-check: has to be "all" or "piggyback", all is desired if you want to periodically run clean up routine.
- inactivity-timeout: The desired connection timeout, in seconds, as a positive integer, or 0 for connections to never expire. Negative values are disallowed.
- Server.xml (taskmanager-granularity): When inactivity-timeout-check is configured to be periodic, this value specify how specified how frequently we want to run the periodic recycling routine.
Here is sample server.xml entry:
3) Different Level of Caching and Related Errors
Actually, after setting 1 and 2, connections were still not getting cleared, and we were able to see on MQ server side (using Tivoli) that connections are not getting closed. We found from Oracle product managers, that Adapter itself manages cache for MQ (or any type of) connections.
We need to provide, cacheConnections=false property in BPEL Partnerlink or ESB end point property. After that ESB and BPEL releases connection nicely and clean up routine described in No 2, works great and cleans up all idle connections.
4) Inbound and Outbound MQ adapter
Another finding I found was, difference between inbound and outbound adapters. If you have MQ outbound adapter with "cacheConnections=false", it releases connection right after completing the unit of work, and connection is available to OC4J connection pool. But if you have MQ inbound adapter with "cacheConnections=false", it still holds the connection. Probably it is because of continuous polling.
I have not tried it with changing the polling frequency to see if connection get releasesd.
8 comments:
I am using following peice of code
javax.jms.Connection con = null;
Session session = null;
try {
logger.info("start producer ");
RmsProperties locator = RmsProperties.getInstance();
queue = (Queue)locator.getLocalJndiResource(queueName);
oracle.j2ee.ra.jms.generic.XAConnectionFactoryWrapper connectionFactoryWrapper =
(oracle.j2ee.ra.jms.generic.XAConnectionFactoryWrapper)locator.getLocalJndiResource(qcfName);
con = connectionFactoryWrapper.createConnection();
session = con.createSession(true, Session.AUTO_ACKNOWLEDGE);
TextMessage message = session.createTextMessage();
// message.setText(XMLUtilities.getXMLString(doc));
message.setText(msg);
MessageProducer producerSend = session.createProducer(queue);
producerSend.send(message);
logger.info("End producer ");
} catch (JMSException ex) {
logger.error("Internal JMS Error", ex);
throw new RMSSystemException(ErrorMessageReader.RMSI0941,
ex.getLocalizedMessage(), "RMS", ex);
} catch (NamingException ex) {
logger.error("Internal JNDI Error", ex);
throw new RMSSystemException(ErrorMessageReader.RMSI0943,
ex.getLocalizedMessage(), "RMS", ex);
} catch (RuntimeException re) {
logger.error("RuntimeException", re);
throw re;
} finally {
try {
logger.debug("about to if's in MQ connection");
if (session != null) {
logger.debug("about to close MQ session");
session.close();
logger.debug("just closed MQ session");
}
if (con != null) {
logger.debug("about to close MQ connection");
con.close();
logger.debug("just closed MQ connection");
}
logger.debug("after if's in MQ connection");
} catch (JMSException e) {
logger.error(e);
} catch (Exception e) {
logger.error(e);
}
}
}
I am explicitily closing the connection but still it holding the old connection to MQ Queue.
I added the taskmanager-granularity attribute to server.xml still it is not working
Hi,
can you please tell me where to set this
cacheConnections=false in the BPEL Partnerlink?
Inside the wsdl?
Please take a look at
http://forums.oracle.com/forums/thread.jspa?messageID=3221830�
kind regards
Dietrich
Hello Ditrich,
I guess, for BPEL it should be in bpel.xml and not in WSDL. Let me know if it doesn't work.
Thanks,
Chintan
Hi,
i tried with bpel.xml but this does not work ;-(
Hello Dietrich,
It has to work with bpel.xml. May be something else you are missing in the code? Did you check other settings on my blog? also make sure you are using EIS and not making direct connections.
Regards,
Chintan
Hi Chintan,
Could you please mention how and where to update the "cacheConnections=false" property in bpel.xml. Any example would be of great help.
Thanks,
Sagar Shah
Hi Chintan. We followed your advice with the exception of the mode being set to periodic. It has been working great on 10.1.3.3.1, however we just upgraded certain environments to 10.1.3.5.0 and we are not having our sessions get cleaned up. Do you know of a change in this later version?
Post a Comment