Is it dangerous to store HttpServletRequest objects in a queue for later processing?

So, I'm in a situation where I want to queue up a bunch of HttpServletRequest objects for asynch开发者_JAVA百科ronous processing. Put aside for the moment whether or not this is a wise strategy -- it actually is in this case, as I'm trying to retrofit an awful legacy system -- is this a dangerous thing to do?

What I'm concerned about here is whether or not the HttpServletRequest object holds onto any valuable resources or open connections that would lead to deadlocks or resource contention issues.

Assume here that I'm implementing a simple servlet with a doPost() method that takes the HttpServletRequest object, puts it into a LinkedBlockingQueue, and then sends the user some kind of stock response (like a 301 redirect to a confirmation page).

Thank you!

i've seen the internals of jetty, and i can assure you that moving that structure out of the current request would be very, very bad. there's all kinds of current connection state which cannot be used outside of the current request. i can't help but assume that would be true for pretty much any servlet container.

it sounds like you are planning on responding to the original request and then doing some additional processing. i'd recommend copying the info you need from the original request into a separate data structure for the offline processing. also, if you are dealing with code which requires an HttpServeletRequest, you can always mock up your own with the bits of data required by the code.

I did a very similar thing, and one of the problems I experienced is that Jetty seems to clean up stuff inside the HttpServletRequest at some point, leaving you with null return values from some of the getXYZ methods and even throwing NPEs at you for others.

So, yes, it is dangerous.

I now copy the stuff I need inside doPost and doGet and forget about the instance altogether.