Yes, it's not a good idea to use threads in a servlet. A servlet is akin to an interrupt service routine in that the object is to get in, do what you need, and get out again as quickly as possible. Otherwise the user will see a sgtalled browser and the browser request may even timeout. HTTP is not a client/server platform, so the rules are not the same.
Servlets should also not attempt to maintain state. For one thing, in a clustered environment, the next user hit may be to a different instance of the same servlet in a different JVM or even on a different machine.
If a process is too long-running to execute directly,
you should pass the request to a background processor of some sort. My ususal choice is what I call a "null servlet", which is a servlet that has no get/post processors, but starts up the engine as a background thread from its init() method and then stands by to recieve requests. Although that might conceivably break too, depending whether a new system bans
all threading or just request/response threading. Two other ways of handling this situation are to use (vendor-specific) startup classes (which is not portable) or use a system such as JMS.