Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"500 read timeout on line 188" XML-RPC error

195 views
Skip to first unread message

John D

unread,
Nov 10, 2009, 4:00:23 AM11/10/09
to
Hi,

I'm unable to get XML-RPC connections going on my setup. Using
bz_webservice_demo.pl, pointing to the uri http://my.bugzillainstall.com/xmlrpc.cgi,
I get

500 read timeout at bz_webservice_demo.pl line 188

whereas pointing to the landfill demo install goes OK. This appears to
be the line that makes the call asking for version information.

Using:
Bugzilla 3.4.2
IIS 6
ActiveState Perl
SOAP::Lite 0.710.08

The Bugzilla installation is one of a few websites hosted on this
machine, differentiated by host header. A check of the IIS log for
this website shows that the http request of xml content was received,
but gave a response code of 502.

Is there some configuration I might be missing? Are there other error
logs I could be checking?

Any insight is greatly appreciated. Cheers!

Max Kanat-Alexander

unread,
Nov 19, 2009, 6:02:38 PM11/19/09
to support-...@lists.mozilla.org
On 11/10/2009 01:00 AM, John D wrote:
> I'm unable to get XML-RPC connections going on my setup. Using
> bz_webservice_demo.pl, pointing to the uri http://my.bugzillainstall.com/xmlrpc.cgi,
> I get
>
> 500 read timeout at bz_webservice_demo.pl line 188

My suspicion is that the IP address that my.bugzillainstall.com points
to cannot be routed to from inside your firewall.

-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

Cheetah

unread,
Dec 9, 2009, 6:01:36 PM12/9/09
to
On Nov 19, 6:02 pm, Max Kanat-Alexander <mka...@bugzilla.org> wrote:
> On 11/10/2009 01:00 AM, John D wrote:
>
> > I'm unable to get XML-RPC connections going on my setup. Using
> > bz_webservice_demo.pl, pointing to the urihttp://my.bugzillainstall.com/xmlrpc.cgi,
> > I get
>
> > 500 readtimeoutat bz_webservice_demo.pl line 188

>
>         My suspicion is that the IP address that my.bugzillainstall.com points
> to cannot be routed to from inside your firewall.

I'm seeing this same kind of error on my setup, with any XML-RPC
client I care to try, including telnet and careful use of a text
editor to craft a request by hand. No matter what I send xmlrpc.cgi,
as long as I have a Content-Length header, xmlrpc.cgi never sends me
back a single byte. Even sending this gets no response:

POST /bugzilla/xmlrpc.cgi HTTP/1.1
Content-Type: text/plain
User-Agent: XML-RPC.NET
Host: softwareserver
Content-Length: 3

bob

When in this non-responsive state, looking at a stack trace for the
perl.exe on the server (using process explorer), it looks like it's
still waiting for more data from the client, as the stack trace has
several Perl...read... methods listed near the top.

I'm using bugzilla 3.4.4 with activeperl 5.8.8 on vista with iis7.
I'd previously been using 3.2.2 when I first saw this, and had hoped
that upgrading bugzilla and the related perl modules would help, but
no such luck :(

Cheetah

unread,
Dec 10, 2009, 1:43:15 PM12/10/09
to
On Dec 9, 6:01 pm, Cheetah <fast...@gmail.com> wrote:
> I'm using bugzilla 3.4.4 with activeperl 5.8.8 on vista with iis7.
> I'd previously been using 3.2.2 when I first saw this, and had hoped
> that upgrading bugzilla and the related perl modules would help, but
> no such luck :(

FWIW, I just purged perl from the system and reinstalled the latest
ActivePerl 5.10.1, and it's still doing the same thing.

Cheetah

unread,
Dec 10, 2009, 2:27:16 PM12/10/09
to

More debugging: using PerlEx30.dll instead of perl.exe seems to make
xmlrpc.cgi work partially (*), but break everything else. It seems
that the fact that PerlEx does the BEGIN block processing before
requests come in prevents all the normal CGI scripts from seeing their
CGI arguments :(

(*) xmlrpc.cgi will do queries, and reports success creating bugs, but
the bugs don't seem to be fully created. xmlrpc.cgi can see the bugs,
but the normal web pages can't. Perhaps database transactions aren't
getting committed due to how PerlEx works? After restarting IIS,
xmlrpc.cgi can't see the bugs either, which points towards the
transaction thing too.

oobi

unread,
Dec 25, 2009, 5:10:30 PM12/25/09
to
Anyone ever find a solution for this? I've been stuck with the same
issue.
Bugzilla 3.4.2 on Perl 5.10.1
Windows 2003 server

Max Kanat-Alexander

unread,
Mar 8, 2010, 10:58:34 PM3/8/10
to support-...@lists.mozilla.org
On 12/10/2009 11:27 AM, Cheetah wrote:
>>> I'm using bugzilla 3.4.4 with activeperl 5.8.8 on vista with iis7.

It's entirely possible that IIS doesn't like requests that don't have
the right Content-Types in the sent data or the returned data.

John D

unread,
Apr 30, 2010, 4:22:45 PM4/30/10
to
>         It's entirely possible that IIS doesn't like requests that don't have
> the right Content-Types in the sent data or the returned data.
>

my guess is that it's closer to this than internal routing, as I can
pull up bugzilla via a browser on the machine it's installed on using
the hostname or ip+port.

a wireshark packet sniff shows that that the POST request of protocol
type HTTP/XML is making it to the server. checking my iis logs, the
request is showing up, but gives a 502 error.

using the iBzilla client:
2010-04-30 19:08:58 W3SVC1843929363 RHSQL 10.1.1.7 POST /xmlrpc.cgi -
80 - 10.1.1.144 HTTP/1.1 wp-iphone/1.6 bugzilla.renkus-heinz.com 502 1
1236

using bz_webservice_demo:
2010-04-30 19:52:24 W3SVC1843929363 RHSQL 10.1.1.7 POST /xmlrpc.cgi -
88 - 10.1.1.7 HTTP/1.1 SOAP::Lite/Perl/0.711 10.1.1.7:88 502 1 64

i've since updated to bugzilla 3.6 and soap-lite 0.711, to no avail.
thanks to anybody for any info in advance.

again, it's:
bugzilla 3.6
iis 6.0
activestate perl
soap-lite 0.711

0 new messages