Hello, > I see no reason you would need your servlet to stay in memory. As long > as it is alive when needed (that is when requests arrive) it's enough. > Maybe you problem is that it does much than serving request, like > running background thread, send message to people and so on. Then you
Exactly. I am using some external API which is receiving endless data stream (namely stock price changes), and have to be running 24h, every day. Running a background thread or something like this would do for me. Answering mere HTTP requests is not enough. > might simply need to separate the servlet (part that answer a client) > from the service object (part that handle various thread). The service Yes, I was considering running some 'background' daemon for that. > object could be started/stopped by a simple servletContextListener and > attached to JNDI. The servlet would then request that object from JNDI. I have no knowledge (yet) in servletContextListener and JNDI yet (and this may be the sole reason why I am asking such questions instead of just using it), but from your mail I reckon, that it will just be the solution for me. I have to google for this now. > If you don't like to use JNDI you can still attach it to application scope. I dont know yet if I like JNDI ;) > This will be more easy to maintain and more performant than delegating > work to another server and add an other row of TCP/IP packets. Yeah, I was concerned about performance and complexity of my alternative solution (separate executable + tcp socket + custom protocol or at least some rpc which would use a lot of xml). > Kamil Burzynski a écrit : >> Hello, >> >> >>> Please read the other responses to this thread, since they are correct that >>> there is no guarantee. However, the current implementation of TC (3.3-6.0) >>> will not unload a Servlet unless the entire context is reloaded (with a >>> slight exception for JSP pages). But then you are programming against >>> Tomcat itself, in an area where there is no guarantee that it won't change >>> in the future, and it may not work if you try to move to another Servlet >>> container. >>> >> >> Yeah, I was afraid of getting such answer, actually ;) In my project it >> would be enough to code against current version of Tomcat, though I >> would like a clean solution. So, it seems, that I'll do standalone >> server and then webapp will connect to it via some protocol (I am not >> familiar with java world enough to know if any good rpc is there - most >> probably it is). >> >> Thanks for all answers. >> >> > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Best regards from Kamil Burzynski --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
