|   | 
	 
  
    | 
RSS Feed - WebSphere MQ Support
 | 
RSS Feed - Message Broker Support
 |   
 
  
	     | 
	 | 
   
 
  
	|  Unable to trace internal a timeout of an internal SOAP call | 
	« View previous topic :: View next topic »  | 
   
  
  	
	  
		
		
		  | Author | 
		  Message
		 |  
		
		  | Mounti | 
		  
		    
			  
				 Posted: Tue Jun 21, 2022 6:59 am    Post subject: Unable to trace internal a timeout of an internal SOAP call | 
				     | 
			   
			 
		   | 
		 
		
		   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 | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | abhi_thri | 
		  
		    
			  
				 Posted: Wed Jun 22, 2022 12:37 am    Post subject:  | 
				     | 
			   
			 
		   | 
		 
		
		    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 | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | Mounti | 
		  
		    
			  
				 Posted: Wed Jun 22, 2022 3:39 am    Post subject:  | 
				     | 
			   
			 
		   | 
		 
		
		   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 | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | abhi_thri | 
		  
		    
			  
				 Posted: Wed Jun 22, 2022 5:46 am    Post subject:  | 
				     | 
			   
			 
		   | 
		 
		
		    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 | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | Mounti | 
		  
		    
			  
				 Posted: Wed Jun 22, 2022 12:00 pm    Post subject:  | 
				     | 
			   
			 
		   | 
		 
		
		   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 | 
		  
		  	
		   | 
		 
		
		    | 
		 
		
		  | 
		    
		   | 
		 
	   
	 | 
   
 
  
	     | 
	 | 
	Page 1 of 1 | 
   
 
 
 
  
  	
	  
		
		  
 
  | 
		  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
  | 
  		 
	   
	 | 
   
 
  	 | 
	  |