| Author |
Message
|
| ashish_halge |
 Posted: Wed Mar 07, 2012 3:57 am Post subject: Issue with HttpInput node for processing multiple request |
 |
|
Novice
Joined: 24 Aug 2008
Posts: 13
Location: Dubai, UAE
|
We are using message broker V6.1.0.8, and the issue as follows;
An Http client connecting to my broker using a single socket connection and posting all the request through the same. Now the problem is, the biphttplistener, alloting only one thread per socket. We verified the same through the biphttplistener service trace
All the request coming on the same socket are processed sequentially.
So There is a lot of time delay in processing the last request.
HTTP Version used is 1.1
Kindly suggest what configuration needs to be done at the broker end . |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Mar 07, 2012 5:59 am Post subject: Re: Issue with HttpInput node for processing multiple reques |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ashish_halge wrote: |
| Kindly suggest what configuration needs to be done at the broker end . |
Additional instances of the processing flow.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Mar 07, 2012 6:17 am Post subject: Re: Issue with HttpInput node for processing multiple reques |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Vitor wrote: |
| ashish_halge wrote: |
| Kindly suggest what configuration needs to be done at the broker end . |
Additional instances of the processing flow. |
Yes. With flows starting with HTTPInput nodes this is a bit tricky because the only place where you can increase the number of instances is the bar file. This is probably why you have missed it. |
|
| Back to top |
|
|
| ashish_halge |
| Posted: Thu Mar 08, 2012 12:15 am Post subject: |
|
|
Novice
Joined: 24 Aug 2008
Posts: 13
Location: Dubai, UAE
|
Currently the additional instances has been set to 4
For clarifi cation
We are not facing the issue at the Flow level . The issue is faced at the biphttplistener.
Due to mutiple request coming from same server at the same socket . The biphttplistener is processing them sequentially . As a result last message arrives at the SYSTEM.WS.INPUT queue so late that the server timeout and get a SOAP FAULT.
Is is possible that we can activate multiple threads from server side to cater to one socket. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Mar 08, 2012 12:21 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
It's the client end that needs to be modified to open more sockets...
Have you tried putting an HTTP proxy between the client and the server? |
|
| Back to top |
|
|
| ashish_halge |
| Posted: Thu Mar 08, 2012 1:01 am Post subject: |
|
|
Novice
Joined: 24 Aug 2008
Posts: 13
Location: Dubai, UAE
|
Thanks for the reply
Sorry i forgot to mention the below part.
All the clients are connecting to the sever via proxy .The Proxy itself is opening one socket and pumping the requests.
We are trying to find that whether some configuration can be done at the server end to concurrently process the request coming on the same socket
If not possible then we can ask the Proxy to open more socket |
|
| Back to top |
|
|
| tdolby |
| Posted: Thu Mar 08, 2012 9:28 am Post subject: |
|
|
Newbie
Joined: 29 Jun 2004
Posts: 8
|
Assuming I'm understanding correctly, the proxy is using pipelining (see RFC 2616) on a single socket out to the MB listener, and the MB listener is handling each request in turn, finishing one request before starting the next.
The described MB listener behaviour is what I would expect, mostly because we don't have any reordering going on in the listener: if we send multiple requests from the same socket to the flow, we would need to ensure the responses get sent back to the client (proxy, in this case) in the right sequence (as required by RFC 2616), and we don't have code that does that at the moment.
In general, it's been unusual to encounter a proxy that behaves this way by default, because of the issue of slow requests jamming up quick ones. If the proxy receives a request that will take 10 seconds to complete, followed by 10 requests that each take 1 millisecond, the 1 millisecond requests will have to wait for the 10 second request to complete before the 1 millisecond responses will be flowed back across the socket. To do anything else requires either multiple sockets, or breaking the HTTP protocol spec and sending responses back out of order.
I hope this make sense  The upshot is that the best bet is to get the proxy to use multiple sockets: this will allow the proxy to work with broker and will also protect against the ordering issues described above.
_________________
Trevor Dolby
IIB Development |
|
| Back to top |
|
|
| ashish_halge |
| Posted: Sun Mar 11, 2012 10:52 pm Post subject: |
|
|
Novice
Joined: 24 Aug 2008
Posts: 13
Location: Dubai, UAE
|
Thanks for your reply, its helpful...
So, finally we have decided that the change has to be done at the client side/HTTP proxy to open multiple sockets and no further changes can be done at Broker side.... |
|
| Back to top |
|
|
|
|
