Http Post

[ts wong]

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?

[Tim Moores]

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

[ts wong]

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?

[Tim Moores]

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.

[Rob Spoor]

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:

Server A ->(request) your server ->(acknowledgement) server A
                                 ->(request) server B ->(acknowledgement) your server ->(request) server A

[Tim Holloway]

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.