| Author |
Message
|
| sanjoo |
 Posted: Sat Oct 18, 2014 2:13 pm Post subject: HTTPRequest node: BIP3161 socket exception |
 |
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Hi All,
We are using HTTPRequest node to invoke a webservice. In production when we deployed this for the first time, we are getting below exception logged-
HTTP Request::Function:ImbWSRequest::readDataFromSocket::An error occurred whilst performing a TCP/IP socket operation. The socket was closed before all expected data was received, as the end of the HTTP headers have not been found. Total data received: 0.::0"
In all lower environments, it worked beautifully. I have verified from the admin that network settings on lower env and prod are largely similar.
I tried reading documentation on BIP3161. Its not giving any clue on where this might be network issue or application issue.
Another question I have is whether this socket exception is happening in the request path or response path.
BTW, we are at WMB 7 FP 7 on AIX.
Thanks in advance.
_________________
Sanjoo
Keep smiling
 |
|
| Back to top |
|
 |
| nelson |
| Posted: Sun Oct 19, 2014 9:38 am Post subject: Re: HTTPRequest node: BIP3161 socket exception |
|
|
Partisan
Joined: 02 Oct 2012
Posts: 313
|
sanjoo
This case is very similiar to yours.
Kind regards. |
|
| Back to top |
|
|
| sanjoo |
| Posted: Sun Oct 19, 2014 2:58 pm Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Hi, I did went through that post and I didn't find it conclusive for the root cause.
Timeout for web service is 15 seconds but within 50 ms I get this socket exception saying "BIP3161S: A socket was closed before all expected data was received. Total data received: 0. "
So I don't think it's about not having enough time to receive data.
Anyway, network admin is looking into it now. I will update once I find anything.
In the meantime, if you have any helpful inputs, please do share.
Thanks
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| sanjoo |
| Posted: Sun Oct 19, 2014 4:21 pm Post subject: |
|
|
Acolyte
Joined: 26 Oct 2005
Posts: 65
|
Hi,
The documentation for BIP3161 says ->
BIP3161
A socket was closed before all expected data was received. Total data received: <insert_1>.
Severity
30 : Severe error
Explanation
An error occurred whilst performing a TCP/IP socket operation. The socket was closed before all expected data was received, as the end of the HTTP headers have not been found. Ensure that the HTTP data is valid.
===========
Could this be data issue that application is sending?
_________________
Sanjoo
Keep smiling
|
|
| Back to top |
|
|
| Hoshi |
| Posted: Thu Apr 21, 2016 12:45 am Post subject: |
|
|
Novice
Joined: 02 Feb 2016
Posts: 10
|
Hello, Sanjoo,
Were you able to identify the root cause for the error above?
We are facing a similar situation. We have a simple message flow performing requests to an HTTPS endpoint. The flow is under reasonably high load processing several messages per second. For majority of messages (>99%) everything works fine, but once in a few minutes we get the same error as yours:
| Code: |
| An error occurred whilst performing a TCP/IP socket operation. The socket was closed before all expected data was received, as the end of the HTTP headers have not been found. Total data received: &1.(0) |
We are also running WMB 7.0.0.7 on AIX. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Apr 21, 2016 1:49 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
You do know that WMB 7 went out of service/support last September?
_________________
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 |
|
|
| Hoshi |
| Posted: Thu Apr 21, 2016 4:09 am Post subject: |
|
|
Novice
Joined: 02 Feb 2016
Posts: 10
|
| Yes, I do. But thanks for the reminder! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 21, 2016 4:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Make sure you know what the message tree you are passing to the request node looks like.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Hoshi |
| Posted: Thu Apr 21, 2016 10:34 pm Post subject: |
|
|
Novice
Joined: 02 Feb 2016
Posts: 10
|
It looks like we were able to figure out what was causing the error in our case.
The HTTPRequest node in our flow is configured to use persistent connections with HTTP 1.1 keep-alive over TLS protocol. The maxSocketAge attribute on broker's ComIbmSocketConnectionManager was set to default value of 4 seconds. On the other hand the server was configured to close idle connections after 1 second timeout.
So due to the amount of requests the flow was processing it was not too uncommon that broker would try to send a new request through an open connection exactly 1 second after previous successful request. And in some cases it would happen so that right at the same time the server would send a TLS close_notify event (before the actual TCP FIN packet) due to connection being idle. The broker would then try to parse this close notification as a valid HTTP response and failing to do so would raise the above exception.
Changing overall configuration so that maxSocketAge at the broker side is less than the server idle connection timeout seemed to have resolved the issue. |
|
| Back to top |
|
|
| vinod28885 |
| Posted: Tue May 17, 2016 3:09 am Post subject: Need help on this issue |
|
|
Newbie
Joined: 17 May 2016
Posts: 3
|
Hi Hoshi,
I am also facing this issue in my case. In your answer you have mentioned that the server idle timeout is 1 second. Which server you are using ? Can this timeout be imposed by a firewall too ?
BTW I am interacting with a Web Serivce using WMB HttpRequestNode.
Regards
Vinod |
|
| Back to top |
|
|
| Hoshi |
| Posted: Thu May 19, 2016 12:35 pm Post subject: |
|
|
Novice
Joined: 02 Feb 2016
Posts: 10
|
Hi vinod,
I don't really have information about the server software since it's a 3rd party. And for the second question - I'm pretty certain a firewall can close idle connections too.
Anyway the best thing you can do to analyze the problem is capture, decrypt (in case of SSL) and analyze the traffic between Broker and Web Server during the moment the problem occurs. |
|
| Back to top |
|
|
| vinod28885 |
| Posted: Fri May 20, 2016 1:56 am Post subject: |
|
|
Newbie
Joined: 17 May 2016
Posts: 3
|
Hi Hoshi,
Thanks for the reply.
I wanted to know how you were able to find out the time out value of target server as 1 second.
Where is the time out set ? in TCP layer / server layer ?
Regards
Vinod |
|
| Back to top |
|
|
| Hoshi |
| Posted: Sun May 22, 2016 11:44 am Post subject: |
|
|
Novice
Joined: 02 Feb 2016
Posts: 10
|
| It's a Web Server configuration for persistent (keep-alive) connections. We didn't have to find it out in our case, since server admins just told us what they configured. |
|
| Back to top |
|
|
| vinod28885 |
| Posted: Mon May 23, 2016 4:31 am Post subject: |
|
|
Newbie
Joined: 17 May 2016
Posts: 3
|
Thanks Hoshi.
1 last question
Whats the final value you set in WMB and server side to resolve the issue ?
Regards
Vinod |
|
| Back to top |
|
|
| Hoshi |
| Posted: Mon May 23, 2016 8:53 am Post subject: |
|
|
Novice
Joined: 02 Feb 2016
Posts: 10
|
We've set 1 second on the Broker side and 2 seconds on the Web Server side.
Although I strongly suggest you capture and analyze the traffic in your environment, since I believe there may be many different factors to cause the error in discussion. |
|
| Back to top |
|
|
|
|
