[ php-blog-Bugs-1460057 ] Trouble with comment posting process

Bugs item #1460057, was opened at 03/28/06 06:59
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=542822&aid=1460057&group_id=75065

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Plugins
Group: None
>Status: Closed
Resolution: Fixed
Priority: 1
Submitted By: John Goerzen (jgoerzen)
Assigned to: Garvin Hicking (garvinhicking)
Summary: Trouble with comment posting process

Initial Comment:
This is on 1.0beta2.

There are two distinct problems here.

First off, while a comment is in the process of being
posted, the entire site of locked.  That means that,
for the 45 seconds (or however long it takes) that s9y
is working on posting that comment, nobody can even
view the homepage of the site.  The browser will just
sit there, getting no result until the comment is
posted (or rejected).  I'm using the MySQL backend, and
wonder if perhaps this would be better with the
PostgreSQL backend due to no having to do so much locking.

Secondly, this problem appeared to be relating to
blogg.de being down or unreachable.  After some time,
the user trying to post a comment got back a cryptic
PEAR error, citing a timeout.  I think that if a
timeout occurs, the comment should be posted anyway. 
We shouldn't be dropping comments because some
spam-checking service is unreachable.


----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 04/14/06 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Garvin Hicking (garvinhicking)
Date: 03/31/06 00:26

Message:
Logged In: YES 
user_id=473563

Thanks for bearing with me :)

Our IRC debugging session went great, so I'm proud to
present the fixup:
http://svn.berlios.de/viewcvs/serendipity?rev=1042&view=rev

HTH,
Garvin

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 03/30/06 19:22

Message:
Logged In: YES 
user_id=491567

FWIW, I am still seeing this on my live production server. 
So I suspect it is not a per-host thing but would be happy
to investigate.

Also I see the behavior while posting stories, not just
comments.

I investigated both Drupal and Wordpress to see how they are
handling this.  Neither one uses PEAR.  Drupal uses its own
HTTP client code, and I believe Wordpress uses some other
library from PHP (but for some reason I can't remember for
sure just now.)  I don't knowif this is the reason for that
or not, though.

----------------------------------------------------------------------

Comment By: Garvin Hicking (garvinhicking)
Date: 03/29/06 06:24

Message:
Logged In: YES 
user_id=473563

Hi!

Hm, serendipity does not do any locking in its code. We use
a non-modified PEAR::HTTP_Request library for doing HTTP
Requests. I don't know if that one does any locking...

I am not that familar with the PEAR class, if I find some
time the next weeks I can try to investigate that. Of course
any help is appreciated. I honestly admit I do not know all
there is to know about socket operations and stuff. :)

Best Regards,
Garvin

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 03/29/06 06:10

Message:
Logged In: YES 
user_id=491567

Hi again Garvin,

I can sympathize that PHP may not provide adequate
error-checking facilities, and that is really a shame.

On the other hand, I manage my own server and can assure you
that there is no blocking going on, either in the OS, the
upstream router, or the PHP environment.  I can't imagine
what about my environment could be the problem, as I have
other PHP scripts doing similar things without incident. 
But if there are things you'd like to inspect, please let me
know.

But my main complaint is not that things are slow for the
administrator.

My complaint is that this problem makes the site completely
unresponsive for *everybody*.  That is, the entire blog is
completely shut down for, say, 45 seconds while one of these
queries is in progress.  It seems to me that this shouldn't
have to be the case, and indeed it isn't the case with any
other PHP system I've tried (Wordpress and Drupal, for
instance).

----------------------------------------------------------------------

Comment By: Garvin Hicking (garvinhicking)
Date: 03/28/06 23:36

Message:
Logged In: YES 
user_id=473563

I got more responses yesterday from people telling me that
netmirror.org is having connection errors.

The problem is that that server does not return a status
code or connection error after a certain timeout amount.
That is a problem of netmirror.org, which accepts the
connection but then does nothing with it. Usually when
servers are down, they refuse a connection immediately.
Sadly there is still nothing we can do about it - we are
dependant on using foreign file mirrors, because we have no
own infrastructure to offer. Usually netmirror.org is quite
stable, in the past 2 years it only had like 2-3 days were
it didn't work. :-/

Best regards,
Garvin

----------------------------------------------------------------------

Comment By: Garvin Hicking (garvinhicking)
Date: 03/28/06 23:26

Message:
Logged In: YES 
user_id=473563

Hi!

If Spartacus is also acting slow, the problems are
definitely from your host and outgoing connections, and/or
restrictions ony our apache/webserver.

There's nothing a PHP script can do if your internet
connections time out or have ocnnectivity problems - we can
only try to access the URL and then have to wait for a
timeout or error; no "probing" is possible once network
connections issues are in effect.

So if you experience these things on your host, you must
disable the corresponding facilities, I see no other ways.
On host with proper internet connectivity, this is no
problem (I have access to about 7 installations on different
servers, where those issues don't arise).

Also if the connection is just slow - I don't see any way
what a script can do about that. You will then just have to
not use these remote connectivity options...?

The spamblock module should continue, if the host is not
reachable. But PHP sometimes emits a fatal error on errenous
network connections - there's also no way to get around that
than to fix the network issue on the server side.

I hope I don't sound rude with my answer, it's not intended
to be. I just want to explain that the network issues you're
having are not related to Serendipity, but your webserver
setup and that PHP scripts have no option to face with that
kind of problems. At least I've no idea of such an option. :)

Best regards,
Garvin

----------------------------------------------------------------------

Comment By: John Goerzen (jgoerzen)
Date: 03/28/06 17:56

Message:
Logged In: YES 
user_id=491567

Garvin,

Thanks again for your reply.

I have decided to deploy S9Y on my site and this is the most
serious problem I see right now.

After doing some additional checking, I am seeing the same
behavior withing Sparticus as well.  That is, netmirror.org
is unreachable right now (verified via a web client on three
different networks).  S9Y sits there on the admin screen
while Sparticus is trying to do its thing.  Meanwhile, all
regular client connections block.

It is not a problem with my host not being able to get out.
 I am typing this message from my host.  tcpdump verifies
that the packets are exiting onto the Internet.  I also
can't think of any reason that PEAR may be doing this.

I also don't think that disabling options with external
dependencies is a meaningful solution.  There are all sorts
of things that could disrupt proper functioning of things
like Sparticus or SURBL.  Anything from routing issues on
the Internet to remote server outages on a different
continent.  I don't think that S9Y administrators should
have to constantly monitor the state of Sparticus and/or
SURBL servers just to keep their blog responsive (let alone
permit comments).

The other thing is that this implies that connections that
are just *slow*, not even non-responsive, could slow down
the entire site for all visitors -- even ones that have
nothing to do with the specific operations in quesion.

I also think that better error-handling is called for,
especially for comments.  At minimum, admins should have the
option of letting comments proceed on in the event of a
failure communicating with a remote spam service (in both of
the spam modules).

As a final note -- with the Sparticus testing I've just
done, I've been using a S9Y installation against PostgreSQL
instead of MySQL, so the DB backend doesn't appear to make a
difference.

PS... I flipped the status back to pending since I really
believe this problem isn't closed.  Hope that is OK with
you.  If not, I'll never do that again.

If there's anything I can provide to help track this down,
please let me know.  I'm more than happy to do whatever I
can to help here.

Thanks,

-- John Goerzen

----------------------------------------------------------------------

Comment By: Garvin Hicking (garvinhicking)
Date: 03/28/06 07:17

Message:
Logged In: YES 
user_id=473563

If you get this behaviour, your host does not allow outgoing
directions. IF you installed the spamblock plugin, you might
have enabled the SURBL/RBL blocking options. This means s9y
tries to connect to a SURBL server and if that fails it
times out after about 45 seconds, which is what you're
experience. So either enable outgoing connections or disable
the SURBL checks. Also you usually only get this for
yourself; not the entire host should be blocked, only your
own connections.

The second error goes into the same direction; something on
your host is fishy and you should disable options with
external dependencies.

Regards,
Garvin

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=542822&aid=1460057&group_id=75065


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642