I have an applet that maintains a persistent connection to a tunneling servlet (which tunnels to a back-end C++ process). The current architecture involves POSTing a setup query, then pushing periodic updates back to the applet for display on the web page.
This works fine, but now I'd like the capability of sending more requests for the same connection. As far as I can tell, data incoming to a servlet can only be requested once - the InputStream is read completely the first time. If the applet never closes the request, then the servlet will never see it in the first place.
Now, adding this new capability wouldn't normally be an issue, except that our servlet engines are load balanced behind Apache servers, one per Apache. So if I decided to just hold the connection in the servlet engine and direct new POST requests (with a unique ID or somesuch) to that connection, I won't be guaranteed that I'm getting the same server. At this point, I don't want to mess around with clustered state or JMS queues if I don't have to.
So, the question is, what is the best way to hold a persistent tunneled connection to a servlet for bi-directional communication? If I'm mistaken about the utility of InputStream, that would be good -- but I would still be concerned about buffering. We had to patch Apache's mod_proxy to enable unbuffered connections for the return data in the first place.
HTTP 1.1 doesn't help, because the load balancer will still redirect new POSTs to whichever server is next in line.
Would there be any point to writing a Servlet instead of n HttpServlet, and handle the communication directly? I don't know if the ServletRequest InputStream would react any differently in that case either.
We're using OC4J as the servlet engine.
Any other ideas?
Thanks in advance,