Http Post

The original flow is server A will send http post to my server then my server will massage data and send to server B. Server B will response to my server and response back to server A. Please see working flow as following :

'Server A' -> 'My server' -> 'Server B' -> 'My server' -> 'Server A'

The server encounter timeout issue because Server B taking too long to process the data. Therefore i intend to change the flow as below:

'Server A' -> 'My server' -> 'Server A'(immediately reply back to server A as acknowledge)

After response back to server A, then only 'My server' -> 'Server B' -> 'My server'. Is that anyway to do so?

How will your server get back to server A? Does it have an HTTP callback where your server can post the results?

I don't need callback to Server A after first time acknowledge. I knew this process can be done by thread. Besides of thread is there other way to do so?

I don't need callback to Server A after first time acknowledge.

Does that mean server A does not need the results? If your server sends an immediate HTTP response to server A, then there is no way to send another response later.

What Tim is trying to say, that server A needs a servlet, JSP page or something similar that your server can call when it's actually done. The process is then like this:

HTTP is based on a strict request/response protocol. For each request there can be one and only one response. Furthermore, responses cannot come unsolicited, only in response to a request. Finally, the response can only be returned to the place the request came from.

So no, client cannot request server A to request to server B to respond directly to client.

The usual way to handle time-related problems like this is to hand the intermediate processing over to an out-of-band component, which makes the server B request and gets back the result. Client can then poll server A until server A is ready to pass back the results from server B. This not only satisfies HTTP restrictions, it hides details of the back-end processes, so that the client is insulated from changes in the back end.

One very critical thing to note when using an out-of-band manager for long-running processes (what I usually call an engine), is that servlets and JSPs are expressly forbidden by the J2EE standard to either wait on long-running processes OR to spawn threads. So the engine thread needs to be spawned outside of the servlet/JSP request-processing context. This was formerly done in a servlet's init() method, but commonly these days is done in a servletcontext listener.