Mollom Problems

62 views
Skip to first unread message

Jamie Neil

unread,
Aug 5, 2009, 12:47:11 PM8/5/09
to silverst...@googlegroups.com
We've had Mollom running on a few sites for several months now and it's
generally been working fine. However today it seems to be completely
broken. Any page with a comment form (which is what I'm using mollom
for) is timing out and eventually displaying a blank white page.

Testing on our dev server and looking at the code I've noticed a couple
of things:

1) It dies with:

( ! ) Fatal error: Maximum function nesting level of '100' reached,
aborting! in <snipped path>/public_html/mollom/lib/Mollom.php on line 128

because the Mollom servers are all busy (1200 error).

2) The third party Mollom lib seems to differ from the most up to date
one even though they have the same version numbers - I assume the SS one
has been modified (which IMHO is normally a bad idea). In particular the
SS one used the xmlrpc1/2/3 addresses to get the server list from which
seems to be wrong.

3) Why does doCall call itself recursively without any safety stop?
Seems a strange way of handling the error, and obviously fails if the
Mollom servers are overloaded.

4) Why does SS call verifyKey every time it initialises a Mollom form?
Surely it's only necessary to call this if we are actually doing a spam
check. This is why none of my Mollom protected pages are even displaying
, so as a temporary fix I've simply commented out the verifyKey check in
MollomSpamProtector.php (line 29).

Is anyone else seeing these problems or is it just me?

Regards,
jam13

Liam Whittle

unread,
Aug 5, 2009, 12:59:16 PM8/5/09
to silverst...@googlegroups.com
Only running it on one site but it's working fine today. Just posted a comment to test and it went through with all pages loading fine.

I even noticed they seemed to have fixed their algro to better handle a whole bunch of spam comments that were getting through that contained semi colons in them. At least I think they fixed it as I haven't noticed any the last couple of days, where as before I was getting hammered by the same type of comment by the 1000s.

keeny

unread,
Aug 5, 2009, 6:38:48 PM8/5/09
to SilverStripe Development
Hi Jamie,

I'm having the same problems. Like you - sites a week or two ago were
working fine but this week any sites that have mollom installed hang &
become completely unresponsive.

1) Whereabouts do you see this error? Is it in a log file?

2) Did you replace the lib with the updated one from mollom
themselves?

3) & 4) Did these fixes get mollom working for you again?

I much prefer mollom over recapcha and would prefer to get it working
again. If you got it working I'd really appreciate it if you could
tell me how.

Many thanks,

Barry.

Sam Minnee

unread,
Aug 5, 2009, 6:52:17 PM8/5/09
to SilverStripe Development
Hi Jamie,

Regarding point (2), we had a bunch of issues with the Mollom-
distributed library and so had to modify it to get it working. I
agree that normally it would be bad to fork the distributed file, but
it's worse to have it broken :-P. I think that the Joomla crowd did
something similar.

Regarding points (1) and (3), these were bits of Mollom.php that we
*didn't* modify, but yeah, you might be right.

For all of those reasons, it might be worth kicking off discussion on
the mollom dev list to see if there are any plans to release a new
version of their library?

Regarding point (4), you're right, it sounds like this could be
improved. Are you able to come up with a patch suitable for inclusion
on the mollom module?

Jamie Neil

unread,
Aug 6, 2009, 2:34:55 AM8/6/09
to silverst...@googlegroups.com
Sam Minnee wrote:
> Regarding point (2), we had a bunch of issues with the Mollom-
> distributed library and so had to modify it to get it working. I
> agree that normally it would be bad to fork the distributed file, but
> it's worse to have it broken :-P. I think that the Joomla crowd did
> something similar.

Fair enough.

> Regarding points (1) and (3), these were bits of Mollom.php that we
> *didn't* modify, but yeah, you might be right.
>
> For all of those reasons, it might be worth kicking off discussion on
> the mollom dev list to see if there are any plans to release a new
> version of their library?

The library does seem to need a bit of work in being able to handle
outages like this, but I imagine at the moment the Mollom devs are going
to be more concerned about the fact that their service seems to be
completely dead in the water :(.

> Regarding point (4), you're right, it sounds like this could be
> improved. Are you able to come up with a patch suitable for inclusion
> on the mollom module?

I will try to come up with something this morning as a matter of
urgency, because all our sites using Mollom are still borked.

jam13

jam13

unread,
Aug 6, 2009, 5:21:30 AM8/6/09
to SilverStripe Development
After upgrading a site to the Mollom Plus service it seems to be
working ok. The module still needs attention, but this is probably the
best workaround at the moment.

jam13

Siddharth Menon

unread,
Aug 6, 2009, 5:45:05 AM8/6/09
to SilverStripe Development
Mollom was little disappointing for me.
When I open pages in FireFox it ask to run Windows Media extension to
pay audio.
Waiting for further development before enabling it.

jam13

unread,
Aug 6, 2009, 7:44:40 AM8/6/09
to SilverStripe Development
Looks like I spoke too soon - the other two sites that I've upgraded
to Plus are still broken. I've checked the Mollom server cache and all
the code and it's the same as the working site, so I'm assuming it
must be something at Mollom.

Liam Whittle

unread,
Aug 6, 2009, 9:41:01 AM8/6/09
to silverst...@googlegroups.com
I was having a discussion with Jamie and thought it would be of interest to post the details to the group.

I haven't had any problems with Mollom regarding these issues. My site running it is still functioning like normal.

Here are the unique servers listed in the associated table for Mollom.

http://174.37.205.152/
http://88.151.243.145/
http://88.151.243.81/
http://82.103.131.136/

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Aug 6, 2009, 10:01:24 AM8/6/09
to silverst...@googlegroups.com
Hi

I also found the mollom module difficult to use:

* hard to test to see if it is working
* often did not work without much explanation (no useful error messages or alerts)
* not very user-friendly (and indeed requesting people to install extensions to enter a form)

I am looking forward to the next version.

Nicolaas

Jamie Neil

unread,
Aug 6, 2009, 10:10:04 AM8/6/09
to silverst...@googlegroups.com
Liam Whittle wrote:
> I was having a discussion with Jamie and thought it would be of interest
> to post the details to the group.
>
> I haven't had any problems with Mollom regarding these issues. My site
> running it is still functioning like normal.
>
> Here are the unique servers listed in the associated table for Mollom.
>
> http://174.37.205.152/
> http://88.151.243.145/
> http://88.151.243.81/
> http://82.103.131.136/

That's the same list as I've got, so it can't be that.

I'm now getting a different failure on one site instead of the previous
1200 loop:

<code>

[User Error] Uncaught Exception: [error 1000] Unsupported API version
string.
POST /mypage/PageComments/PostCommentForm

Line 103 in /<sitepath>/mollom/code/MollomServer.php
Source

94 // if the cached serverlist is outdated
95 case 1100:
96 // delete cached server list first - in database
97 singleton('MollomServer')->clearCachedServerList();
98 // use default server list
99 Mollom::setServerList(Mollom::getServerList());
100 break;
101
102 default:
103 throw new Exception( $e->getMessage() , $errCode);
104 }
105
106 }
107 }
108
109 }

Trace

* MollomServer::doCall(checkContent,Array)
Line 77 of MollomServer.php
* MollomServer::checkContent(,,test,Jamie,,<myemailaddress>,)
Line 149 of MollomField.php
* MollomField->validate(RequiredFields)
Line 98 of RequiredFields.php
* RequiredFields->php(Array)
Line 106 of Validator.php
* Validator->validate()
Line 752 of Form.php
* Form->validate()
Line 189 of Form.php
* Form->httpSubmission(HTTPRequest)
Line 129 of RequestHandler.php
* RequestHandler->handleRequest(HTTPRequest)
Line 143 of RequestHandler.php
* RequestHandler->handleRequest(HTTPRequest)
Line 143 of RequestHandler.php
* RequestHandler->handleRequest(HTTPRequest)
Line 122 of Controller.php
* Controller->handleRequest(HTTPRequest)
Line 29 of ModelAsController.php
* ModelAsController->handleRequest(HTTPRequest)
Line 277 of Director.php
* Director::handleRequest(HTTPRequest,Session)
Line 121 of Director.php
* Director::direct(/mypage/PageComments/PostCommentForm)
Line 118 of main.php

</code>

jam13

jam13

unread,
Aug 6, 2009, 10:35:01 AM8/6/09
to SilverStripe Development
On Aug 6, 3:10 pm, Jamie Neil <jamie.n...@gmail.com> wrote:
> Liam Whittle wrote:
> > I was having a discussion with Jamie and thought it would be of interest
> > to post the details to the group.
>
> > I haven't had any problems with Mollom regarding these issues. My site
> > running it is still functioning like normal.
>
> > Here are the unique servers listed in the associated table for Mollom.
>
> >http://174.37.205.152/
> >http://88.151.243.145/
> >http://88.151.243.81/
> >http://82.103.131.136/
>
> That's the same list as I've got, so it can't be that.

But the ordering is different. I assumed that SS was doing a round
robin of the addresses, but it appears not because if I delete all the
entries from the table except for either:

http://82.103.131.136
http://174.37.205.152

then it seems to work!

However:

http://88.151.243.81
http://88.151.243.145

are both dead.

So if you delete both these entries from your MollomServer table or
you were lucky and had one of these first in the table then you should
be good to go.

Methinks the Mollom php library needs a good slap.

Bruce Bowden

unread,
Aug 6, 2009, 9:14:03 PM8/6/09
to SilverStripe Development
As an added side-effect, every call to an affected page generates a
50Mb code.xxxx file in the sapphire folder. Lots of testing yesterday
filled our 5Gb hosting space very quickly.

Liam Whittle

unread,
Aug 6, 2009, 9:26:25 PM8/6/09
to silverst...@googlegroups.com
Wow really? Thanks for the heads up. I'll have to keep that in mind
and double check when I'm back on my computer.

----------------------------
Sent from my iPhone

dio5

unread,
Aug 8, 2009, 6:24:27 AM8/8/09
to SilverStripe Development
AFAIK the Mollom PHP library isn't written by someone of Mollom,
perhaps contact him if there's an issue with it http://mollom.crsolutions.be/?
Although I haven't studied the problem yet, I doubt the problem is
that original library - surely other non-SS-users most have had issues
as well?

On 6 aug, 16:35, jam13 <jamie.n...@gmail.com> wrote:
> On Aug 6, 3:10 pm, Jamie Neil <jamie.n...@gmail.com> wrote:
>
> > Liam Whittle wrote:
> > > I was having a discussion with Jamie and thought it would be of interest
> > > to post the details to the group.
>
> > > I haven't had any problems with Mollom regarding these issues. My site
> > > running it is still functioning like normal.
>
> > > Here are the unique servers listed in the associated table for Mollom.
>
> > >http://174.37.205.152/
> > >http://88.151.243.145/
> > >http://88.151.243.81/
> > >http://82.103.131.136/
>
> > That's the same list as I've got, so it can't be that.
>
> But the ordering is different. I assumed that SS was doing a round
> robin of the addresses, but it appears not because if I delete all the
> entries from the table except for either:
>
> http://82.103.131.136http://174.37.205.152
>
> then it seems to work!
>
> However:
>
> http://88.151.243.81http://88.151.243.145

Jamie Neil

unread,
Aug 9, 2009, 4:34:07 AM8/9/09
to silverst...@googlegroups.com
dio5 wrote:
> Although I haven't studied the problem yet, I doubt the problem is
> that original library - surely other non-SS-users most have had issues
> as well?

The orignal lib has this section of code:

// code 1200 (Server too busy)
case 1200:
if(!count(self::$serverList)) self::getServerList();
// do call again
return self::doCall($method, $parameters,
self::$serverList[$counter], $counter++);
break;

which is supposed to recursively call the doCall method incrementing the
counter each time to select the next server in the list. The problem
AFAICS is that the incremented $counter never actually gets used because
at the beginning of the doCall method is:

private static function doCall($method, $parameters = array(), $server
= null, $counter = 0) {
[snip]
// still null
if($server === null) $server = self::$serverList[$counter];

i.e. because the recursive call passes the the same server through that
caused the 1200 error, $server is _not_ null and so the incremented
$counter is not used.

The end result is that if there is a persistent problem (1200 = busy)
with the first server in the $serverList then it just calls that same
server again recursively until it hits the nested call limit (100 on my
system).

I haven't tested it, but maybe changing the recursive call to:

return self::doCall($method, $parameters, null, $counter++);

would fix the problem?

jam13

Will Rossiter

unread,
Aug 14, 2009, 12:35:38 AM8/14/09
to SilverStripe Development
Hey All!

I have commited a couple changes to Mollom trunk (as well as some
improvements to SpamProtection but you should not need to upgrade your
spamprotection to get the updates to mollom working. Download URL
http://www.silverstripe.org/mollom-module/TrunkDownload/generate

I see on the forum threads a couple issues still exist with the module
but if anyone has any other reports please submit them as tickets to
open.silverstripe.org and we will look into them accordingly.

Cheers,

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Aug 14, 2009, 1:15:44 AM8/14/09
to silverst...@googlegroups.com
Thanks a million Will! That is great news.
Reply all
Reply to author
Forward
0 new messages