Hello
Thank You for the explanation. From docs,I've found that usually
programs that use of some kind of 'watchers' on file descriptors may do
either fork() or pthread() to process the event. In this scenario,I
assume that once You call Your callback function,the application will
block until it finishes the callback function ?
Basically,I need long-lasting TCP connection for a protocol that has
kind of 'keepalive' messages integrated,for example if the server does
not receive 'hello' packet from within the protocol in let's say 30
sec,the server will consider the connection closed. Occasionally,from
the same connection/socket it might arrives some other commands that
will demand some database operations against PostgreSQL database. I
guess if this callback function will involve in any database operations
it might block longer than they are supposed to,but on the other hand
PostgreSQL API provides with asynchronous communication where You
basically send some database command/sql and then watching that fd for
any change meaning the backend send us a reply to our sql command ?
Also as a addon to this scenario,some connection pooling application can
be used (Pgbounder/Pgpool) that will increase the use of stored
procedures/cached prepared statements and so,since cache is valid only
if the database connection is operational.
Any ideas for this scenario ?
Sincerely
Willy Tarreau wrote:
On Mon, Apr 27, 2009 at 02:38:27PM +0200, Dragan Zubac wrote:
Hello
1. You said Your design is to use single-process event-driven
architecture. Could You just give some info about the design of backend
workers or callback that are called when an event occur ? Do You use
fork(),pthreads or something else to achieve concurency among things
that are supposed to be done at 'the-same-time' ?
an event-driven model consists in processing events as soon as they happen,
and in very small and fast operations. For instance, it consists in reading
data from a socket and storing it into a buffer, then calling a function to
process those data. You should look around for more information about the
"poll" system call and what is called "non-blocking I/O".
2. Is You software capable to handle 'long-lasting' TCP connections,for
example far-end clients are supposed to connect to backend servers,they
need to keep those TCP sockets open for a long time,and occasionally
send/receive some data on those sockets ?
Yes, of course. You just have to configure large enough timeouts to ensure
that connections will not be closed before your application speaks. What
type of problem are you foreseeing with long-lasting TCP connections ?
Regards,
Willy
