> I have little idea of what a servlet is, however, spawning a new thread > for each HTTP request doesn't seem to be very efficient. (Others may > have more experience with the topic though.)
I think it is up to the web container to spawn new threads or pool them. > As for initialising 0MQ just once the best place to do so it at the > beginning of main() and storing it in a global variable. Well, I have refreshed my rusty knowledge of servlets, and there is a place to initialize 0MQ just once: the servlet's init() method (and the corresponding destroy() method at the end): http://en.wikipedia.org/wiki/Java_Servlet > > Now, say there IS a place to initialize 0MQ just once. If I do that, I > > would have to make a guess as to the number of concurrent threads (HTTP > > requests) that I would be using it, right? Say, 100 simultaneous HTTP > > requests. What happens if I initialize 0MQ with that assumption but > > then, during runtime, end up going above that? > > It returns EMTHREAD error when you try to create a socket. Would it be conceivable to handle this in a more dynamic way? For instance, a function to ask 0MQ how many user threads it can currently handle, and another to increase (and maybe decrease) that number of threads. > > Finally, say I have five concurrent threads serving five simultaneous > > HTTP requests. Each of these threads will want to send out a message > > over 0MQ, and then wait for a response. It seems to me the only safe way > > of doing this is using REQ/REP sockets, but if all these threads send a > > message to the same process (the one that will generate the answers), > > will I be assured that the answers will come back to the appropriate > > thread? Have replies any "affinity" to the underlying socket that > > actually sent the corresponding request? > > Yes, they do. Ok, I thought I had read something about this on the list, sorry for re-asking something already covered. > > Is this a pattern (let's call it "multi-threaded web server") that is > > well understood? Has anybody implemented something similar? If yes, can > > you share some thoughts about it? Or maybe this is a mismatch for 0MQ's > > architecture? > > When confronted with "multi-threaded server" I would imagine a server > application with a shared queue and N worker threads connected to the > queue using inproc transport. M clients would be connected to the shared > queue via TCP transport. But it seems that you have something different > in mind. No, no, this is exactly what I have in mind. I am just trying to map the Java servlet model to this concept, using 0MQ for communications. Perhaps I am just not being too bright today... :-) -- Gonzalo Diethelm ----------------------------------------- Declaración de confidencialidad: Este Mensaje esta destinado para el uso de la o las personas o entidades a quien ha sido dirigido y puede contener información reservada y confidencial que no puede ser divulgada, difundida, ni aprovechada en forma alguna. El uso no autorizado de la información contenida en este correo podrá ser sancionado de conformidad con la ley chilena. Si usted ha recibido este correo electrónico por error, le pedimos eliminarlo junto con los archivos adjuntos y avisar inmediatamente al remitente, respondiendo este mensaje. "Before printing this e-mail think if is really necesary". Disclosure: This Message is to be used by the individual, individuals or entities that it is addressed to and may include private and confidential information that may not be disclosed, made public nor used in any way at all. Unauthorized use of the information in this electronic mail message may be subject to the penalties set forth by Chilean law. If you have received this electronic mail message in error, we ask you to destroy the message and its attached file(s) and to immediately notify the sender by answering this message. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
