| Author |
Message
|
| kienvang |
 Posted: Tue Jul 16, 2013 12:46 am Post subject: TCP/IP server Input Node Slow to receive message |
 |
|
Newbie
Joined: 10 Jan 2013
Posts: 7
|
Hi,
I'm using Message Broker 8.0.0.2 and trying to connect it with Opus Electra ATM Switch. I successfully parse ISO8583 message and get message process in Broker.
However, the TCP/IP server Input node takes 5 seconds to receive message and trigger the flow.
The result of this issue is that our ATM balance queries take 5 seconds to get the result and this is unacceptable for a bank.
Could you please give us some guidance ? |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Jul 16, 2013 3:14 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
You need to set Input Message Parsing to XMLNSC, and declare a Custom Record delimiter (postfix).
I have the same flow as you, and my response time, including record processing, is usually around 430 millis.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jul 16, 2013 4:00 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I think this is a known issue with DFDL and TCP/IP. If so, then there's a fix available.
First, though, we need to know which domain you are using to parse the messages. I note that lancelotinc has assumed that you are parsing XML documents. |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Jul 16, 2013 4:04 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| I successfully parse ISO8583 |
Sounds more like DFDL to me 
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jul 16, 2013 4:04 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| kimbert wrote: |
| First, though, we need to know which domain you are using to parse the messages. I note that lancelotinc has assumed that you are parsing XML documents. |
Sorry my bad -- you are probably correct, he's likely using DFDL to parse the messages. The Opus Electra ATM Switch can send data in either fixed-format or XML.
http://www.electracard.com/solutions-suite/EFT-Switch-Solutions/electra-switch.php
| Quote: |
electra Message Mapper for easy integration to third party solutions
Certified for industry standards – ISO 8583/XML, PA-DSS, IFX, EMV |
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kienvang |
| Posted: Tue Jul 16, 2013 8:25 pm Post subject: TCP/IP Server Input Node Error |
|
|
Newbie
Joined: 10 Jan 2013
Posts: 7
|
Hi,
I tried another Flow where I use TCP/IP server Input node to collect fixed length record from Electra switch (HP Unix). However, I got the same problem.
I also notice that If i connect locally from a command line to message broker. The TCP/IP Server Input Node trigger flow very fast.
 |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jul 16, 2013 10:36 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
One thought struck me here.
The TCP-IP Header param 'OpenTimeStamp' is the CONNECTION OPEN TIME and not the message send time.
I have not looked at this for a while but I think that that particular time does not change while you have a connection open between the two systems.
Send a few messages and see if that field changes. It won't explain the slowness but it might stop a wild goose chase or two.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jul 16, 2013 11:39 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
At risk of repeating myself...
| Quote: |
| I think this is a known issue with DFDL and TCP/IP. If so, then there's a fix available. |
|
|
| Back to top |
|
|
| kienvang |
| Posted: Wed Jul 17, 2013 12:10 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2013
Posts: 7
|
Dear Kimbert,
At first, I also think of DFDL issue. I tried to separate DFDL parsing portion out of the flow.
As you see in my newest flow DFDL parsing is only performed in TCP/IP server receive node while the delay time is reported in T0 node, before TCP/IP server receive.
Do you have any suggest for testing to prove it is DFDL issue ? |
|
| Back to top |
|
|
| kienvang |
| Posted: Wed Jul 17, 2013 12:13 am Post subject: |
|
|
Newbie
Joined: 10 Jan 2013
Posts: 7
|
Also Kimbert,
Can you advice me where I can download your suggested fix for DFDL TCP/IP ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 17, 2013 12:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kienvang wrote: |
Also Kimbert,
Can you advice me where I can download your suggested fix for DFDL TCP/IP ? |
Open a PMR.
Ask IBM for the fix.
Include a link to this thread in the PMR text. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jul 17, 2013 1:04 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Do you have any suggest for testing to prove it is DFDL issue ? |
If it is the problem that I'm thinking of, then the delay is incurred within the DFDL parser just before it completes parsing of the document. I suggest that you create a version of the flow that doesn't use DFDL, and see whether the delay goes away.
| Quote: |
| Can you advice me where I can download your suggested fix for DFDL TCP/IP ? |
The fix is in the IBM DFDL component. It was discovered quite recently, so it is not publicly available yet. You will need to open a PMR and request a fix for your problem. When you do, make sure that you reference this thread - it will ensure that the PMR gets processed efficiently. |
|
| Back to top |
|
|
| ddbvn |
| Posted: Wed Jul 17, 2013 11:56 pm Post subject: |
|
|
Newbie
Joined: 09 Jan 2013
Posts: 8
|
| The weird thing is when we connect the tcpip input and output nodes directly there's still a delay so we think this problem comes from the tcp nodes. Anyone suffered from this before? And because we have to keep the EFT switch intact so we're trying to find out a workaround for it. Thanks everyone for your replies |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jul 18, 2013 12:08 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| The weird thing is when we connect the tcpip input and output nodes directly there's still a delay so we think this problem comes from the tcp nodes |
That's a useful test, but the result does not rule out the DFDL parser. In this particular test,
1. What is the 'Domain' property on the TCP/IP input node?
2. What is the 'Parse Timing' property on the TCP/IP input node? |
|
| Back to top |
|
|
| ddbvn |
| Posted: Thu Jul 18, 2013 12:22 am Post subject: |
|
|
Newbie
Joined: 09 Jan 2013
Posts: 8
|
| kimbert wrote: |
| Quote: |
| The weird thing is when we connect the tcpip input and output nodes directly there's still a delay so we think this problem comes from the tcp nodes |
That's a useful test, but the result does not rule out the DFDL parser. In this particular test,
1. What is the 'Domain' property on the TCP/IP input node?
2. What is the 'Parse Timing' property on the TCP/IP input node? |
Thanks for your quick response
1. Domain property of TCP/IP input node in the test is BLOB, Record detection is set to Fixed length with length = exact size of incoming message, it just echoes back the incoming message to the EFT switch  .
2. It's On Demand but i think its not important when Domain = BLOB.
At first, we think we should do some tcpip tuning in Windows registry but it didnt work 
Last edited by ddbvn on Thu Jul 18, 2013 12:29 am; edited 1 time in total |
|
| Back to top |
|
|
|
|
