Bug #25656
closed
Scheduler cannot handle large Exceptions
0%
Description
When a Task fails with a very long Exception message (say a few thousand lines), the scheduler mod will not load and display an error message:
Fatal error: Call to a member function getCode() on a non-object in /var/www/domains/schrittauftritt.ch/typo3/sysext/scheduler/mod1/index.php on line 1087
I iterate over several thousand fe_users in a reminder task and log some lines for each user (along the lines of: User xy with uid N will be reminded or Email failed/succeeded etc).
I used this when I was programming the Task, but I found it useful to include in the error message.
However, the db-field lastexecution_failure (type text) is too small to store large serialized Exceptions.
So when the scheduler tries to unserialize them, the result will be null (as shown by the Fatal error).
Solution (either or both):
- Use a bigger db-field (MEDIUMTEXT or LONGTEXT)
- Make sure the unserialized object checked for null
(issue imported from #M14184)
Updated by Christian Kuhn over 14 years ago
Hmm, I'm unsure if we should really make the field much bigger. It's currently TEXT, and I think 65k of data is plenty in this case.
If you want to log that much data, it might be a better solution to create a special log table with some structure (eg. with fields for task date, user id and message), and create some be-module to show this data. Or you could stuff your data into a mail and send it to some admin account.
But it's a bug that the scheduler doesn't crop the exception to a max length to ensure a non-broken serialization. That should be fixed.
Updated by Francois Suter over 14 years ago
Christian,
It's a good idea, but it seems a bit hard to know where to crop an object so that its serialized form is kept to within a certain size. Any suggestions how to achieve that?
Updated by Francois Suter over 14 years ago
This is my proposal: do nothing upon serializing, but rather test the result of unserializing. If it fails, instead of the error message stored in the Exception object, we display a message to the effect that the Exception object was badly stored so the error could not be retrieved. It seems simpler to me.
Updated by Nils Blattner over 14 years ago
I agree Francois. That would be the proper way imo.
The returned value would be FALSE, and since you serialize an object the return should never be false except when it failed.
Christian:
From how I understand TEXT/BLOB storage, MEDIUM-/LONGTEXT only requires more storage size than TEXT if the extra space is actually filled.
TBE it's stored separatly blockwise with a reference to that in the row.
Thus while the exception text were small, the same amount of storage is used as with a normal TEXT type but would allow for much larger exceptions aswell to be stored.
However the issue with the call on a non-object should still be solved.
Updated by Christian Kuhn over 14 years ago
Sorry for not responding by now ... I just didn't have time to take care of this issue and take a look at the code to figure dependencies and constraints. Will test your patch over the weekend, though.
Updated by Francois Suter over 14 years ago
Committed v_2 to 4.3 in revision 7971
Committed v_2 to trunk in revision 7972
Updated by Francois Suter over 12 years ago
- Status changed from Resolved to Closed
Updated by Michael Stucki almost 11 years ago
- Project changed from 739 to TYPO3 Core
- Category changed from scheduler to scheduler
- Target version deleted (
0)