persistent connections for handlers
Hi
I am writing a mod_perl handler that takes a HTTP POST and sends mail. What
I'd like to do is to open up a connection to the SMTP server [a Net::SMTP
object] and a log file [filehandle] that exist outside of the handler. So
that when the handler is run, it has access to these items, and can send
data to them, but that they don't get opened up and brought down each time.
Right now, I have them being set up [and torn down] in BEGIN {} and END {}
blocks. The code doesn't complain, and it sends the right thing back to the
browser, but nothing gets mailed or written to the log. I can post the code,
but I was hoping that this problem is generic enough [and my description
good enough] that someone can point me in the right direction without the
details of the code.
My question is this: how do you set up persistent connections that a handler
can use, but ones that don't get initalized each time the handler is called?
Are these just file [package] scoped globals?
Do I need subroutines to check the status of these objects/handles and
reinitialize them as needed?
Is there another way?
Any pointers, suggestions, or non-sequitors are welcome, thanks.
--
\js
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: persistent connections for handlers
I'm also interested in this problem. I've
been piping my mails to sendmail and I'm
told that this is not a good idea with mod_perl.
I find that talking to SMTP server is noticeably
slower although I don't know whether the slowness is
just in the initial connection. I am using the local
sendmail daemon as the SMTP server.
On Sat, Dec 09, 2000 at 11:05:50AM -0500, John Saylor wrote:
Hi
I am writing a mod_perl handler that takes a HTTP POST and sends mail. What
I'd like to do is to open up a connection to the SMTP server [a Net::SMTP
object] and a log file [filehandle] that exist outside of the handler. So
that when the handler is run, it has access to these items, and can send
data to them, but that they don't get opened up and brought down each time.
Right now, I have them being set up [and torn down] in BEGIN {} and END {}
blocks. The code doesn't complain, and it sends the right thing back to the
browser, but nothing gets mailed or written to the log. I can post the code,
but I was hoping that this problem is generic enough [and my description
good enough] that someone can point me in the right direction without the
details of the code.
My question is this: how do you set up persistent connections that a handler
can use, but ones that don't get initalized each time the handler is called?
Are these just file [package] scoped globals?
Do I need subroutines to check the status of these objects/handles and
reinitialize them as needed?
Is there another way?
Any pointers, suggestions, or non-sequitors are welcome, thanks.
--
\js
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: persistent connections for handlers
[EMAIL PROTECTED] wrote: I'm also interested in this problem. I've been piping my mails to sendmail and I'm told that this is not a good idea with mod_perl. I find that talking to SMTP server is noticeably slower although I don't know whether the slowness is just in the initial connection. I am using the local sendmail daemon as the SMTP server. On Sat, Dec 09, 2000 at 11:05:50AM -0500, John Saylor wrote: I am writing a mod_perl handler that takes a HTTP POST and sends mail. What I'd like to do is to open up a connection to the SMTP server [a Net::SMTP object] and a log file [filehandle] that exist outside of the handler. So that when the handler is run, it has access to these items, and can send data to them, but that they don't get opened up and brought down each time. Have a look at the Apache::DBI source, which keeps a pool of connections open like you need. Use a PerlChildInitHandler to set up a connection for each process (if you do it in startup.pl you have to share one between processes, which isn't ideal). There's nothing wrong with piping to sendmail though. If you fork() under a decent operating system, most memory is shared between processes. So just fork() and open a pipe to sendmail. For logging you might prefer to use Unix::Syslog rather than opening a file directly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
