On 8 December 2010 19:51, razor <razorj...@gazeta.pl> wrote: > So i can just start my own thread (threads) for receiving non-http > data (where to put initialization/starting stuff? as a new servlet ? ) >
If you implement your entire non-HTTP system as a servlet in its own context, you have the advantage that you can implement a few web pages on that servlet for control and monitoring of your service, and can start and stop it independently of the rest of your servlets. and then my code will put received data in some 'public' synchronized > queue/collection or database (like HSQLDB) > and other threads/modules (and again, where should i start them? in > new servlets?) can process data > You can start as many threads as you like in one servlet, provided you monitor them and make sure you shut them down tidily. I'd suggest you manage them all from a single servlet, so that you don't get hit by issues like the inability to control context startup orders. As all of your code then shares the same class loader, you can use whatever mechanism you wish to communicate between the modules. and at the end next threads have to send data using webservices or/and > webdav (a lot of data and i need resume option if something goes > wrong) > That's fine; if the threads in your code are themselves making client connections to web services and/or WebDAV then the container won't give you any assistance anyway. It's up to you to make sure the client code works! > > Is my thinking correct ? > > It's certainly pretty close :-). I'd tend to keep your subsystem in one context rather than many, as it gives you more options. Good luck! - Peter
