[zeromq-dev] Servlets and 0MQ

gonzalo diethelm gdiethelm at dcv.cl
Mon Mar 15 14:33:23 CET 2010

> I have little idea of what a servlet is, however, spawning a new
> 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):

> > Now, say there IS a place to initialize 0MQ just once. If I do that,
> > would have to make a guess as to the number of concurrent threads
> > requests) that I would be using it, right? Say, 100 simultaneous
> > 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

> > Finally, say I have five concurrent threads serving five
> > 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
> > 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
> > 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
> > well understood? Has anybody implemented something similar? If yes,
> > you share some thoughts about it? Or maybe this is a mismatch for
> > 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
> queue via TCP transport. But it seems that you have something
> 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. 

More information about the zeromq-dev mailing list