| Author |
Message
|
| George Carey |
 Posted: Thu Sep 10, 2009 2:56 pm Post subject: question on connection issues in java |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Question 1)
Environment is MQ v7.0.0.2 code on Linux box
Developer is getting from his Java Bean on Oracle app server using RA to connect to MQ server doing point to point I/O to queue destinations, gets Maxnumber of channels reached. (from amqrmppa) (user mqm)
qm.ini has default values so 100 connections max I believe is set. Application should have no more then a handful of concurrent connections. So application code is obviously leaving connection open and reconnecting anew some where.
Coder is experienced Java coder (but may be new to JMS usage) .
a.)Is there a typical area for JMS newbies to look for such logic errors in their code?
b.) Would a finally method as the following, catch all such problems:
( where conn is Connection from conn = factory.createXAConnection(); )
finally {
_________if (conn != null) {
____________try {
_________________conn.close();
____________} catch (JMSException e) {
_________________e.printStackTrace();
____________}
_________}
______}
(note: _____ used for space characters)
c.) Isn't the use of a RA supposed to avoid these connections issues ?
Question 2.) (tangent - curiousity)
Error log file shows the max channel reached error ... and says to look at previous error messages in the error files to determine cause ...
I am, however, at line one of AMQERR01.LOG ... any chance I have previous error or has it been overwritten ??
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding")
Last edited by George Carey on Fri Sep 11, 2009 4:04 pm; edited 1 time in total |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Sep 10, 2009 3:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you are at line 1 in AMQERR01.LOG check out AMQERR02.LOG...
As for the JMS thingy... Each app server has a little bit of a different imperative and the coding will also depend on the transaction manager.
Typically you need to close the objects at the end of the method having acquired the the resource being used.
The MDB with the onMessage method is a little bit special as you do not handle the current connection / session but for the transactionality descriptor with requiresNew.
100 connections may be awfully low depending on the type of work you are trying to model.
Remember each instance of an MDB requires a connection (add 1 per MDB)
i.e. and MDB with 10 instances requires 11 connections.
Now add all the outbound connections being created on the fly (outbound messages) and concurrent. This can be throttled somewhat by setting a limit to the size of the connection factory pool.
Add all other connections / channels the qmgr needs...
You get the picture... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Sep 11, 2009 10:21 am Post subject: java question followup |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
The java question is most important so I will focus on that:
The number of channels being used for this app is absolutely less then default max ... and developer does not want to increase max channels as he says that will only delay the recurrence of the problem (absolutely correct!).
| Quote: |
Typically you need to close the objects at the end of the method having acquired the the resource being used. from fjb.
|
The resource allocation logic is all in main method of JavaBean. (there is one method that reads xml file into byte array, eventually put into msg but not relevant to MQ connections.)
The code is request/reply paradigm and using JMS MessageProducer and MessageConsumer on destination object queues.
Pseudo code steps as follows:
1.) start of main
2.try) create Properties = props for ContextFactory and ProviderUrl for ContextFactory
3.) create InitialContext = context using props
4.) create XAConnectionFactory = factory
5.) create XAConnection = conn using factory
6.) create Session = session using conn
7.) create Destination = request from context.lookup
8.) create MessageProducer = prod from session and request
9.) Start Connection using conn
10.) create TxtMessage = msg
11.1.try) "produce/send msg" using prod.send
_____11.2) create Destination = reply from context.lookup
_____11.3) create MessageConsumer = consumer from session and reply
_____11.4) receive Message = replyMsg using consumer.receive
11.1.catch)catch JMS exceptions
12.catch)catch exceptions
13.)finally() check for connection not closed by testing for conn !=null
14.) end of main
With the above pseudo code ... any response to previous questions a, b, or c.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 11, 2009 11:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I think you need to issue the disconnect method on the QM object. Just closing the session may not do that (I am a Java newbie). But if you end without disconnecting, either explicitly or implicitly, you leave an orphaned MQ channel.
You can protect yourself from this scenario as an MQ Admin buy making sure your QM uses TCP Keep Alive, and that the O/S has it turned on. Of course this can only help with a reasonable rate of orphaned connections.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| atheek |
| Posted: Fri Sep 11, 2009 11:32 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg1IZ53632
| Quote: |
IZ53632: XASESSIONS CLOSED DURING XACONNECTION.CLOSE() DO NOT DISCONNECT UNDERLYING CONNECTIONS TO THE QUEUE MANAGER
A fix is available
WebSphere MQ V7.0 Refresh Pack 7.0.1.0.
APAR status
Closed as program error.
Error description
When XAConnection.close() is called it closes any
XASessions that were created from the XAConnection. When
these XASessions close, the underlying physical connection to th
queue manager is not disconnected, leading to a build up of
connection handles. This appears as an apparent memory leak and
potentially a build up of amqrmppa processes in the
queue manager.
The problem only applies when XASessions are closed as part
of a XAConnection.close() and not when the XASessions
objects are closed directly.
Local fix
Problem summary
****************************************************************
USERS AFFECTED:
This error affects applications that use XAConnections and do
not close any child XASession objects explicitly but rely on the
XASessions closing when the XAConnection is closed.
Platforms affected:
All Distributed (iSeries, all Unix and Windows) +Java
****************************************************************
PROBLEM SUMMARY:
The close(boolean) method called to close sessions during
XAConnection.close() was not overridden, and so when closing
XASessions the method on the superclass was called. This does no
close the associated session and so the physical connection to
the queue manager was not closed.
Problem conclusion
The close method is now overridden correctly, and the physical
connections to the queue manager are closed when XASessions are
closed by calling close on the parent XAConnection.
|
|
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Sep 11, 2009 3:45 pm Post subject: program error |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
With this finally() logic it cetainly looks like that could be the problem atheek, thanks I will have the developers check it out next week.
| Quote: |
finally {
_________if (conn != null) {
____________try {
_________________conn.close();
____________} catch (JMSException e) {
_________________e.printStackTrace();
____________}
_________}
______} |
Interesting APAR wording:
| Quote: |
APAR status
Closed as program error. |
Not the application program's error but the IBM JMS implementation of the XAConnection.close logic, is it not ?!!
I suppose an alternative work around would be to close the Sessions explicitly/directly(y/n)?
I will see about getting the 7.0.1 update in the interim.
Lastly, what is the value of using the Resource Adapter from IBM for this connectivity ... I thought this would handle such matters. What does the RA really do for a coder? ... I guess I will have to re-read some more.
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Sep 11, 2009 4:32 pm Post subject: Re: program error |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Quote: |
Interesting APAR wording:
APAR status
Closed as program error. |
Not really, its standard stuff.
| Quote: |
Not the application program's error but the IBM JMS implementation of the XAConnection.close logic, is it not ?!!
|
Yes, thats exactly what it is!
| Quote: |
I will see about getting the 7.0.1 update in the interim.
|
This sounds like the best approach. I normally find people are more open to upgrades when it fixes something specific for your setup.
| Quote: |
Lastly, what is the value of using the Resource Adapter from IBM for this connectivity ... I thought this would handle such matters.
|
It should do but for the bug. Even IBM get it wrong sometimes!
| Quote: |
What does the RA really do for a coder?
|
Provides a standard approach for developers to build adapters to backend Enterprise Information Systems so that the container can manage them for you providing things such as transactions, security and scalability. |
|
| Back to top |
|
|
| atheek |
| Posted: Fri Sep 11, 2009 5:37 pm Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| The best practise would be to close all the consumer, producer, session and connection objects explicitly in the finally block. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 12, 2009 10:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
10.) create TxtMessage = msg
11.1.try) "produce/send msg" using prod.send
_____11.2) create Destination = reply from context.lookup
_____11.3) create MessageConsumer = consumer from session and reply
_____11.4) receive Message = replyMsg using consumer.receive
11.1.catch)catch JMS exceptions |
And please note the logic error in the above snippet
| Code: |
10.) create TxtMessage = msg
11.0.try)
_____11.1) create Destination = reply from context.lookup
_____11.2) "set reply Destination on msg"
_____11.3) "produce/send msg" using prod.send
_____11.4) "create selector from msg.msgid/correlid"
_____11.5) create MessageConsumer = consumer from session and reply + selector
_____11.6) receive Message = replyMsg using consumer.receive
11.1.catch)catch JMS exceptions |
is what it should look like
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Mon Sep 14, 2009 10:26 am Post subject: logioc error ? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Thanks for the best practices tip ... I will forward that onto our developers.
On the 'logic error':
The Destination request was created earlier in the (pseudo)code and just sent in this section and then a new Destination reply was created without selectors being used and also since a pre-ordained destination queue for reply messsages is being used, no need to put in the Detination = request in original request msg, correct?
I don't believe either selectors or reply queue are required to be specifiecd for the API. But even if they were how is that a logic error?
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 14, 2009 1:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The logic error was in sending the request message without having put the replyTo destination on it.
It becomes more crucial to use the selector for the correlationId (=msgid or correlid) if all the responses are commingled in the same response queue.
You could as well have a completely disconnected asynchronous model where the receiver just processes any message and puts it into a DB for the correlation to happen there... But then why would you want the response on the same thread??
If you are working with transacted sessions make sure you COMMIT after the request send method because you are not going to get a reply before the request has been committed.
So my 11.3) should probably say produce and commit.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
