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 Index » WebSphere Message Broker (ACE) Support » Unable to trace internal a timeout of an internal SOAP call

Post new topic  Reply to topic
 Unable to trace internal a timeout of an internal SOAP call « View previous topic :: View next topic » 
Author Message
Mounti
PostPosted: Tue Jun 21, 2022 6:59 am    Post subject: Unable to trace internal a timeout of an internal SOAP call Reply with quote

Newbie

Joined: 21 Jun 2022
Posts: 3

Dear sirs,
We have 2 x IIB message flows hosted on the same integration server [IIB 10].
The first message flow is invoked via an external SOAP request, and in its turn it invokes the second message flow also via SOAP.
This was working all the time but for some reason, it stopped recently; the invocation of the second message flow is failing after 120 seconds with the below error:

"BIP3151 - A timeout occurred whilst performing a socket operation"

We did a trace with the below sequence of steps:
. mqsichangetrace IIB1D -t -e BLESB2D -l debug -r
. Use SOAPUI to invoke the first message flow
. mqsichangetrace IIB1D -t -e BLESB2D -l none
. mqsireadlog IIB1D -e BLESB2D -t -f -o /iibdata/trace.xml
. mqsiformatlog -i /iibdata/trace.xml -o /iibdata/trace.txt

The obtained trace showed that the first message flow invoked the second and that the HTTP request was received by the integration server, however nothing else in the trace is denoting what happened with that request after that. Message flow 1 is timing out after 120 seconds with the BIP3151 message shown earlier.

Kindly help diagnosing this issue. Is there any more verbose trace or action that allows to show what error happened with the SOAP request received by message flow 2?

2022-06-21 11:11:51.711384 73519 >> UserTrace BIP3633I: Node 'CallAndReply.SOAP Request' sending HTTP data to URL '/BLESB/ENT/TransferServices' at host 'localhost' (port 7801).
The integration node is sending data via HTTP to a remote server at host 'localhost' (port 7801) using URL '/BLESB/ENT/TransferServices'. See subsequent messages for success or failure messages relating to this request.
No action required.
2022-06-21 11:11:51.711388 73519 >> ImbWSRequest::sendHttpData 'Using buffer and sending all data in one write' , 1452
2022-06-21 11:11:51.711400 73519 >> ImbWSRequest::sendHttpData 'send request with HTTP headers: ' , 'Content-Length: 1131
Parenttransactionid: X'534f41500000000100000000855149ed000000000000bccc'
Content-Type: text/xml; charset=utf-8
Accept-Encoding: gzip,deflate
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Host: localhost:7801
SOAPAction: ""
Connection: Keep-Alive

', 0
2022-06-21 11:11:51.711404 73519 >> ImbWSRequest::sendHttpData 'Sending whole request'
2022-06-21 11:11:51.711412 73519 >> { ImbBasicSocket::sendTimeout , (*ptr)1b47efe46, 1452, 1655799231711
2022-06-21 11:11:51.711432 73519 >> } ImbBasicSocket::sendTimeout , 'sent ', 1, 1452, 120000
2022-06-21 11:11:51.711436 73519 >> } ImbWSRequest::sendHttpData
2022-06-21 11:11:51.711444 73519 >> { ImbWSRequest::getHttpResponse , 1655799231711
2022-06-21 11:11:51.711448 73519 >> { ImbWSRequest::readDataFromSocket , 1655799231711, false
2022-06-21 11:11:51.711460 73519 >> { ImbBasicSocket::recvTimeout , (*ptr)1b551ff30, 32768, 1655799231711, true
.
.
.

022-06-21 11:11:51.713336 14665 UserTrace BIP3630I: The integration node has received an HTTP message on port '7801' with URL path '/BLESB/ENT/TransferServices'.
The integration node is listening on port '7801' and has received a message sent by a client using URL path '/BLESB/ENT/TransferServices'. This message will be sent on to either a SOAP Input Node or a SOAP Asynchronous Response Node.
No action required.
2022-06-21 11:11:51.713348 14665 AdapterClass.service 'Found dispatch match for uri: /BLESB/ENT/TransferServices'
2022-06-21 11:11:51.713360 14665 AdapterClass.service 'wo |com.ibm.broker.inlinehttp.tomcatthreadpool.WorkObject@fe934f22|'



Appreciating your help,
Best regards,
Back to top
View user's profile Send private message
abhi_thri
PostPosted: Wed Jun 22, 2022 12:37 am    Post subject: Reply with quote

Knight

Joined: 17 Jul 2017
Posts: 516
Location: UK

hi...worth checking what got changed around the time this stopped working (eg:- network/firewall changes).

- are you able to invoke the second flow outside of the first flow, curl or Soap UI etc?

- run the user trace for the second flow to see where exactly it is spending time
Back to top
View user's profile Send private message
Mounti
PostPosted: Wed Jun 22, 2022 3:39 am    Post subject: Reply with quote

Newbie

Joined: 21 Jun 2022
Posts: 3

Hi again,
Thanks for your hint.
As mentioned in my original post, the trace generated was a global one and not for a specific flow and as I mentioned it just showed that the request was received by the integration node with a "Found dispatch match" but without showing why it was not dispatched to the second flow.
Anyway we rolled back a change and it fixed the issue. However I'm interested in knowing what else could be done to increase the traces in case possible or to check somewhere else to see why it was not dispatched.

022-06-21 11:11:51.713336 14665 UserTrace BIP3630I: The integration node has received an HTTP message on port '7801' with URL path '/BLESB/ENT/TransferServices'.
The integration node is listening on port '7801' and has received a message sent by a client using URL path '/BLESB/ENT/TransferServices'. This message will be sent on to either a SOAP Input Node or a SOAP Asynchronous Response Node.
No action required.
2022-06-21 11:11:51.713348 14665 AdapterClass.service 'Found dispatch match for uri: /BLESB/ENT/TransferServices'
2022-06-21 11:11:51.713360 14665 AdapterClass.service 'wo |com.ibm.broker.inlinehttp.tomcatthreadpool.WorkObject@fe934f22|'
Back to top
View user's profile Send private message
abhi_thri
PostPosted: Wed Jun 22, 2022 5:46 am    Post subject: Reply with quote

Knight

Joined: 17 Jul 2017
Posts: 516
Location: UK

Mounti wrote:
Hi again,
Anyway we rolled back a change and it fixed the issue. However I'm interested in knowing what else could be done to increase the traces in case possible or to check somewhere else to see why it was not dispatched.


hi...you could enable service trace and see what it shows but if the user trace itself doesn't show that the request is forwarded or not, then the service trace may not be that helpful.

If the rollback of the other change fixed the issue then isn't it just the matter of understanding what that change is all about and why it is intefering with request forwarding?
Back to top
View user's profile Send private message
Mounti
PostPosted: Wed Jun 22, 2022 12:00 pm    Post subject: Reply with quote

Newbie

Joined: 21 Jun 2022
Posts: 3

Dear abhi_thri,
This what we are trying to do (understand how the change impacted things).
About the "service trace", isn't it the same as what we did? Using "-t" instead of "-u" in the below command:
mqsichangetrace IIB1D -t -e BLESB2D -l debug -r

Best regards,
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Unable to trace internal a timeout of an internal SOAP call
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.