 |
MySQLTalk.org
MYSQL discussions groups
|
| View previous topic :: View next topic |
| Author |
Message |
Gaetano Giunta
Guest
|
 Posted: Thu Apr 26, 2007 10:10 am Post subject: problem with sending large amounts of mail |
 |
|
We ran into some eventum problems lat week, when the email based workflow suddenly stopped working.
After some careful investigation, we found out that the process_mail_queue.php process was somehow stuck and never ending, so that subsequent schedulations where not working at all, because of the lock held by the first process.
This (holding a lock) is by design, and I think it is not a problem. The problem is rather with the mail sending process getting stuck.
We are using exchange 2000 server, and eventum is on a php 4.3.11 red hat es 4.0 box, with two nics in bonding plus a virtual address used.
I used ethereal to sniff out the smtp communication, and it really looks like a low-level tcp problem, eg. once in a while the php process gets stuck while opening the socket to the eamil server.
This tends to happen at random times, but especially when there are a lot of messages on the queue, so that the process gets stuck at say mail nr. 50 or 250.
Did anybody else experience the same problems beside us?
All I could think of so far has been adding a 'sleep(1)' call in between every email sending, in class.mail_queue line 236, so that the exchange server gets some relief during intense communication periods.
Other workaround might include scheduling a "process_mail_queue --fix-lock" to run once a day, but it really looks too hackish to me.
One thing that really tripped me over is the fact that the php script that has to send email never times out.
Is it because of an explicit call to ini_set('max_execution_time') or is it because of the way php calcluates the time spent running not taking into account the time spent in socket communication?
Digging throught the code, all I could gather is:
- by default the eventum classes do not set an explicit timeout for smtp -> wich ends up in pear_mail_smtp | pear_net_smtp | pear_net_socket | fsockopen()
- pear_net_socket also allows setting a timeout for operations carried out AFTER opening the socket, eg. a read timeout. (Net_Socket::setTimeout). Unfortunately this method is only available on the socket class, not in the derived Mail classes (rant: darn I hate OOP when it is used to layer useless classes upon classes just for the sake of hiding useful stuff)
Maybe setting an explicit socket timeout would help?
Any help would be appreciated
Bye
gaetano |
|
| Back to top |
|
 |
Jostein Martinsen
Guest
|
| Posted: Thu Apr 26, 2007 10:10 am Post subject: Re: problem with sending large amounts of mail |
|
|
I can confirm all the problems you described. It has existed long time,
in several different releases of Eventum.
On Thu, 26 Apr 2007 09:52:45 +0200
"Gaetano Giunta" <giunta.gaetano@sea-aeroportimilano.it> wrote:
| Quote: | We ran into some eventum problems lat week, when the email based
workflow suddenly stopped working.
After some careful investigation, we found out that the
process_mail_queue.php process was somehow stuck and never ending, so
that subsequent schedulations where not working at all, because of
the lock held by the first process.
This (holding a lock) is by design, and I think it is not a problem.
The problem is rather with the mail sending process getting stuck. We
are using exchange 2000 server, and eventum is on a php 4.3.11 red
hat es 4.0 box, with two nics in bonding plus a virtual address used.
I used ethereal to sniff out the smtp communication, and it really
looks like a low-level tcp problem, eg. once in a while the php
process gets stuck while opening the socket to the eamil server. This
tends to happen at random times, but especially when there are a lot
of messages on the queue, so that the process gets stuck at say mail
nr. 50 or 250.
Did anybody else experience the same problems beside us?
All I could think of so far has been adding a 'sleep(1)' call in
between every email sending, in class.mail_queue line 236, so that
the exchange server gets some relief during intense communication
periods.
Other workaround might include scheduling a "process_mail_queue
--fix-lock" to run once a day, but it really looks too hackish to me.
One thing that really tripped me over is the fact that the php script
that has to send email never times out. Is it because of an explicit
call to ini_set('max_execution_time') or is it because of the way php
calcluates the time spent running not taking into account the time
spent in socket communication?
Digging throught the code, all I could gather is:
- by default the eventum classes do not set an explicit timeout for
smtp -> wich ends up in pear_mail_smtp | pear_net_smtp |
pear_net_socket | fsockopen()
- pear_net_socket also allows setting a timeout for operations
carried out AFTER opening the socket, eg. a read timeout.
(Net_Socket::setTimeout). Unfortunately this method is only available
on the socket class, not in the derived Mail classes (rant: darn I
hate OOP when it is used to layer useless classes upon classes just
for the sake of hiding useful stuff)
Maybe setting an explicit socket timeout would help?
Any help would be appreciated
Bye
gaetano |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
