Pada hari Selasa, tanggal 25/10/2005 pukul 18:35 +0100, Alvaro Lopez
Ortega menulis:
Hi!
> use, the more problems we will have with the parsing. What do you
> think of something like this?
>
> Handler fastcgi {
> Server 127.0.0.1:9090
> Server /tmp/unix.sock
> Server other.host:port
> }
Ok this is better
> What about building the content without knowing the ID, and then,
> when you get it, add the header with the ID? :-m
Ok this is doable
> > fcgi_manager_step returns immediately if there is a response from fcgi
> > server which has not being picked up by handler. then handler would
> > reset the buffer after pick the data and return it to the main thread.
>
> Well, my original idea was: If the manager get something from the
> FastCGI server, it will process it, always. As long as it has a
> pointer to each connection which is currently using it and therefore
> waiting for some information, it will copy the information into its
> buffer.
Is it safe to write directly to conn->buffer and conn->header_buffer?
But tried that but got no output to the client.
Let's see this process:
0. handler -> 1. manager -> 2. handler
at 0, handler A goes into, say, phase_add_headers then it calls manager
to read some data from fcgi
at 1, manager receives some data from fcgi, but the data is for another
thread of handler, say, for handler B. the manager then writes directly
to handler B's header buffer (or conn->buffer if the header has already
filled in in previous call). the manager then returns ret_eagain for
handler A because the data for A a is not available yet, and manager
should tell B that the data for it is ready.
at 2, handler then returns the return value it got from manager
the tricky part is that the manager couldn't tell the handler directly
about the data being retrieved from fcgi server. is it ok if I use
handler_fastcgi_t type in the manager's pool instead of connection_t?
I could still pass a variable to be filled in by the manager if we are
going to use connection_t still.
another issue is that if the data for a handler is not ready yet, it
should try to get that again next time, so it's just returns immediately
from the manager. returning ret_again will cause some CPU hog,
especially if there are many threads running. is it ok to have some
timeout delay?
> It is important here the concurrency. Each thread has a set of
> connections. These connection will never change of thread, so there
> is only one connection being processed and all the other connections
> of the thread are not being used. Besides that, each thread has its
> own fastcgi manager, so it can safely work in that way.
>
> If we have one Fcgi manager in it thread, it is going to be a few
> connections to the fcgi server, as many as threads in the server.
> Maybe five or so..
>
> > ret = cherokee_socket_read (fcgim->socket, &fcgim->read_buffer,
> > DEFAULT_READ_SIZE, &size); (fcgi_manager.c:327)
> >
> > any hints?
>
> Ummm.. no. Have you sorted this out?
Yes, it was my fault to read from a finished cycle of fcgi protocol.
However, do we have some read timeout in cherokee_socket_read?, because
it waited forever there if there is no more data to be read.
My current findings in many threads is this one:
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread -1228862544 (LWP 26775)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7f8ba18 in send () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7f7036b in cherokee_write (socket=0x8088a80, buf=0x812f420 "",
buf_len=0, written=0xb6c10330) at socket.c:678
#3 0xb7f707ea in cherokee_socket_write (socket=0x8088a80,
buf=0xb7f7e2e4,
written=0xb7f7e2e4) at socket.c:885
#4 0xb7f47b8f in cherokee_connection_send (cnt=0x8088998) at
connection.c:829
#5 0xb7f4de9c in process_active_connections (thd=0x807fb00) at
thread.c:955
#6 0xb7f4e18a in cherokee_thread_step_MULTI_THREAD (thd=0x807fb00,
dont_block=false) at thread.c:1489
#7 0xb7f4e5e3 in thread_routine (data=0x807fb00) at thread.c:113
#8 0xb7f86361 in start_thread ()
from /lib/tls/i686/cmov/libpthread.so.0
#9 0xb7ed5bde in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) run
Somehow it lost the connection somewhere. Digging it.
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
