Alternative implementations for respons timeout: Please critique


EJB design: Alternative implementations for respons timeout: Please critique

  1. Requirements: 1. client sends request which typically takes less than X seconds to complete. 2. If the request does not complete in X seconds, the server(Servlet) needs to send back a reply anyway with some status message. 3. The client assumes everything is ok. 4. The server needs to continue to process request. The client does not need to see the result of the late completed request. This is not a typical async request/response scenario because it is essentially sync req/resp with the client who wants to be notified by X seconds. The client will also not implement timeout on their end. Current system: Servlets and some EJBS doing all the work Constraints: Cannot interrupt Servlets/EJBs, no timer threads etc., according to J2EE spec. I have come up with the following alternatives: 1. On client request, the servlet puts the request on a JMS queue 'REQUESTQ', with a unique correlation id 2. The servlet makes a synchronous call to 'RESPONSEQ' with timeout of X seconds. 3. An MDB processes the request and puts the reply with the correlationid on the REQUESTQ. 4. servlet times out if it does not see its response in the RESPONSEQ in X seconds, and replies to the end client with some status message. The problems I see with this picture are : Every client request which receives timeout will haev a corresponding message remaining in the RESPONSEQ because the servlet will timeout on the receive and not remove it. I will post my other alternatives after I receive responses to this one. This must be a common scenario but I could not find many good solutions. Enlightened souls please respond. BTW I cannot use TimerService etc., because its on Weblogic8.1 Thanks A
  2. Just make a http call to a servlet to do the actual processing when the client makes the initial request Thus, you will be able to reply immediatly to the client. and you would have spawned another http request to your server which will do the actual process. let me know if this is not clear.
  3. This is NOT an async request. It needs to be a synchronous request as for as the client is concerned, but with timeout semantics. Ideally the client would implement the timeout (http or otherwise). But for various reasons client cannot implement the timeout 90 % of the time the response data will be available within X seconds and will go out as a response to the initial request. By doing what you are suggesting I will have the reply immediately.... I HAVE to wait X seconds for the reply. For this I need to be able to either sleep or block for X seconds. BTW am I allowed to use Thread.sleep in a servlet ?
  4. You know, they may boot me off this forum for proposing this solution. From your e-mail, I assume this is only one client of your or I sure hope so.... here it goes... ------------------------ First of all, Sleep is allowed in the Servlet Container, but not a good idea... -------------------------- OK, the trick to for you to make this async on your side, with the impression of being synchronous from the external source. I would implement a Servlet Filter (maybe a few HTTP Wrappers as well) and a Messaging Architecture for this solution. Filter to isolate this "Very very bad code" , messaging to allow the work to continue on your side independent of the returning HTTP response. A few HTTP Wrappers as well may help the structure of the code. Steps: 1. Start the timer on entry of the filter chain 2. Execute the Servlet 3. Place all work in a message for a messaging solution. This is where the speed of a MDB will come in handy. Having a server which is optimized for Local resources will also help- speed) a. Make sure the MDB or whatever services the request replies to a queue with the response. b. Create a class to lisnet for the response and attach it to the session Object(or another scope). c. Wait for the response (on the message) by listening to a queue (message listener) attached to session, request, response (Purhaps a wrapper HTTP class ). 4. Return to the Servlet filter, figure out how much time you have spent. Figure out how much time you can wait(Sleep). Sleep for x amount of time. 5. Wake up, yield, see if your response has been listened(retrieved) to my your Message Listener object. 6. return the response, if it is there, return some empty or appropriate result if it has not returned yet. OK, yes this has many problems, and I suggest you test this, and refer to your servlet container documentation for sleep , thread, and servlet hints, and ways in which you may optimize it. OK I don't like this either, but some solution is better than no solution. I may even give this a try myself to see if it would work... I must be loosing my mind?? you can say I am on drugs or something. Best of luck Tony Sun Certified Web Business Component Developer Sun Certified Web Components Developer Sun Certified Programmer for the Java 2 Platform
  5. why you think the original proposed solution which does sort what you propose without using timers or a servlet filter not a good idea ? Essentially I block for x seconds in the servlet on a reply queue.... btw this is how i implemented it, so far no problems
  6. Scalability[ Go to top ]

    The problem is that this way, every servlet instance which is waiting for response holds one jms connection. Thus it's not very scalable. As soon as the response time is long and there is many concurrent users, app server will run out of jms connections. Of course that applies only if you use connection pooling. Still, if you don't use pooling, you will open one connection for every user that accesses application