ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexWebSphere Message Broker SupportPerformance, XA and getJDBCType4Connection

Post new topicReply to topic
Performance, XA and getJDBCType4Connection View previous topic :: View next topic
Author Message
Algol
PostPosted: Sat Sep 30, 2017 5:43 am Post subject: Performance, XA and getJDBCType4Connection Reply with quote

Newbie

Joined: 23 Jan 2017
Posts: 9

Our customer have strange performance problem with IIB application that interacts with 3 Oracle databases. Our flows have several compute nodes that call getJDBCType4Connection to obtain connections to required databases to read/write data. This application uses XA coordinated transaction (flows and qm.ini is configured) and works good on testing environment. But production IIB produces some strange delay, so that the first logging point - in compute node that is right after SOAP Input node, gets control with delay (up to 30 sec).
From another side - when we switched off XA coordinated transaction (in flows and in qm.ini) we have got another problem - subsequente calls
Connection conn1 = getJDBCType4Connection("dataSource1", JDBC_TransactionType.MB_TRANSACTION_AUTO);
Connection conn2 = getJDBCType4Connection("dataSource2", JDBC_TransactionType.MB_TRANSACTION_AUTO);
Connection conn3 = getJDBCType4Connection("dataSource3", JDBC_TransactionType.MB_TRANSACTION_AUTO);
produce delay up to 60 seconds on second or third line.
What can be a reason for such strange behavior?
Back to top
View user's profile Send private message
Algol
PostPosted: Sat Sep 30, 2017 5:55 am Post subject: Reply with quote

Newbie

Joined: 23 Jan 2017
Posts: 9

Flow diagram for the message is here:
https://www.dropbox.com/s/3mcbcv59dn2t0yy/flow.gif?dl=0
First logging is happening in CheckAuth node.
And as I said its happening with delay up to 30 sec. when the flow uses XA.
When the flow doesn't use XA there are no delay in SOAP Input, but we have delay on getJDBCType4Connection.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Sep 30, 2017 8:17 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17443

I'm not sure what the qm.ini has to do with SOAP message flows.

I'm not sure where the qmgr comes in at all. None of your nodes appear to use MQ at all.

I'm not sure where XA is inolved with a non-transactional input, HTTP, and a non-transactional database call (JDBC Type 4 connection).

But maybe I'm misreading your flow diagram. It's a bit much to go through for fun.
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
Algol
PostPosted: Sat Sep 30, 2017 8:28 am Post subject: Reply with quote

Newbie

Joined: 23 Jan 2017
Posts: 9

BTW, we have found, that order of getJDBCType4Connection calls depends on result. So it works very fast and stable in case of opening connections in different order. Is it dealing with our case when one dataSource uses some one database, and two others - another?
Can it be also a reason for delay of flow in case of XA?
Back to top
View user's profile Send private message
Algol
PostPosted: Sat Sep 30, 2017 8:38 am Post subject: Reply with quote

Newbie

Joined: 23 Jan 2017
Posts: 9

mqjeff wrote:
I'm not sure what the qm.ini has to do with SOAP message flows.

msgflow in resources of bar file has Coordinated transaction property. This property is directly dealing with XA. And qm.ini is the file where XA resources are configured.
https://www.dropbox.com/s/r13815btdm8z7mw/msgflow.gif?dl=0
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Sep 30, 2017 9:01 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17443

Algol wrote:
mqjeff wrote:
I'm not sure what the qm.ini has to do with SOAP message flows.

msgflow in resources of bar file has Coordinated transaction property. This property is directly dealing with XA. And qm.ini is the file where XA resources are configured.
https://www.dropbox.com/s/r13815btdm8z7mw/msgflow.gif?dl=0


Are you using MQ? At all?

If not, the qm.ini does nothing for your flow.

Are you using ODBC? At all?

Then configuring XA between the qmgr and Oracle does nothing for your flow.

Is HTTP transactional?

If not, how will you do XA between two transactional resources?

Is JDBC Type 4 transactional?

If not, how will you do XA between two transactional resources?
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
Algol
PostPosted: Sat Sep 30, 2017 9:05 am Post subject: Reply with quote

Newbie

Joined: 23 Jan 2017
Posts: 9

Just one link for answer:
https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ah61330_.htm
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Sep 30, 2017 9:18 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17443

Algol wrote:
Just one link for answer:
https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ah61330_.htm


Wow.

Congratulations. Nobody's done that to me in a long time.

So, okay. You get a slowdown when you use XA to talk to your database.

Run a service trace of your message flow with XA enabled. it's a deeply complex document that is best read by IBM Support. But for your needs, some basic analysis can help.

Look for large gaps in time stamps in the trace. See if you can tell what operations are being performed right before those gaps - i.e. what is taking the longest to complete.

Make sure to eliminate the queue manager as the source of the slowdown. If it is, then look at reconfiguring the queue manager for better ttransaction handling. Likely by talking to IIB support using the trace you've already taken.

If it's not MQ,then.

It could be several things: Allocating the JDBC Connection pool, establishing an XA transaction with the Database, doing an insert/update during an XA session, comitting the update/insert during an XA Session, or simply network connectivity between the IIB server and the broker.

Once you've identified the issue as talking to the DB, tell. the network people that they've broken the connection. When they say it's not their fault, show them the gap in timestamps.

They'll blame the DBAs. So tell the DBAs that they've caused slowdowns in critical business processing.

Once they blame the network people, then get everyone in the same room, with the network people having data on the connection between the broker and the database, and the dbas having data on the processing of the insert/updates on their side.

Then show them the gaps in your log, and given them 20 minutes to argue.
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
Algol
PostPosted: Sat Sep 30, 2017 9:33 am Post subject: Reply with quote

Newbie

Joined: 23 Jan 2017
Posts: 9

Thank you.
I think that I saw your similar answer before
But as system analyst I'm both DBA and ESB developer in one face.
In any case thanks to you I found one more point to check.
I'll inform here if the idea is correct.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Sep 30, 2017 9:54 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17443

If you're the DBA, you might also see if the transaction commits faster if you use a stored procedure.

That's a wild guess with no data to back it up.
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
Algol
PostPosted: Tue Oct 03, 2017 4:42 am Post subject: Reply with quote

Newbie

Joined: 23 Jan 2017
Posts: 9

Well, I tried to reconfigure dataSources, removed not-usefull getJDBCType4Connection and at last it works quite fast. But without XA.
I want to return to XA problem and here is the latest trace for my case:
https://www.dropbox.com/s/9otusj7yy84i8cf/serviceflowtrace.zip?dl=0
My service was called from SoapUI at 11:50:42, but it was first mentioned in trace just at 11:51:00.
2017-10-03 11:51:00.795540 22257 TomcatWorkInProgress.getHTTPHeaderInternal 'Header: === MimeHeaders === accept-encoding = gzip,deflate content-type = text/xml;charset=UTF-8 soapaction = "http://IntegrationService/getCardList" authorization = Basic QlVTVVNFUjpCVVNVCHANGED== content-length = 406 host = wmb.bank:7810 connection = Keep-Alive user-agent = Apache-HttpClient/4.1.1 (java 1.5) '
What was happened during 18 seconds after the call - unknown.
But 18 seconds to start processing is too much...
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Message Broker SupportPerformance, XA and getJDBCType4Connection
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.