Inbound E-Mail Parser Runs forever...?

[seans]

Help! In the Scheduled Jobs setup page the Inbound E-Mail Parser show a last runtime of "Last run: Sat, Jun 28 2008 11:44 AM" and it is "locked". I tried unlocking it and disabling and and re-enabling it, however it simply locks itself again and just sits there. I restarted the server and it still does the same thing. Now the status reads
Runs every: 1 minutes
Last run: Sat, Jun 28 2008 11:44 AM
Locked: Mon, Jun 30 2008 12:46 PM

I looked in the new mail folder, there are 350 in new folder dating back to about 2pm on 6/29 and there are about 250 messages in the fail folder dated between Sat, Jun 28 2008 11:44 AM and 2pm on 6/29.

Any idea how to get the Inbound E-Mail Parser running again?

[Hildy]

What output do you get when you click "run now" on the Parser task?

[seans]

What output do you get when you click "run now" on the Parser task?

Nothing seems to happen... The browser just sits there blank until it times out. Meanwhile the average inquiries per sec on the mySQL database goes from 4/sec to over 1500/sec. Is there any other output we can check?

-Sean

[Hildy]

Eeeenteresting... </accent>

Have you modified your Ticket Mask generation code ( http://cerberusweb.com/kb/article/000015 ) at all? If it's unable to find a unique mask in the time allotted before timeout, then it would (theoretically) move a single message at a time to /fail, and only run once every 15 minutes (when the lock times out, which roughly corresponds to the number of messages you have in /fail, too.).

If you haven't modified that code, we did have a single instance where someone reported that rand() was *really* slow on their system (though not fatal), and the solution was to change the mask generator to use mt_rand() instead (which was much faster for them).

[seans]

Eeeenteresting... </accent>

Have you modified your Ticket Mask generation code ( http://cerberusweb.com/kb/article/000015 ) at all? If it's unable to find a unique mask in the time allotted before timeout, then it would (theoretically) move a single message at a time to /fail, and only run once every 15 minutes (when the lock times out, which roughly corresponds to the number of messages you have in /fail, too.).

If you haven't modified that code, we did have a single instance where someone reported that rand() was *really* slow on their system (though not fatal), and the solution was to change the mask generator to use mt_rand() instead (which was much faster for them).

Well we decided to "punt" and create a complety new instance of cerb4 and import the database from a backup. And we still had the same problem. Then we tried changing all the rand()'s to mt_rand()'s in the Application.class.php file and IT WORKED? The strange part is it just gave up at a random time. We don't work asaturdays so no one had messed with anything at least 12 hours prior to the problem starting. Is there a different version of "srand()" we should try to use as well?

-Sean

[Hildy]

While it should be mt_srand() instead of srand(), yes, it's also not necessary (but go ahead and change it anyway). http://php.net/mt_rand has a note indicating that the seeding is done automatically in PHP 4.2+.

[seans]

While it should be mt_srand() instead of srand(), yes, it's also not necessary (but go ahead and change it anyway). http://php.net/mt_rand has a note indicating that the seeding is done automatically in PHP 4.2+.

Great, thanks for the help. I remember when migrating to cerb4 about 5 months ago the import of our old emails took days, I guess this was the problem. But I wonder what caused it to finally slow to halt, it was running fine (but apparently slow) for months??

-Sean

[Hildy]

If you take a look at http://www.boallen.com/random-numbers.html , he's got a lovely graphical comparison of the difference between "random" numbers, as generated by rand(), and truly random data.

There's a quite blatantly repetitive pattern showing up in rand(), and it's my guess that your system was searching for an available mask, and ran out of time before it found one (the 1500 qps on your MySQL server was likely the "Is this mask available?" questions). It's possible there's a bug in your version of rand(), too, that progresses through the same list of "random" masks over and over, making each progressive ticket harder to find an open mask for.